Объяснение ферм серверов удаленных рабочих столов (часть 1)

Введение

В этой статье мы более подробно рассмотрим фермы удаленных рабочих столов в Windows Server 2008 R2. Ферма серверов удаленных рабочих столов состоит из нескольких хост-серверов сеансов удаленных рабочих столов. Зачем вам ферма RDS? Какие есть варианты? Каковы сценарии? Вот некоторые из вопросов, на которые мы ответим в этой статье. Конечно, также доступны сторонние инструменты, которые работают поверх ферм RDS и расширяют их, но в этой статье основное внимание будет уделено готовым решениям Microsoft.

Что такое ферма RDS?

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

Зачем нужна ферма RDS?

Итак, зачем нам ферма RDS? Я очень сомневаюсь в этом, но если вы не уверены, прочитайте этот абзац:

Существует несколько причин необходимости фермы RDS. Одна из причин очевидна: пользовательская база вашей организации выросла до количества, которое просто не «помещается» (с точки зрения технических ресурсов) на один сервер узла сеансов удаленных рабочих столов. Несмотря на то, что доступное оборудование растет чрезвычайно быстро, особенно с виртуализацией серверов, есть момент, когда оно просто больше не работает в соответствии с определенными стандартами на одном хосте сеансов удаленных рабочих столов. Еще одна важная причина, конечно, высокая доступность. Особенно, если вы размещаете полный рабочий стол на узле сеансов удаленных рабочих столов для своих пользователей, время простоя означает, что эти пользователи больше не могут выполнять свои повседневные задачи. Поэтому, как и в случае со всеми профессиональными ИТ-услугами, ваши серверы узла сеансов удаленных рабочих столов должны быть всегда доступны, что означает запуск нескольких серверов с ролью узла сеансов удаленных рабочих столов для соблюдения высоких стандартов SLA, касающихся времени безотказной работы и доступности. Конечно, виртуализация вашего сервера узла сеансов удаленных рабочих столов в кластере виртуализации серверов (например, в кластере Hyper-V) обеспечивает высокую доступность оборудования, но не решает (программные) проблемы на сервере узла сеансов удаленных рабочих столов. Третья причина – техническое обслуживание. Рассмотрите возможность обновления, обновления или обслуживания сервера узла сеансов удаленных рабочих столов. Если вы будете использовать один сервер, это может означать простои для ваших конечных пользователей. Однако, если вы используете ферму с несколькими серверами, вы можете очень быстро слить сервер (разрешив выполнение существующих подключений, но запретив дополнительные новые сеансы) до тех пор, пока он не освободится от сеансов, не создавая простоев для доставленной службы.

Каковы проблемы, связанные с фермой RDS?

Теперь, когда мы знаем, что такое ферма, и убеждены в том, что она нам нужна, давайте посмотрим, с какими функциональными проблемами, не вдаваясь в слишком много технических подробностей, нам придется здесь столкнуться. Итак, мы знаем, что в нашей среде будет несколько серверов узла сеансов удаленных рабочих столов. Как равномерно распределить рабочую нагрузку по этим серверам, чтобы оптимально использовать доступные ресурсы? Именно здесь вступает в действие термин балансировки нагрузки, метод распределения рабочей нагрузки на основе нескольких условий. Теперь, когда у нас есть несколько серверов узла сеансов удаленных рабочих столов, можно ли гарантировать, что в случае (сетевого) сбоя между клиентом и сервером, я вернусь к сеансу, который я оставил открытым? Да, оно может. Дополнительная роль Windows Server, называемая посредником подключений к удаленному рабочему столу, может убедиться, что вы это сделаете.

Какие есть сценарии и варианты?

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

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

Вариант 1: циклический DNS

Циклический DNS (часто называемый RR DNS или DNS RR) — это, хотя и очень простая, форма балансировки нагрузки. RR DNS реализуется путем указания записи DNS A (или AAAA) на несколько пунктов назначения. Давайте рассмотрим сценарий, в котором у нас есть три хост-сервера сеансов удаленных рабочих столов. Конфигурация DNS для создания RR DNS может быть следующей:

Хост RDSFarm1 (A) 192.168.1.20
Хост RDSFarm1 (A) 192.168.1.21
Хост RDSFarm1 (A) 192.168.1.22

В этом случае RDSFarm1 — это DNS-имя фермы, указывающее на три сервера узлов сеансов удаленных рабочих столов. Как работает балансировка нагрузки? Пользователи подключаются к ферме, запуская (предварительно) настроенный RDP-файл (либо через RD WebAccess, либо используя mstsc напрямую) и используют RDSFarm1 в качестве имени хоста. Клиент, на котором запущен сеанс RDP, разрешит имя хоста, и конструкция RR DNS вернет одну из записей DNS.

ПЛЮСЫ:

• простота установки и отсутствие дополнительных аппаратных или серверных ролей.

МИНУСЫ:

• RR DNS не обнаруживает отключенные серверы узла сеансов удаленных рабочих столов и может привести к тому, что пользователи будут подключаться к серверу, который недоступен.
• RR DNS не обнаруживает серверы узла сеансов удаленных рабочих столов, которые находятся в режиме обслуживания (режим слива), и может привести к тому, что пользователи будут подключаться к серверу, который недоступен.
• Сессии распределяются неравномерно из-за проблем, таких как, например, кеш DNS.
• Без посредника подключений к удаленному рабочему столу невозможно повторно подключиться к отключенному сеансу.

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

Вариант 2. Балансировка сетевой нагрузки

Балансировка сетевой нагрузки (сокращенно NLB) — это программная балансировка нагрузки, основанная на стандартной доступной роли сервера в Windows Server 2008 R2 (а также доступной в предыдущих выпусках Windows Server). Когда мы настраиваем NLB, нам снова нужно определить имя фермы, но на этот раз указать его на один IP-адрес (IP-адрес фермы). Не вдаваясь в технические подробности конфигурации, вы в основном создаете ферму NLB с именем фермы и IP-адресом, и этот адрес становится доступным в качестве «дополнительного адреса» на всех серверах узла сеансов удаленных рабочих столов. Опять же, пользователи подключаются к ферме, запуская (предварительно) настроенный RDP-файл (либо через RD WebAccess, либо используя mstsc напрямую) и используют RDSFarm1 в качестве имени хоста. На этот раз NLB обеспечивает отправку сеанса на сервер узла сеансов удаленных рабочих столов с наименьшей нагрузкой, основываясь на количестве сеансов на узел сеансов удаленных рабочих столов, которое NLB «подсчитывает».

ПЛЮСЫ:

• Дополнительное оборудование не требуется (за исключением сетевого оборудования, совместимого с NLB)
• Сеансы распределяются равномерно в зависимости от количества сеансов на узел сеансов удаленных рабочих столов.

МИНУСЫ:

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

NLB также можно комбинировать с ролью посредника подключений к удаленному рабочему столу. Опять же, мы рассмотрим это позже в этой статье.

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

Аппаратная балансировка нагрузки в основном имеет те же PROS, что и NLB, но, кроме того, может, в зависимости от типа оборудования (или программного обеспечения), распределять пользователей по узлу сеансов удаленных рабочих столов на основе лучших условий, чем просто количество сеансов. Большинство этих аппаратных или программных продуктов позволяют создавать «виртуальную нагрузку», которую можно определить. Например, доступный ЦП или память могут быть добавлены в качестве измерения. Кроме того, в качестве измерения можно добавить типичные запущенные приложения. Вы можете, если знаете, что конкретное приложение обычно использует много ресурсов, например, определить, что 10 пользователей на 1 узле сеансов удаленных рабочих столов работают, это приложение считается загруженным на 100%, и, таким образом, вы не разрешаете новые сеансы. Очевидным минусом этого сценария является, конечно же, тот факт, что вам нужно дополнительное оборудование или программное обеспечение.

Опять же, этот вариант также можно комбинировать с посредником подключений к удаленному рабочему столу.

Вариант 4. Балансировка нагрузки посредника подключений к удаленному рабочему столу

Посредник подключений к удаленному рабочему столу, как и узел сеансов удаленных рабочих столов, представляет собой роль сервера, поставляемую с Windows Server 2008 R2. (Нетехническая) функциональность такая же, как у NLB, новые сеансы отправляются на сервер с наименьшей нагрузкой в зависимости от количества подключений, о которых знает посредник подключений к удаленному рабочему столу. Однако здесь есть одно отличие; функция балансировки нагрузки посредника подключений к удаленному рабочему столу не имеет DNS-имени фермы для подключения. Так как же нам подключиться к ферме с балансировкой нагрузки с помощью посредника подключений к удаленному рабочему столу? Здесь представлен выделенный перенаправитель. Выделенный перенаправитель — это не что иное, как сервер с ролью узла сеансов удаленных рабочих столов, однако он не запускает никаких реальных подключений. По сути, это узел сеансов удаленных рабочих столов, работающий в режиме слива. Таким образом, пользователи подключаются к ферме, запуская (предварительно) настроенный RDP-файл (либо через RD WebAccess, либо используя mstsc напрямую) и используют имя хоста или полное доменное имя, указывающее на этот выделенный перенаправитель. Поскольку этот узел сеансов удаленных рабочих столов не разрешает новые подключения (режим стока), связывается с посредником подключений к удаленному рабочему столу, который выполняет свои действия по балансировке нагрузки, чтобы определить сервер с наименьшей нагрузкой, к которому будет подключаться пользователь. Имейте в виду, однако, что эта конструкция может привести к тому, что выделенный редиректор станет единой точкой отказа. Если вы не настроите несколько выделенных перенаправителей и не сбалансируете нагрузку, используя, например, RR DNS.

Центральная роль посредника подключений к удаленному рабочему столу

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

Несколько раз в статье мы упоминали, что параметры могут (и я считаю, должны) сочетаться с ролью посредника подключений к удаленному рабочему столу. Во второй части этой статьи мы продолжим с того места, на котором остановились, и обсудим центральную роль посредника подключений к удаленному рабочему столу и то, как его можно сочетать с описанными выше вариантами. Следите за обновлениями…