Шаг 0. Исходные данные. Схема решения.


 

Высокая доступность (англ. high availability) — это метод проектирования системы, позволяющий достигать высокий уровень доступности системы в течение какого-либо промежутка времени.

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

В данном примере рассмотрим систему предоставляющую доступ к удаленным  рабочим столам (Remote Desktop Services, RDS), на платформе Microsoft Windows Server 2012 R2.

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

К основным ролям RDS можно отнести:

  • RD Connection Broker — «Посредник подключений». Отвечает за установление сессии и повторного подключения.
  • RD Web Access — «Веб доступ». Предоставляет веб-доступ к опубликованным приложениям
  • RD Session Host — «Узел сеансов». Собственно сервер с терминальными приложениями, на котором происходит работа пользователей.

Дополнительные роли:

  • RD Licensing — «Сервер лицензий». Отвечает за лицензирование клиентских подключений. Существуют варианты лицензирования на пользователя (per user) и на устройство (per device).
  • RD Gateway — «Шлюз». Обеспечивает шифрованное соединение (RPC/HTTPS) как из внутренне сети, так и сети интернет. Предоставляет возможность использования RemoteApp.

Цель этого проекта:

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

Для реализации задачи выбран следующий вариант дублирования основных ролей RDS, в сочетании:

  • 2 сервера с ролью Session Host.
  • 2 сервера с ролями Connection Broker + Web Access + Gateway.
  • SQL сервер (необходим для обеспечения высокой доступности Connection Broker).
  • Файловое хранилище (SAN или сетевая папка с высокой доступностью).

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

Схема решения выглядит так:

Схема RDS HA

Схема 1.

Исходные данные:

  • Домен LAB.LOCAL, forest level 2012 R2
  • DNS зона alekssh.com, будет использоваться для клиентских подключений из локальной сети и интернет.
  • DC1 — контроллер домена + центр сертификации.       192.168.1.11
  • SQL1 — SQL Server  2012                                                        192.1681.15
  • RDCB1 — Connection Broker + Web Access + Gateway     192.168.1.21
  • RDCB2 — Connection Broker + Web Access + Gateway     192.168.1.22
  • RDSH1— Session Host                                                                192.168.1.23
  • RDSH2— Session Host                                                                192.168.1.24
  • Файловое хранилище (Сетевая папка)                              192.168.1.11
  • Кластерное Файловое хранилище                                      192.168.1.26

Требования к серверам:

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

  • SQL сервер — не ниже SQL 2008 R2. (2 vCpu RAM 4 Gb)
  • RDCB1 и RDCB2 — Windows Server 2012 R2. (2 vCpu RAM 4 Gb)
  • RDSH — Windows Server 2012 R2. (2 vCpu RAM 4 Gb)

Статьи, используемые при разработке этого проекта:

http://technet.microsoft.com/ru-ru/library/hh831447.aspx

http://blogs.msdn.com/b/rds/archive/2012/06/27/rd-connection-broker-high-availability-in-windows-server-2012.aspx

http://blogs.technet.com/b/tommypatterson/archive/2014/02/19/step-by-step-lab-guide-for-building-a-windows-server-2012-r2-remote-desktop-services-environment.aspx

http://blogs.msdn.com/b/rds/archive/2012/10/16/configure-remote-desktop-connection-broker-in-windows-server-2012-with-sql-server-2012-high-availability.aspx

http://blogs.technet.com/b/yungchou/archive/2013/02/07/remote-desktop-services-rds-quick-start-deployment-for-remoteapp-windows-server-2012-style.aspx

http://blogs.technet.com/b/iftekhar/archive/2010/02/10/rds-hardware-sizing-and-capacity-planning-guidance.aspx



Реклама

Об авторе Alexander Shestakov

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

3 комментария на «Шаг 0. Исходные данные. Схема решения.»

  1. А что изменилось в этом сценарии с выходом 2016го сервера?
    Будет обновленная статья ? 🙂

    Нравится

  2. Здравствуйте! Есть интересненький вопрос. Жила себе ферма на 2016: 2 RDCB + 2 RDWA + SQL + 8 RDSH + 1 RDUPD. Она почти вся ( кроме сервера с профилями юзеров и база SQL брокера ) «умерли». Теперь нужно поднять новую ферму. Как правильно поступить — поднять ферму и назвать по новому или можно как-то «втиснуться» в существующую ??

    Нравится

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

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

Логотип WordPress.com

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

Google+ photo

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

Фотография Twitter

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

Фотография Facebook

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

Connecting to %s