Переезд на OpsMgr.ru

С сегодняшнего дня записи об Operations Manager будут размещаться на сайте http://opsmgr.ru

Установка кластера RMS в существующую инфраструктуру OpsMgr 2007 R2. Часть 2. Создание кластера и установка OpsMgr.

В предыдущей статье мы рассмотрели перенос на кластер операционной базы данных OpsMgr. В данной статье мы рассмотрим создание кластера для OpsMgr и сам процесс перевода RMS на этот кластер.
Напомню, что OpsMgr для роли RMS требует отдельного кластера, и нельзя в этом же кластере размещать другие сервисы OpsMgr (БД OpsMrg, MS и т.д.)
 
Для поддержки кластера RMS нам потребуются следующие ресурсы:
  • 2 физических сетевых интерфейса в случае, если доступ к СХД будет по FC, и 3 – в случае использования iSCSI
  • 2 диска на СХД – один для диска кворума (а это всё-таки самая желательная конфигурация) и второй для диска OpsMgr
  • минимум 2 IP-адреса и 2 сетевых имени – один для самого кластера, второй для служб OpsMgr
Размер дисков:
  • Диск кворума – 500 Мб (рекомендация MS для всех кластеров)
  • Диск OpsMgr – 3-5 Гб
На всех нодах кластера (я буду рассматривать решение с 2мя нодами) должны быть установлены следующие фичи (Features) из состава Windows Server 2008:
  • .NET Framework 3.0
  • Failover Clustering (также автоматически будут выбраны Failover Clustering Tools)
  • SNMP Services (для мониторинга SNMP-устройств в OpsMgr)
  • Windows PowerShell
В итоге у вас должно получиться вот так (Telnet Client я ставлю на все тестовые сервера, просто на всякий случай):
image
Также все ноды должны иметь одинаковый набор Service Pack и обновлений.
Когда все ресурсы подготовлены, всё требуемое ПО установлено, можно приступать к созданию кластера.
 

Создание кластера

  1. Запускаем на любой ноде консоль “Failover Cluster Management” (Start –> Administrative Tools –> Failover Cluster Management)
  2. В корни консоли вызывает контекстное меню и выбираем пункт Create Cluster, переходим к шагу Select Servers
    image
  3. Добавляем все сервера, которые будут участвовать в нашем кластере. В нашем случае это два сервера: SCOM-CL1 и SCOM-CL2, переходим к шагу Validation Servers
    image
  4. Обязательно выбираем пункт Yes. Это запустит проверку всех параметров кластера на всех нодах. Только когда валидация пройдет успешно на всех нодах можно приступать к созданию кластера. После этого запустится мастер проверки кластера.
    image
  5. Пройдите все шаги мастера проверки. Он должен показать Вам полное отсутствие ошибок и предупреждений.
    image
    image 
  6. После того, как все тесты прошли успешно, можно создавать кластер. На шаге Access Point for administering the Cluster введите имя кластера, по которому вы будете подключаться к этому кластера для управления (это имя только для управления, оно не будет использоваться для доступа к службам, которые будут работать на этом кластере). В нашем примере выбрано имя кластера SCOM-CLUSTER.
    Также на этом шаге Вам возможно, если не используется DHCP, нужно будет указать IP-адрес для управления (также не используется для служб кластера, только для управления). В нашем примере IP-адрес выдается через DHCP.
    image
  7. На шаге Confirmation проверяем все параметры еще раз, и нажимаем Next для создания кластера
    image
  8. Дожидаемся окончание процесса создания кластера, после чего проверяем отчет. Все операции должны завершиться без ошибок и предупреждений.
    image
  9. Созданный кластер сразу добавиться в консоль управления кластера. Следует внимательно проверить все ресурсы кластера (они должны быть доступны), возможно переименовать некоторые из них для удобства (Cluster Disk 1 в Witness Disk, Cluster Network 2 в SAN и т.д.)
  10. Проверить доступность кластера по сети (н-р командой ping scom-cluster)
  11. На этом создание кластера завершено

Внимание! Все последующие действия будут вносить изменения  в конфигурацию OpsMgr, поэтому обязательно сделайте резервные копии всех компонентов OpsMgr согласно документации!

Установка OpsMgr

Для работы в кластере необходимо установить в обычном порядке OpsMgr 2007 R2 на все ноды кластера

  1. Запускаем SetupOM.exe из дистрибутива
  2. В появившемся окне выбираем Check Prerequisites. Выбираем Server и Console, затем нажимаем Check. Все проверки должны пройти успешно. Закрываем программу проверки.
    image
    image
  3. Выбираем пункт Install Operations Manager 2007 R2, который запустит собственно инсталлятор.
  4. При установке надо обратить внимание на этап выбора компонентов – на ноды кластера необходимо установить только Management Server, User Interface и Command Shell
    image
  5. В настройках БД Указываем адрес кластера MSSQL, который мы создали в предыдущей части, и имя базы данных
    image
  6. Укажите Action Account и SDK and Config Service Account. Не забудьте последнюю добавить в группу локальных администраторов на каждой ноде кластера.
  7. Дожидаемся окончания установки.

Восстановление ключа шифрования OpsMgr

После установки OpsMgr 2007 R2 на все ноды кластера, нам необходимо восстановить ключ шифрования, который мы архивировали, когда переносили БД OpsMgr.
Напомню, для архивирования ключа необходимо использовать следующую команду на текущем сервере RMS:
SecureStorageBackup.exe Backup \\server\share\BackupRMSKey.key
 
Для восстановления ключа шифрования на каждой ноде кластера необходимо выполнить следующую команду:
SecureStorageBackup.exe Restore \\server\share\BackupRMSKey.key
 
Обе команды необходимо выполнять с повышенными привилегиями, если включен UAC.
image
 

Создание виртуального сервера в кластере

 
Следующее, что нам нужно сделать, это создать виртуальный сервер для OpsMgr в кластере. Для этого вновь возвращаемся к консоли Failover Cluster Management.
  1. Если вы не хотите давать права учетной записи сервера кластера (в нашем случае это SCOM-CLUSTER) на создание учетных записей компьютеров в домене, Вам необходимо создать в AD учетную запись с именем Вашего будущего RMS (SCOM-CL), и дать на эту учетную запись полные права учетной записи кластера
    image
  2. Подключаемся к нашему кластеру SCOM-CLUSTER, выбираем Service and Applications, вызывает контекстное меню в котором выбираем пункт Configure Service or Application
    image
  3. Выбираем тип сервиса Other Server
    image
  4. Вводим имя данного сервера и, если нет DHCP, IP адрес. Эти имя и IP-адрес и есть те сетевые ресурсы, которые будут использоваться для подключения к будущему RMS. Поэтому подойдите к их выбору внимательно и осознано. В нашем примере используется DHCP, а имя сервера я выбрал SCOM-CL.
    image
  5. Выбираем диск, который будет использовать наш сервер (в нашем случае – диск D)
    image
  6. Проверяем все параметры и создаем новый сервер.
    image
  7. Проверяем, что новый сервер имеет статус Online

Создание сервисов в кластере

После создания виртуального сервера необходимо добавить сервисы. Вновь работает в консоли Failover Cluster Management

  1. У только что созданного сервера вызываем контекстное меню и выбираем пункт Add Resource –> 4 – Generic Service
    image
  2. Выбираем из списка сервис System Center Management, жмем Next для создания кластеризованного сервиса. Созданный сервис будет иметь статус Offline.
    image
  3. Повторяем шаги 1 и 2 для сервисов System Center Management Configuration и System Center Data Access

Повышение виртуального сервера до роли Root Management Server (RMS)

Следующий шаг, в случае возникновения какого-то сбоя, может оказаться самым деструктивным для всей инфраструктуры OpsMgr. Поэтому еще раз убедитесь, что у Вас есть резервная копия, из который Вы сможете восстановить все данные и конфигурации.

Для повышения виртуального сервера служит утилита ManagementServerConfigTool.exe, которая находится на диске с дистрибутивом OpsMgr 2007 R2 в папке SupportTools\amd64 или SupportTools\i386, в зависимости от платформы. Данную утилиту необходимо скопировать на ту ноду, которая является текущим владельцем для виртуального сервера SCOM-CL в папку с установленным OpsMgr 2007 (по умолчанию — c:\Program Files\System Center Operations Manager 2007\).

Для повышения виртуального сервера утилиту  ManagementServerConfigTool.exe необходимо запустить со следующими ключами:
ManagementServerConfigTool.exe InstallCluster /vs:%VIRT_SERVERNAME% /disk:%DISK_LATER%
где
%VIRT_SERVERNAME% – имя виртуального сервера для OpsMgr (нашем случае SCOM-CL)
%DISK_LATER% – буква диска, который добавлен к виртуальному серверу OpsMgr (в нашем случае D)
 
Таким образом полностью команда будет выглядеть вот так:
ManagementServerConfigTool.exe InstallCluster /vs:SCOM-CL /disk:D
 
Запускаем утилиту, подтверждаем наше желание установить новый RMS, после чего ожидаем окончания операции
image
В случае, если все операции пройдут успешно, Вы должны увидеть следующее сообщение:
image
 
В итоге мы получим следующее:
  • Старый RMS будет понижен до уровня рядового Management Server
  • На старом RMS службы System Center Management Configuration и System Center Data Access будут отключены (Disabled)
  • На обоих нодах кластера все службы, относящиеся к OpsMgr, будут установлены в режим запуска Manual

Регистрация SPN-записей

Для своей работы OpsMgr требует наличия нескольких SPN-записей для учетных записей серверов и учетной записи SDK and Config Service, В случае, когда RMS находится на обычном сервере, эти записи регистрируются автоматически. В случае же с кластером, нам придется зарегестрировать эти записи вручную.
Для работы RMS на кластере требуются следующие SPN-записи (источник):
  1. Для учетной записи виртуального сервера RMS (SCOM-CL):
    1. MSOMHSvc/scom-cl.domain.local
    2. MSOMHSvc/scom-cl
  2. Для учетной записи SDK and Config Service необходимы записи каждой ноды кластера
    1. MSOMSdkSvc/scom-cl1
    2. MSOMSdkSvc/scom-cl1.domain.local
    3. MSOMSdkSvc/scom-cl2
    4. MSOMSdkSvc/scom-cl1.domain.local
Кроме этого, нем необходимо удалить старые записи RMS-сервера.
В данный момент вызов команды setspn –L DOMAIN\OpsMgrSDKConfig (DOMAIN\OpsMgrSDKConfig – учетная запись SDK and Config Service) должен возвращать следующее:
MSOMSdkSvc/SCOM-ROOT
MSOMSdkSvc/SCOM-ROOT.domain.local
где SCOM-ROOT – имя старого RMS-сервера.
Обе эти записи необходимо удалить.
 
Нам необходимо выполнить следующие команды:
  1. setspn –D DOMAIN\OpsMgrSDKConfig MSOMSdkSvc/SCOM-ROOT
  2. setspn –D DOMAIN\OpsMgrSDKConfig MSOMSdkSvc/SCOM-ROOT.domain.local
  3. setspn –A DOMAIN\SCOM-CL$ MSOMHSvc/scom-cl.domain.local
  4. setspn –A DOMAIN\SCOM-CL$ MSOMHSvc/scom-cl
  5. setspn –A DOMAIN\OpsMgrSDKConfig MSOMSdkSvc/scom-cl1
  6. setspn –A DOMAIN\OpsMgrSDKConfig MSOMSdkSvc/scom-cl1.domain.local
  7. setspn –A DOMAIN\OpsMgrSDKConfig MSOMSdkSvc/scom-cl2
  8. setspn –A DOMAIN\OpsMgrSDKConfig MSOMSdkSvc/scom-cl2.domain.local

Запуск нового RMS

 
После регистрации SPN-записей можно запускать кластеризаонные службы RMS
  1. Открываем консоль Failover Cluster Management
  2. Заходим в наш виртуальный сервер
  3. Выбираем каждый из трех сервисов и включаем их (Bring online)
    image
  4. Проверяем, что все сервисы благополучно запустились

После этого запускаем консоль OpsMgr и подключаемся к новому RMS по адресу SCOM-CL. Проверяем работоспособность.

Настройка Reporting Services для OpsMgr

В случае, если новый RMS на кластере работает корректно, необходимо также перенастроить службы отчетности (Reporting Services). Это необходимо сделать, т.к. файлы конфигурации Repoting Services хранят в себе ссылки на RMS.
  1. Запускаем диспетчер IIS на сервере, где расположены Reporting Services
  2. Открываем приложение ReportServer, вызываем контекстное меню и выбираем пункт Explorer (Проводник)
    image
  3. Находим файл rsreportserver.config, делаем его копию, затем открываем в любом текстовом редаторе (не забываем, что текстовый редактор надо запускать с повышенными привилегиями, если включен UAC).
  4. Находим поиском все теги <ServerName>, и меняем их значение со старого RMS на новый (соответственно <ServerName>scom-root.domain.local</ServerName> на <ServerName>scom-cl.domain.local</ServerName>). Всего должно быть две замены.
  5. Запускаем редактор реестра. Переходим к узлу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting на этом же сервере. Делаем экспорт этого узла.
  6. Заменяем значение параметра DefaultSDKServiceMachine со старого RMS на новый.
  7. Проверяем работу отчетов OpsMgr

Действия после установки кластера

После окончания всех действий и проверок, Вам необходимо будет:

  • Перераспределить клиентов между management-серверами OpsMgr
  • Доустановить дополнительное ПО на каждую ноду кластера, если такое умеется
  • Разрешить на всех SNMP-устройствах доступ с нового RMS
  • Удалить старый RMS, если он не нужен как рядовой management-сервер

Полезные ссылки

 

Обновления MP для AD и Exchange 2007

Последние несколько дней получились жаркими для администраторов opsMgr. Вышли сразу несколько крупных обновлений, не последними в этом списке стоят MP для Active Directory и для Exchange 2003/2007
 
Основным (и собственно единственным) нововведением в MP для Active Directory является полная поддержка Windows Server 2008 R2 и Windows 7:
  • Support for monitoring Windows Server® 2008 R2 server operating systems as well as Windows® 7 client operating systems
  • Support for monitoring the Active Directory Web Service (ADWS) in Windows Server 2008 R2 as well as the Active Directory Management Gateway Service in Windows Server 2008 and Windows Server 2003

В MP для Exchange 2007 исправлены некоторые ошибки.


Добавлено
Собственно, не обошлось без правила "исправили старые баги и добавили чуть-чуть новых". В MP для Active Directory присутствует баг:
Правило "AD Processor Overload (lsass) Monitor" с Target "Active Directory Domain Controller Server 2003 Computer Role" выполняет скрипт AD_LSASS_CPU.vbs
Скрипт пытается выполинть код:
Set colProcessors = oWMI.ExecQuery("Select NumberOfCores from Win32_Processor")
Однако свойство NumberOfCores под Windows 2003 не поддерживается
Временное решение — отключить этот монитор.
 
Спасибо Александру за то, что обратил внимание на этот баг.
 

Добавлено 16.10.2009
На 12:00 ссылка на закачку MP для Active Directory убрана из каталога и с сайта download.microsoft.com
 

Добавлено 05.11.2009
MP для Active Directory за версией 6.0.7065.0 вновь добавлен в каталог
 
Ошибка со скриптом исправлена

Обновления кросс-платформенных компонентов в OpsMgr 2007 R2

Вышел хот-фикс KB973583 для Operations Manager 2007 R2 Cross Platform. Основные изменения:
  • Monitoring of SUSE Linux Enterprise Server 11 servers (both 32-bit and 64-bit versions)
  • Support of Solaris Zones
  • Fix for defunct Process issue
  • The Cross Platform Agent may not discover soft partitions on Solaris systems. Therefore, the disk provider may be unloaded, and the Cross Platform Agent may stop collecting information from the system disks.
  • The Cross Platform Agent may not restart after the AIX server reboots
  • Маленький хинт. Уставнока состоит из 2х частей — сначала запускается скачаный MSI-пакет, который разархивирует MSP-пакет и инсталятор (причем последние два — x86, соответственно скопируются в папку C:\Program Files (x86)) и запускает установку собственно апдейта.

    Так вот если вы запустите MSI-пакет в Windows Server 2008 с включенным UAC без повышения привелегий, то апдейт разархивируется, но не запуститься. При попытке запустить руками "C:\Program Files (x86)\System Center 2007 Hotfix Utility\SetupUpdateOM.exe" вы получите ошибку: "Software update failled, either patch file is not provided ot it does not exists".

    Решение: запускать cmd с повышенными привелегиями (пунтк Run as administrator…) и уже из командной строки запустить SystemCenterOperationsManager2007-R2-KB973583-X64-ENU.MSI. Об этом честно написано в Readme, но увидите вы его только после запуска MSI-пакета :)

    Ссылка на апдейт: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4a41a8be-0a37-4bd2-b5b1-026468b317fb

    Обновились Operations Manager 2007 R2 Management Pack

    На выходных вышла версия 6.1.7533.0. Немного косметических изменений, плюс мелкие исправления:

    Version 6.1.7533.0 of the Operations Manager Management Pack for Operations Manager 2007 R2 includes the following changes:

    ·      Changed the time-out value to 1 minute for recovery tasks associated with the following monitors:

    ·      Health Service Handle Count Threshold

    ·      Health Service Private Bytes Threshold

    ·      Monitoring Host Handle Count Threshold

    ·      Monitoring Host Private Bytes Threshold

    ·      Changed the threshold values for the Health Service Handle Count Thresholds and Monitoring Host Handle Count Thresholds monitors to 10,000 on management servers and 6,000 on agents.

    ·      Changed the threshold values for the Health Service Private Bytes Threshold and Monitoring Host Private Bytes Threshold monitors to 1500 MB on management servers and 300 MB on agents.

    ·      Updated the layout and default filters and sort order for a number of views.

    ·      Fixed an issue that was previously preventing all rules related to agentless exception monitoring from generating alerts.

    ·      Added display names, descriptions, and product knowledge where missing.

    ·      Added the rule “Collects Opsmgr SDK Service\Client Connections” to collect the number of connected clients for a given management group.  This data is shown in the view “Console and SDK Connection Count” under the folder “Operations Manager\Management Server Performance”.

    ·      Updated a number of monitors and rules to ensure that data is reported to the correct management group for multihomed agents.

    ·      The following rules and monitors are now disabled by default as they are generally not actionable:

    ·      A GroupPopulator module unloaded due to an unrecoverable error

    ·      Health Service Cannot Find Management Group

    ·      Data Validity Check

    ·      Root Connector Data Validity Check

    ·      Added event collection rule for events 5400, 5401, 5402, 5404 5405, and 5500.

    ·      Updated the alert suppression criteria for the rule “Alert on Dropped MultiInstance Performance Module” in order to significantly reduce the alert volumes generated by this rule and make it easier to identify the root cause.

    ·      The monitors listed below have been updated so that the value of the sample must exceed the threshold for a specific number of consecutive samples, as opposed to the average of the samples over the consecutive samples.  This will increase the accuracy of the monitors by handling periodic spikes in resource utilization better:

    ·      Health Service Handle Count Threshold

    ·      Health Service Private Bytes Threshold

    ·      Monitoring Host Handle Count Threshold

    ·      Monitoring Host Private Bytes Threshold

    ·      Updated the knowledge for the rule “Data Access Service Spn Registration” significantly.

    ·              Fixed the configuration of the rule “IIS Discovery Probe Module Execution Failure” to so that the parameter replacement will now work correctly for alert suppression and generating the details of the alert’s description.
     

    Установка кластера RMS в существующую инфраструктуру OpsMgr 2007 R2. Часть 1. Перенос базы OperationDB.

    У всех со временем приходит понимание, что система мониторинга – ключевой компонент ИТ-инфраструктуры, в особенности крупной. И этот компонент, как никакой другой, требует 100% доступности. В связи с этим многие задаются вопросом – можно ли создать кластер на базе OpsMgr 2007 в уже существующей инфраструктуре? До появления версии R2 ответ на этот вопрос был “нет” (официально). В версии R2 инструменту ManagementServerConfigTool была добавлена поддержка установки кластера RMS в существующей инфраструктуре. Поддерживаемые схемы апгрейда вы можете найти здесь. Если очень кратко – поддерживается лишь один сценарий, при котором у вас есть сервер RMS, вы настраиваете новый кластер OpsMgr 2007 R2, повышаете его до кластера RMS, при этом старый RMS становится обычным MS (managment server).

    Кроме этого, часто вместе с установкой кластера RMS, приходится и переносить базу данных OpsMgr, н-р на кластер MS SQL , ведь как-то не логично оставлять точку отказа в виде БД. Нахождение базы данных OpsMgr и RMS в одном кластере не поддерживается.

    В данной статье мы рассмотрим полный цикл перевода нашей инфраструктуры RMS OpsMgr 2007 R2 на кластер (кроме отчетности, которую в принципе невозможно перевести на кластер).

    Принятые сокращения:

    RMS Root Managment server
    MS рядовой Managment Server
    OperationsDB База данных OpsMgr 2007 R2
    OperationsDW База данных Datawarehouse
       
       

    Текущее состояние будет следующим:

    Сервер Описание ОС SQL Примечание
    SCOM-ROOT
    • RMS
    • Web-консоль
    Windows server 2008 STD ENG

     
    SCOM-DB

    Сервер БД, на нем расположены:

    • OperstionsDB, DW
    • БД репортинга
    • сам репортинг
    Windows server 2008 STD ENG MS SQL 2005 STD ENG  
    SCOM-ACS Рядовой MS, который также служит коллектором для службы ACS Windows server 2008 STD ENG

    Не будет переноситься на кластер
    SCOM-ACS-DB Сервер БД для службы ACS Windows server 2008 STD ENG MS SQL 2005 STD ENG Не будет переноситься на кластер
    MSDB-CL1* Сервер БД, нода кластера MS SQL Windows Server 2008 ENT ENG MS SQL 2005 STD ENG Имя кластера – MSDB-CL
    MSDB-CL2* Сервер БД, нода кластера MS SQL Windows Server 2008 ENT ENG MS SQL 2005 STD ENG Имя кластера – MSDB-CL

    * – предполагается, что кластер MS SQL у Вас уже есть, но OpsMgr 2007 его не использует.

    После перехода мы получим следующую картину:

    Сервер Описание ОС SQL Примечание
    MSDB-Cl1

    Сервер БД, нода кластера MS SQL

    • OperationsDB
    Windows Server 2008 ENT ENG MS SQL 2005 STD ENG Имя кластера – MSDB-CL
    MSDB-CL2

    Сервер БД, нода кластера MS SQL

    • OperationsDB
    Windows Server 2008 ENT ENG MS SQL 2005 STD ENG Имя кластера – MSDB-CL
    SCOM-CL1 Нода кластера RMS Windows Server 2008 ENT ENG    
    SCOM-CL2 Нода кластера RMS Windows Server 2008 ENT ENG    
    SCOM-ROOT
    • MS
    • Web-консоль
    Windows server 2008 STD ENG

     
    SCOM-DB

    Сервер БД:

    • DW 
    • БД репортинга
    • сам репортинг
    Windows server 2008 STD ENG MS SQL 2005 STD ENG  
    SCOM-ACS Рядовой MS, который также служит коллектором для службы ACS Windows server 2008 STD ENG

    Не будет переноситься на кластер
    SCOM-ACS-DB Сервер БД для службы ACS Windows server 2008 STD ENG MS SQL 2005 STD ENG Не будет переноситься на кластер

     

    Список официальной (и не очень) документации, используемой в процессе перехода, будет представлен в конце статьи.

    Общий план работ следующий:

    1. Перенести OperationsDB на кластер MSSQL
    2. Создать две ноды кластера для RMS (два сервера под управлением Windows Server 2008 ENT)
    3. Установить OpsMgr 2007 на каждую ноду нового кластера
    4. Восстановить ключ шифрования на каждой ноде кластера
    5. Создать ресурсы кластера для всех служб OpsMgr 2007
    6. Повысить новый кластер OpsMgr 2007 до RMS

    Практически перед каждым этапом необходимо будет делать резервную копию OperationsDB.

    Этап I. Перенос OperationsDB на кластер MSSQL

    Как было сказано выше, подразумевается, что кластер MS SQL уже есть, и нам лишь надо перенести БД на этот сервер. В случае, если кластера у вас нет, в Сети есть масса статей по его установке и настройке (н-р вот такой веб-каст).

    Процедура переноса OperationsDB подробно описана в статье How to Move the OperationsManager Database in Operations Manager 2007, поэтому в данной статье я не буду подробно описывать все шаги, а лишь ссылаться на шаги из руководства, применимо к нашей инфраструктуре.

    Перед тем, как начать мигрировать базу данных, следует обратить внимание на следующие моменты:

    • Во время миграции ВСЯ инфраструктура OpsMgr 2007 R2 будет недоступна. Т.е. во время переноса мониторинг работать не будет.
    • Перенос базы по сценарию Attach-Detach не поддерживается. Обязательно надо выполнить Backup-Restore.
    • Во время миграции Вам понадобится информация об учетных записях, под которыми стартуют службы OpsMgr 2007.
    • Протоколируйте все действия (остановка служб, изменения в реестр, резервное копирование). Данная информация будет крайне полезна, если вдруг что-то пойдет не так. Подойдут любые средства – блокнот, запись видео, скриншоты.

    Итак, приступим.

    1. Установка и настройка MSSQL. У нас он уже есть, так что сразу переходим в шагу 2.
    2. Создаем:
      • полный бакап всех баз данных на SCOM-DB (в том числе и системных) любыми доступными средствами.
      • бакап ключа шифрования (команда SecureStorageBackup.exe Backup disk:\path\BackupRMSKey.key на сервере SCOM-ROOT), не забудьте запомнить пароль.
    3. Остановить все службы OpsMgr 2007 R2 на всех MS (в том числе и на RMS). В нашем случае это SCOM-ROOT и SCOM-ACS.
      • System Center Data Access (OMSDK) – SCOM-ROOT, запущен от имени учетной записи SDK
      • System Center Management (HealthService) – SCOM-ROOT, SCOM-ACS, запущен от имени локальной учетной записи System
      • System Center Management Configuration (OMCFG) – SCOM-ROOT, запущен от имени учетной записи SDK
    4. Удалить компоненты базы данных OpsMgr 2007 с сервера SCOM-DB.
    5. Удалить базу данных.
    6. Восстановить базу данных OperationsDB на кластере MSDB-CL любыми доступными средствами. До восстановления лучше выполнить пункты 9 – 11 (добавить только аккаунты, без назначения прав), т.к. это избавит от возможных проблем при добавлении аккаунтов после восстановления.
    7. Отредактировать реестр на серверах SCOM-ROOT и SCOM-ACS, значение HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Setup\@DatabaseServerName изменить с SCOM-DB на MSDB-CL. После этого надо запустить все остановленные на шаге 3 службы OpsMgr 2007 R2.
    8. Отредактировать БД OperationsDB, в таблице dbo.MT_ManagmentGroup поменять имя сервера БД на MSDB-CL согласно мануалу.
    9. Добавить разрешения на базу данных для учетной записи SDK
    10. Добавить разрешения на базу данных для учетной записи Action
    11. Добавить разрешения на базу данных для учетной записи Data Warehouse Action (он же DW Data Writer)
    12. Проверить состояние брокера, и если надо – установить его в нужное состояние
    13. Перезапустить все службы OpsMgr 2007 R2 на серверах SCOM-ROOT и SCOM-ACS.
    14. Проверить работоспособность OpsMgr 2007 R2

    Т.к. служб несколько, для удобства можно создать сценарий для остановки и запуска всех служб:

    @echo off
    echo Stop "System Center Data Access" on SCOM-ROOT…
    sc \\SCOM-ROOT stop OMSDK
    echo Stop "System Center Management Configuration" on SCOM-ROOT…
    sc \\SCOM-ROOT stop OMCFG
    echo Stop "System Center Management" on SCOM-ROOT…
    sc \\SCOM-ROOT stop HealthService
    echo Stop "System Center Management" on SCOM-ACS…
    sc \\SCOM-ACS stop HealthService

     

    @echo off
    echo Start "System Center Data Access" on SCOM-ROOT…
    sc \\SCOM-ROOT start OMSDK
    echo Start "System Center Management Configuration" on SCOM-ROOT…
    sc \\SCOM-ROOT start OMCFG
    echo Start "System Center Management" on SCOM-ROOT…
    sc \\SCOM-ROOT start HealthService
    echo Start "System Center Management" on SCOM-ACS…
    sc \\SCOM-ACS start HealthService

    Пару слов стоит сказать о шаге 6. В случае, если Вы сначала восстановите базу данных, а затем начнете добавлять логины (шаги 9 — 11), Вы получите ошибку “данный пользователь уже существует в базе данных”, но при этом логин получит верные права в базе данных. Если же Вы добавите логины, а затем восстановите БД, связывание пользователя и логина произойдет в момент восстановления автоматически.

    На этом первый этап завершен.

    Создание самого кластера будет описано чуть позже.

    Список литературы

    Operations Manager 2007 R2 Supported Configurations

    OpsMgr 2007: How to install and configure an RMS on a Windows Server 2008 cluster

    New R2 Deployment Complex Scenarios (Adding Clustered RMS and Upgrading to SQL 2008)

    Ошибка при создании Service Level Tracking

    При попытке создать объект Service Level Tracking в OpsMgr R2 вы можете получить “информативную” ошибку после нажатия кнопки Finish:

    The client has been disconnected from the server. Please call ManagementGroup.Reconnect() to reestablish the connection

    image

    Такая ошибка может появится в том случае, если в одном из SLO стоит не целое значение в поле Goal, н-р 99,999%. Несмотря на наличие 3х знаков после запятой, допускается использовать только целые значения.

     

    Временное решение: для учетной записи OpsMgr SDK Config изменить локаль на Английскую (США) или просто сделать разделителем целой и дробной части точку (.) В этом случае SLO сохраняется корректно. Очередной "превед" программистам.

    ЗЫ. Алексей, всё-таки я считаю это просто пренебрежением к конечному пользователю. Такие ошибки есть ни что иное, как расхлябанность.