Обновляем System Center 2012 SP1 Operations Manager до уровня System Center 2012 R2 (в конфигурации Single-server management group)

Продолжая тему обновления линейки продуктов Microsoft System Center (SC) 2012 SP1 до уровня System Center 2012 R2, в этой заметке будет рассмотрена процедура обновления SC 2012 SP1 Operations Manager (SCOM) методом In-place Upgrade. Исходим из условия, что все компоненты SCOM расположены на одном сервере под управлением Windows Server 2012 Standard с использованием для хранения баз данных Operational Database и Data Warehouse Database локально установленного экземпляра SQL Server 2012 SP1 Standard, то есть фактически мы будем обновлять конфигурацию имеющую название Single-server management group

Разумеется данное описание не сможет затронуть всех нюансов перехода на новую версию и ни в коем разе не позиционируется как руководство к действию, а лишь является отражением моего опыта. Поэтому крайне рекомендую перед началом процесса обновления внимательно прочитать публично доступную документацию от Microsoft, как минимум:

• Системные требования, выдвигаемыми новой версией SCOM в документе System Requirements: System Center 2012 R2 Operations Manager
• О нововведениях версии — в документе What's New in System Center 2012 R2 Operations Manager
• Информация о порядке обновления в документе — Upgrading System Center 2012 SP1 - Operations Manager to System Center 2012 R2

Рекомендуемая последовательность шагов по обновлению всех компонент инфраструктуры SCOM следующая:

1. Подготовительные процедуры
2. Последовательное обновление серверов управления (Management Server)
3. Обновление Аудит-коллектора (Audit Collection Service). Выполняется как правило параллельно с обновлением п.2
4. Обновление Шлюзовых серверов управления (Gateway Server)
5. Обновление консолей Operations Console
6. Обновление Агентов SCOM
7. Обновление веб-консоли (Web Console)
8. Обновление сервера отчетов (Reporting Server)
9. Заключительные процедуры

В нашем примере компоненты Management Server, Operations Console, Web Console, Reporting Server на сервере SCOM будут обновлены одновременно.

 

Шаг #1. Подготовительные процедуры

Рекомендации по предварительной подготовке приведены в документе Pre-Upgrade Tasks When Upgrading to System Center 2012 R2 Operations Manager. Пройдёмся по ним применительно к нашей ситуации.

1. Убеждаемся что все сервера в нашей группе управления SCOM соответствуют уровню System Center 2012 SP1 – версии не ниже 7.0.9538

 
2. Перед непосредственным процессом установки обновления выполнить скрипт обслуживания БД OperationsManager (очистка ETL), чтобы в последующем ускорить процесс обновления и избежать таймаутов отработки инсталлятора, особенно это касается БД обслуживающих большое количество агентов. Для того чтобы посчитать какое количество записей подлежащих обработке (удалению) для БД OperationsManager выполним скрипт:

DECLARE @SubscriptionWatermark bigint = 0;

SELECT @SubscriptionWatermark = dbo.fn_GetEntityChangeLogGroomingWatermark();

Select COUNT (*)
FROM EntityTransactionLog ETL with(nolock)
WHERE NOT EXISTS (SELECT 1 FROM EntityChangeLog ECL with(nolock) WHERE ECL.EntityTransactionLogId = ETL.EntityTransactionLogId)
AND NOT EXISTS (SELECT 1 FROM RelatedEntityChangeLog RECL with(nolock) WHERE RECL.EntityTransactionLogId = ETL.EntityTransactionLogId)
AND EntityTransactionLogId < @SubscriptionWatermark;

В нашем случае скрипт вернул значение примерно в 3 тысячи строк.

DECLARE @RowCount int = 1;
DECLARE @BatchSize int = 100000;
DECLARE @SubscriptionWatermark bigint = 0;
DECLARE @LastErr int;

SELECT @SubscriptionWatermark = dbo.fn_GetEntityChangeLogGroomingWatermark();
WHILE(@RowCount > 0)
BEGIN 
DELETE TOP (@BatchSize) ETL
FROM EntityTransactionLog ETL
WHERE NOT EXISTS (SELECT 1 FROM EntityChangeLog ECL WHERE ECL.EntityTransactionLogId = ETL.EntityTransactionLogId)
AND NOT EXISTS (SELECT 1 FROM RelatedEntityChangeLog RECL WHERE RECL.EntityTransactionLogId = ETL.EntityTransactionLogId)
AND ETL.EntityTransactionLogId < @SubscriptionWatermark;

SELECT @LastErr = @@ERROR, @RowCount = @@ROWCOUNT;

END

 

В нашем случае скрипт выполнился за насколько секунд.

3. Убеждаемся в том, что в консоли SCOM (Administration > Device Management > Pending Management) нет клиентов ожидающих принятия подключения к группе управления.

4. Выключаем все действующие подписки на уведомления (Administration > Notifications > Subscriptions). Если подписок немного то можно сделать это в консоли, если же их приличное количество, то выполним их отключение через PowerShell, так как в этом разделе консоли мульти-селект по какой-то непонятной для меня причине не реализован. Через Operations Manager Shell выполним:

Get-SCOMNotificationSubscription | Disable-SCOMNotificationSubscription 

5. Останавливаем службы отвечающие за сторонние коннекторы (Connectors) к SCOM, если такие имеются.

6. Удаляем настроенную интеграцию SCOM в другие продуты System Center, например:

- удаляем интеграцию SCOM в VMM, т.е. удаляем в консоли SCOM пакет VMM Monitoring Pack а также удаляем консоль SCOM с сервера VMM;
- удаляем интеграцию SCOM в Orchestrator, т.е. удаляем в Orchestrator пакет SCOM Integration Pack и консоль SCOM RTM с сервера Orchestrator;
- и т.д.

7. Убеждаемся в том, что наш экземпляр SQL Server готов к процедуре обновления, а именно соблюдены требования:
- Оперативная БД OperationsManager имеет не менее 50% свободного места;
- Лог транзакций оперативной БД имеет размер не менее 50% от размера файла данных.

Для того чтобы получить информацию о текущем состоянии БД можно воспользоваться отчётом в SQL Server Management Studio (Object Explorer > Databases > правой кнопкой мыши на БД OperationsManager > Reports > Standard Reports > Disk Usage)

 Если требуется увеличиваем размер Initial Size в свойствах оперативной БД для файла данных и лога транзакций таким образом чтобы соблюсти требования.

 

8. По традиции перед обновлением выполняем резервное копирование как минимум баз данных OperationsManager и OperationsManagerDW. В документе How to Schedule Backups of System Center 2012 — Operations Manager Databases даны рекомендации также для резервного копирования БД OperationsManagerAC, master, msdb, ReportServer, ReportServerTempDB. Перед выполнением резервного копирования можно остановить службы System Center Data Access Service и System Center Management Configuration

Net stop "OMSDK"
Net Stop "cshost"

Если в вашей группе управления несколько серверов, то остановить эти службы нужно на всех серверах.

Так как БД SCOM в общей сложности могут иметь довольно внушительный размер, выберем самый оперативный способ создания резервной копии – создадим точку восстановления в уже обновлённом SC 2012 R2 Data Protection Manager.

 

После окончания процесса создания резервной копии снова запустим остановленные ранее службы SCOM, а ещё лучше выполнима перезагрузку сервера для их планового автоматического запуска.

 

Шаг #2. Обновляем Management Server

Приступаем к процедуре обновления, руководствуясь в нашей конфигурации документом How to Upgrade a Single-Server Management Group to System Center 2012 R2 Operations Manager

Монтируем образа диска с дистрибутивом SC 2012 R2 OM – файл SW_DVD5_Sys_Ctr_2012_R2_English_OpsMgr_MLF_X19-18307.ISO и с правами Администратора запускаем программу установки Setup.exe. В открывшейся форме выбираем Install

Запустится мастер установки, который определит наличие установленных компонент SC 2012 SP1 Operations Manager и переключится в режим обновления. Нам снова напомнят о необходимости предварительно сделать резервную копию баз данных.

 

На следующем шаге соглашаемся с лицензионным соглашением и переходим к определению каталога установки обновлённой версии SCOM. Каталог установки оставляем предложенный по умолчанию, если нет реальной необходимости его изменить, а также обращаем внимание на требования к свободному месту на диске для успешной установки.

 

После этого будет выполнена проверка на наличие всех требуемых для установки компонент…

 

Затем укажем доменную учетную запись службы конфигурации и подключения к данным, которая используется для работы нашей группы управления на текущий момент…

 

Далее нажимаем кнопку Upgrade и дожидаемся успешного завершения процесса обновления всех установленных компонент.

 

Если в вашей группе управления несколько серверов, то обязательно дожидаемся завершения процедуры обновления первого сервера управления чтобы избежать в дальнейшем проблем с обновлением БД как описано в статье System Center: Operations Manager Engineering Blog — Patience is a virtue with the System Center 2012 Operations Manager SP1 installation. То есть запускать одновременно процедуру обновления на нескольких серверах серверах управления, до тех пор пока первый сервер в группе обновления до конца не обновлён успешно – крайне не рекомендуется.

После завершения программы установки на сервере управления открываем обновлённую версию консоли Operations Console и в разделе консоли Administration > Device Management > Management Servers убеждаемся в том, что для обновлённых серверов отображается версия соответствующая уровню обновления System Center 2012 R2 — 7.1.10226.0

 

 

Шаг #3-4. Обновляем ACS и Gateway Server

Процедуру обновления аудит-коллекторов (ACS) и шлюзов (Gateway) мы пропускаем, так как на текущий момент не имеем данных компонент в своей группе управления SCOM. Информацию по порядку обновления этих компонент можно найти по ссылкам:

• How to Upgrade an ACS Collector to System Center 2012 R2 Operations Manager
• How to Upgrade a Gateway Server to System Center 2012 R2 Operations Manager

<

p align="left"> 

<

p align="left">Шаг #5. Обновляем консоли Operations Console

Переходим к процедуре обновления всех отдельно установленных консолей Operations console, то есть обновляем экземпляры установленных консолей на рабочих станциях администраторов и серверах управления System Center. Минимальные требования System Requirements: System Center 2012 R2 Operations Manager - Operations Console. На моей клиентской Windows 8.1 из перечисленных требований пришлось предварительно установить пакеты:

• Microsoft System CLR Types for SQL Server 2012 из состава Microsoft SQL Server 2012 SP1 Feature Pack (файл для загрузки ENU\x64\SQLSysClrTypes.msi) 
• Microsoft Report Viewer 2012 Redistributable Package (файл ReportViewer.msi)

После этого консоль SCOM была успешно обновлена с установленной ранее версии SC 2012 SP1 до новой версии (предыдущая версия консоли была автоматически удалена)…

Согласно документа How to Upgrade an Operations Console to System Center 2012 R2 Operations Manager процедуру установки можно выполнить в “тихом” режиме командой:

Setup.exe /silent /upgrade /AcceptEndUserLicenseAgreement:1 

При использовании “тихого” режима факт успешной установки/обновления консоли может подтверждать значение ключа реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup
UIVersion = 7.1.10226.0

Позднее, при возможности, мы постараемся опубликовать заметку об автоматизации процесса обновления установленных консолей SCOM с помощью SC 2012 Configuration Manager.

 

Шаг #6. Обновляем Агентов SCOM

Далее согласно документа How to Upgrade an Agent to System Center 2012 R2 Operations Manager переходим к процедуре обновления развернутых Агентов SCOM. В консоли Operations Console в разделе Administration > Device Management > Pending Management выделяем небольшими порциями агентов, находящихся в состоянии Agent Requires Update и одобряем автоматическую  установку обновления – Approve

По завершению отслеживаем состояние версии агентов на закладке Monitoring во вьюшке Operations Manager > Agent Details > Agents By Version. Версия должна быть 7.1.10184.0

Обратите внимание на то, что если на какой-то обновляемой системе одновременно был установлен и агент и консоль SCOM – надо сначала удалить консоль, затем обновить агента, а уже потом установить новую версию консоли.

 

Шаг #7. Обновляем веб-консоль

Далее по плану обновление компоненты веб-консоли SCOM — Web Console согласно документа How to Upgrade a Web Console to System Center 2012 R2 Operations Manager. В нашем случае веб-консоль находится на сервере управления который уже обновлён, и в процессе его обновления так же были обновлены и компоненты веб-консоли. Всё что нам остается сделать – выполнить работоспособность веб-консоли. С рабочей станции Администратора открываем URL веб-консоли в браузере запущенном с правами Администратора, и получив сообщение о необходимости дополнительной настройки – соглашаемся (Configure) и выбрав исполнение запускаемого модуля настройки…

После сообщения об успешной настройке перезапускаем браузер и убеждаемся в работоспособности веб-консоли.

 

Шаг #8. Обновляем сервер отчетов

Далее, согласно документа How to Upgrade Reporting to System Center 2012 - Operations Manager обновляем компоненты отчётов SCOM Reporing server. В нашем случае репортинг находится на сервере управления который уже обновлён, и в процессе его обновления так же были обновлены и компоненты отчётности. Всё что нам надо сделать – проверить работоспособность отчетов на закладке Reporing консоли Operations Console.

 

Шаг #9. Заключительные процедуры

Теперь, после того как все компоненты SCOM обновлены, включаем ранее выключенные подписки на уведомления через Operations Manager Shell

Get-SCOMNotificationSubscription | Enable-SCOMNotificationSubscription

Проверяем в консоли Administration > Notifications > Subscriptions (Enabled = True)

При необходимости выполняем дополнительные процедуры для восстановления интеграции SCOM в другие продукты System Center.

На этом, пожалуй, закончим сжатое описание процедуры обновления имеющейся в нашем примере инфраструктуры Operations Manager до уровня System Center 2012 R2. В одной из последующих заметок мы рассмотрим процедуру миграции описанной конфигурации SCOM на Windows Server 2012 R2, с развёртыванием дополнительного сервера управления, переносом баз данных SCOM на кластерный экземпляр SQL Server и выделением компоненты отчетности Reporing server на отдельный сервер, то есть конфигурацию SCOM из режима Single-server management group преобразуем в режим Distributed Management Group с повышением доступности некоторых компонент.