Rds ферма что это
Remote Desktop Services 2012 – Отказоустойчивая ферма Remote Connection Broker нового поколения
Если в версиях 2008/R2 использовалась схема Active/Passive для кластеризации службы RD Connection Broker, то в версии Windows Server 2012 схема работы служб RD переработана в корне. И для отказоустойчивой работы службы RD Connection Broker предлагается схема Active/Active.
Если в предыдущих версиях Connection Broker хранил всю информацию о пользовательских сессиях в локальной базе и, для развёртывания отказоустойчивой фермы, нам предлагалось использовать Failover Cluster, то в новой схеме Failover Cluster не используется. RD Connection Broker хранит свои данные в базе данных SQL Server, а клиенты подключаются к серверам RD Connection Broker используя DNS Round Robin.
Среда исполнения
Четыре виртуальных сервера на базе Windows Server 2012 Standard EN. Серверу, выполняющему роль контроллера домена в лесу contoso.com и DNS сервера присвоено имя DC1 и IP адрес 10.0.0.1. Сервер базы данных нашей фермы имеет имя SQL и IP адрес 10.0.0.10. Два сервера с установленной ОС, роли на них будут добавлены в процессе развертывания служб RDS.
Визуально схема будет выглядеть так:
В нашем случае серверы RD1 и RD2 будут являться как Remote Desktop Session Host, так и Remote Desktop Connection Broker.
На сервере SQL будет установлена SQL Server 2012 Standard (так же возможно использование SQL Server 2008 R2 в редакции не ниже Standard).
Предварительные настройки
1. Так как RD Connection Broker использует SQL Server в отказоустойчивой схеме, то сервер RD Connection Broker должен иметь полные привилегии доступа к SQL Server. Создадим в AD группу RDCB Servers, включим в нее наши RD Connection Broker серверы, а после дадим этой группе все привилегии доступа в разделе Security сервера SQL, используя SQL Server Management Studio.
3. Создадим заранее папку для базы данных. Это может быть как локальная папка, так и расшаренная где либо еще. В нашем случае это будет локальная папка C:\Base на сервере SQL.
4. Установим на каждый сервер, где планируется развертывание RD Connection Broker, Microsoft SQL Server 2012 Native Client. Скачать его можно со страницы Microsoft SQL Server 2012 Feature Pack (http://www.microsoft.com/en-us/download/details.aspx?id=29065). Для SQL Server 2008 R2 клиента можно взять тут (http://www.microsoft.com/en-us/download/details.aspx?id=30440).
5. Создадим имя DNS Round Robin для каждого RD Connection Broker сервера. В нашем случае это будет 2 записи A с именем RD указывающих на IP адреса 10.0.0.3 и 10.0.0.4.
6. Перед тем как создавать нашу ферму, объединим наши будущие RDS сервера в группу. Откроем Manage – Create Server Group, добавим оба сервера в группу и дадим ей название RDS.
Создание отказоустойчивой фермы Remote Desktop Connection Broker
1. Запустите Add Roles and Features Wizard на сервере RD1 и переключите режим установки на Remote Desktop Services installation.
2. Оставьте опцию Standard deployment, так как мы будем делать развертывание на несколько серверов.
3. Выберем Session-based desktop deployment, так как в данной конфигурации мы не рассматриваем ферму VDI.
4. Помимо ролей RD Connection Broker и RD Session Host будет так же установлена роль RD Web Access. Отказаться от нее почему то нельзя. По крайней мере, я не нашел такой возможности.
5. На следующей странице выберем сервер RD1 для установки роли RD Connection Broker.
6. На странице RD Web Access выберем сервер доступа через веб. В нашем случае это будет тот же сервер что и RD Connection Broker. Установим чекбокс Install the RD Web Access role on the RD Connection Broker server и перейдем к следующей странице.
7. Добавим оба сервера в список для установки на них роли RD Session Host на одноименной странице и нажмем Next.
8. На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Установим чекбокс Restart the destination server automatically if required и нажмем Deploy.
9. Далее последует установка ролей на серверы, после чего они перезагрузятся и закончат установку всех выбранных ролей.
10. Приступим, собственно, к созданию отказоустойчивой конфигурации RD Connection Broker. Для этого перейдем на вкладку Overview раздела Remote Desktop Services менеджера серверов (Server Manager) и нажмем правой клавишей мыши на изображении RD Connection Broker. Там для нас будет доступна одна функция – Configure High Availability.
11. Запустив данную функцию мы увидим новый визард, на стартовой странице которого будут перечислены необходимые предварительные настройки, которые мы выполнили в полной мере.
13. На странице подтверждения еще раз проверим введенные нами данные и нажмем Configure.
14. На странице Progress дождемся окончания конфигурации.
Собственно это все, как мы можем видеть на странице Overview раздела Remote Desktop Services менеджера сервера наш RD Connection Broker работает в режиме High Availability Mode. Можно использовать эту ферму RDS через точку входа RD.contoso.com.
Добавление серверов RD Connection Broker делается через то же самое контекстное меню на странице Overview.
Rds ферма что это
Добрый день! Уважаемые читатели и гости крупного IT блога Pyatilistnik.org. В прошлый раз я вам как увидеть скрытые папки в Windows 10. Сегодня мы поговорим, про одну очень важную вещь в IT инфраструктуре почти любой организации, речь пойдет про общие понятия терминальной фермы RDS (Remote Desktop Services). Мы узнаем из каких компонентов она состоит, какие сценарии развертывания есть у данной технологии, как она помогает улучшить работу сотрудников и уменьшить административную нагрузку на системного администратора или инженера. Это будет вводная статья, перед развертывание высокодоступной RDS фермы на Windows Server 2019.
Желания бизнеса и системного администратора
Если вернуться во времени лет на 10 назад, то работу компании или офиса можно представить вот в таком виде:
Исходя из этих тезисов, многие компании по разработке оборудования, программ и операционных систем, продолжали разработку модели при которой бизнес бы смог минимизировать время простоя при аварии и тем самым сделать сервисы лучше, надежнее и минимизировать нагрузку на системного инженера. Одним из таких шагов сделала компания Microsoft, выпустив службу «Удаленных рабочих столов (Служба терминалов, Терминальный стол или Remote Desktop Services)». Данная разработка решала ряд важных вещей:
Компоненты терминальной RDS фермы
Перед тем, как я вам приведу примеры внедрения технологии Remote Desktop Services в реальной жизни, я бы хотел вас познакомить с компонентами, которые входят в состав. Если вы откроете у себя Windows Server 2019 или другую версию по ниже, то в списке ролей вы сможете найти:
Типы развертывания RDS фермы в Windows Server
Существует несколько типов установки терминальной фермы на серверах Windows:
В Windows Server 2019 вы найдете только компонент «Соединитель Multipiont»
Служба Multipoint как вы поняли по лицензии доступна только для учебных и государственных учреждений, ее основная задача с помощью тонких клиентов, это такие компьютеры без оперативной памяти, жесткого диска, чаще всего без вентиляторов, подключить человека к удаленному серверу, ресурсы которого будут использоваться. На рисунке к серверу подключаются напрямую четыре клиента по USB и, к примеру, VGA-порты. Очевидно, что подобный тип подключения подразумевает соответствующие требования к аппаратной конфигурации головной станции и в некоторых сценариях не применим (масштабы, расстояние, мобильность)
А вот еще пример подключения тонких клиентов через USB хаб и через COM-порт.
Сценарии развертывания RDS фермы
Так же есть несколько сценариев развертывания:
Практические примеры внедрения терминальной фермы
Теперь я хочу вам показать, как можно внедрять RDS фермы в ваше рабочее окружение:
По приведенной ниже схеме прекрасно видно, что у нас есть два посредника подключений, у которых общая база данных, клиент подключается по DNS имени, которое разрешается в один из адресов RDCB, после чего попадает в нужную коллекцию.
Создание терминальной фермы RDS с использованием технологии NLB и публикация RD Web Access на ISA Server 2006
Итак, мы хотим добиться балансировки нагрузки на наши терминальные сервера, их отказоустойчивость, или же хотим добавить к уже имеющемуся терминальному серверу второй для увеличения производительности сервиса. В моем примере я буду реализовывать следующую схему:
Как мы видим, для реализации такой схемы нам понадобится три сервера. Причем, роль Брокера можно установить на уже имеющийся у нас сервер, например, на файловый или сервер печати. Для наглядности назовем наши сервера следующим образом:
Как мы видим, имя нашего домена – 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). Выбираем для установки следующие службы ролей:
— Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)
— Шлюз удаленных рабочих столов (Remote Desktop Gateway)
— Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)
— Сервер политики сети (NPS)
При установке служб ставим галочку «Require NLA», остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.
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):
После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.
Теперь на закладке 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 и создаем политику авторизации подключений при помощи мастера:
Добавим в список авторизованных для подключения пользователей группу rdg_users, куда включим всех тех, кому надо получить доступ к терминальным сервисам.
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-прослушивателя:
Rds ферма что это
Доброго времени суток, многоуважаемые инженеры, системные администраторы и просто начинающие пользователи. Рад вас вновь приветствовать на страницах 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. Тут у вас два варианта:
И та и другая выдали вам ip-адреса, в которое разрешается ваше виртуальное имя RDS фермы. В моем примере их два. Эти адреса принадлежат посредникам по подключению (Connection Broker), делаем так же запрос:
Стрелками я выделил полученные DNS имена, самое главное мы получили.
Теперь открывает оснастку «Диспетчер серверов» от имени той учетной записи у которой есть права на администрирование RDS фермы. В открывшейся оснастке выберите пункт «Добавить другие серверы для управления»
У вас откроется окно «Добавление серверов», перейдите на вкладку DNS и в поисковой строке укажите нужное имя брокера и нажмите кнопку с изображением лупы. У вас будет осуществлен поиск по базе Active Directory, если такой сервер есть, то он будет отображен в списке. Переносим его в поле выбрано.
Точно так же поступаем и с остальными посредниками подключений к Remote Desktop Services ферме.
У вас начнется процесс добавление в вашу оснастку дополнительных серверов. Когда закончится добавление, то вы увидите, что у вас появились серверные роли, в нашем случае «Службы удаленных рабочих столов» и обратите внимание на иконку «Все серверы», тут стало их уже два.
Переходим в роль «Службы удаленных рабочих столов», в итоге у вас отобразится список всех участников RDS фермы, и для ее управления вам нужно их всех добавить в данных пул серверов.
В итоге у меня добавились все мои хосты подключения и сервера лицензирования. Как видите стало 20 серверов.
Переходим в «Службы удаленных рабочих столов», в этот раз у вас уже откроется полноценное управление коллекциями RDS. Вы увидите схему работы, вам будет представлен список всех ваших серверов и кто за какую роль отвечает. Переходим в саму коллекцию.
Попав в коллекцию удаленных рабочих столов, у вас будет несколько областей:
Так же для удобства администрирования серверов, я вам советую создавать отдельные группы по нужным вам признакам и управлять ими, но об этом уже в другой раз. Либо же вы можете создать группу серверов в Remote Desktop Connection Manager.