Анти NLB в ферме терминальных серверов. Создание отказоустойчивой фермы Remote Desktop Connection Broker

25.03.2019

В данной статье я приведу подробную пошаговую инструкцию по установке сервера терминалов (англ. terminal server), или по другому, службы удаленных рабочих столов в Windows Server 2012. В принципе, последовательность действий не сильно отличается от установки , однако есть ряд значимых отличий. Итак:

1. Что понадобится

  1. Компьютер (сервер) с установленной на нем Windows Server 2012 (об установки этой ОС, я писал ) и права администратора на данном сервере.
  2. Действительная клиентская лицензия сервера терминалов, приобретенная по одной из существующих программ лицензирования. (В данной статье я буду использовать найденный в интернете номер соглашения, по программе Enterprise Agriment. На момент написания статьи рабочими были номера: 6565792, 5296992, 3325596, 4965437, 4526017.)
  3. Доступ к сети Internet для активации сервера лицензирования и установки лицензий (возможна также активация и по телефону).

2. Установка службы удаленных рабочих столов

Запускаем Диспетчер серверов. Его можно запустить с ярлыка на панели задач, или же выполнив команду servermanager.exe (Для этого необходимо нажать комбинацию клавиш Win + R, в появившемся окне в поле «Открыть » (Open ) написать имя команды и нажать «ОК »).

В меню, в верхнем правом углу, выбираем «Управление » (Manage ) — «Добавить роли и компоненты » (Add Roles and Features ) .

Запустится «Мастер добавления ролей и компонентов » (Add Roles and Features Wizard) . Нажимаем «Далее » (Next) на начальной странице.

Оставляем переключатель на «Установка ролей и компонентов » (Role-based or features-based installation ) и снова жмем «Далее » (Next) .

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В моем примере это данный локальный сервер. Нажимаем «Далее » (Next) .

Отмечаем роль «» (Remote Desktop Services ) в списке ролей и жмем «Далее » (Next) .

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее » (Next) .

Читаем описание службы удаленных рабочих столов и нажимаем «Далее » (Next) .

Теперь необходимо выбрать устанавливаемые службы ролей. Как минимум нам пригодится «Лицензирование удаленных рабочих столов » (Remote Desktop Licensing ) (также соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты » (Add Features ) в появившемся мастере)

и «» (Remote Desktop Session Host ) (опять соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты » (Add Features ) в открывшемся окне). Отметив необходимы службы ролей, нажимаем «Далее » (Next) .

Все параметры установки роли определены. На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется » (Restart the destination server automatically if required ) , подтвердим выбор нажав «Да » (Yes ) в появившемся окне и нажмем «Установить » (Install ) для запуска установки службы.

Если все прошло хорошо, после перезагрузки, увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть » (Close ) для завершения работы мастера.

3. Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «» (RD Licensing Diagnoser) . Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства » (Tools ) — «Terminal Services » — «Средство диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) .

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc .

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:

  • «Конфигурация компьютера » (Computer Configuration )
    • «Административные шаблоны » (Administrative Templates )
      • «Компоненты Windows » (Windows Components )
        • «Службы удаленных рабочих столов » (Remote Desktop Services )
          • «Узел сеансов удаленных рабочих столов » (Remote Desktop Session Host )
            • «Лицензирование » (Licensing )

Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов » (Use the specified Remote Desktop license servers ) , кликнув 2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено » (Enabled ) . Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК » .

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов » (Set the Remote licensing mode ) . Также устанавливаем переключатель в «Включено » (Enabled ) и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта:

  • «На пользователя» (Per User)
  • «На устройство» (Per Device)

Для того, чтобы разобраться чем отличаются эти режимы, рассмотрим простой пример. Предположим, у Вас есть 5 лицензий. При режиме «На устройство » вы можете создать неограниченное число пользователей на сервере, которые смогут подключаться через удаленный рабочий стол только с 5 компьютеров, на которых установлены эти лицензии. Если выбрать режим «На пользователя », то зайти на сервер смогут только 5 выбранных пользователей, независимо с какого устройства они подключаются.

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК » .

Изменив вышеперечисленные политики, закрываем редактор.

Возвращаемся в оснастку «Средство диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) и видим новую ошибку, указывающую на то, что сервер лицензирования указан, но не включен.

Для запуска сервера лицензирования переходим в «» (RD Licensing Manager ) . Найти его можно в диспетчере серверов, вкладка «Средства » (Tools ) — «Terminal Services » — «Диспетчер лицензирования удаленных рабочих столов » (Remote Desktop Licensing Manager ) .

Здесь найдем наш сервер лицензирования, со статусом «Не активирован » (Not Activated ) . Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер » (Activate Server ) .

Запустится Мастер активации сервера. Жмем «Далее » (Next) на первой странице мастера.

Затем выбираем метод подключения («Авто » (Automatic connection ) по умолчанию) и жмем «Далее » (Next) .

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее » (Next) .

Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее » (Next) .

Сервер лицензирования активирован. Теперь следует установить лицензии. Для этого нажимаем «Далее » (Next) оставив включенным флаг «Запустить мастер установки лицензий » .

4. Установка лицензий на сервер лицензирования службы удаленных рабочих столов

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement «» . Жмем «Далее » (Next) .

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее » (Next) .

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

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

Ну и наконец возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.

На этом установка сервера терминалов в Windows Server 2012 завершена.

5. Подключение к серверу терминалов

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

Помогла ли Вам данная статья?

Remote Desktop Connection Broker (RD Connection Broker), ранее известный под именем Terminal Services Session Broker (TS Session Broker), — это роль сервера Windows 2008 R2, предоставляющая следующий функционал:

  • Позволяет пользователям переподключаться к своим текущим сессиям в ферме серверов RD Session Host (терминальные сервера Windows). Тем самым предотвращается создание новых пользовательских подключений на других серверах фермы при наличии подключения в состоянии «disconnected».
  • Позволяет равномерно распределить нагрузку между серверами терминальной фермы RD.

RD Connection Broker отслеживает все сессии пользователей в ферме терминальных серверов Windows Server 2008 R2. База данных RD Connection Broker хранит сессионную информацию, включая имена серверов RD Session Host, на которых находятся сессии пользователя, идентификатор сессии (session ID) и имя пользователя, ассоциированное с сессией. Служба RD Connection Broker использует эту информацию для перенаправления пользователя, уже имеющего активную терминальную сессию на тот сервер, на котором она запущена.

В том случае, если пользователь отключился (disconnect) от своей сессии (из-за сетевого сбоя или осознанно), все приложения, которые он запустил на сервере продолжают работать. И когда пользователь пытается вновь подключиться к ферме терминалов, Connection Broker определяет сервер, на котором уже имеется сессия пользователя и перенаправляет подключение пользователя именно туда.

Балансировка нагрузки RD Connection Broker Load Balancing, позволяет при подключении пользователя (предполагается, что у него не осталось подключений в состоянии disconnect) к ферме, перенаправить его на наименее загруженный сервер фермы (с наименьшим количеством пользовательских сессий). Чтобы более гибко управлять балансировкой нагрузки в ферме терминальных серверов, администратор может в зависимости от вычислительных мощностей серверов фермы назначить каждому из них относительный вес.

Компоненты RD Connection Broker

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

Сервер RD Connection Broker . Это сервер с запущенной службой Remote Desktop Connection Broker, который отслеживает сессии пользователей и осуществляет балансировку нагрузки между членами фермы RD. Существует имя сервера RD Connection Broker, с помощью которого можно отнести конкретный терминальный сервер к той или иной ферме.

Сервера RD Session Host , настроенные на использование Connection Broker. Это рядовые члены терминальной фермы. Для того, чтобы являться членом фермы под управление RD Connection Broker, терминальный сервер должен соответствовать следующим критериям:

  • На сервере должна быть установлена роль RD Session Host.
  • Сервер должен быть членом домена Active Directory.
  • Сервер должен входить в локальную группу «Session Broker Computers» на сервере с ролью RD Connection Broker.

Последовательность настройки терминальной фермы RD Connection Broker с балансировкой нагрузки:

  1. Установите роль RD Connection Broker на сервере (это может быть выделенный сервер, или один из членов будущей фермы).
  2. Добавьте все терминальные сервера в локальную группу безопасности «Session Broker Computers» на сервере с ролью RD Connection Broker.
  3. Настройте всех членов фермы на использование сервера RD Connection Broker
  4. Настройте записи DNS для реализация механизма «DNS round robin»

Шаг 1: Установка роли Connection Broker

Если роль Remote Desktop Services уже установлена:

  • Разверните роль Remote Desktop Services.
  • Нажмите кнопку Add Role Services.
  • На странице служб роли выберите Remote Desktop Connection Broker и нажмите Next

В моем стенде 2 сервера, настроенных следующим образом:

RDS01

Шаг 2: Добавляем сервера RD Session Host в локальную группу Session Broker Computers.

Для этого на сервер с установленной ролью RD Connection Broker :

  • Нажмите Start -> Administrative Tools -> Computer Management.
  • В левой панели разверните узел Local Users and Groups, и выберите Groups.
  • Найдите локальную группу Session Broker Computers , и выберите пункт Properties.
  • На вкладке General, нажмите Add.
  • В окне выбора нажмите кнопку Object Types.
  • Отметьте пункт Computers, и нажмите OK.
  • Последовательно укажите и добавьте имена всех серверов, которые будут участвовать в терминальной ферме
  • Нажмите OK.

Шаг 3: Включаем сервера RD Session Host в ферму RD Connection Broker , настраиваем балансировку нагрузки

На каждом из терминальных серверов RD Session Host выполните следующее:

  • На сервер RD Session Host откройте консоль Remote Desktop Session Host Configuration (Start ->Administrative Tools->Remote Desktop Services -> Remote Desktop Session Host Configuration).
  • В разделе Edit settings, щелкните по полю Member of farm in RD Connection Broker.
  • На вкладке RD Connection Broker нажмите кнопку Change Settings.
  • В окне RD Connection Broker Settings выберите Farm member.
  • Введите имя сервера с ролью RD Connection Broker.
  • В окне Farm name, укажите имя создаваемой фермы.
  • Чтобы активировать балансировку нагрузки в ферме RD Connection Broker отметьте опцию Participate in Connection Broker Load-Balancing.
  • В случае необходимости можно настроить относительный вес каждого из серверов в ферме (Server weight). Значение по умолчанию — 100. В том случае, если вы зададите вес одного сервера 100, а другого 50, это будет означать, что сервер с меньшим весом будет получать в 2 раза меньше подключений.
  • По умолчанию используется перенаправление по IP адресу (IP address redirection), также можно использовать перенаправление по токену (Use token redirection).

Я выполнил соответствующую настройку на обоих серверах RDS01 и RDS02


Task 4: Настройка DNS round robin

Для балансировки нагрузки в терминальных фермах RD Session Host, можно использовать балансировку нагрузки RD Connection Broker Load Balancing совместно с функцией DNS round robin. Во втором случае, вы должны для каждого из серверов членов фермы создать DNS запись (тип A), создающую соответствие между IP адресом каждого сервера RD Session Host и DNS именем фермы.

Я опишу процедуру настройки DNS записей на контроллере домена Windows Server 2008 R2. Сразу стоит отметить, что для выполнения данной процедуры у вас должны быть права Domain Admins/ Enterprise Admins / DNS Admins.

  • Откройте оснастку DNS (Start->Administrative Tools-> DNS).
  • Разверните сервер, и в зонах прямого просмотра (Forward Lookup Zones), разверните ветку с именем вашего домена.
  • Щелкните по зоне и выберите New Host (A or AAAA).
  • В поле Name укажите имя фермы (именно фермы, а не конкретного сервера в ней), а в поле IP address укажите ip адрес первого сервера в ферме.

Эти действия необходимо повторить для каждого из серверов-членов фермы RDS (в каждом случае меняться будет только ip адрес)

Проверим, что наша ферма создалась, для чего откройте Remote Desktop Services Manager. Щелкните правой кнопкой по Remote Desktop Services Manager и выберите Import from RD Connection Broker и укажите FQDN имя сервера с ролью Connection broker(в моем случае RDS01.сайт)

Теперь в дереве RD Connection Broker появится новая терминальная ферма!

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

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

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

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

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

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

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

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

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

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


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

Как мы видим, имя нашего домена – domain.local. Для доступа к терминальным службам снаружи будет использоваться доменное имя domain.ru. Таким образом, в нашем DNS домена domain.local нам необходимо будет создать дополнительную зону с именем domain.ru, где мы потом создадим запись RDS.domain.ru, которая будет ссылаться на IP адрес терминальной фермы.

1. Установка терминальных служб на сервер RDS1.

1.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:
1.2 Создадим в ДНС нашего домена запись RDFarm.domain.local, которой присвоим IP адрес 192.168.0.80. Это будет внутренний адрес нашей фермы, а также адрес кластера NLB.
1.3 Создадим в ДНС зоне domain.ru нашего домена запись RDS.domain.ru, которой присвоим тот же IP адрес, что и адрес кластера - 192.168.0.80. Это будет внешний адрес нашей фермы, через который будут заходить удаленные пользователи.
1.4 Заходим в оснастку Remote Desktop Services – RemoteApp Manager – RD Gateway и настраиваем параметры следующим образом:

На закладке Digital Signature указываем сертификат, который надо предварительно запросить. Для выполнения этого шага в вашем домене должен быть центр сертификации (CA). На сервере RDS1 запустите mmc и добавьте оснастку Certificates (computer account):

Теперь на закладке Digital Signature мы можем указать наш сертификат:

1.5 Заходим в оснастку Remote Desktop Services – RemoteApp Manager и в разделе RemoteApp Programs и добавим одно удаленное приложение. Пусть это будет калькулятор.

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

1.6 Заходим в оснастку Remote Desktop Services – RD Gateway Manager и настраиваем свойства RDS1 (Local). Но перед этим необходимо запросить еще один сертификат (см. пункт 1.4), но на сей раз с Common Name внешнего адреса – RDS.domain.ru.

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

После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.

Теперь указываем этот сертификат в свойствах нашего шлюза удаленных рабочих столов:

Переходим на закладку Server Farm, где добавим наш сервер RDS1 в ферму шлюзов:

Обратите внимание, что на данном этапе поле статус не обязательно должно иметь состояние «ОК».

1.7 Заходим в оснастку Remote Desktop Services – RD Gateway Manager - RDS1 (Local) – Policies – Connection Authorization Policies и создаем политику авторизации подключений при помощи мастера:

1.8 Заходим в оснастку Remote Desktop Services – RD Gateway Manager - RDS1 (Local) – Policies – Resource Authorization Policies и создаем политику авторизации приложений минуя мастер (Create New Policy – Custom):

1.9 Заходим в оснастку Remote Desktop Services – RD Session Host Configuration и настраиваем свойства подключения RDP-Tcp следующим образом:

Нажимаем на кнопку «Select» и указываем сертификат с Common Name нашей фермы – RDFarm.domain.local (он уже был установлен на сервер в пункте 1.4).

Остальные параметры не настраиваем.

Здесь же, в RD Session Host Configuration, настраиваем параметры лицензирования.

1.10 Для проверки правильности настройки приложения RemoteApp заходим на адрес localhost/RDWeb

2. Установка терминальных служб на сервер RDS2.

2.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:

Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)

Шлюз удаленных рабочих столов (Remote Desktop Gateway)

Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)

Сервер политики сети (NPS)

При установке служб ставим галочку «Require NLA», остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.

2.2 Настраиваем второй сервер RDS2 точно таким же образом, как и настроен наш первый сервер за исключением того, что сертификаты уже запрашивать не нужно – их надо импортировать с сервера RDS1. Для импортирования сертификатов запустите mmc и добавьте оснастку Certificates (computer account):

Укажите путь к pfx файлам, содержащим сертификаты, и импортируйте их в личные сертификаты компьютера RDS2.

3. Создание и конфигурирование терминальной фермы.

3.1 Устанавливаем роль RD Connection Broker на сервер BROKER.

3.2 Добавляем сервера RDS1 и RDS2 в локальную группу Session Broker Computers на сервере BROKER.

3.3 Добавляем все наши три сервера в локальную группу TS Web Access Computers на серверах RDS1 и RDS2

3.4 На сервере BROKER добавляем наши сервера RDS1 и RDS2 в группу RD Web Access (Admin Tools > Remote Desktop Services > Remote Desktop Connection Manager > Add RD Web Access Server).

3.5 Сперва на сервере RDS1, а затем и на RDS2, заходим в Remote Desktop Services > Remote Desktop Session Host Configuration и меняем настройки RD Connection Broker:

3.6 Настраиваем удаленные приложения RemoteApp на работу с нашей фермой. Для этого на серверах RDS1 и RDS2 заходим в Remote Desktop Services > RemoteApp Manager и меняем параметр Server Name:

3.7 На сервере BROKER идем в Remote Desktop Services > Remote Desktop Connection Manager > RemoteApp Sources и жмем кнопку «Add RemoteApp Source…»:

Добавляем все наши возможные ресурсы RemoteApp: RDFarm.domain.local, RDS1.domain.local, RDS2.domain.local и RDS.domain.ru.

3.8 Создаем кластер NLB.

3.8.1 Устанавливаем компонент Network Load Balancing на сервера RDS1 и RDS2. Далее открываем оснастку Network Load Balancing Manager на сервере RDS1 и создаем кластер:

Включаем в балансировку только 443 и 3389 TCP порты.

3.8.2 Добавляем второй компьютер (RDS2) в NLB кластер

3.9 Удостоверяемся, что на серверах RDS1 и RDS2, в свойствах сервера RD Gateway Manager на закладке Server Farm указаны оба наших сервера:

3.10 На серверах RDS1 и RDS2 заходим в оснастку IIS Manager, далее Sites – Default Web Site – RDWeb – Pages и справа жмем Application Settings, где присваиваем параметру DefaultTSGateway значение RDS.domain.ru:

4. Публикация фермы RemoteApp приложений на ISA Server.

Вначале необходимо установить наш сертификат с Common Name «RDS.domain.ru» на ISA сервер (сделать это можно так же, как в случае с сервером RDS2, когда мы переносили на него сертификат с RDS1).

Этот раздел я не буду рассматривать слишком подробно, а обойдусь лишь наиболее важными скриншотами с настройками правила публикации и созданием WEB-прослушивателя:

Спасибо за внимание.

Remote Desktop Connection Broker (RD Connection Broker) – это функционал роли терминального сервера Windows Server. RD Connection Broker позволяет равномерно распределить нагрузку между серверам в ферме Remote Desktop (при подключении к RDS пользователя перенаправляет на наименее загруженный сервер), обеспечить доступ пользователей к VDI и RemoteApp, а также реализует возможность переподключения пользователей к своим сессиям (при подключении к новому серверу RDS, RDCB проверяет наличие незавершенной сессии на других серверах фермы, и в случае ее обнаружения новая сессия не создается, а пользователь перенаправляется в старую сессию).

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

В отличии от реализации , Connection Broker в Windows Server 2012 обеспечивает высокую доступность в режиме Active/Active, когда каждый из серверов RDCB является активным и обрабатывает входящие запросы. Это позволяет обеспечить высокую доступность и масштабируемость RDCB в больших фермах Remote Desktop. Для хранения данных RDCB используется БД на MS SQL Server.

Примечание . В Windows Server 2008 R2 поддерживалась кластеризация службы RDCB только в режиме Active/Passive. Т.е. для фермы RD серверов поддерживался только один активный сервер Connection Broker.

Требования для внедрения отказоустойчивого RDCB

  • Как минимум 2 сервера с ролью RDCB (под ОС Windows Server 2012 / 2012 R2)
  • SQL Server (редакция SQL server 2008 R2 Standard или выше) c минимум 4 Гб RAM
  • Наличие установленного SQL Server Native Client
  • Полные права серверов RD Connection Broker на БД SQL и каталог установки SQL
  • Минимум один сервер с ролью Remote Desktop Session Host в ферме
  • Разрешенные исключения для портов SQL server в фаерволе Windows

Важно . Перед началом создания отказоустойчивой конфигурации RDCB, убедитесь, что эта роль установлена только на одном из серверов.

Всем серверам, на которых будут установлены роли RD Connection Broker необходимо назначить статические ip-адреса и включить в домен Active Drectory.

  • RDCB1.domain.ru — 172.25.104.71
  • RDCB2.domain.ru — 172.25.104.171

В Active Directory создадим отдельную группу безопасности RDS Connection Brokers , в которую нужно включить все сервера RDCB.

Далее на отдельном сервере (или SQL-кластере) устанавливается SQL Server версии 2008 R2 или 2012 Standard.

На SQL сервере с помощью SQL Server Management Studio в разделе Security нужно создать новый login и предоставить доменной группе RDCB права с возможностью создания и редактирования баз данных. Также этой группе нужно предоставить полные права на каталог установки SQL.

На SQL сервере нужно создать каталог, в котором будут храниться файлы БД, например, C:\SQLDB , и предоставить этой же группе полные права на каталог.

На всех серверах с ролью RDCB необходимо установить. Его нужно скачать отдельно с сайта MS, либо запустить прямо с установочного диска (на установочном диске SQL Server 2012 он хранится в каталоге \1033_ENU_LP\x64\Setup\x64\sqlncli.msi).

Для SQL server 2008 R2 нужен SQL native client 10, для SQL Server 2012 — SQL Native client 11.

В брандмауэра SQL-сервера создадим новое правило, открывающее порт TCP 1433 для доменных машин. Сделать это можно так:

netsh advfirewall firewall add rule name = SQLSRVPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN

Следующий шаг – создание в DNS зоне A записей для реализации балансировки нагрузки (Round Robin) между серверами RD Connection Broker. Например, DNS имя нашей фермы RDCB будет RDCB_lb . Создадим две следующие A записи вида:

  • A RDCB_lb.domain.ru 172.25.104.71 (ip адрес RDCB1)
  • A RDCB_lb.domain.ru 172.25.104.171 (ip адрес RDCB2)

С помощью консоли Server Manager на первом из серверов RDCB устанавливаем роль RD Connection Broker (если еще не установлена).

После установки роли RDCB используется маленькая локальная база SQL, хранящаяся на локальном диске сервера RD Connection Broker в каталоге c:\windows\rdcbDb\ .

В этой базе хранится информация о ферме и терминальный сессиях пользователей. Так как она расположена на локальной машине, другие сервера RDCB не смогут ее использовать. Для создания HA для RDCB нужно перенести ее на выделенный SQL сервер, на котором она будет доступна другим серверам.

Для переноса БД на выделенный SQL Server нужно перейти на вкладку управления Remote Desktop Services -> Overview . Для запуска мастера создания отказоустойчивой конфигурации RD Connection Broker, щёлкнем ПКМ по изображению роли RD Connection Broker и выбираем пункт Configure High Availability . Запустившийся мастер должен создать БД на MS SQL Server и перенести в нее локальную конфигурацию.

Заполним три поля:

  • Database Connection String – строка подключения с базе на SQL сервере.Для SQL 2008 R2 : DRIVER=SQL Server Native Client 10.0;SERVER=

    Для SQL 2012 :DRIVER=SQL Server Native Client 11.0;SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=

  • Folder to store database files – каталог, в котором будут храниться файла БД: C:\SQLDB . Папка находится на SQL сервере, мы ранее ее создали и предоставили доступ группе серверов RDCB.
  • DNS Round Robin name : FQDN имя фермы RDCB, для которой мы создавали записи в DNS для Round Robin (в нашем примере это RDCB_lb ). Именно по этому адресу будут обращаться RDP клиенты при подключении к серверам RD Connection Broker.

Затем откроем SQL Server Manager на сервере СУБД и убедимся, что была создана новая база. Переходим на вкладку Security , выберем ранее добавленную группу — > свойства, и в качестве БД по-умолчанию выбираем базу RDS. Потом отмечаем роли db_owner и public .

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

Для этого щелкаем ПКМ по иконке RD Connection Broker, и выбираем пункт Add RD Connection Broker Server .

Указываем имя второго сервера, на котором нужно установить роль Connection Broker и жмем Далее.

На этом настройка High Availability конфигурации Connection Broker завершена.

Итак, мы создали высоко доступный сервис RD Connection Broker на Windows Server 2012. Вы можете протестируйте доступность RDCB, отключив один из серверов фермы RDCB. В этом сценарии точкой отказа остается SQL server. Отказоустойчивость SQL сервера можно реализовать с помощью HA SQL кластера или зеркалирования базы SQL.