Обновляем System Center 2012 SP1 Virtual Machine Manager до уровня System Center 2012 R2 на Windows Server 2012 R2 и SQL Server 2012 SP1 с параллельным переходом в режим Highly Available

Завершая тему обновления линейки продуктов Microsoft System Center (SC) 2012 SP1 до уровня System Center 2012 R2, в этой заметке будет рассмотрена процедура обновления SC 2012 SP1 Virtual Machine Manager (VMM). В нашем примере исходный экземпляр VMM Management Server расположен на одном виртуальном сервере под управлением Windows Server 2012 Standard с использованием для хранения базы данных VirtualManagerDB удалённого кластеризованного экземпляра SQL Server 2012 SP1

Рассмотрим процесс обновления существующего экземпляра SC 2012 SP1 VMM до уровня System Center 2012 R2 с параллельным внедрением конфигурации повышенной доступности с использованием двух серверов управления на базе службы кластеризации Windows Server 2012 R2 Standard. В качестве исходных условий принимается то, что БД VMM уже расположена на выделенном кластеризованном экземпляре SQL Server 2012 SP1, а в качестве VMM Library используется отдельный файловый кластер, таким образом, в нашей конфигурации на текущий момент роль VMM Management Server является узким местом - возможной точкой отказа. В ходе дальнейшего описания рассмотрим процесс кластеризации обозначенной роли, чтобы в конечном итоге получить схему инфраструктуры VMM, в которой все основные компоненты выполняются в режиме повышенной доступности - Highly Available

Рассмотрим процесс создания двух-узлового кластера Failover Cluster на базе Windows Server 2012 R2 Standard, который в нашем примере будет иметь следующую конфигурацию. 

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

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

В нашем случае в VMM не используются хосты виртуализации VMware и не используются механизмы Performance and Resource Optimization (PRO). В случае использование этих вещей перед обновлением стоит ознакомится с дополнительными подготовительными процедурами согласно Planning Considerations for Upgrading VMM

Как и ранее, для обновления VMM до уровня System Center 2012 R2 не поддерживается сценарий In-Place Upgrade, то есть фактически требуется переустановка VMM с сохранением БД.

Реализация поставленных задач в нашем случае будет выполнятся по следующему плану:

1. Удаляем VMM с сохранением БД VirtualManagerDB
- Выполняем резервную копию БД
- Удаляем ранее установленные Update Rollup
- Удаляем SC 2012 SP1 VMM
2. Подготавливаем инфраструктуру для создания кластера VMM
- Создаем учетные записи для Cluster Name Objects
- Подготавливаем домен для механизма Distributed Key Management
3. Разворачиваем первый сервер
- Переустанавливаем ОС на Windows Server 2012 R2
- Настраиваем сетевые параметры
- Включаем поддержку Failover Clustering и создаём кластер
- Устанавливаем дополнительные требуемые для VMM компоненты.
- Устанавливаем SC 2012 R2 VMM в режиме восстановления БД
4. Разворачиваем второй сервер VMM
- Устанавливаем ОС Windows Server 2012 R2
- Настраиваем сетевые параметры
- Устанавливаем дополнительные требуемые для VMM компоненты.
- Включаем поддержку Failover Clustering и добавляем узел в существующий кластер
- Устанавливаем SC 2012 R2 VMM в режиме подключения к кластерной службе VMM
5. Проверяем работу кластера VMM
6. Удаляем устаревшую информацию о Library Server
7. Обновляем агентов и отдельно установленные консоли VMM

 

1. Удаляем VMM с сохранением БД VirtualManagerDB

Выполняем резервную копию БД

Для начала, на текущем сервере VMM мы должны убедиться в том, что отсутствуют выполняющиеся задачи в рабочей области Задания, после чего, по правильной традиции, в отдельное надёжное место создадим резервную копию базы данных VMM. Сделать это можно разными способами, но предпочтительный – с помощью консоли VMM (Параметры > Резервное копирование). Укажем каталог в который будет сохранена резервная копия и запустим процедуру.

Обратите внимание на то, что на сетевую папку, которую мы будем использовать в качестве места назначения для сохранения резервной копии БД, для учетной записи, от имени которой выполняется SQL Server, предварительно должно быть предоставлено право на запись.

Отследить состояние задачи резервного копирования можно в рабочей области консоли VMM - Задания.

 

Удаляем ранее установленные Update Rollup

С помощью оснастки установки и удаления программ удаляем все кумулятивные обновления установленные после SP1. В нашем примере это Update Rollup 3

Я удалил оба обновления – и для сервера и для консоли VMM, правда при удалении консоли система потребовала доступ к оригинальному файлу AdminConsole.msi из состава инсталлятора SC 2012 SP1 VMM

По завершению удаления Update Rollup потребуется перезагрузка системы, после чего мы возвращаемся в оснастку установки и удаления программ и выполняем удаление VMM.

Если перед удалением VMM предварительно не удалить Update Rollup, то попытка удаления VMM может завершиться ошибкой, описание которой мягко говоря может поставить в тупик..

You cannot upgrade from the currently installed version of VMM to System Center 2012 SP1 – Virtual Machine Manager. You must first uninstall VMM, and then install System Center 2012 SP1. If you are running System Center 2012, when you uninstall VMM, you can retain the database. When you install System Center 2012 SP1, use the retained database

 

Удаляем SC 2012 SP1 VMM

В мастере установки/удаления компонент VMM выбираем режим удаления – Remove features

Затем выбираем компоненты VMM которые мы хотим удалить – отмечаем все.

На следующем шаге выбираем режим сохранения БД – Retain database.

Дожидаемся окончания процесса удаления.

Таким образом, на нашем удалённом кластеризованном экземпляре SQL Server останется БД VMM соответствующая уровню System Center 2012 SP1, к которой в дальнейшем мы и будем подключаться в процессе установки SC 2012 R2 VMM.

 

2. Подготавливаем инфраструктуру для создания кластера VMM

Создаем учетные записи для Cluster Name Objects

В отдельном OU в домене создадим две учетные записи компьютеров. Они потребуются нам в дальнейшем для создания кластера VMM – эти учетные записи будут использоваться в качестве Cluster Name Objects (CNO). После создания учетных записей нам необходимо будет их выключить, чтобы служба кластеризации смогла их использовать. В нашем примере учетная запись KOM-AD01-SCVMFC создается для экземпляра кластера Failover Cluster, а учетная запись KOM-AD01-SCVMCL – для кластеризованной службы VMM Management Server, которая будет работать на базе кластера KOM-AD01-SCVMFC.

В свойствах безопасности учетной записи KOM-AD01-SCVMCL добавляем полные разрешения для учетной записи KOM-AD01-SCVMFC чтобы служба кластера могла беспрепятственно сконфигурировать CNO службы VMM. Доступ дадим как на сам объект так и на его дочерние объекты.

 

Подготавливаем домен для механизма Distributed Key Management (DKM)

Согласно документа Configuring Distributed Key Management in VMM нам необходимо создать специальный контейнер в домене для хранения данных механизма DKM. Сделаем это с помощью оснастки adsiedit.msc. Подключившись к доменному Контексту именования по умолчанию перейдём к тому OU внутри которого мы желаем создать контейнер, выберем меню Создать > Объект

 

В качестве класса создаваемого объекта укажем container и затем укажем имя создаваемого контейнера так чтобы оно говорило само за себя..

В нашем примере создан контейнер
CN=System Center VMM DKM,OU=Service Objects,OU=KOM-AD01,OU=KOM,DC=holding,DC=com

Откроем свойства безопасности созданного контейнера и дадим полный доступ доменной учетной записи от имени которой у нас работала ранее и будет работать в дальнейшем служба VMM (в нашем случае это учетная запись KOM\s-SCVMMSvc). Доступ дадим как на сам объект так и на его дочерние объекты.

 

Обратите внимание на то, что у учетной записи от имени которой в дальнейшем будет выполняться установка VMM с использованием созданного контейнера DKM также должны быть полные права на созданный контейнер.

 

3. Разворачиваем первый сервер VMM.

Переустанавливаем ОС на Windows Server 2012 R2.

Переустанавливаем ОС на нашем виртуальном сервере на Windows Server 2012 R2 Standard, при этом для установленной системы присваиваем тоже имя сервера что было ранее.

Настраиваем сетевые параметры

Так как наш сервер будет участником кластера Windows Failover Cluster, настроим в нём два сетевых интерфейса. Назовём их NIC1 – Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере (обмен служебными меж-узловыми кластерными данными) .

Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections). NIC1 должен иметь приоритет над NIC2, то есть в списке подключений должен стоять первым.

Интерфейс NIC1 настроим обычным образом, задав ему IP адрес (согласно нашей схемы), маску подсети, IP адрес шлюза, адреса DNS серверов. Несколько иначе будет настроен интерфейс NIC2.

В свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP. В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети. Кластерная подсеть должна отличаться от от подсети интерфейса NIC1, иначе в дальнейшем при создании кластера могут возникнуть проблемы с автоматическим созданием кластерных сетей. Также нужно понимать, что так как мы не указываем на этом интерфейсе адрес шлюза, все сервера будущего кластера должны находиться в одном физическом сегменте сети.

Здесь же, по кнопке Advanced откроем окно дополнительных настроек TCP/IP, где на закладке DNS отключим опцию регистрации этого подключения в DNS – Register this connection’s addresses in DNS

В дальнейшем, по аналогии, указанные настройки сетевых интерфейсов нужно выполнить на втором сервере который мы будем включать в кластер VMM.

Далее вводим сервер в домен и устанавливаем все доступные обновления Windows Update

Включаем в группу локальных Администраторов доменную сервисную учетную запись пользователя, от имени которого будет работать служба VMM (в нашем примере это учетная запись KOM\s-SCVMMSvc). Учетную запись службы VMM желательно оставить ту же, что использовалась ранее, если мы не хотим потерять данные о сохранённых в VMM паролях. Возможные последствия при выборе другой учетной записи описаны в документе Choosing Service Account and Distributed Key Management Settings During an Upgrade

 

Включаем поддержку Failover Clustering и создаём кластер

Выполняем установку компоненты для возможности работы с кластером — Failover Clustering. Выполнить это можно либо в оснастке Server Manager либо с помощью PowerShell:

Import-Module ServerManager
Add-WindowsFeature "Failover-Clustering" -IncludeManagementTools

Открываем оснастку Failover Cluster Manager (Cluadmin.msc) и в меню действий Action выбираем пункт создания нового кластера – Create a Cluster

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

На следующем шаге мастера укажем имя и IP адрес выделенный для администрирования кластера. В качестве имени можно указать как короткое NetBIOS имя, так и имя в формате distinguishedName (DN), если нам необходимо чтобы учетная запись Cluster Name Object была создана/обновлена в определённом доменном OU. В нашем примере в качестве имени указано имя DN созданной ранее учетной записи компьютера: CN=KOM-AD01-SCVMFC,OU=Cluster Name Objects,OU=Domain Computers,OU=KOM-AD01,OU=KOM,DC=holding,DC=com

Далее, исходя из нашей конфигурации, мастером будет автоматически создан кластер с моделью кворума большинства узлов — Node Majority. Это значит, что наш будущий двух-узловой кластер будет оставаться в работоспособном состоянии (принимать запросы от клиентов) в том случае, даже если будет доступен только один узел.

В процессе создания кластера учетная запись подготовленная нами ранее в домене для CNO будет автоматически включена и обновлена, при этом будет выполнена регистрация указанного имени кластера в DNS. Проверим доступность созданного кластера, заодно убедившись в том, что имя без проблем разрешается в IP-адрес, то есть динамическая регистрация имени кластера в DNS прошла успешно…

Дополнительно нам нужно убедиться в том, что кластерные сети сети настроены таким образом, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования меж-узлового кластерного обмена. В свойствах кластерной сети, предназначенной для Cluster Heartbeat (в нашем случае это Cluster Network 2) должна быть отключена опция Allow clients to connect through this network.

 

Теперь можно сказать что наш кластер готов для развёртывания в нём кластеризованной службы VMM Management Server.

 

Устанавливаем дополнительные требуемые для VMM компоненты

Исходя из требований описанных в документах System Requirements: VMM Management Server и System Requirements: VMM Console на наш сервер нам потребуется предварительно установить Windows Assessment and Deployment Kit (WADK). Загружаем инсталлятор WADK из Microsoft Download Center и запускаем файл adksetup.exe. Выбираем каталог в который из интернета будут загружены все необходимые файлы для полной установки компонент ADK…

После окончания загрузки файлов объёмом примерно 2,85 GB запускаем с правами Администратора файл adksetup.exe уже из каталога загрузки. На этапе выбора компонент выбираем минимально необходимые для VMM - Deployment Tools и Windows Preinstallation Environment

 

<

p align="center">***

Так как БД VMM в нашем случае расположена на удалённом экземпляре SQL Server 2012 SP1, перед установкой VMM нам необходимо установить пакеты Microsoft SQL Server Native Client и Microsoft SQL Server 2012 SP1 Command Line Utilities из состава Microsoft SQL Server 2012 SP1 Feature Pack. В нашем случае должны быть загружены файлы ENU\x64\sqlncli.msi и ENU\x64\SqlCmdLnUtils.msi соответственно.

<

p align="center">***

После установки клиента SQL Server создадим на нашем сервере SQL-Alias, который будем в дальнейшем использовать для подключения службы VMM к серверу SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (%windir%\system32\cliconfg.exe) и добавим два новых алиаса – с коротким именем SQL-сервера и его FQDN.

При создании алиаса помним про требование в документе System Requirements: VMM Database исходя из которого длина имени не сервера БД должна превышать 15 символов.

Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection

Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.

<

p align="center">***

Инсталлятор VMM перед фактической попыткой подключения к SQL Server попытается проверить его доступность по имени сервера, поэтому так как мы создали SQL-Alias, нам дополнительно нужно создать соответствующую запись CNAME в DNS

После создания записи убедимся в том что на нашем сервере, где мы будем выполняем установку VMM, соответствующий CNAME успешно разрешается в IP (возможно потребуется очистка кэша локального DNS-клиента командой ipconfig /flushdns) 

 

Устанавливаем SC 2012 R2 VMM в режиме восстановления БД

Монтируем образ дистрибутива VMM файл SW_DVD5_Sys_Ctr_2012_R2_MultiLang_VMM_MLF_X19-18212.ISO и запускаем с правами Администратора файл setup.exe

В запущенном мастере установки на этапе выбора компонент при включении VMM management server мы получим запрос об установке этой роли в высоко-доступном режиме (highly available).

Компонента VMM console при этом будет автоматически включена к установке.

Указываем регистрационную информацию и вводим ключ продукта который используется один и тот же для всех продуктов линейки System Center 2012 RTM/SP1/R2

Каталог установки оставляем предложенный по умолчанию..

На шаге Database configuration имя сервера SQL укажем в виде ранее созданного нами SQL-алиаса. При необходимости укажем имя экземпляра (Instance name). В качестве БД выберем использование уже существующей БД (Existing database), при этом вручную укажем имя существующей БД, которую осталась у нас после удаления VMM предыдущей версии (в нашем примере это VirtualManagerDB)

При этом инсталлятор должен определить что предложенная БД имеет старую версию и предложить нам выполнить её обновление. Соглашаемся..

Обратите внимание на то, что мы предварительно не выполняли никаких специальных настроек по доступу к существующей БД VMM. Всё что нам нужно – это иметь полные права на доступ к экземпляру SQL Server для той учетной записи от имени которой производится установка VMM. В процессе установки инсталлятор самостоятельно настроит доступ к БД для учетной записи службы VMM, которую мы укажем далее.

На шаге Cluster configuration укажем имя для кластеризованной службы VMM согласно предварительно созданной нами в домене учетной записи KOM-AD01-SCVMCL, а также укажем IP адрес соответствующий этому имени согласно нашей схемы. 

На следующем шаге укажем имя и пароль учетной записи службы VMM (KOM\s-SCVMMSvс) а также DN имя контейнера который мы предварительно создали для хранения данных DKM, в нашем случае это: CN=System Center VMM DKM,OU=Service Objects,OU=KOM-AD01,OU=KOM,DC=holding,DC=com

Порты без реальной необходимости изменения оставляем в конфигурации по умолчанию…

На шаге Library configuration нам будут недоступны настройки установки библиотеки VMM, так как в кластерной конфигурации эта функция не поддерживается. Подразумевается что в идеале для VMM Library мы должны использовать отдельный файловый кластер.

На следующем шаге Upgrade compatibility report нам будет дан ряд замечаний о процессе обновления VMM…

•    Some data in the VMM database (for example, Run As account credentials and passwords in guest operating system profiles) is encrypted using the Windows Data Protection API (DPAPI). To retain this encrypted data, the VMM management server must be installed on the same computer where VMM was previously installed. Also, you must use the same service account for the System Center Virtual Machine Manager service that you used in your previous installation of VMM. If you install VMM on a different computer or use a different service account, this encrypted data will not be retained. For more information, see Retaining Encrypted Data in VMM (http://go.microsoft.com/fwlink/p/?LinkID=246611).

•    VMM does not support a library server on a computer that is running Windows Server 2003. If your library server is running Windows Server 2003 and you continue with the upgrade, you will not be able to use the library server in VMM. You will only be able to remove the library server from VMM. If you want to use the library server in VMM, click Cancel to exit the upgrade and then move the library server to a computer that is running a supported operating system. For information about library servers and upgrading to System Center 2012 Virtual Machine Manager, see Upgrading to System Center 2012 Virtual Machine Manager (http://go.microsoft.com/fwlink/?LinkID=214129).

•    After VMM for System Center 2012 R2 is installed, you need to perform additional tasks in order to complete the upgrade to VMM in System Center 2012 R2. For more information about these tasks, see 'Upgrading to System Center 2012 R2 Virtual Machine Manager' (http://go.microsoft.com/fwlink/?LinkID=214130).

На шаге Installation summary ещё раз проверяем все заданные настройки запускаем процесс установки – Install

Дожидаемся успешного завершения процесса установки…

В случае возникновения проблем лог-файлы установки в можно найти в папке C:\ProgramData\VMMLogs

 

4. Разворачиваем второй сервер VMM

Разворачиваем новую виртуальную машину с двумя сетевыми адаптерами на базе ОС Windows Server 2012 R2. В нашем примере серверу присвоено имя KOM-AD01-SCVM02. Далее по сжатому плану:
- Выполняем настройку сетевых параметров в соответствии с приведённой в начале заметки схемой по аналогии с тем, как это делалось на первом сервере;
- Вводим сервера в домен и устанавливаем все текущие обновления Windows Update;
- Добавляем сервисную учетную запись службы VMM в группу локальных Администраторов;
- Устанавливаем WADK
- Устанавливаем клиентские компоненты SQL Server и создаем SQL-Alias;
- Включаем поддержку Failover Clustering и переходим к процессу добавления дополнительного узла в кластер, который рассмотрим более подробно.

 

Добавляем узел в существующий кластер 

Итак, на сервере KOM-AD01-SCVM02 открываем оснастку Failover Cluster Manager и выполняем подключение к созданному ранее кластеру Connect to Cluster … KOM-AD01-SCVMFC

Подключившись к кластеру переместимся на список узлов и вызовем пункт добавления нового узла Nodes > Add Node

 

В открывшемся мастере добавления узлов укажем имя нашего второго сервера KOM-AD01-SCVM02 и добавим его – Add

Далее нам будет предложено запустить мастер проверки обоих узлов кластера (существующего и добавляемого) на отсутствие проблем совместимости с технологией кластеризации Microsoft. Соглашаемся…

Мастер добавления узла будет переключен на мастер валидации, в котором мы воспользуемся рекомендуемым выбором и запустим выполнение всех тестов – Run all tests

Если в ходе выполнения проверок критических ошибок не было найдено, то мы снова будем возвращены в мастер добавления узлов…

На экране готовности к добавлению узла в кластер можем отключить установленную по умолчанию опцию Add all eligible storage to the cluster, так как в нашем случае необходимости в использовании кластерных дисковых ресурсов нет. 

В результате мастер сообщит нам об успешном добавлении узла в кластер  и выдаст пару предупреждений которые в нашей ситуации можно проигнорировать.

В консоли Failover Cluster Manager переключимся в раздел управления кластерными сетями Networks и убедимся в том, что появились данные сетевых адаптеров добавленного узла. 

Добавление узла в кластер можно считать законченным, но для того чтобы второй узел смог стать членом кластеризованной службы VMM нам необходимо выполнить процедуру установки VMM на этот сервер.

Устанавливаем SC 2012 R2 VMM в режиме подключения к кластерной службе VMM

По аналогии с первым сервером запускаем программу установки SC 2012 R2 VMM и на этапе выбора компонент, при включении компоненты VMM management server, мы получим вопрос – хотим ли мы присоединить этот сервер к высоко-доступному экземпляру VMM. Выбираем Yes

При этом инсталлятор перейдёт в режим добавления узла в кластер VMM и поэтому настройки Database configuration настройки будут нам отображены без возможности изменения и будут автоматически настроены таким образом, как они были заданы на этапе установки первого сервера KOM-AD01-SCVM01.

Единственное что нас попросят, так это ввести пароль учетной записи для запуска службы VMM

На шагах Port configuration и Library configuration все параметры также будут отображаться в режиме только для чтения и соответствовать тем параметрам которые были определены при установке VMM на первый сервер.

После успешного завершения установки можно перейти к процедурам проверки работоспособности кластера VMM

 

5. Проверяем работу кластера VMM

При первом запуске консоли VMM указываем FQDN имя и порт, которые был определены в процессе установки в качестве имени кластеризованной службы VMM.

Если мы без проблем подключились консолью к кластерному имени – первая проверка пройдена.

В консоли VMM, как я понял, на текущий момент функции управления кластером VMM Management Service не реализованы, и вся информация которую мы можем получить по кластеру в консоли доступна на вкладке Fabric в ветке Servers > Infrastructure > VMM Servers. Здесь мы можем видеть имя кластера к которому относится сервер VMM, а так же понять какой именно сервер на данный момент является активным узлом.

Для фактического управления кластером VMM мы можем использовать оснастку Failover Cluster Manager. Например здесь мы можем протестировать, то как поведёт себя VMM при передачи роли активного сервера с одного узла кластера на другой. В узле Roles выбираем кластер VMM затем Move > Select Node и выбираем второй узел кластера, который мы хотим сделать активным…  

Если кластер функционирует нормально, то через некоторое время (в нашем случае чуть больше минуты) роль владельца кластерной службы VMM успешно перейдет ко второму серверу… 

В процессе переключения активного узла у Администраторов работающих с консолью VMM появится диалоговое окно о временной недоступности службы с выполнением автоматических попыток переподключения.

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

 

6. Удаляем устаревшую информацию о Library Server

По причине того, что ранее сервер KOM-AD01-SCVM01 у нас использовался в качестве единственного сервера VMM и на нём была развернута роль VMM Library, эта информация осталась в консоли после восстановления БД. Как мы и условились роль VMM Library в нашем случае будет выполняться на отдельном файловом кластере и поэтому нам нужно удалить устаревшую информацию о том что на  сервере KOM-AD01-SCVM01 есть VMM Library. Для этого переместимся в раздел консоли Fabric > Servers > Infrastructure > Library Servers выберем сервер у вызовем пункт удаления роли Remove…

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

При этом консоль VMM мне доблестно соврала о том, что параллельно был удалён VMM Agent.

 

7. Обновляем агентов и отдельно установленные консоли VMM

Как и со всеми предыдущими версиями VMM, установка новой версии сервера управления неминуемо влечёт за собой процедуру обновления развернутых агентов VMM.
Переходим в рабочую область консоли Fabric и на вкладке Servers, добавив для отображения колонку Agent Version Status увидим что нашим агентам требуется обновление. Запускаем процедуру обновления до версии 3.2.7510.0 – Update Agent…

В моём окружении обновление агентов VMM прошло достаточно быстро и при этом перезагрузка серверов на которых агенты были обновлены не потребовалась.

Параллельно нам нужно позаботиться об обновлении отдельно установленных консолей VMM. Не смотря на то, что мне удалось подключиться к обновлённому серверу VMM старой версией консоли, стало очевидно, что в таком режиме работать нельзя, так как в разных местах консоль вызывала исключения и попросту падала.

О том как автоматизировать процесс обновления отдельно установленных консолей VMM с помощью SCCM 2012 описано в заметке В.Якоба — Развёртывание консоли управления System Center 2012 Virtual Machine Manager SP1 при помощи SC 2012 CM. 

В целом, на данном этапе можно сказать, что задача которую мы перед собой поставили – выполнена. Хочется лишь сделать пару замечаний об использовании VMM в режиме Highly Available:
- В процессе перехода по отказу (failover), как уже было замечено ранее, пользователи консоли VMM на некоторое (незначительно) время потеряют возможность работать с консолью.
- Все выполняющиеся в VMM задачи (jobs) на момент перехода по отказу будут остановлены и не будут повторно запущены автоматически после восстановления VMM, поэтому их нужно будет повторно  запустить вручную при необходимости.

Дополнительные источники информации:

TechNet Library - Installing a Highly Available VMM Management Server
System Center: VMM Engineering Blog - SCVMM 2012- Creating a Highly Available VMM Server
Hyper-v.nu - System Center VMM 2012 SP1 High Availability with SQL Server 2012 AlwaysOn Availability Groups