RDS 2012 R2. Тестирование высокой доступности.

RDS Blog home page


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

Исходная схема подразумевает дублирование основных ролей Remote Desktop Services:

Схема RDS HA

При проведении контрольных испытаний в ходе работы пользователей будет имитирован выход из строя 2 серверов:

  • RDCB1 — Connection Broker, Web Access, Gateway, Licensing
  • RDSH1 — Session Host

Схема RDS HA Crushtest

1.Отключение RDCB1.

При выходе из строя одного или даже всех серверов с ролью Connection Broker уже установленные соединения не будут прерваны. При выходе из строя одного из серверов (в данном случае RDCB1), пользователи которые устанавливаю новое подключение к удаленному приложению, подключатся в обычном режиме. Пользователей выход из строя сервера Connection Broker пройдет незаметно.

2.Отключение RDSH1.

Напомню, коллекция приложений включает в себя 2 сервера Session Host (RDSH1 и RDSH2). В коллекции присутствует балансировка нагрузки между серверами:

Crushtest-2014-10-09 12_30_37-Domain Users Свойства

При выходе из строя одного из серверов Session Host, события будут развиваться по более сложному сценарию:

Естественно, если активное подключение пользователя было установлено на сервере RDSH2, то для этого пользователя выход из строя RDSH1 пройдет незаметно 🙂

В данном примере пользователь alekssh подключен к приложению на сервере RDSH1.lab.local:

Rights-2014-10-10 13_02_48-Диспетчер серверов

Ну а если серьезно, то при выходе из строя сервера, на котором есть активные подключения, то пользователи, подключенные к этому серверу, увидят следующую картину, на примере WordPad:

2014-10-09 12_36_23-Program Manager

Если в течении 5 минут сервер RDSH1 вновь станет доступным, то пользователи смогут подключиться к своему текущему сеансу.

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

2014-10-09 12_50_19-Document - WordPad (Laboratory)

В консоли коллекции приложений можно увидеть что сеанс пользователя находится на  сервере RDSH2:

Rights-2014-10-10 13_16_57-Диспетчер серверов

 Как видно по времени активного сеанса, прошло 10 минут с момента выхода из строя сервера RDSH1 до подключения пользователя к новому сеансу на другом сервере.

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


 

Реклама

Об авторе Alexander Shestakov

MCITP, MCSE. Компания "Динамика"
Запись опубликована в рубрике RDS 2012 R2. Добавьте в закладки постоянную ссылку.

11 комментариев на «RDS 2012 R2. Тестирование высокой доступности.»

  1. madmongoose:

    При схеме работы RDS HA из двух серверов со всеми ролями, при отключении одного из серверов, нет возможности завершить зависшие сессии работающих пользователей. Никаким доступным способом, ни через PowerShell ни через GUI. И даже перезагрузка оставшегося рабочего брокера не решает проблему. Т.е. для того, чтобы отключить зависших пользователей необходимо разобрать ферму. Вот обсуждение, к которому хочу привлечь Ваше внимание https://social.technet.microsoft.com/Forums/ru-RU/2372c220-47eb-4d96-b12a-39fe4f699120/rds-ha-?forum=WS8ru

    Нравится

  2. а как «ускрить» перекодключение для активных сеансов которые были на упавшем сервере? Ждать 5 минут очень долго.

    Нравится

    • Боюсь никак, переподключение происходит на самом клиенте 😦

      Нравится

      • Делаю тест: выключаю 1й RDSH и все активные юзеры которыей были на нем повторно не могт подключиться к ферме. Ошибка: В пуле нет доступных компьютеров.
        ЧЯДНТ ?

        Нравится

        • Опишите еще раз, пожалуйста, схему решения.

          Нравится

        • НА брокер (2 сервера) с RR DNS-ом terminal.domen.com + 2 отдельных cервера сенсов SH-1 и SH-2. Пользователь-1 по RDP заходит на terminal.domen.com, попадает на SH-1. Я выключаю сетевую карту на SH-1 и пользователь-1 повторно зайти на terminal.domen.com может лишь через 4-5 минут. Если на terminal.domen.com заходить под пользователем-2 (у него до отключения SH не было активных сеансов вообще) то подключение проходит сразу. Вот и хочу понять как уменьшить эту задержку в 4-5 минут

          Нравится

        • Погодите, terminal — это broker, вы отключаете узел sh-1, брокер работает. То есть получается, что брокер не может создать новый сеанс для пользователя. Посмотрите, сеанс для пользователя-1, при отключении узла, остается в подключениях коллекции?

          Нравится

  3. я тестил через отключение сетевухи и если ее отключить то на SH-1 висит сесия юзера в статусе Disconected.

    Нравится

    • а если при отключении сетевухи, сделать log off сеанса этого пользователя, то получится подключиться к новому сеансу на другом узле?

      Нравится

      • Если logoff сделать до отключения сетевухи — все ОК 🙂 что логично.
        Если после (принудительно завершить сеанс юзера) то это не помогает, что тоже логично 🙂

        Нравится

        • Тем не менее поведение странное, не понятно откуда вообще в этом случае берется задержка в переключении сеанса. не знаю что и предложить, анализировать логи, TerminalServices-SessionBroker и TerminalServices-SessionBroker-Client может что полезного напишут ☻

          Нравится

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s