Данная статья написана в рамках общего описания настройки терминальных служб в Windows server 2012. Центральная статья с описанием тут.

Отказоустойчивость в RDS

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

Отказоустойчивость серверной части можно обеспечить на двух уровнях:

  • аппаратный — когда выход из строя физического сервера не ведет к долгому простою терминального сервера. Это легко осуществимо при использовании платформы виртуализации от любого производителя VMware, Citrix, Microsoft, у них у всех есть технология высокой доступности HA (High Availability) 
  • программный — когда выходит из строя операционная система (Windows server 2008 или 2012) и администратору приходится восстанавливать данные из резервной копии с неизбежной потерей информации. Чтобы пережить программные сбои нужно настраивать кластеры, дублирующие серверы и не забывать о резервном копировании.

Терминальный сервер 03

Клиентское устройство, очевидно, что это должен быть тонкий клиент, на котором не хранится никакой информации, только базовые настройки подключения. Он должен уметь подключаться к терминальному серверу (серверам) по RDP протоколу и отображать на экране монитора удаленный рабочий стол или опубликованные приложения. Таких тонких клиентов сейчас на рынке очень много, от недорогих китайских (3000 руб) до дорогих брендовых на платформе Windows Embedded (до 20 000 руб). Я предлагаю использовать вот такие решения — самосборные, HP, Wise.

Распределение нагрузки и отказоустойчивость. Если клиент будет подключаться напрямую к терминальному серверу (точка-точка), то в такой схеме не будет никакой отказоустойчивости. Выходит из строя сервер — работа встает. Нужно несколько терминальных серверов с одинаковым функционалом, чтобы при поломке первого клиент мог бы продолжить работу на втором, третьем и т.д. Для этого устанавливают посредник подключения к удаленными рабочим столам. В 2012 сервере (и ранее в 2008) в этой роли выступает RD connection broker – это роль, которую можно добавить через мастер добавления ролей в диспетчере сервера. Посредник подключений в первую очередь распределяет нагрузку между терминальными серверами, отправляет пользователей на тот сервер терминалов, на котором в данный момент меньше пользователей.
Для отказоустойчивости роль посредника устанавливали на два сервера, затем объединяли их в кластер, если в Windows server 2008 Broker работал по схеме Active – Passive, т.е. один из серверов посредника, находясь в простое, ждал, пока откажет основной, то в 2012 эта схема улучшена (переработана) и работает как Active –Active кластер. Клиенты поочередно обращаются то к одному, то к другому Connection Broker (за счет работы службы DNS Round Robin), который уже указывает на терминальный сервер к которому ему следует подключаться.
Но есть одно НО, для работы в отказоустойчивом режиме Connection Broker использует базу данных MSSQL. По логике отказоустойчивости нужно и ее дублировать, создавать кластер, а это еще больше усложнит схему.
Не забываем, про доменные службы, которые должны обеспечивать аутентификацию пользователей, DNS сервер должен разрешать имена, без этого наши терминальные службы тоже работать не будут.

Терминальный сервер 04

В итоге, для отказоустойчивой схемы потребуется как минимум два сервера с Ролью Connection Broker, два терминальных сервера, два MSSQL сервера, два контроллера домена и два DNS сервера. Плюс два сервера, на которых будут хранениться профили пользователей. Общая папка, в которой они будут храниться, должна реплицироваться между двумя серверами.

Теперь я задам вопрос: » Стоит ли городить такой огород из разнообразных служб Microsoft? Может быть есть другой способ?»
Думаю, что есть. Не создаем кластеры из MSSQL, контроллеров доменов, DNS серверов, а используя технологии виртуализации, реплицируем виртуальные машины на другой физический сервер и не забываем делать резервное копирование. Но такая схема потребует вмешательства администратора при сбое, он должен будет удостовериться, что основные виртуальные машины вышли из строя и в ручном режиме запустить реплики.

  • artem

    «Но есть одно НО, для работы в отказоустойчивом режиме Connection Broker использует базу данных MSSQL»

    Можно еще добавить — при потере базы, вся RDS инсталляция встает раком — починить нельзя только reinstall. Разобрать брокеры объединенные в HA нельзя, необратимая операция.