Терминальная ферма что это

Создание терминальной фермы 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-прослушивателя:

Источник

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.

Источник

Терминальная ферма что это

Добрый день! Уважаемые читатели и гости крупного 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, после чего попадает в нужную коллекцию.

Источник

Организация территориально-распределенной архитектуры системы DIRECTUM

Опубликовано:
28 сентября 2018 в 15:30

В прошлых сезонах сериала

Вводное

Рассмотрим три варианта:

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

Особенности использования веб-доступа:

Особенности использования терминального сервера :

Механизмы для взаимодействия с несколькими базами данных рекомендуются в ситуациях:

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

Рекомендации

Единая база данных. Территориально-удаленные пользователи работают в системе через веб-доступ:

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

SAN (Storage Area Network) — Сеть хранения данных — предназначена для консолидации дискового пространства серверов на специально выделенных дисковых хранилищах. При использовании сети хранения данных дисковые ресурсы используются экономнее, легче управляются и имеют большую производительность.

Кластер СУБД

Для обеспечения надежной работы системы DIRECTUM необходимо создать активный кластер, который позволит обеспечить отказоустойчивое функционирование СУБД.

Кластер состоит из 2 узлов:

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

Веб-ферма серверов доступа к системе DIRECTUM и кластер балансировки нагрузки сетевого трафика

Для обеспечения высокой доступности сервиса веб-доступа к системе DIRECTUM необходимо объединить физические или виртуальные серверы веб-доступа в ферму веб-серверов на базе IIS. Инсталляция работает в режиме распределения нагрузки за счет использования кластера балансировки нагрузки сетевого трафика.

Серверам веб-доступа необходимо обеспечить высокую отказоустойчивость и масштабируемость. Мы рекомендуем использовать для этого связку технологий NLB кластера + ARR фермой серверов веб-доступа. В случае отказа одного из серверов, его пользовательская нагрузка перераспределится между остальными серверами фермы.

Виртуальный сервер служб DIRECTUM

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

Единая база данных. Территориально-удаленные пользователи работают в системе через терминальный сервер

Архитектура:

Ферма терминальных серверов

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

Несколько баз данных. У территориально-удаленных организаций свои БД, у головной организации также отдельная БД

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

В общем виде схему взаимодействия систем DIRECTUM можно представить, например, так:

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

Далее сюжет нашего сериала разворачивается таким образом, что возникает потребность в организации передачи и синхронизации каких-то данных между этими системами DIRECTUM, построении общих бизнес-процессов. О том, с помощью каких наших сервисов это можно сделать, я буду вести повествование в следующем разделе.

Службы взаимодействия систем DIRECTUM Intersystem Cooperation Services (DICS)

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

Механизмы межсистемного взаимодействия DIRECTUM (DIRECTUM Cross-system Interaction Toolset, DCI)

Механизмы межсистемного взаимодействия DIRECTUM (DIRECTUM Cross-system Interaction Toolset, DCI) – решение для взаимодействия разных систем внутри одной группы компаний. Решение предназначено для крупных территориально и юридически распределенных предприятий с децентрализованной базой данных.

Схема взаимодействия двух систем DIRECTUM:

DCI для связи внутри разных сетей:

В заключение

У вас волчанка админка ©

В статье я преследовал цель систематизирования того опыта и знаний, который накопился внутри нашей компании и лично у меня с проектов внедрения, пресейла. И да, в этой статье приведены не все рекомендации и возможности нашей системы по организации территориально-распределенной архитектуры. Иначе это был бы долгий и скучный лонгрид, вероятность запутаться в котором составляла бы 90%. Но на то он и сериал, чтобы следить за дальнейшим развитием событий и ждать выхода новых серий.
Оставляйте ваши вопросы и пожелания в комментариях под статьей!

Источник