System Center 2012 R2 App Controller Hight Availability на базе узлов кластера Virtual Machine Manager

Несмотря на то, что такой продукт, как App Controller из состава System Center 2012 R2, можно сказать, уже близок к завершению своего жизненного цикла, выполнять его установку и настройку, да ещё и в варианте Hight Availability, мне до сих пор не доводилось. Практика показала, что процедура такого развёртывания имеет свои нюансы, и поэтому в данной заметке я попытаюсь пошагово описать данный процесс. Основным и главным условием развёртывания высоко-доступного App Controller в моём случае будет использование уже имеющихся серверов System Center 2012 R2 Virtual Machine Manager (VMM), то есть установка служб App Controller будет выполняться на узлы действующего кластера VMM, конфигурация которого рассматривалась ранее в заметке Обновляем System Center 2012 SP1 Virtual Machine Manager до уровня System Center 2012 R2 на Windows Server 2012 R2 и SQL Server 2012 SP1 с параллельным переходом в режим Highly Available.

Предвосхищая вопрос о целесообразности использования App Controller в то время, как Microsoft предлагает на замену этого продукта более мощный и функциональный Windows Azure Pack, могу сказать то, что в моём случае функционала App Controller более чем достаточно (требуется элементарная раздача прав разным категориям пользователей на управление рядом виртуальных машин из кластера Hyper-V). К тому же меня пока отпугивает некая “монструозность” как самой архитектуры Windows Azure Pack, так и процесса его развёртывания.

Для начала напомню о конфигурации ранее описанной среды, в которой мы будем выполнять развёртывание высоко-доступного App Controller. Это две виртуальные машины с именами KOM-AD01-SCVM01 и KOM-AD01-SCVM02 образуют кластерный экземпляр на базе Windows Failover Cluster в составе ОС Windows Server 2012 R2 с именем KOM-AD01-SCVMCL. На эти две виртуальные машины мы и будем устанавливать App Controller с последующим созданием NLB-кластера c именем KOM-AD01-SCACCL на внешнем балансировщике (не забываем о невозможности сосуществования служб Windows Failover Cluster и Windows NLB в рамках одной серверной ОС Windows Server). При этом оба установленных экземпляра App Controller будут использовать общую базу данных, расположенную в кластеризованном экземпляре Microsoft SQL Server 2012, на котором уже размещена база данных VMM. Таким образом, схема расположения основных компонент в нашем случае будет выглядеть следующим образом:

Чтобы узнать о предварительных требованиях для развертывания App Controller, обратимся к онлайн-документации, доступной в TechNet Library. Явных противопоказаний к сосуществованию служб VMM и App Controller на одной серверной системе мне найти не удалось, поэтому приступаем…

 

Создаём учётную запись для служб App Controller

Создадим в домене Active Directory служебную учётную запись пользователя, от имени которой в дальнейшем будут запускаться службы App Controller на обоих серверах. В нашем примере это будет учётная запись KOM\s-SCACSvc. Включим данную учётную запись в группу локальных администраторов на обоих серверах. Сделать это нужно до начала процесса установки App Controller.

 

Настраиваем делегирование для служб App Controller

Для корректной работы механизмов Single Sign-On (SSO) в конфигурации с несколькими экземплярами App Controller использующими общую БД и единое подключение к VMM нам потребуется настроить делегирование передачи учётных данных для доменных учётных записей компьютеров на которые будет установлен App Controller. Как и описывалось ранее, в нашем случае VMM выполняется от имени служебной доменной учётной записи KOM\s-SCVMMSvc, и соответственно эта учётная запись имеет регистрацию ServicePrincipalName для имени кластеризованного экземпляра VMM.

В оснастке Active Directory - Users and Computers (dsa.msc) откроем свойства учётной записи каждого из компьютеров, на которые мы будем устанавливать App Controller, и на закладке Delegation выберем опции Trust this computer for delegation to specific services only / Use any authentication protocol. В окне выбора служб добавим ранее упомянутую учётную запись, от имени которой работает кластеризованный VMM (KOM\s-SCVMMSvc) и выберем соответствующее ей значение службы SCVMM с именем кластера VMM (KOM-AD01-SCVMCL). После этого дополнительно добавим службу cifs для компьютера, являющегося вторым узлом кластера VMM. Таким образом, получим следующие настройки:

- для учётной записи компьютера KOM-AD01-SCVM01:

- для учётной записи компьютера KOM-AD01-SCVM02:

Если данные настройки делегирования не произвести или произвести неправильно, то в перспективе механизм SSO при доступе к веб-консоли App Controller будет работать некорректно.

 

Устанавливаем цифровой сертификат IIS

Так как фронт-энд App Controller представляет собой сайт на базе веб-сервера IIS, который в свою очередь использует для защиты HTTP-сессий цифровой сертификат, нам желательно предварительно создать и установить в систему такой сертификат, запросив его у доверенного (например доменного) Центра сертификации (ЦС). Если этого не сделать заранее, то программа установки App Controller попытается создать самоподписанный сертификат, к которому у клиентов нашей локальной сети доверия не будет.

Перейдём на любой из двух наших серверов, например KOM-AD01-SCVM01, и создадим временный конфигурационный файл для генерации запроса сертификата KOM-AD01-SCACCL.inf с содержимым:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-SCACCL.holding.com"
Exportable = TRUE; Private key is exportable
KeyLength = 2048
KeySpec = 1
KeyUsage = 0x30; Key Encipherment, Data Encipherment
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-SCACCL.holding.com&" 
_continue_ = "dns=KOM-AD01-SCVM01.holding.com&" 
_continue_ = "dns=KOM-AD01-SCVM02.holding.com&" 
_continue_ = "dns=KOM-AD01-SCACCL&" 
_continue_ = "dns=KOM-AD01-SCVM01&" 
_continue_ = "dns=KOM-AD01-SCVM02&"

Как видно из конфигурационного файла, мы создаём запрос на сертификат с поддержкой альтернативных имён (Subject Alternative Name, SAN). То есть этот сертификат можно будет использовать на IIS на обоих наших серверах, так как помимо основного имени (имя будущего NLB-кластера), сертификат имеет альтернативные имена относящиеся к отдельным узлам кластера. Опция Exportable = TRUE позволит нам в дальнейшем экспортировать установленный на первом сервере сертификат в паре с относящимся к нему закрытым ключом для последующего импорта на второй сервер.

Генерируем файл запроса на основе конфигурационного файла (помним что выполняется это непосредственно на сервере KOM-AD01-SCVM01):

certreq -new -f "C:\Temp\KOM-AD01-SCACCL.inf" "C:\Temp\KOM-AD01-SCACCL.req"

Получаем ответ, что запрос создан и сразу отправляем этот запрос в ЦС. В нашем случае ЦС настроен на автоматическое одобрение запросов и выдачу сертификатов (если автоматическая выдача не используется, то пример ручного получения сертификата можно взять например здесь.), поэтому при отправке запроса сразу указываем куда будет сохранён автоматически полученный готовый сертификат:

certreq -submit -f -config "KOM-AD01-CA01.holding.com\KOMI CA" "C:\Temp\KOM-AD01-SCACCL.req" "C:\Temp\KOM-AD01-SCACCL.cer"

После того, как сертификат загружен выполняем его установку в систему:

certreq -accept "C:\Temp\KOM-AD01-SCACCL.cer"

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

Как видим, сертификат успешно установлен и связан с закрытым ключом. Теперь в этой же оснастке выполняем экспорт сертификата вместе с закрытым ключом с последующим импортом на втором сервере (KOM-AD01-SCVM02). После того как сертификат установлен на обоих серверах, можем приступить к процедуре установки App Controller.

 

Устанавливаем первый сервер App Controller

Начинаем установку App Controller с пассивного узла кластера VMM. Быстро определить, какой из узлов кластера на данный момент является владельцем кластерного экземпляра VMM, можно например с помощью PowerShell:

Как видим, активным владельцем кластерной службы VMM является сервер KOM-AD01-SCVM01,  поэтому установку App Controller мы начнём с узла KOM-AD01-SCVM02.

Итак, на сервере KOM-AD01-SCVM02 смонтируем образ с дистрибутивом App Controller (файл SW_DVD5_Sys_Ctr_2012_R2_MultiLang_AppCont_MLF_X19-18210.ISO размером 37,4 MB) и запустим с правами администратора программу установки Setup.exe

 

Вводим ключ продукта, принимаем лицензионное соглашение…

 

На шаге проверки предварительных требований нам сообщат о необходимости установки роли веб-сервера (если она ещё не была установлена ранее) IIS и пакета WCF Data Services 5.0. Эти компоненты будут развёрнуты программой установки автоматически.

 

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

 

На шаге конфигурирования служб App Controller определим то, что службы будут выполняться от имени созданной нами ранее служебной учётной записи KOM\s-SCACSvc

 

На шаге конфигурирования веб-сайта App Controller переопределим предлагаемый по умолчанию 443 порт на другой неиспользуемый на нашем сервере порт, например 8443. В нашем случае во избежание конфликтов сделать это изменение обязательно, так как фактически будет иметь место сосуществование служб App Controller со службами VMM, которые уже используют порт 443 под задачи BITS.

Помимо изменения номера порта может возникнуть соблазн указать конкретный интерфейс для TCP-прослушивателя IIS, но походив “по граблям” в результате такой настройки, могу сказать, что от этой затеи лучше отказаться сразу и оставить вариант предлагаемый по умолчанию - All unassigned.

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

 

На шаге настроек базы данных App Controller указываем имя кластеризованного экземпляра SQL Server и номер его порта. Как я уже сказал ранее, в нашем случае используется уже действующий экземпляр на котором уже расположена база данных кластеризованного VMM. Имя базы данных оставляем предложенное по умолчанию - AppController

 

Проходим шаг с предложением поучаствовать в программе развития продуктов Microsoft.

 

Ещё раз просматриваем заданные настройки и переходим к процессе установки по кнопке Install

 

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

 

По завершению процесса установки проверяем доступность веб-узла App Controller локально на текущем сервере.

Если локальной сайт успешно открывается, проверяем его URL (https://kom-ad01-scvm02.holding.com:8443) и с удалённой машины. Если удалённо сайт не открывается, то проверяем правило в Windows Firewall с именем “System Center 2012 R2 App Controller website” которое открывает доступ к указанному в процессе установки TCP порту.

Как видим, веб-сайт App Controller в конфигурации по умолчанию предлагает нам явный ввод учётных данных, то есть механизм SSO не работает. Чтобы это исправить, откроем консоль IIS Manager, развернём сайт AppController, найдём внутри него приложение api и выберем для него настройку аутентификации - Authentication

 

Отключим включенный по умолчанию тип аутентификации Basic Authentication и включим, так называемую, встроенную проверку подлинности Windows – Windows Authentication 

Перезапускаем браузер и снова пробуем открыть веб-сайт App Controller. И если мы ничего не напутали с ранее выполненной настройкой делегирования в домене, сайт откроется без запроса аутентификации.

 

Выгружаем App Controller AES Key

Чтобы развернуть дополнительный сервер App Controller с подключением к уже имеющейся базе данных, нам потребуется выполнить экспорт специального ключа шифрования App Controller Advanced Encryption Standard Key (SCACAesKey) из реестра первого развёрнутого сервера App Controller. Сделать это можно непосредственно на первом сервере App Controller (напомню, что в нашем случае это сервер KOM-AD01-SCVM02) в PS-консоли с подгружаемыми PS-командлетами App Controller (нам потребуется Export-SCACAesKey). Ярлык на запуск соответствующей консоли Windows PowerShell module for App Controller расположен по умолчанию в папке C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft System Center 2012 R2\App Controller.

Итак, запускаем с правами администратора консоль Windows PowerShell module for App Controller и выполняем в ней следующий набор команд:

$Credentials = Get-Credential
Get-SCACServer -ServerName "https://kom-ad01-scvm02.holding.com:8443" -Credential $Credentials
$Password = ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force
Export-SCACAESKey -Path "C:\Tools\SCACAesKey\SCACAESKey.txt" -Password $Password

Именно на этом этапе можно получить излишние проблемы, если в процессе установки App Controller задать конкретный интерфейс для TCP-прослушивателя его веб-сайта.

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

Появившийся в результате выполнения последней команды файл ключа SCACAESKey.txt нам и понадобится в дальнейшем при развёртывании второго сервера App Controller.

 

Проверяем работоспособность VMM на первом сервере App Controller

Передаём ресурсы VMM на узел с только что установленным App Controller и проверяем работоспособность VMM

Выполнить такую проверку весьма желательно, чтобы понимать то, что появившиеся службы App Controller никак не нарушают действующую функциональность служб VMM на текущем сервере, и нам можно со спокойной душой продолжить процесс развёртывания App Controller на втором узле кластера VMM.

 

Устанавливаем второй сервер App Controller

Приступаем к установке App Controller на второй узел кластера VMM, в нашем случае это будет сервер KOM-AD01-SCVM01.

В целом процесс установки на втором узле будет аналогичен  уже описанному выше процессу установки на первом узле до шага мастера установки, следующего за шагом выбора БД. Поняв то, что в качестве настроек базы данных мы указали уже существующий экземпляр БД App Controller, мастер установки запросит у нас ключ шифрования. Укажем путь к копии файла полученного с первого сервера и пароль который был указан в процессе экспорта ключа (в нашем примере P@ssw0rd)

Дождавшись успешного окончания процесса установки, по аналогии с первым сервером, выполним проверку локальной и удалённой доступности URL веб-сайта App Controller на втором сервере по соответствующей ссылке https://kom-ad01-scvm01.holding.com:8443

И так же, по аналогии с первым сервером, настроим веб-сайт IIS для возможности использования SSO.

 

Настраиваем подключение App Controller к VMM

Подключаемся к веб-консоли App Controller первого сервера, в дереве навигации выбираем Settings > Connections и используя кнопку Connect выбираем пункт меню SCVMM

В открывшейся веб-форме вводим FQDN имя и порт нашего кластеризованного экземпляра VMM с включением опции импорта SSL сертификатов.

Здесь App Controller должен успешно подключиться к VMM и на веб-консоли должна появиться информация о виртуальных машинах принадлежащих тому или иному частному облаку, определённому текущими настройками VMM.

После этого закроем веб-консоль и подключимся к веб-консоли второго сервера App Controller чтобы убедиться в том, что там также доступна информация о созданном подключении к VMM.

 

Создаём NLB кластер App Controller и проверяем его работу

На данном этапе у нас уже есть два функционирующих сервера App Controller использующих общую базу данных и настало время создать для них единую точку подключения с возможностью балансировки. На наших серверах используются механизмы Windows Failover Cluster для повышения доступности службы VMM, которые, как известно, не должны сосуществовать с Windows NLB. По этой причине для повышения доступности и балансировки App Controller вместо классического Windows NLB мы будем использовать внешний балансировщик, - в нашем примере будет использоваться виртуальный Zen Load Balancer. Причём в отличие от WNLB, который работает на сетевом уровне L4, то есть доступность узла NLB-кластера определяется на уровне всего хоста, на Zen мы настроим NLB кластер, который будет работать на более высоком уровне (L7), то есть доступность будет проверяться на более высоком уровне – уровне HTTP-запросов к веб-северу.

Перед началом настройки балансировщика сделаем пару вещей.

Во первых, создадим в локальной зоне DNS A-запись для IP адреса, который будет определять единую точку подключения к App Controller (в дальнейшем будет использован нами для создания кластера NLB). Как мы и условились ранее, имя кластера будет KOM-AD01-SCACCL.holding.com

Во вторых, так как веб-серверы, которые мы собираемся включить в NLB-кластер, используют для защиты соединений созданный и установленный нами ранее цифровой сертификат, нам потребуется установить данный сертификат и на наш внешний балансировщик. Сертификат нужно будет выгрузить в паре с закрытым ключом в файл формата PFX (сделать это можно через туже оснастку управления сертификатами в консоли mmc, которая упоминалась ранее), а затем конвертировать PFX в понятный для балансировщика Zen формат PEM (например с помощью утилиты OpenSSL):

openssl pkcs12 -in KOM-AD01-SCACCL.pfx -out KOM-AD01-SCACCL.pem -nodes

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

-----BEGIN RSA PRIVATE KEY-----
MIIEow...ops0aMS
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIFgzC....Y7rdOnc=
-----END CERTIFICATE-----

Теперь можем перейти на веб-интерфейс управления нашим внешним балансировщиком Zen и импортировать получившийся PEM-файл

Создадим отдельный виртуальный IP под нашу задачу

Создадим ферму с типом балансировки HTTP

В свойствах созданной фермы настроим параметры таким образом, чтобы балансировщик способен был принимать HTTPS запросы. Изменим тип прослушивателя Farm listener на HTTPS , укажем ранее импортированный HTTPS-сертификат PEM, и через поле Add service добавим службу для указания параметров серверов-участников NLB-кластера.

Зададим произвольное имя службы, например console и настроим её свойства. Зададим связку IP адрес и порт для каждого из наших серверов, на которых мы ранее развернули App Controller и обязательно включим признак того что наши серверы являются HTTPS Backends. В поле Persistence session выберем подходящий тип закрепления клиентов за тем или иным узлом NLB-кластера для механизма балансировки, например IP: client address. Дополнительно (это делать вовсе не обязательно) я ещё указал в поле Virtual Host FQDN-имя которое считается приемлемым в HTTP-заголовках при обращении клиентов к веб-серверу.

Сохраняем указанные настройки HTTP-службы, фермы балансировки и проверяем результат обратившись с клиентского компьютера на URL https://kom-ad01-scaccl.holding.com:8443

Чтобы проверить работоспособность построенной схемы повышения доступности App Controller, имитируем всевозможные проблемные ситуации, как то:

- выключение активного узла кластера VMM, тем самым проверяя доступность веб-консоли App Controller при ситуации смены владельца кластеризованной службы VMM;
- остановка всего IIS или только пула приложений IIS, отвечающего за сайт App Controller на любом из серверов (лучше проверить на обоих), тем самым проверяя то, что внешний балансировщик будет направлять клиентские запросы только на сервер с работоспособным IIS.