Кластер терминальных серверов. RemoteApp Manager и меняем параметр Server Name

Всем привет сегодня расскажу как настроить отказоустойчивый кластер Hyper-V в Windows Server 2012 R2. Напомню, что тоже саое мы с вами уже рассматривали для Hyper-V в Windows Server 2012 R2 .

Уже на этапе планирования будущей виртуальной инфраструктуры следует задуматься об обеспечении высокой доступности ваших виртуальных машин. Если в обычной ситуации временная недоступность одного из серверов еще может быть приемлема, то в случае остановки хоста Hyper-V недоступной окажется значительная часть инфраструктуры. В связи с чем резко вырастает сложность администрирования - остановить или перезагрузить хост в рабочее время практически невозможно, а в случае отказа оборудования или программного сбоя получим ЧП уровня предприятия.

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.

Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.

Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 - SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.

Следующим шагом добавим компоненту Отказоустойчивая кластеризация .

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

Миграцию виртуальных машин оставляем выключенной .

Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в данной статье, но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

Создайте новую цель iSCSI и разрешите доступ к ней двум инициаторам, в качестве которых будут выступать узлы кластера.

И сопоставьте данной цели созданные виртуальные диски.

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

Подключенные диски инициализируем и форматируем.

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

После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов. Их название на обоих узлах должно полностью совпадать .

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

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

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

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

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

При создании кластера для него создается виртуальный объект, обладающий сетевым именем и адресом. Укажем их в открывшемся Мастере создания кластеров .

Больше вопросов не последует и мастер сообщит нам, что кластер создан, выдав при этом предупреждение об отсутствии диска-свидетеля.

Закроем мастер и развернем дерево слева до уровня Хранилище - Диски , в доступных действиях справа выберем Добавить диск и укажем подключаемые диски в открывшемся окне, в нашем случае их два.

Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия - Настроить параметры кворума в кластере .

Теперь настроим диск хранилища, с ним все гораздо проще, просто щелкаем на диске правой кнопкой и указываем: Добавить в общие хранилища кластера .

Для того, чтобы диск мог использоваться сразу несколькими участниками кластера на нем создается CSVFS - реализуемая поверх NTFS кластерная файловая система, впервые появившаяся в Windows Server 2008 R2 и позволяющая использовать такие функции как Динамическая (Живая) миграция, т.е. передачу виртуальной машины между узлами кластера без остановки ее работы.

Общие хранилища становятся доступны на всех узлах кластера в расположенииC:\ClusterStorage\VolumeN . Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

Закончив с дисками, перейдем к настройкам сети, для этого перейдем в раздел Сети . Для сети, которая подключена к сети предприятия указываем и Разрешить клиентам подключаться через эту сеть . Для сети хранения данных просто оставим Разрешить кластеру использовать эту сеть , таким образом обеспечив необходимую избыточность сетевых соединений.

На этом настройка кластера закончена. Для работы с кластеризованными виртуальными машинами следует использовать Диспетчер отказоустойчивости кластеров , а не Диспетчер Hyper-V , который предназначен для управления виртуалками расположенными локально.

Чтобы создать виртуальную машину перейдите в раздел Роли в меню правой кнопки мыши выберите Виртуальные машины - Создать виртуальную машину , это же можно сделать и через панель Действия справа.

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

После выбора узла откроется стандартный Мастер создания виртуальной машины, работа с ним не представляет сложности, поэтому остановимся только на значимых моментах. В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:\ClusterStorage\VolumeN .

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

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

Затем перейдите в Сетевой адаптер - Аппаратное ускорение и убедитесь, что выбранные опции поддерживаются сетевыми картами всех узлов кластера или отключите их.

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

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

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

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

На этом настройка виртуальной машины закончена, можем запускать и работать с ней.

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

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

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

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

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

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

Кластер Hyper-V не обеспечивает отказоустойчивости виртуальным машинам, отказ узла приводит к отказу всех размещенных на нем машин, но он позволяет обеспечить вашим службам высокую доступность, автоматически восстанавливая их работу и обеспечивая минимально возможное время простоя. Также он позволяет значительно облегчить администрирование виртуальной инфраструктуры позволяя перемещать виртуальные машины между узлами без прерывания их работы.

Бог сервера 12 октября 2012 в 19:24

Remote Desktop Services 2012 – Отказоустойчивая ферма Remote Connection Broker нового поколения

  • Чулан *

Если в версиях 2008/R2 использовалась схема Active/Passive для кластеризации службы RD Connection Broker , то в версии Windows Server 2012 схема работы служб RD переработана в корне. И для отказоустойчивой работы службы RD Connection Broker предлагается схема Active/Active .
Если в предыдущих версиях Connection Broker хранил всю информацию о пользовательских сессиях в локальной базе и, для развёртывания отказоустойчивой фермы, нам предлагалось использовать Failover Cluster, то в новой схеме Failover Cluster не используется. RD Connection Broker хранит свои данные в базе данных SQL Server , а клиенты подключаются к серверам RD Connection Broker используя DNS Round Robin .

Среда исполнения

Четыре виртуальных сервера на базе Windows Server 2012 Standard EN . Серверу, выполняющему роль контроллера домена в лесу contoso.com и DNS сервера присвоено имя DC1 и IP адрес 10.0.0.1. Сервер базы данных нашей фермы имеет имя SQL и IP адрес 10.0.0.10. Два сервера с установленной ОС, роли на них будут добавлены в процессе развертывания служб RDS.

Визуально схема будет выглядеть так:

В нашем случае серверы RD1 и RD2 будут являться как Remote Desktop Session Host , так и Remote Desktop Connection Broker .
На сервере SQL будет установлена SQL Server 2012 Standard (так же возможно использование SQL Server 2008 R2 в редакции не ниже Standard).

Предварительные настройки

1. Так как RD Connection Broker использует SQL Server в отказоустойчивой схеме, то сервер RD Connection Broker должен иметь полные привилегии доступа к SQL Server. Создадим в AD группу RDCB Servers , включим в нее наши RD Connection Broker серверы, а после дадим этой группе все привилегии доступа в разделе Security сервера SQL, используя SQL Server Management Studio .

2. Так же изменим параметры Windows Firewall на нашем SQL сервере, что бы он пропускал входящие подключения. Откроем окно командной строки или PowerShell и введем следующее: netsh advfirewall firewall add rule name = SQLPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN .

3. Создадим заранее папку для базы данных. Это может быть как локальная папка, так и расшаренная где либо еще. В нашем случае это будет локальная папка C:\Base на сервере SQL .

5. Создадим имя DNS Round Robin для каждого RD Connection Broker сервера. В нашем случае это будет 2 записи A с именем RD указывающих на IP адреса 10.0.0.3 и 10.0.0.4.

6. Перед тем как создавать нашу ферму, объединим наши будущие RDS сервера в группу. Откроем Manage – Create Server Group , добавим оба сервера в группу и дадим ей название RDS .

Создание отказоустойчивой фермы Remote Desktop Connection Broker

1. Запустите Add Roles and Features Wizard на сервере RD1 и переключите режим установки на Remote Desktop Services installation .

2. Оставьте опцию Standard deployment , так как мы будем делать развертывание на несколько серверов.

3. Выберем Session-based desktop deployment , так как в данной конфигурации мы не рассматриваем ферму VDI.

4. Помимо ролей RD Connection Broker и RD Session Host будет так же установлена роль RD Web Access . Отказаться от нее почему то нельзя. По крайней мере, я не нашел такой возможности.

5. На следующей странице выберем сервер RD1 для установки роли RD Connection Broker .

6. На странице RD Web Access выберем сервер доступа через веб. В нашем случае это будет тот же сервер что и RD Connection Broker . Установим чекбокс Install the RD Web Access role on the RD Connection Broker server и перейдем к следующей странице.

7. Добавим оба сервера в список для установки на них роли RD Session Host на одноименной странице и нажмем Next .

8. На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Установим чекбокс Restart the destination server automatically if required и нажмем Deploy .

10. Приступим, собственно, к созданию отказоустойчивой конфигурации RD Connection Broker . Для этого перейдем на вкладку Overview раздела Remote Desktop Services менеджера серверов (Server Manager ) и нажмем правой клавишей мыши на изображении RD Connection Broker . Там для нас будет доступна одна функция – Configure High Availability .

11. Запустив данную функцию мы увидим новый визард, на стартовой странице которого будут перечислены необходимые предварительные настройки, которые мы выполнили в полной мере.

12. На вкладке Configure High Availability нам нужно заполнить 3 строки. Database connection string должна выглядеть следующим образом DRIVER=SQL Server Native Client 11.0 (или 10.50 если вы используете SQL Server 2008 R2);SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=. В нашем случае введем следующую строку DRIVER=SQL Server Native Client 11.0;SERVER=SQL.contoso.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB . В строку Folder to store database files введем путь заранее подготовленной нами папки C:\Base . В строку DNS round robin name введем созданный заранее FQDN нашей точки входа RD.contoso.com .

13. На странице подтверждения еще раз проверим введенные нами данные и нажмем Configure .

14. На странице Progress дождемся окончания конфигурации.

Собственно это все, как мы можем видеть на странице Overview раздела Remote Desktop Services менеджера сервера наш RD Connection Broker работает в режиме High Availability Mode . Можно использовать эту ферму RDS через точку входа RD.contoso.com .

Добавление серверов RD Connection Broker делается через то же самое контекстное меню на странице Overview .

Теги: Windows Server 8, Windows Server 2012, RDS, RDCB, Remote Desktop, Remote Desktop Connection Broker, Failover, high availability

крепыш 12 октября 2012 в 19:24

Remote Desktop Services 2012 – Отказоустойчивая ферма Remote Connection Broker нового поколения

Если в версиях 2008/R2 использовалась схема Active/Passive для кластеризации службы RD Connection Broker , то в версии Windows Server 2012 схема работы служб RD переработана в корне. И для отказоустойчивой работы службы RD Connection Broker предлагается схема Active/Active .
Если в предыдущих версиях Connection Broker хранил всю информацию о пользовательских сессиях в локальной базе и, для развёртывания отказоустойчивой фермы, нам предлагалось использовать Failover Cluster, то в новой схеме Failover Cluster не используется. RD Connection Broker хранит свои данные в базе данных SQL Server , а клиенты подключаются к серверам RD Connection Broker используя DNS Round Robin .

Среда исполнения

Четыре виртуальных сервера на базе Windows Server 2012 Standard EN . Серверу, выполняющему роль контроллера домена в лесу contoso.com и DNS сервера присвоено имя DC1 и IP адрес 10.0.0.1. Сервер базы данных нашей фермы имеет имя SQL и IP адрес 10.0.0.10. Два сервера с установленной ОС, роли на них будут добавлены в процессе развертывания служб RDS.

Визуально схема будет выглядеть так:

В нашем случае серверы RD1 и RD2 будут являться как Remote Desktop Session Host , так и Remote Desktop Connection Broker .
На сервере SQL будет установлена SQL Server 2012 Standard (так же возможно использование SQL Server 2008 R2 в редакции не ниже Standard).

Предварительные настройки

1. Так как RD Connection Broker использует SQL Server в отказоустойчивой схеме, то сервер RD Connection Broker должен иметь полные привилегии доступа к SQL Server. Создадим в AD группу RDCB Servers , включим в нее наши RD Connection Broker серверы, а после дадим этой группе все привилегии доступа в разделе Security сервера SQL, используя SQL Server Management Studio .

2. Так же изменим параметры Windows Firewall на нашем SQL сервере, что бы он пропускал входящие подключения. Откроем окно командной строки или PowerShell и введем следующее: netsh advfirewall firewall add rule name = SQLPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN .

3. Создадим заранее папку для базы данных. Это может быть как локальная папка, так и расшаренная где либо еще. В нашем случае это будет локальная папка C:\Base на сервере SQL .

5. Создадим имя DNS Round Robin для каждого RD Connection Broker сервера. В нашем случае это будет 2 записи A с именем RD указывающих на IP адреса 10.0.0.3 и 10.0.0.4.

6. Перед тем как создавать нашу ферму, объединим наши будущие RDS сервера в группу. Откроем Manage – Create Server Group , добавим оба сервера в группу и дадим ей название RDS .

Создание отказоустойчивой фермы Remote Desktop Connection Broker

1. Запустите Add Roles and Features Wizard на сервере RD1 и переключите режим установки на Remote Desktop Services installation .

2. Оставьте опцию Standard deployment , так как мы будем делать развертывание на несколько серверов.

3. Выберем Session-based desktop deployment , так как в данной конфигурации мы не рассматриваем ферму VDI.

4. Помимо ролей RD Connection Broker и RD Session Host будет так же установлена роль RD Web Access . Отказаться от нее почему то нельзя. По крайней мере, я не нашел такой возможности.

5. На следующей странице выберем сервер RD1 для установки роли RD Connection Broker .

6. На странице RD Web Access выберем сервер доступа через веб. В нашем случае это будет тот же сервер что и RD Connection Broker . Установим чекбокс Install the RD Web Access role on the RD Connection Broker server и перейдем к следующей странице.

7. Добавим оба сервера в список для установки на них роли RD Session Host на одноименной странице и нажмем Next .

8. На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Установим чекбокс Restart the destination server automatically if required и нажмем Deploy .

10. Приступим, собственно, к созданию отказоустойчивой конфигурации RD Connection Broker . Для этого перейдем на вкладку Overview раздела Remote Desktop Services менеджера серверов (Server Manager ) и нажмем правой клавишей мыши на изображении RD Connection Broker . Там для нас будет доступна одна функция – Configure High Availability .

11. Запустив данную функцию мы увидим новый визард, на стартовой странице которого будут перечислены необходимые предварительные настройки, которые мы выполнили в полной мере.

12. На вкладке Configure High Availability нам нужно заполнить 3 строки. Database connection string должна выглядеть следующим образом DRIVER=SQL Server Native Client 11.0 (или 10.50 если вы используете SQL Server 2008 R2);SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=. В нашем случае введем следующую строку DRIVER=SQL Server Native Client 11.0;SERVER=SQL.contoso.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB . В строку Folder to store database files введем путь заранее подготовленной нами папки C:\Base . В строку DNS round robin name введем созданный заранее FQDN нашей точки входа RD.contoso.com .

13. На странице подтверждения еще раз проверим введенные нами данные и нажмем Configure .

14. На странице Progress дождемся окончания конфигурации.

Собственно это все, как мы можем видеть на странице Overview раздела Remote Desktop Services менеджера сервера наш RD Connection Broker работает в режиме High Availability Mode . Можно использовать эту ферму RDS через точку входа RD.contoso.com .

Добавление серверов RD Connection Broker делается через то же самое контекстное меню на странице Overview .

Теги: Windows Server 8, Windows Server 2012, RDS, RDCB, Remote Desktop, Remote Desktop Connection Broker, Failover, high availability

Почему «Анти NLB »? Потому что хочется развеять частое заблуждение о возможностях NLBпо балансировке нагрузки и обеспечению отказоустойчивости, в частности относительно терминальной фермы серверов.

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

И так обратимся к документации. Цитата из :

Using NLB with Terminal Services offers the benefits of increased availability, scalability, and load-balancing performance, as well as the ability to distribute a large number of Terminal Services clients over a group of terminal servers.

Думаю без перевода понятно как все круто. Только не все так круто на самом деле.

Давайте посмотрим на конфигурацию, когда несколько терминальных серверов в ферме объединены в NLB -кластер. Чтобы привязать клиента к определенному серверу в ферме, NLB использует affinity – привязку по ip -адресу клиента или по его сети класса C. Обратите внимание – это единственный критерий! – NLB никак не контролирует загрузку сетевых интерфейсов и тем более загрузку ресурсов сервера (процессор, память). Иначе говоря, балансировка нагрузки заключается просто в законе больших чисел: чем больше инициировано подключений из большего количество мест, тем равнее сессии будут разбросаны по серверам фермы. (Но при этом существует вероятность, что на одном сервере окажутся сессии, приложения в которых съедят все ресурсы процессора, на втором окажутся сессии с приложениями, которые займут всю память, а на третьем приложения будут забивать весь сетевой канал.)

У вас есть терминальная ферма, к которой подключаются сотни и тысячи клиентов с большой частотой? Если есть, то вы тоже не будете использовать NLB – вы купите аппаратный балансировщик для такого важного ресурса!

Еще один момент – availability. NLB обеспечивает доступность? Я бы сказал наоборот. NLB всвоих настройках имеет только номер порта, но совершенно ничего не знает о сервисе, который его обеспечивает! И если этот сервис не отвечает, «упал», на одном сервере в ферме, то NLB будет, как и прежде, направлять на этот сервер новые подключения, а клиенты не смогут с ним работать и очень долго (до ручной переконфигурации NLB)! Вот если упадет весь сервер (или хотя бы у него будет недоступен физически сетевой интерфейс), то NLB это обнаружит через несколько секунд, исключит сервер из кластера и не будет направлять на него новые подключения клиентов.

Ручная переконфигурация NLB, упомянутая выше, заключается в том, что нужен механизм (скрипт), который, во-первых, диагностирует отказ сервиса (может оказать очень сложной задачей, например, подключение по RDP-порту есть,а сессия реально не создается (черный экран)), во-вторых, исключит сервер из кластера NLB (это можно сделать с помощью WMI).

Вот так и получается, что NLB это не совсем network load balancing и не совсем cluster – всему, что написано в цитате выше, дословно верить нельзя – надо осознать, что такое NLB на самом деле.

Цитата из документации Network Load Balancing Step-by-Step Guide :

TS Session Broker enables you to load balance sessions between terminal servers in a farm. This functionality is provided by the TS Session Broker Load Balancing feature. However, this session-based load balancing feature requires a front-end load balancing mechanism to distribute the initial connection requests to the terminal server farm. You can use a load balancing mechanism such as DNS round robin, NLB or a hardware load balancer to distribute the initial connection requests.

Ого-го! Оказывается вся необходимость в NLB заключается в том, чтобы распределять между серверами терминальной фермы первичные запросы! А что такое первичный запрос? В ответ от терминального сервера клиент должен получить указание подключиться к брокеру, а уже тот даст клиенту адрес сервера в ферме, где будет создана сессия. Нагрузка, создаваемая первичным запросом, как видно, невелика, но ответ на первичный запрос критически важен.

Как было описано выше, такую работу NLB делает, но не слишком уж надежно, и что самое плохое при падении сервиса NLB не исключает сервер из кластера (нужны внешние средства, чтобы диагностировать ситуацию и исключить сервер из кластера или восстановить сервис). Другое дело DNS round robin с коротким временем жизни записи для имени фермы: клиент, попав на мертвый сервис, через некоторое время (30 секунд) все равно переключится на другой адрес! Получается, что конфигурация с DNS round robin не только проще в настройке, но и надежнее. А если ферма большая и хорошо нагруженная, то напрашивается вариант с аппаратным балансировщиком. (Хотя прежде чем его покупать, можно рассмотреть вариант выделенного редиректора в терминальной ферме: терминального сервера, единственной задачей которого будет прием первичных запросов на подключение от клиентов. Редиректор также можно резервировать не через NLB, а DNS round robin.)

Осталось сравнить обеспечение надежности, которое реализует NLB и сам Connection Broker. Проблемы с NLB мы уже знаем. Connection Broker работает более грамотно. Он контролирует приходящие редиректы от серверов фермы и таким образом понимает, что терминальный север жив и здоров. Если редиректов нет более 60 секунд (параметр TimeServerSilentBeforePing), то Connection Broker начинает пинговать терминальный сервер, и если несколько пингов подряд (параметр NumberFailedPingsBeforePurge) завершаются неудачно, Connection Broker исключает сервер из свой базы. Как видите Connection Broker работает гораздо умнее NLB.

В данной статье будет показано, как построить отказоустойчивый кластер Server 2012 с двумя узлами. Сначала я перечислю обязательные условия и представлю обзор настроек аппаратной среды, сети и хранилища данных. Затем будет подробно описано, как дополнить Server 2012 функциями отказоустойчивой кластеризации и использовать диспетчер отказоустойчивого кластера для настройки кластера с двумя узлами

В Windows Server 2012 появилось так много новшеств, что за всеми уследить трудно. Часть наиболее важных строительных блоков новой ИТ-инфраструктуры связана с улучшениями в отказоустойчивой кластеризации. Отказоустойчивая кластеризация зародилась как технология для защиты важнейших приложений, необходимых для производственной деятельности, таких как Microsoft SQL Server и Microsoft Exchange. Но впоследствии отказоустойчивая кластеризация превратилась в платформу высокой доступности для ряда служб и приложений Windows. Отказоустойчивая кластеризация - часть фундамента Dynamic Datacenter и таких технологий, как динамическая миграция. Благодаря Server 2012 и усовершенствованиям нового протокола Server Message Block (SMB) 3.0 область действия отказоустойчивой кластеризации стала увеличиваться, обеспечивая непрерывно доступные файловые ресурсы с общим доступом. Обзор функциональности отказоустойчивой кластеризации в Server 2012 приведен в опубликованной в этом же номере журнала статье «Новые возможности отказоустойчивой кластеризации Windows Server 2012».

Обязательные условия отказоустойчивой кластеризации

Для построения двухузлового отказоустойчивого кластера Server 2012 необходимы два компьютера, работающие с версиями Server 2012 Datacenter или Standard. Это могут быть физические компьютеры или виртуальные машины. Кластеры с виртуальными узлами можно построить с помощью Microsoft Hyper-V или VMware vSphere. В данной статье используются два физических сервера, но этапы настройки кластера для физических и виртуальных узлов одни и те же. Ключевая особенность заключается в том, что узлы должны быть настроены одинаково, чтобы резервный узел мог выполнять рабочие нагрузки в случае аварийного переключения или динамической миграции. Компоненты, использованные в тестовом отказоустойчивом кластере Server 2012 представлены на рисунке.

Для отказоустойчивого кластера Server 2012 необходимо общее хранилище данных типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В нашем примере используется iSCSI SAN. Следует помнить о следующих особенностях хранилищ этого типа.

  • Каждый сервер должен располагать по крайней мере тремя сетевыми адаптерами: одним для подключения хранилища iSCSI, одним для связи с узлом кластера и одним для связи с внешней сетью. Если предполагается задействовать кластер для динамической миграции, то полезно иметь четвертый сетевой адаптер. Однако динамическую миграцию можно выполнить и через внешнее сетевое соединение - она просто будет выполняться медленнее. Если серверы используются для виртуализации на основе Hyper-V и консолидации серверов, то нужны дополнительные сетевые адаптеры для передачи сетевого трафика виртуальных машин.
  • В быстрых сетях работать всегда лучше, поэтому быстродействие канала связи iSCSI должно быть не менее 1 ГГц.
  • Цель iSCSI должна соответствовать спецификации iSCSI-3, в частности обеспечивать постоянное резервирование. Это обязательное требование динамической миграции. Оборудование почти всех поставщиков систем хранения данных соответствует стандарту iSCSI 3. Если нужно организовать кластер в лабораторной среде с небольшими затратами, обязательно убедитесь, что программное обеспечение цели iSCSI соответствует iSCSI 3 и требованиям постоянного резервирования. Старые версии Openfiler не поддерживают этот стандарт, в отличие от новой версии Openfiler с модулем Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). Кроме того, бесплатная версия StarWind iSCSI SAN Free Edition компании StarWind Software (http://www.starwindsoftware.com/starwind-free) полностью совместима с Hyper-V и динамической миграцией. Некоторые версии Microsoft Windows Server также могут функционировать в качестве цели iSCSI, совместимой со стандартами iSCSI 3. В состав Server 2012 входит цель iSCSI. Windows Storage Server 2008 R2 поддерживает программное обеспечение цели iSCSI. Кроме того, можно загрузить программу Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx?id=19867), которая работает с Windows Server 2008 R2.

Дополнительные сведения о настройке хранилища iSCSI для отказоустойчивого кластера приведены во врезке «Пример настройки хранилища iSCSI». Более подробно о требованиях к отказоустойчивой кластеризации рассказано в статье «Failover Clustering Hardware Requirements and Storage Options» (http://technet.microsoft.com/en-us/library/jj612869.aspx).

Добавление функций отказоустойчивой кластеризации

Первый шаг к созданию двухузлового отказоустойчивого кластера Server 2012 - добавление компонента отказоустойчивого кластера с использованием диспетчера сервера. Диспетчер сервера автоматически открывается при регистрации в Server 2012. Чтобы добавить компонент отказоустойчивого кластера, выберите Local Server («Локальный сервер») и прокрутите список вниз до раздела ROLES AND FEATURES. Из раскрывающегося списка TASKS выберите Add Roles and Features, как показано на экране 1. В результате будет запущен мастер добавления ролей и компонентов.

Первой после запуска мастера откроется страница приветствия Before you begin. Нажмите кнопку Next для перехода к странице выбора типа установки, на которой задается вопрос, нужно ли установить компонент на локальном компьютере или в службе Remote Desktop. Для данного примера выберите вариант Role-based or feature-based installation и нажмите кнопку Next.

На странице Select destination server выберите сервер, на котором следует установить функции отказоустойчивого кластера. В моем случае это локальный сервер с именем WS2012-N1. Выбрав локальный сервер, нажмите кнопку Next, чтобы перейти к странице Select server roles. В данном примере роль сервера не устанавливается, поэтому нажмите кнопку Next. Или можно щелкнуть ссылку Features в левом меню.

На странице Select features прокрутите список компонентов до пункта Failover Clustering. Щелкните в поле перед Failover Clustering и увидите диалоговое окно со списком различных компонентов, которые будут установлены как части этого компонента. Как показано на экране 2, по умолчанию мастер установит средства управления отказоустойчивыми кластерами и модуль отказоустойчивого кластера для Windows PowerShell. Нажмите кнопку Add Features, чтобы вернуться на страницу выбора компонентов. Щелкните Next.

На странице Confirm installation selections будет показана функция отказоустойчивого кластера наряду с инструментами управления и модулем PowerShell. С этой страницы можно вернуться и внести любые изменения. При нажатии кнопки Install начнется собственно установка компонентов. После завершения установки работа мастера будет завершена и функция отказоустойчивого кластера появится в разделе ROLES AND FEATURES диспетчера сервера. Этот процесс необходимо выполнить на обоих узлах.

Проверка отказоустойчивого кластера

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

Чтобы открыть диспетчер отказоустойчивого кластера, выберите параметр Failover Cluster Manager в меню Tools в диспетчере сервера. В области Management щелкните ссылку Validate Configuration, как показано на экране 3, чтобы запустить мастер проверки настроек.
Экран 3. Запуск мастера проверки конфигурации

Сначала выводится страница приветствия мастера. Нажмите кнопку Next, чтобы перейти к выбору серверов или странице Cluster. На этой странице введите имена узлов кластера, который необходимо проверить. Я указал WS2012-N1 и WS2012-N2. Нажмите кнопку Next, чтобы показать страницу Testing Options, на которой можно выбрать конкретные наборы тестов или запустить все тесты. По крайней мере в первый раз я рекомендую запустить все тесты. Нажмите кнопку Next, чтобы перейти на страницу подтверждения, на которой показаны выполняемые тесты. Нажмите кнопку Next, чтобы начать процесс тестирования кластера. В ходе тестирования проверяется версия операционной системы, настройки сети и хранилища всех узлов кластера. Сводка результатов отображается после завершения теста.

Если тесты проверки выполнены успешно, можно создать кластер. На экране 4 показан экран сводки для успешно проверенного кластера. Если при проверке обнаружены ошибки, то отчет будет отмечен желтым треугольником (предупреждения) или красным значком "X" в случае серьезных ошибок. С предупреждениями следует ознакомиться, но их можно игнорировать. Серьезные ошибки необходимо исправить перед созданием кластера.

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

На странице Access Point for Administering the Cluster следует указать имя и IP-адрес кластера, которые должны быть уникальными в сети. На экране 7 видно, что имя моего кластера WS2012-CL01, а IP-адрес - 192.168.100.200. При использовании Server 2012 IP-адрес кластера может быть назначен через DHCP, но я предпочитаю для своих серверов статически назначаемый IP-адрес.

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 8). На этой странице можно проверить настройки, сделанные при создании кластера. При необходимости можно вернуться и внести изменения.

После нажатия кнопки Next на странице подтверждения формируется кластер на всех выбранных узлах. На странице хода выполнения показаны шаги мастера в процессе создания нового кластера. По завершении мастер покажет страницу сводки с настройками нового кластера.

Мастер создания кластера автоматически выбирает хранилище для кворума, но часто он выбирает не тот диск кворума, который хотелось бы администратору. Чтобы проверить, какой диск используется для кворума, откройте диспетчер отказоустойчивого кластера и разверните кластер. Затем откройте узел Storage и щелкните узел Disks. Диски, доступные в кластере, будут показаны на панели Disks. Диск, выбранный мастером для кворума кластера, будет указан в разделе Disk Witness in Quorum.

В данном примере для кворума был использован Cluster Disk 4. Его размер 520 Мбайт, чуть больше минимального значения для кворума 512 Мбайт. Если нужно использовать другой диск для кворума кластера, можно изменить настройки кластера, щелкнув правой кнопкой мыши имя кластера в диспетчере отказоустойчивого кластера, выбрав пункт More Actions и Configure Cluster Quorum Settings. В результате появится мастер выбора конфигурации кворума, с помощью которого можно изменить параметры кворума кластера.

Настройка общих томов кластера и роли виртуальных машин

Оба узла в моем кластере имеют роль Hyper-V, так как кластер предназначен для виртуальных машин с высокой доступностью, обеспечивающих динамическую миграцию. Чтобы упростить динамическую миграцию, далее требуется настроить общие тома кластера Cluster Shared Volumes (CSV). В отличие от Server 2008 R2, в Server 2012 общие тома кластера включены по умолчанию. Однако все же требуется указать, какое хранилище следует использовать для общих томов кластера. Чтобы включить CSV на доступном диске, разверните узел Storage и выберите узел Disks. Затем выберите диск кластера, который нужно использовать как CSV, и щелкните ссылку Add to Cluster Shared Volumes на панели Actions диспетчера отказоустойчивого кластера (экран 9). Поле Assigned To этого диска кластера изменится с Available Storage на Cluster Shared Volume (общий том кластера), как показано на экране 9.

В это время диспетчер отказоустойчивого кластера настраивает хранилище диска кластера для CSV, в частности добавляет точку подключения в системном диске. В данном примере общие тома кластера включаются как на Cluster Disk 1, так и на Cluster Disk 3 с добавлением следующих точек подключения:

* C:ClusterStorageVolume1 * C:ClusterStorageVolume2

На данном этапе построен двухузловой кластер Server 2012 и включены общие тома кластера. Затем можно установить кластеризованные приложения или добавить в кластер роли. В данном случае кластер создан для виртуализации, поэтому добавляем роль виртуальной машины в кластер.

Чтобы добавить новую роль, выберите имя кластера на панели навигации диспетчера отказоустойчивого кластера и щелкните ссылку Configure Roles на панели Actions, чтобы запустить мастер высокой готовности. Нажмите кнопку Next на странице приветствия, чтобы перейти на страницу выбора роли. Прокрутите список ролей, пока не увидите роль виртуальной машины, как показано на экране 10. Выберите роль и нажмите кнопку Next.

На странице выбора виртуальной машины будут перечислены все VM на всех узлах кластера, как показано на экране 11. Прокрутите список и выберите виртуальные машины, которым необходимо обеспечить высокую готовность. Нажмите кнопку Next. Подтвердив свой выбор, нажмите Next, чтобы добавить роли виртуальной машины в диспетчер отказоустойчивого кластера.

Пример настройки хранилища iSCSI

Для отказоустойчивого кластера Windows Server 2012 требуется общее хранилище, которое может быть типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В данном отказоустойчивом кластере используется Channel SAN.

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Экран A. Настройка iSCSI Initiator

Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV). При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B. При создании кластера диски будут показаны как доступное хранилище.