Архитектура Termidesk VDI приведена на рисунке. 

Когда пользователь запускает компонент «Клиент» и нажимает кнопку [Подключиться] для получения ВРМ происходит следующее:

• «Клиент» подключается к указанному серверу («Универсальному диспетчеру») и передает учетные данные пользователя, с которыми он хочет подключиться;
• «Универсальный диспетчер» запрашивает сервер каталогов для аутентификации пользователя;
• при успешной аутентификации «Универсальный диспетчер» посылает команду платформе виртуализации на запуск ВМ для аутентифицированного пользователя;
• в случае, если используется программный комплекс «Средства виртуализации «Брест» (далее - ПК СВ Брест), платформа виртуализации получает билет kerberos от сервера каталогов. Это гарантирует, что платформа виртуализации получила полномочия на запуск ВМ через единый центр управления пользователями;
• платформа виртуализации размещает ВМ на гипервизоре и запускает ее;
• гипервизор контролирует состояние ВМ;
• после запуска ОС на ВМ установленный в ней «Агент виртуального рабочего места» проводит необходимые настройки и добавляет ВМ в домен. Если ВМ уже была создана ранее (использовалась), то заново настройки не выполняются;
• «Агент виртуального рабочего места» сообщает «Универсальному диспетчеру» о готовности ВМ к работе;
• «Универсальный диспетчер» формирует параметры подключения к ВМ для «Клиента» и передает их.

Пользователь получает ВРМ через «Клиент», который в свою очередь запускает приложение доставки рабочего места ПО Termidesk Viewer для отображения экрана.

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

• «Клиент» подключается к указанному серверу («Универсальному диспетчеру») и передает учетные данные пользователя, с которыми он хочет подключиться;
• «Универсальный диспетчер» запрашивает сервер каталогов для аутентификации пользователя;
• при успешной аутентификации «Универсальный диспетчер» обращается к «Агенту виртуального рабочего места»;
• «Агент виртуального рабочего места» сообщает «Универсальному диспетчеру» о готовности рабочего места;
• «Универсальный диспетчер» формирует параметры подключения к автономной машине для «Клиента» и передает их.
• пользователь получает рабочее место через «Клиент», который в свою очередь запускает ПО Termidesk Viewer для отображения экрана.

Если пользователь хочет получить терминальную сессию или приложение STAL, происходит следующее:

• «Клиент» подключается к указанному серверу («Универсальному диспетчеру») и передает учетные данные пользователя, с которыми он хочет подключиться;
• «Универсальный диспетчер» запрашивает сервер каталогов для аутентификации пользователя;
• при успешной аутентификации «Универсальный диспетчер» посылает команду STAL о подключении аутентифицированного пользователя через компонент «Сессионный агент»;
• от «Сессионного агента» на STAL поступает запрос на создание сессии. Взаимодействие выполняется посредством шины dbus;
• при успешном создании сессии «Сессионный агент» сообщает «Универсальному диспетчеру» о готовности к работе;
• пользователь получает доступ в сессию через «Клиент», который в свою очередь запускает соответствующее приложение доставки (mstsc, xfreerdp или ПО Termidesk Viewer) для отображения экрана терминальной сессии или приложения STAL.

При туннелировании протокола доставки через «Шлюз» происходят похожие процессы, при этом появляются новые:

• «Универсальный диспетчер» формирует параметры подключения и выдает «Клиенту» URL-адрес, содержащий токен доступа. Токен доступа представляет собой закодированную структуру данных с указанием параметров перенаправления «Клиента»;
• «Клиент» обращается по этому URL-адресу;
• «Шлюз» проверяет переданный от «Клиента» токен доступа API-запросом через «Универсальный диспетчер»;
• если проверка прошла успешно, «Универсальный диспетчер» возвращает «Шлюзу» параметры подключения (хост и порт) из токена доступа;
• «Шлюз» перенаправляет соединение «Клиента» на указанный хост и порт.

Подключения между «Клиентом» и «Шлюзом» формируются через вебсокеты (WS), которые позволяют туннелировать протоколы SPICE, TERA (протокол удаленного доступа собственной разработки) и RDP.

Соединения от «Шлюза» формируются напрямую (без WS):

• по протоколу SPICE на гипервизор;
• по протоколу RDP в гостевую ОС или терминальный сервер;
• по протоколу TERA напрямую в гостевую ОС рабочего места, без участия гипервизора.

Опционально подключение пользователя может выполняться через веб-браузер с поддержкой HTML5 по протоколам SPICE и TERA, однако в этом случае функционал работы с рабочим местом будет неполным.

ля решения задач по доставке приложений и рабочих столов терминальных серверов с ОС Astra Linux Special Edition (Server) служит компонент STAL, который устанавливается вместе с «Сессионным агентом».

Для решения задач по доставке приложений и рабочих столов терминальных серверов с ОС Microsoft Windows Server достаточно установить «Сессионный агент» на уже настроенный для работы сервер Microsoft Windows Server с ролью «Remote Desktop Session Host» из состава «Remote Desktop Services» (далее – MS RDS).

Вариант развертывания Termidesk Terminal приведен на рисунке.

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

Установка нескольких экземпляров (N+1) «Универсального диспетчера», «Шлюза», «Менеджера рабочих мест» позволяет избежать единой точки отказа системы.

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

Общая схема распределенной установки фермы Termidesk представлена на рисунке.

Использование Termidesk со STAL возможно в следующих вариантах:

• STAL как отдельный сервер, см. рисунок. Решение может использоваться как в продукте Termidesk VDI, так и в Termidesk Terminal;
• STAL в метапоставщике, см. рисунок. Решение может использоваться в продукте Termidesk VDI.

Использование Termidesk с MS RDS возможно в следующих вариантах:

• MS RDS как отдельная настроенная инфраструктура, см. рисунок. Решение может использоваться как в продукте Termidesk VDI, так и в Termidesk Terminal;
• MS RDS в метапоставщике, см. рисунок. Решение может использоваться в продукте Termidesk VDI.

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

Минимальная конфигурация компонентов при горизонтальном масштабировании следующая:

• «Универсальный диспетчер» – 2 шт.;
• «Шлюз» – 2 шт.;
• «Менеджер рабочих мест» – 2 шт.;
• балансировщик БД – 1 шт. (значение постоянно и остается таким при конфигурации N+1);
• серверы БД – 2 шт. (значение постоянно и остается таким при конфигурации N+1);
• балансировщики подключений – 2 шт. Предполагается, что необходим отдельный балансировщик для «Шлюзов», и отдельный для «Универсальных диспетчеров».

В общем случае при горизонтальном масштабировании будут задействованы компоненты, указанные на схеме:

• Сети:
  • EXTERNAL NET – внешняя сеть, в которой находятся пользователи;
  • MGMT NET – управляющая сеть Termidesk;
  • DISPLAY NET – сеть узлов платформ виртуализации для подключения к экранам пользовательских рабочих станций;
  • VM NET – сеть рабочих мест для терминирования прямых подключений (например, RDP).
• Компоненты:
  • балансировщик – представляет собой точку входа в Termidesk для внешних пользователей и внутренних компонент. Принимает HTTP-запросы на внешние и внутренние доменные имена Termidesk и распределяет обычные запросы между серверами Termidesk;

• • компонент «Универсальный диспетчер» – обеспечивает работу веб-интерфейса панели управления Termidesk и веб-интерфейса портала пользователя, отвечает за идентификацию пользователей, назначение и контроль доставки им рабочих мест;
  • компонент «Менеджер рабочих мест» – является обработчиком фоновых задач;
  • компонент «Шлюз» – обеспечивает работу WS-подключений. «Шлюзы» обладают общим внешним доменным именем, которое определяется в один из виртуальных IP-адресов по кругу («Round-robin»). Каждый «Шлюз» обладает собственным виртуальным IP-адресом (GWN-VRRP). При отказе одного из «Шлюзов», запросы начинает обрабатывать один из оставшихся, в зависимости от выставленного приоритета. «Шлюзы» должны иметь доступ через балансировщики к узлам Termidesk;
  • кластер БД – обеспечивает работу при больших нагрузках на БД. Состоит из балансировщика для подключений к серверам БД и непосредственно серверов БД;
  • ВРМ – непосредственно получаемые пользователем рабочие места. Должны иметь доступ к серверам Termidesk через балансировщики.

Для решения задач, связанных с разворачиванием Termidesk в облачной инфраструктуре, служит компонент «Оркестратор». «Оркестратор» предназначен для организации единой точки взаимодействия облачных компонентов с компонентами Termidesk.

Схема взаимодействия компонентов Termidesk в облачной инфраструктуре выглядит следующим образом.

Общая схема установки Агрегатора и фермы Termidesk представлена на рисунке. Взаимодействие компонентов внутри фермы аналогично ранее приведенному рисунку, поэтому не отображено здесь.

Когда пользователь запускает компонент «Клиент» происходит следующее:

• пользователь выбирает сайт «Агрегатора» и нажимает кнопку [Подключиться];
• «Клиент» подключается к указанному сайту, размещенному на «Агрегаторе» и передает учетные данные пользователя, с которыми он хочет подключиться;
• «Агрегатор» запрашивает сервер каталогов для аутентификации пользователя. При успешной аутентификации пользователя «Клиент» запросит у «Агрегатора» список доступных пользователю ресурсов;
• «Агрегатор» запросит информацию о фермах Termidesk из своей БД, затем обратится к узлам «Универсального диспетчера» ферм для получения списка ресурсов;
• «Универсальные диспетчеры» ферм далее получат список ресурсов из своих БД, обращаясь к ним, и возвратят «Агрегатору» этот список;
• пользователю отобразятся доступные ресурсы. После выбора ресурса «Клиент» отправит запрос «Агрегатору» на его получение, а «Агрегатор» адресует запрос на конкретный «Универсальный диспетчер» фермы. Далее процесс не отличается от взаимодействия компонентов, приведенного для схемы развертывания фермы Termidesk VDI. 

Если пользователь хочет получить терминальную сессию или приложение STAL, то процесс происходит аналогично: «Клиент» взаимодействует с «Агрегатором», а последовательность обращений внутри фермы Termidesk не отличается от приведенного для схемы развертывания фермы Termidesk VDI.

При туннелировании протокола доставки через «Шлюз» фактически будут происходить те же обращения:

• «Клиент» взаимодействует с «Агрегатором»;
• «Агрегатор» делает запросы к «Универсальному диспетчеру» фермы Termidesk;
• «Универсальный диспетчер» фермы Termidesk формирует параметры подключения через «Шлюз» фермы Termidesk и выдает сформированный URL-адрес «Агрегатору»;
• «Клиент» обращается по этому URL-адресу.

Общая схема распределенной установки фермы «Агрегатора» представлена на рисунке, ферма №1 и ферма №2 содержат идентичный ресурс - ВРМ №1, который будет отображен пользователю в одном экземпляре (решение о подключении к конкретной ферме примет «Агрегатор»).