Этой заметкой мы начнём цикл описаний процедур обновления продуктов линейки System Center 2012 SP1 до уровня System Center 2012 R2, в некоторых случаях с параллельным переходом на новую версию серверной ОС – Windows Server 2012 R2. Чтобы более наглядно увидеть зависимости между основными компонентами System Center можно обратиться к постеру System Center 2012 SP1 Integration Map из комплекта Technical Documentation Download for Technical Scenarios for System Center 2012 SP1, а для того, чтобы понять правильную последовательность обновления продуктов линейки System Center в инфраструктурах, где используется несколько продуктов из этой линейки, обратимся к официальному руководству - TechNet Library - Upgrade Sequencing for System Center 2012 R2.
Рекомендуемый порядок обновления продуктов линейки до уровня System Center 2012 R2 выглядит следующим образом:
1. Service Management Automation
2. Orchestrator
3. Service Manager
4. Data Protection Manager (DPM)
5. Operations Manager
6. Configuration Manager
7. Virtual Machine Manager (VMM)
8. Service Provider Foundation
9. Windows Azure Pack for Windows Server
10. Service Bus Clouds
11. Windows Azure Pack
12. Service Reporting
13. App Controller
Цикл описаний будет затрагивать не все продукты приведённого перечня, а лишь те с которыми у меня есть возможность работать. В этой заметке мы рассмотрим процедуру обновления System Center 2012 SP1 Orchestrator (SCOrch) до уровня System Center 2012 R2.
В нашем примере будет рассматриваться ситуация, когда все компоненты работающего экземпляра SCOrch 2012 SP1 развернуты на одном виртуальном сервере под управлением Windows Server 2012 Standard с использованием БД на удалённом кластеризованном экземпляре SQL Server 2012 Standard.
Для того чтобы понять последовательность действий для обновления SCOrch для начала ознакомимся с документами:
TechNet Library - Upgrading System Center 2012 SP1 Orchestrator to System Center 2012 R2
TechNet Library - Upgrade Sequencing for System Center 2012 R2 > Orchestrator
Кратко о том, что нового, найдём здесь: What's New in System Center 2012 R2 Orchestrator
В частности появилась поддержка Windows Server 2012 R2, разработан новый пакет интеграции System Center Integration Pack (IP) для Microsoft SharePoint и обновлены IP для Windows Azure, Virtual Machine Manager и других продуктов линейки System Center 2012 R2.
В целом вся процедура обновления в нашем примере будет состоять из следующих шагов:
- Резервная копия текущей версии Orchestrator;
- Удаление компонент Orchestrator 2012 SP1 с сохранением БД;
- Переустановка ОС на Windows Server 2012 R2;
- Установка предварительно требуемых программных компонент;
- Установка Orchestrator 2012 R2 с подключением к сохранённой БД;
- Установка пакетов интеграции Orchestrator и проверка работоспособности.
Резервная копия текущей версии Orchestrator
Перед началом обновления читаем документ с рекомендациями по подготовительным действиям
Tasks to Perform Before You Begin the Upgrade
Делаем резервную копию Orchestrator database и виртуальной машины с исполняемыми файлами Orchestrator. Останавливаем все выполняющиеся ранбуки…
В качестве перестраховки, на тот случай, если придётся поднимать Orchestrator с нуля, создадим отдельно копию всех ранбуков, сохранив её на отдельном файловом ресурсе. В консоли выбираем корень дерева навигации Runbooks, далее Меню Actions > Export
Удаление компонент Orchestrator 2012 SP1 с сохранением БД
Удаляем все роли Orchestrator 2012 SP1, при этом экземпляр БД останется нетронутым. Мне не удалось найти информации, о том имеет ли значение порядок удаления в данном случае, но я удалял компоненты по порядку снизу вверх как отображено на скриншоте.
Так как в нашем примере БД Orchestrator находится на отдельном сервере, то нам не нужно предпринимать дополнительных манипуляций по её сохранению для возможности последующего восстановления.
Переустановка ОС на Windows Server 2012 R2
Переустанавливаем ОС на нашем виртуальном сервере на Windows Server 2012 R2. При желании можно поменять сетевые настройки, но вот имя сервера нужно постараться оставить прежним, чтобы избежать ряда проблем, с которыми я столкнулся при первой попытке обновления. В частности, после того как я присвоил серверу новое имя, после установки новой версии SCOrch с подключением к существующей БД в консолях Orchestrator Deployment Manager и Runbook Designer появились фантомные записи о сервере с его прошлым именем, которые никаким штатным способом оттуда не могли быть удалены. В консоли Runbook Designer эта фантомная запись о сервере со старым именем выступала в качестве Primary сервера для выполнения всех ранбуков, а сервер с новым именем выступал в качестве Standby сервера. И если после обновления SCOrch хотя бы можно было переопределить первичный сервер для выполнения ранбуков, то после “чистки” БД методом описанным в System Center Orchestrator Engineering Blog - Removing Inaccessible Computers from Deployment Manager возможность передачи роли первичного сервера вообще перестала работать. Курьёзность ситуации заключается в том, что эта статья написана не где-нибудь, а в блоге команды разработчиков SCOrch, и при этом в указанной статье сказано, что этот метод является официально не поддерживаемым Microsoft и как я смог ощутить несёт по свое сути деструктивные последствия для ещё пока работающей системы. Поэтому вывод из моих тестов напрашивается следующий, – постарайтесь при переустановке не менять имя сервера, а если уж так вышло, что вы его поменяли и нет возможности откатиться назад, не выполняйте никаких псевдо-очисток БД способом по выше-указанной ссылке, ибо фантомные записи о старом имени сервера гораздо меньшее зло, чем неработающий механизм передачи выполнения ранбуков между серверами и прочими неизведанными глюками.
Установка предварительно требуемых программных компонент
Итак, ОС на нашем виртуальном сервере переустановлена и теперь настал черёд установки программных компонент, требуемых для установки SCOrch 2012 R2.
Системные требования описаны в документах:
Single-Computer Requirements for System Center 2012 R2 Orchestrator
Deploying System Center 2012 - Orchestrator - Individual Feature Requirements
Пункт #1. В списке поддерживаемых ОС - установленная на наш виртуальный сервере Windows Server 2012 R2
Пункт #2. В списке поддерживаем БД – используемая в нашем случае Microsoft SQL Server 2012
С одним, незначительным на мой взгляд, отклонением - рекомендуемый порядок сортировки БД Orchestrator (collation) - SQL_Latin1_General_CP1_CI_AS, в то время как в нашем примере используется БД с порядком сортировки Latin1_General_CI_AS_KS_WS, на котором кстати говоря без проблем работала предыдущая версия SCORch 2012 SP1).
Так как в нашем случае используется удалённый экземпляр БД, установим на наш виртуальный сервере клиента SQL Server - свежую версию пакета Microsoft SQL Server 2012 Native Client. Скачать его можно со страницы загрузки Microsoft SQL Server 2012 SP1 Feature Pack (файл ENU\x64\sqlncli.msi)
После установки клиента SQL Server создадим на нашем виртуальном сервере SQL-Alias, который будем в дальнейшем использовать для подключения служб SCOrch к серверу SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (%windir%\system32\cliconfg.exe) и добавим два новых алиаса – с коротким именем SQL-сервера и его FQDN.
Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection
Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.
Пункт #3. Microsoft .NET Framework 3.5 Service Pack 1. Хоть в документации и указано, что эта компонента может быть автоматически до-установлена в систему в процессе установки SCOrch, однако если у нас по какой-то причине доступ в интернет ограничен, то чтобы избежать ошибок во время установки, лучше самостоятельно предварительно установить эту компоненту, например с помощью PowerShell:
Import-Module ServerManager Add-WindowsFeature "NET-Framework-Core" -Restart -Source:"\\FILESERVER\OSInst\WinSrv2012R2\sources\sxs"
Пункт #4. Microsoft .NET Framework 4.5 (в том числе и WCF HTTP Activation). Компоненты NET Framework 4.5 в Windows Server 2012 R2 установлены по умолчанию, а вот с WCF HTTP Activation картина несколько иная…
Доуcтановим данную компоненту с помощью PowerShell:
Import-Module 'ServerManager' Add-WindowsFeature 'NET-WCF-HTTP-Activation45'
Пункт #5. Microsoft Internet Information Services (IIS). Нам потребуется установить компоненты IIS, так как после установки WCF HTTP Activation в системе была включена роль Web Server с неполным набором необходимых для SCOrch компонент IIS. И судя по тому, что пишут о SCOrch 2012 - System Center Orchestrator 2012 Prerequisites and IIS FAQ (#SCORCH, #SYSCTR), инсталлятор SCOrch примитивен в этом плане и проверяет лишь наличие самой роли Web Server, но не проверяет её компоненты если IIS уже был установлен ранее. Не знаю, изменилась ли ситуация в лучшую сторону в SCOrch 2012 R2, но чтобы перестраховаться мы предварительно самостоятельно выполним доустановку всех необходимых компонент IIS с помощью PowerShell:
Import-Module ServerManager Add-WindowsFeature "Web-Static-Content","Web-Default-Doc","Web-Dir-Browsing","Web-Http-Errors","Web-Net-Ext","Web-AppInit","Web-Asp-Net","Web-Asp-Net45","Web-CGI","Web-ISAPI-Ext","Web-ISAPI-Filter","Web-Http-Logging","Web-Log-Libraries","Web-Request-Monitor","Web-Http-Tracing","Web-Windows-Auth","Web-Digest-Auth","Web-Filtering","Web-Stat-Compression","Web-Mgmt-Console"
Пункт #6. Silverlight 4. Он не требуется для работы серверной части - Orchestrator web service, однако если мы хотим чтобы консоль Orchestration console запускалась на сервере, что нам потребуется установить эту компоненту.
Пункт #7. Правила для Windows Firewall. Создадим с помощью PowerShell новые разрешающие правила для входящих подключений на порты (по умолчанию) TCP 81 и 82.
New-NetFirewallRule -DisplayName "System Center 2012 R2 - Orchestrator - REST-based Web Service" -Direction "Inbound" -Protocol "TCP" -Action "Allow" -LocalPort "81" New-NetFirewallRule -DisplayName "System Center 2012 R2 - Orchestrator - Orchestration Console" -Direction "Inbound" -Protocol "TCP" -Action "Allow" -LocalPort "82"
Для корректной работы Monitor Event activities может потребоваться включение встроенных правил Windows Firewall:
- Windows Management Instrumentation (Async-In)
- Windows Management Instrumentation (DCOM-In)
- Windows Management Instrumentation (WMI-In)
Посмотрим текущее состояние этих правил:
Get-NetFirewallRule -DisplayName "*Windows Management Instrumentation*" | Where {$_.Direction -eq "Inbound"} | Select "DisplayName","Name","Enabled" | FT -Auto
Убедившись в том, что указанные правила по умолчанию выключены, включим их:
Enable-NetFirewallRule -Name "WMI-RPCSS-In-TCP","WMI-WINMGMT-In-TCP","WMI-ASYNC-In-TCP"
Если компоненты SCOrch разнесены по разным системам, например Runbook Designer установлен отдельно, то потребуется дополнительная настройка Windows Firewall по документу Troubleshoot Your Orchestrator Installation > Firewall rules between remote computers
Установка Orchestrator 2012 R2 с подключением к сохранённой БД
Монтируем образ SW_DVD5_Sys_Ctr_2012_R2_MultiLang_Orch_MLF_X19-18211.ISO и запускаем с правами Администратора файл SetupOrchestrator.exe. Выбираем Install,
Вводим сведения об организации, ключ продукта.
Включаем полный набор компонент для установки:
- Management Server
- Runbook Server
- Orchestration Console and Web Service
- Runbook Designer
Вводим сведения о доменной учетной записи, от имени которой будут работать процессы Orchestrator (напомню, что учётная запись предварительно уже включена в группу локальных администраторов нового сервера) и нажимаем кнопку для её проверки – Test
Как вы понимаете, в качестве учетной записи мы используем туже самую учетную запись, которая использовалась на сервере SCOrch 2012 SP1, так как именно для неё ранее был настроен доступ на подключение к удалённому экземпляру SQL Server.
Далее вводим имя сервера БД. В нашем случае в качестве имени сервера указывается подготовленный ранее SQL-Alias удалённого экземпляра SQL Server и пытаемся выполнить тестирование соединения – Test Database Connection
В нашем случае попытка оканчивается безуспешно, предположительно по причине того, что инсталлятор перед фактической попыткой подключения к SQL Server пытается проверить его доступность по имени сервера. Создадим соответствующую запись CNAME в DNS для нашего сервера SQL
Убедимся в том что на нашем сервере, где мы выполняем установку SCOrch, соответствующий CNAME успешно разрешается в IP (возможно потребуется очистка кэша локального DNS-клиента командой ipconfig /flushdns) и повторим попытку подключения к SQL Server в мастере установки снова…
На шаге конфигурирования базы данных выбираем совместимый существующий экземпляр БД, который был оставлен нами ранее на этапе удаления SCOrch 2012 SP1 — Orchestrator
Определяемся с группой доступа для пользователей Runbook Designer и Deployment Manager. В нашем случае это та же доменная группа доступа, которую мы ранее использовали на сервере SCOrch 2012 SP1.
Порты без реальных на то причин оставляем в конфигурации по умолчанию…
Каталог установки также оставляем по умолчанию.
Дожидаемся успешного завершения процесса установки.
Если в процессе установки возникли какие-то ошибки, можно обратиться к документу Troubleshoot Your Orchestrator Installation. Кстати в этом документе сказано что лог-файлы, создаваемые в процессе установки расположены в C:\Users\%USERNAME%\AppData\Local\SCO\LOGS, хотя по факту эти файлы я нашёл по другому пути:
C:\Users\%USERNAME%\AppData\Local\Microsoft System Center 2012\Orchestrator\LOGS
Другие лог-файлы создаваемые в процессе эксплуатации SCOrch можно найти в каталоге:
C:\ProgramData\Microsoft System Center 2012\Orchestrator\
Установка пакетов интеграции Orchestrator и проверка работоспособности
После успешного окончания процесса установки открываем консоль Orchestrator Deployment Manager и импортируем (при необходимости) пакеты интеграции:
- System Center 2012 – Orchestrator Component Add-ons and Extensions
(распакуем файл System_Center_2012_Orchestrator_Integration_Packs.EXE — пакеты от RTM версии SCOrch 2012); - System Center 2012 Service Pack 1 — Orchestrator Component Add-ons and Extensions
(распакуем файл System_Center_2012_SP1_Integration_Packs.EXE от версии SCOrch 2012 SP1); - System Center 2012 R2 - Orchestrator Component Add-ons and Extensions
(распакуем файл System_Center_2012_R2_Integration_Packs.EXE от версии SCOrch 2012 R2).
На момент написания этой заметки стали доступны ещё 2 пакета интеграции:
- System Center 2012 R2 Integration Pack for VMware vSphere
- System Center 2012 R2 Integration Pack for HP iLO and OA
Затем в этой же консоли выполняем развёртывание (Deploy IP) этих пакетов, чтобы они стали нам доступны в консоли Runbook Designer
Также на новый сервер не забываем установить все необходимые консоли управления и исполняемые файлы, от которых зависит успешная работа импортированных пакетов интеграции, например для работы пакета интеграции для System Center 2012 Operations Manager потребуется установка соответствующей консоли Operations Console и Operations Manager Shell.
После этого в консоли Runbook Designer в меню Options проверяем работоспособность всех коннекторов, которые мы делали ранее в предыдущей версии SCOrch.
Ну и в конце соответственно проверяем доступность и работоспособность всех настроенных в предыдущей версии SCOrch цепочек Runbook.
Дополнительные источники информации:
RSS - Записи
Добавить комментарий