Windows server 2012r2 rds

Как управлять RDS фермой Windows Server 2012-16

Как управлять RDS фермой Windows Server 2012-16

Доброго времени суток, многоуважаемые инженеры, системные администраторы и просто начинающие пользователи. Рад вас вновь приветствовать на страницах IT блога Pyatilistnik.org. Если вы мой постоянный читатель, то вы заметили, что я очень часто и много пишу про терминальные сервера и RDS фермы. Сегодня я хочу вам показать, как производится управление RDS фермой Windows Server 2012 и Windows Server 16. Я на сто процентов уверен, что данная информация будет вам полезна, так как я часто видел опытных администраторов, кто не знал как это делается, в виду старых знаний и стереотипов, о данной технологии.

Описание ситуации

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

В чем отличие фермы от терминала

Если посмотреть организацию удаленного доступа в Windows Server 2008 R2, то там схема была простой, где-то в сети устанавливался сервер лицензирования удаленных рабочих столов, а уже на нужно из серверов, куда планировалось подключение, ставилась роль «Службы удаленных рабочих столов». Ему назначались лицензии и пользователь подключался.

Если посмотреть концепцию Windows Server 2012 R2 и старше, то выглядит это уже вот так, есть некое виртуальное имя к которому все подключаются, есть серверная роль «Посредник подключения (RD Connection Broker)«, он берет на себя роль распределения нагрузки и количество сеансов пользователей, на сервера удаленного подключения «RD Session Host«, где уже работаю пользователи. Вся эта конструкция объединяется в некий пул. называемый RDS фермой, где легко создать отказоустойчивость на уровне посредников подключения и легко обслуживать хосты конечного подключения.

Схема управления RDS фермой

Тот сотрудник не совсем понимая схему и видя ее впервые, наивно подумал, что все управление Remote Desktop Services фермой осуществляется через посредника подключения (Connection Broker). Он попытался к нему подключиться, но его послали с формулировкой «Удаленный компьютер «имя», попытка подключения к которому выполняется, перенаправляет вас на удаленный компьютер «имя», он то и не знал, что для подключения к нужному хосту фермы нужно использовать специальные ключи.

Далее показав ему, как происходит подключение к посреднику, он попытался отыскать оснастку управления, так как в Windows Server 2008 R2, была именно такая реализация работы, но он там ничего не нашел. Он подглядел у меня, что я управляю RDS, через «Диспетчер серверов». Он его открывает и у него там то же ничего не оказалось, в итоге он побился часок и попросил ему показать. Чтобы знающих людей стало больше и грамотность системных инженеров была больше я вам написал небольшую инструкцию. Не подумайте, что я надменно отнесся к своему коллеге, я просто так же был однажды в на его месте и понимал, что это просто отсутствие опыта, что не смертельно.

Собираем консоль управления RDS фермой

Для управления настройками Remote Desktop Services вам потребуется клиентская операционная система Windows 8.1 или Windows 10, либо это могут быть Windows Server 2012 R2 и выше. Там нам потребуется оснастка «Диспетчер серверов».

Если вы знаете всех участников RDS фермы, то это хорошо, вы немного себе выиграете времени, если нет, то придется слегка пописать команды и помучить DNS-сервер.

Откройте командную строку или запустите PowerShell оболочку. Предположим у вас виртуальное имя для подключения к удаленному рабочему столу TERM. Тут у вас два варианта:

• Воспользоваться утилитой nslookup
• Воспользоваться утилитой Resolve-DnsName

И та и другая выдали вам ip-адреса, в которое разрешается ваше виртуальное имя RDS фермы. В моем примере их два. Эти адреса принадлежат посредникам по подключению (Connection Broker), делаем так же запрос:

Стрелками я выделил полученные DNS имена, самое главное мы получили.

Теперь открывает оснастку «Диспетчер серверов» от имени той учетной записи у которой есть права на администрирование RDS фермы. В открывшейся оснастке выберите пункт «Добавить другие серверы для управления»

У вас откроется окно «Добавление серверов», перейдите на вкладку DNS и в поисковой строке укажите нужное имя брокера и нажмите кнопку с изображением лупы. У вас будет осуществлен поиск по базе Active Directory, если такой сервер есть, то он будет отображен в списке. Переносим его в поле выбрано.

Точно так же поступаем и с остальными посредниками подключений к Remote Desktop Services ферме.

У вас начнется процесс добавление в вашу оснастку дополнительных серверов. Когда закончится добавление, то вы увидите, что у вас появились серверные роли, в нашем случае «Службы удаленных рабочих столов» и обратите внимание на иконку «Все серверы», тут стало их уже два.

Переходим в роль «Службы удаленных рабочих столов», в итоге у вас отобразится список всех участников RDS фермы, и для ее управления вам нужно их всех добавить в данных пул серверов.

В итоге у меня добавились все мои хосты подключения и сервера лицензирования. Как видите стало 20 серверов.

Переходим в «Службы удаленных рабочих столов», в этот раз у вас уже откроется полноценное управление коллекциями RDS. Вы увидите схему работы, вам будет представлен список всех ваших серверов и кто за какую роль отвечает. Переходим в саму коллекцию.

Попав в коллекцию удаленных рабочих столов, у вас будет несколько областей:

• Свойства — тут вы зададите права доступа, лимиты и многое другое
• Подключения — тут будут отображены все ваши сеансы пользователей, в моем примере, это всего 338 человек, так как уже не рабочий день, а вечер пятницы, в пиковое время, эта цифра в районе 950 подключений.
• Удаленные приложения RemoteApp
• Серверы узлов — тут вы сможете запрещать или разрешать новые подключения

Так же для удобства администрирования серверов, я вам советую создавать отдельные группы по нужным вам признакам и управлять ими, но об этом уже в другой раз. Либо же вы можете создать группу серверов в Remote Desktop Connection Manager.

Источник

Windows server 2012r2 rds

Обновлена в июле 2014

План настройки:

1. Различные варианты архитектуры решений MS RDS (эта статья)
2. Описание MS RDS в Windows server 2012 и плана моей настройки (тут)
3. Настройка домена в Windows server 2012 R2: Active Directory, DNS, DHCP
4. Настройка дублирующих служб Active Directory, DNS, DHCP
5. Развертывание RDS и создание кластера NLB
6. Развертывание DFS для хранения данных пользователей
7. Настройка премещаемых профилей и перенаправленных папок

В своих статьях по настройке, я всегда пытаюсь показывать архитектуру, которую рекомендует производитель или разработчик программного обеспечения. ВСЕГДА у ВСЕХ существуют так называемые best practice или reference architecture, в которых показано, как лучшим образом построить масштабируемую и отказоустойчивую систему. Я написал у ВСЕХ? За исключением Microsoft… Может в этом есть большая политика или еще что-то, но для для служб RDS я не смог найти рекомендаций, только какие-то старые статьи и примеры простых настроек, которые не претендуют на полноценные гайды. Интересно написана вот эта статья , с виду все правильно, но для небольшой компании не подойдет, слишком громоздкая схема и дорогая в реализации в плане оборудования и лицензий (их автор не рассматривает). Я тоже подготовил свои вариации на тему терминального сервера от Microsoft, и вот как я мыслю, от простого к сложному.

Вариант 1

Самый простой вариант, известный очень давно, с ним спорить никто не станет, да и придраться не к чему, кроме сомнительной отказоустойчивости данного решения. Хотя есть в компании, где такие установки работают годами и ничего с ними не происходит. На сервер установлен гипервизор (любой), настроены две виртуальные машины: одна Active Directory, DNS, DHCP и вторая со службой удаленных рабочих столов (RDS) и сервером лицензий. Данная схема может успешно держать до 80-100 пользователей. Точки отказа помечены красными кружками. Из строя могут выйти:

• сервер RDS (программная то) — все сессии рвутся, пользователи не работают
• AD, DNS, DHCP (программная то) — существующие сессии продолжают работать, все попытки новых подключение заканчиваются неудачей
• гипервизор (программная то) — все выключается никто не работает больше до восстановления
• сервер (аппаратная) — ничего не работает до починки сервера

Вариант 2 Создаем еще одну виртуальную машину и резервируем важные для работы сервисы Active Directory, DNS, DHCP. Избавляемся от одной программной точки отказа.

Вариант 3

Делаем еще один или несколько терминальных серверов (RDS), в основном для того, чтобы большему числу пользователей дать терминальный доступ, рекомендуется 40-50 человек на один терминальный сервер. Также придется добавить файловый сервер (программная то), где будут храниться профили пользователей и перенаправленные папки. Если пользователь подключается к одному из терминальных серверов, то на этот сервер загружается его профиль с файлового сервера и подключаются перенаправленные папки. Пользователей можно раскидывать между серверами с помощью DNS Round Robin или NLB cluster.

DNS round robin настраивается очень легко, в DNS создаются записи с одинаковыми именами и разными IP адресами. Пользователи обращаются на адрес и случайным образом получают один из IP адресов и попадают на один из терминальных серверов. Опасности DNS round robin:

• нет распределения нагрузки между серверами, может оказаться, что на одном из серверов больше пользователей чем на другом. Или один сервер будет загружен на 80%, а второй на 20%. Данную проблему можно решить, нарастив количество терминальных серверов, тогда нагрузку будет распределять уже гипервизор, который умеет динамически распределять оперативную память и процессорную мощность.
• двойные сессии, если пользователь отключился по каким-то причинам, а затем переподключается, то может легко попасть на другой сервер и откроется еще одна сессия. А в старой могут остаться открытые документы, программы, браузер и другая недоделанная работа. Можно настроить автоматическое отключение неактивных сессий, это приучит пользователей чаще сохраняться и двойных сессий не будет.
• отказ в подключении — DNS round robin не проверяет доступность IP адреса, который он выдает, и это самое неприятное в этом простом алгоритме. Поэтому, если один из терминальных серверов выйдет из строя, то при подключении пользователь может все равно получить его IP адрес и подключение не пройдет. Дальше два варианта, или пользователь не оставляет попытки подключения и в конце концов получает рабочий IP адрес или начинает звонить в тех поддержку. Данную проблему решает только замена DNS round robin на NLB cluster.

NLB cluster — встроенная фича Windows server, которая устанавливается через мастер добавления ролей сервера. В отличии от DNS round robin не перенаправляет пользователей на недоступные в данный момент серверы. Из минусов остаются невозможность распределять нагрузку и двойные сессии.

Вариант 4

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

Вариант 5

Добавляем дублирующий Connection Broker, но чтобы они работали вместе, обязательно нужен MSSQL сервер, который становится новой точкой отказа. Причем MSSQL отказоустойчивый кластер настроить и сложно и дорого. Чтобы сделать это нормально понадобится общая папка на системе хранения данных и лицензия MS SQL server Standard, обойтись версией MSSQL Express не получится. На мой взгляд, в эту сторону имеет смысл двигаться только в больших инфраструктурах, где уже есть отказоустойчивый кластер MS SQL. В любом случае, сделать это на одном физическом сервере не получится.

Распределять пользователей между двумя и более Connection Broker также можно средствами DNS Round Robin или NLB Cluster.

Вариант 6-7 (финальные для одного физического сервера)

Возвращаемся к варианту с одним Connection Broker. От точки отказа файлового сервера избавляемся, заменяем связкой DFS серверов. Это будет финальный вариант для одного физического сервера.

С одной стороны отсутствие Connection Broker лишает распределения нагрузки, с другой стороны убираем точку отказа. Рекомендуется использование NLB cluster на RDS серверах.

Вариант 8

Добавляем второй физический сервер, что добавляет нам производительности. Остается точка отказа Connection Broker (программная), гипервизор (программная то) и сервер на котором находится CB (аппаратная то)

Вариант 9

Явных точек отказа в данном варианте нет. Распределение нагрузки через NLB cluster. Масштабировать решение легко, никаких проблем с этим быть не должно.

Вариант 10

Если добавить в решение систему хранения данных, то можно собрать отказоустойчивый кластер и защитить Connection Broker от аппаратного отказа сервера на котором он запущен. В High Availability кластере виртуальная машина с CB будет автоматически перезапущена на втором сервере. Напомню, что виртуальная машина занимается распределением нагрузки между терминальными серверами.
Данный вариант не защищает от программного сбоя (BSOD например) в виртуальной машине CB.

Вариант 11

По логике Microsoft эта схема самая правильная, и ,конечно, самая дорогая. Connection broker работает в отказоустойчивом режиме, используя в свою очередь отказоустойчивый кластер MS SQL, работающий в режиме active-passive (лицензия MS SQL Standard) или в режиме active-active (лицензия MS SQL Enterprise)

ВЫВОДЫ

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

Источник