Добавление функций отказоустойчивой кластеризации. Установка терминальных служб на сервер RDS1

Оставьте комментарий 6,950

Почему «Анти 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.

Всем привет сегодня расскажу как настроить отказоустойчивый кластер 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 нового поколения

Чулан *