Эта статья предназначена для архитекторов и администраторов, которые будут внедрять Termidesk в корпоративную инфраструктуру.

ВРМ представляет собой виртуальную машину (ВМ) с установленной гостевой операционной системой (ОС) и набором прикладного программного обеспечения (ПО), необходимого пользователю для работы. ВРМ разворачивается на основе мастер-образа ВМ или виртуального диска.

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

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

Существует много различий между указанными технологиями, в частности подход к организации подключений: при терминальном доступе пользователи подключаются к одной ОС, установленной на сервере, а при VDI для каждого пользователя создается отдельная ВМ. 

В качестве рабочего места для пользователя могут выступать:

• ВРМ;
• терминальная сессия или опубликованное приложение, а именно:
  • рабочий стол сервера терминалов Astra Linux – экран рабочего стола терминальной сессии компонента Termidesk «Сервер терминалов Astra Linux» (англ. Terminal Server Astra Linux, далее - STAL);
  • рабочий стол коллекции RDS – экран рабочего стола терминальной сессии коллекции Microsoft RDS;
  • приложение STAL – экран оконного приложения, запущенного в терминальной сессии STAL;
  • приложение RemoteApp – экран оконного приложения RemoteApp, запущенного в терминальной сессии коллекции Microsoft RDS;
• автономные машины - физические персональные компьютеры или статичные ВМ.

Эффект от использования Termidesk:

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

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

• управление профилями пользователей;
• управление шаблонами и образами тиражируемой ОС.

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

• глобальный уникальный сессионный идентификатор (Global Unique Session ID, GUSID, ГУСИ) – позволяет однозначно сопоставить пользователя и производимые им действия. Присваивается в момент аутентификации пользователя в компоненте «Клиент» или на пользовательском портале;
• уникальный идентификатор запуска ресурса (Unique Resource Start ID, URSI) – позволяет однозначно сопоставить пользователя и конкретный ресурс, который он получает - ВРМ, терминальную сессию и/или опубликованное приложение. Присваивается в момент запуска пользователем ресурса.

Компоненты Termidesk

Компонент Termidesk	Описание
«Универсальный диспетчер»	Отделяемый компонент, отвечающий за взаимодействие с гипервизорами, идентификацию пользователей, назначение и контроль доставки им ВРМ, предоставление терминального доступа. «Универсальный диспетчер» использует СУБД PostgreSQL (и СУБД, основанные на PostgreSQL) для хранения информации о подключениях пользователей. «Универсальный диспетчер» предоставляет следующие веб-порталы: «Портал администратора» – веб-интерфейс управления Termidesk; «Портал пользователя» – веб-интерфейс для подключения пользователей. В случае, если производится комплексная установка и выбираются оба веб-портала, будет активирован «Портал универсальный», предоставляющий все функции. Некоторые функции «Универсального диспетчера» использует «Агрегатор»
«Шлюз»	Самостоятельный компонент, отвечающий за туннелирование протоколов доставки, использующих транспортный протокол TCP. Обеспечивает отделение инфраструктуры ВРМ или терминальных серверов, находящихся во внутренней локальной сети, от внешних локальных или глобальных сетей
«Менеджер рабочих мест»	Отделяемый компонент, отвечающий за взаимодействие с поставщиком ресурсов и управление жизненным циклом ВРМ, включая создание, настройку, запуск, отключение и удаление, а также сбор информации о терминальных сессиях. Состоит из служб: termidesk-taskman – основная служба, обеспечивающая выполнение задач, размещенных «Универсальным диспетчером» в БД, на платформе управления виртуализацией; termidesk-celery-worker – обеспечивает управление питанием ВРМ и сбор информации о терминальных сессиях. Выполняет задачи, размещенные в очереди брокера сообщений RabbitMQ; termidesk-celery-beat – обеспечивает отслеживание состояния доступности брокера сообщений RabbitMQ. Службы компонента определяется ролью, выбранной при установке: «Менеджер рабочих мест» относится к termidesk-taskman; «Менеджер рабочих мест (очереди)» относится к termidesk-celery-worker и termidesk-celery-beat
«Агент»	Самостоятельный компонент, отвечающий за контролируемую доставку, взаимодействие с компонентами «Универсальный диспетчер» и «Менеджер рабочих мест». Включается в себя: «Агент виртуального рабочего места» – устанавливается в ВРМ или при подготовке терминального сервера для размещения в метапоставщике. Обеспечивает настройку рабочего места при публикации и передачу сообщений пользователю, фиксирует действия пользователей в ВРМ; «Агент узла виртуализации» – устанавливается на хостах виртуализации ПК СВ Брест. Обеспечивает отключение (выход из сеанса работы с ОС) и сброс SPICE-сессий. Работает в качестве посредника между libvirtd и «Агентом виртуального рабочего места» через именованный virtio канал /dev/virtio-ports/ru.termidesk.tvm.0; «Сессионный агент» – устанавливается на терминальный сервер. Обеспечивает доставку терминальных сессий и приложений пользователю; «Агент виртуальных смарт-карт» – устанавливается в ВРМ. Обеспечивает перенаправление смарт-карт (работающих по спецификации PC/SC) с пользовательской рабочей станции в ВРМ через именованный virtio канал /dev/virtio-ports/ru.termidesk.PCSC.0. Установка компонента применима для подключения пользователя по протоколу SPICE и размещения ВРМ на платформах виртуализации (ПК СВ Брест, oVirt, zVirt, РЕД Виртуализация, VMmanager); «Видеоагент» – устанавливается в ВРМ. Обеспечивает прием изображений с веб-камеры пользовательской рабочей станции через именованный virtio канал /dev/virtio-ports/ru.termidesk.RealtimeStreaming.0 на виртуальную камеру. Установка компонента применима для подключения пользователя по протоколу SPICE и размещения ВРМ на платформах виртуализации (ПК СВ Брест, oVirt, zVirt, РЕД Виртуализация, VMmanager) Все перечисленные каналы должны быть активированы на платформе виртуализации.
«Клиент»	Самостоятельный компонент, предназначенный для установки на пользовательскую рабочую станцию и выполняющий функции: подключение к указанному серверу («Универсальному диспетчеру», «Агрегатору»); отображение списка доступных рабочих мест; получение списка настроек для запуска программы доставки рабочего места; выбор протокола доставки для подключения; запуск программы доставки рабочего места; централизованный просмотр и управление открытыми сессиями, запущенными с использованием программы доставки рабочего места Termidesk Viewer. Совместно с «Клиентом» устанавливается программа доставки рабочего места Termidesk Viewer, которая входит в состав Termidesk и предоставляет следующие возможности: перенаправление буфера обмена (определяется администратором Termidesk в политиках фонда); вывод изображения на несколько мониторов; создание снимка экрана; передача файлов; перенаправление каталогов; перенаправление смарт-карт; перенаправление USB-устройств; перенаправление веб-камер; перенаправление принтеров; передача сочетаний клавиш; получение статистики сеанса и состояния канала связи
«Оркестратор»	Самостоятельный компонент, отвечающий за автоматизацию развертывания Termidesk в облачных структурах
«Сервер терминалов Astra Linux» (STAL)	Самостоятельный компонент, отвечающий за организацию терминального доступа в ОС Astra Linux Special Edition
«Удаленный помощник»	Самостоятельный компонент, предоставляющий администратору или специалисту технической поддержки экран узла пользователя через сеанс удаленного подключения и обеспечивающий передачу голосовой информации для взаимодействия с пользователем. Компонент состоит из: серверной части, устанавливаемой на узел консультирующего специалиста или на отдельный сервер (для подключения к ВРМ из веб-интерфейса Termidesk); клиентской части, устанавливаемой на рабочую станцию пользователя или в ВРМ
«Виртуальный модуль Termidesk»	Самостоятельный компонент, представляющий собой образ ВМ (или диска ВМ) с предварительно установленной и настроенной ОС и набором программного обеспечения, необходимого для эксплуатации Termidesk. Компонент позволяет быстро развернуть и использовать СУБД PostgreSQL, RabbitMQ, ферму Termidesk c компонентами «Универсальный диспетчер», «Шлюз», «Менеджер рабочих мест», а также ферму «Агрегатора»
«Termidesk Live»	Самостоятельный компонент, представляющий собой загрузочный образ ОС с предустановленным компонентом «Клиент». «Termidesk Live» поддерживает добавление приложений в ОС посредством файловой системы OverlayFS

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

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

Поскольку основная задача «Универсального диспетчера» – предоставить рабочие места пользователю, в нем реализованы следующие функции:

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

«Агрегатор» доступен в продукте Termidesk VDI.

Агрегатор может быть установлен со следующими типами веб-интерфейса:

• «Агрегатор администратора» - веб-интерфейс управления «Агрегатором»;
• «Агрегатор пользователя» - веб-интерфейс пользователя для получения ресурсов, предоставляемых «Агрегатором»;
• «Портал универсальный» - веб-интерфейс, предоставляющий функции обоих вариантов.

Основная задача «Агрегатора» – предоставить пользователю объединенный набор ресурсов, поэтому в нем реализованы следующие функции:

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

«Шлюз» обеспечивает изоляцию инфраструктуры VDI и терминальных серверов, находящихся во внутренней локальной сети, от внешних локальных или глобальных сетей.

 Рекомендуется использовать «Шлюз» при работе через недоверенные сети, поскольку это способствует не только защищенному взаимодействию (применяется протокол SSL), но и сокрытию инфраструктуры рабочих мест.

 «Шлюз» использует технологию websockets (WS) для туннелирования протоколов доставки. «Универсальный диспетчер» передает на «Клиент» информацию о «Шлюзе», через который будет осуществляться доставка рабочего места. «Клиент» устанавливает со «Шлюзом» защищенное соединение. Схема работы представлена на рисунке.

Termidesk может взаимодействовать со множеством «Шлюзов», настроенных в режиме балансировки нагрузки.

Работа «Менеджера рабочих мест» основывается на следующих службах:

• termidesk-taskman - работает с API платформ виртуализации, отправляет команды на создание и удаление ВРМ, шаблонов рабочих мест. За установку этой службы отвечает роль «Менеджер рабочих мест» в инсталляторе termidesk-vdi;
• termidesk-celery-worker - выполняет отложенные задачи. В будущем эта служба заменит termidesk-taskman. За установку этой службы отвечает роль «Менеджер рабочих мест (очереди)» в инсталляторе termidesk-vdi;
• termidesk-celery-beat - является планировщиком фоновых задач, запуск осуществляется по расписанию. Взаимодействует со службой RabbitMQ. За установку этой службы отвечает роль «Менеджер рабочих мест (очереди)» в инсталляторе termidesk-vdi.

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

• устанавливаются в гостевую ОС ВМ или автономной машины: «Агент виртуального рабочего места», «Видеоагент», «Агент виртуальных смарт-карт»;
• устанавливается на узел виртуализации ПК СВ Брест: «Агент узла виртуализации»;
• устанавливается на узел терминального сервера: «Сессионный агент».

Для отображения экрана рабочего места «Клиент» открывает соответствующую программу:

• при использовании протоколов SPICE, TERA будет запущено ПО Termidesk Viewer;
• при использовании протокола RDP будет запущено одно из приложений в зависимости от используемой ОС: wfreerdp.exe, mstsc.exe, xfreerdp, ПО Termidesk Viewer (если в настройках «Клиента» активирован экспериментальный функционал).

При подключении через «Шлюз» «Клиент» использует программу vdi-proxy (входит в состав «Клиента») для создания WS-туннеля между запускаемой программой и опубликованным ресурсом (ВРМ или приложением). В качестве аргумента для vdi-proxy передается путь к конфигурационному файлу, который содержит параметры подключения. vdi-proxy подключается по URL к «Шлюзу» и создает WS-туннель (по сути протокол HTTPS с шифрованием). Далее от «Шлюза» до «Агента» создаётся TCP-соединение.

Схема работы представлена на рисунке.

В текущей реализации выполняет роль API-шлюза и обеспечивает обработку запросов внутри управляемого контура и передачу результата обработки облачным компонентам.

Схема работы «Оркестратора» представлена на рисунке.

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

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

Процесс PROXY – внутренний сервис, прослушивающий сетевой сокет на порте 3389 и транслирующий подключения в unix-сокеты, с которыми связан терминальный сервер.

Для того чтобы пользователь после запуска «Клиента» получил приложение или терминальный доступ к STAL, происходит следующее:

• на сервере с установленным STAL сервис PROXY выполняется с правами служебного пользователя stal-proxy;
• пользователь подключается к серверу Termidesk через «Клиент», получает список доступных ему приложений и терминалов и выбирает необходимое подключение;
• от компонента сессионного агента на сервис STAL поступает запрос на создание сессии. Взаимодействие между компонентами выполняется посредством dbus;
• сервис STAL создает X (первую, вторую и так далее) сессию пользователя (в зависимости от количества подключившихся пользователей);
• сервис STAL отправляет сигнал на открытие порта на сервис PROXY;
• сервис PROXY открывает порт 3389 (по умолчанию) на прием соединений и ожидает подключения от «Клиента»;
• при подключении «Клиента» сервис PROXY принимает соединение, затем выполняет следующее:
  • закрывает сокет приема соединений;
  • запускает протокол RDP на локальный unix-сокет;
  • создает асинхронную задачу на передачу данных с сокета принятого соединения «Клиента» на unix-сокет;
  • отправляет на сервис STAL информацию о соединении «Клиента»;
• «Клиент» получает доступ в X-сессию;
• сервис PROXY отслеживает состояние подключения «Клиента» и останавливает передачу данных, если поступил сигнал на отключение от STAL.

Для того чтобы пользователь со своего АРМ смог перенаправить подключенный диск в терминальную сессию, происходит следующее:

• «Cессионный агент» устанавливает политику разрешения перенаправления дисков для терминальной сессии;
• STAL выполняет запуск сервера freerdp-shadow с каналом RDPDR (клиент шины DBus ru.uveon.stal.rdpdr);
• при первом обращении в шину запускается STAL-RDPDR (менеджер сессионной шины DBus ru.uveon.stal.rdpdr);
• служба xfreerdp (или другие программы доставки, использующиеся у пользователя - например, mstsc или ПО Termidesk Viewer) передает служебную информацию через протокол MS-RDPEFS;
• расширение RDPDR транслирует команды протокола RDPDR в шину DBus ru.uveon.stal.rdpdr;
• STAL-FUSE (менеджер службы fuse) запускается на каждую точку монтирования и транслирует команды RDPDR в FUSE API;
• пользователь получает подключенный к точке монтирования ресурс.

Для того чтобы пользователь со своего АРМ смог перенаправить печать из терминальной сессии, происходит следующее:

Печать пользователей изолирована и выполняется в отдельных сессиях при подключении разных пользователей с разных АРМ.

• «Cессионный агент» устанавливает политику разрешения печати для терминальной сессии;
• STAL выполняет запуск сервера freerdp-shadow с каналом RDPDR (клиент шины DBus ru.uveon.stal.rdpdr);
• при первом обращении в шину запускается STAL-RDPDR (менеджер сессионной шины DBus ru.uveon.stal.rdpdr);
• при старте системы запускается STAL-RDPEPC (менеджер системной шины DBus ru.uveon.stal.rdpepc);
• служба xfreerdp (или другие программы доставки, использующиеся у пользователя - например, mstsc или ПО Termidesk Viewer) передает служебную информацию через протокол RDPEPC (базируется на операциях протокола RDPDR);
• расширение RDPDR транслирует команды протокола RDPEPC в шину DBus ru.uveon.stal.rdpdr и далее в шину DBus ru.uveon.stal.rdpepc;
• STAL-RDPEPC транслирует команды в CUPS API;
• пользователь автоматически получает виртуальные принтеры во всех своих сессиях;
• пользователь инициирует печать документа на виртуальный принтер;
• CUPS запускает печать через VPRINT (драйвер виртуального принтера);
• VPRINT сохраняет задание в каталоге JOBS SPOOL и как клиент DBus отправляет в STAL-RDPEPC информацию о завершении печати документа, количества копий, страницы и т.д.;
• STAL-RDPEPC передает данные печати через DBus в сессию пользователя в STAL-RDPDR;
• RDPDR отправляет данные печати через RDPEPC.

Вариант развертывания фермы 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).

Целевым решением для доступа пользователей к терминальному серверу MS RDS является использование поставщика ресурсов «Метапоставщик», реализованного в Termidesk.

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

«Метапоставщик» доступен в продукте Termidesk VDI.

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

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

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

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

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

Серверы СУБД и RabbitMQ входят в область инфраструктурных сервисов, однако необходимы для функционирования непосредственно Termidesk. Отказоустойчивость этих серверов настраивается согласно документации на используемые решения.

Рекомендуемое количество серверов «Менеджер рабочих мест» - 2 шт. Количество может быть N, однако активен будет всегда один сервер, поскольку используется балансировка «active-passive» через механизм keepalive. 

Схема установки Termidesk со STAL

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

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

Схема установки Termidesk с MS RDS

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

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

Масштабируемость

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

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

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

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

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

В текущей архитектуре балансировщики могут быть реализованы программным обеспечением nginx/haproxy.

• • компонент «Универсальный диспетчер» – обеспечивает работу веб-интерфейса панели управления Termidesk и веб-интерфейса портала пользователя, отвечает за идентификацию пользователей, назначение и контроль доставки им рабочих мест;
  • компонент «Менеджер рабочих мест» – является обработчиком фоновых задач;

В текущей архитектуре компонент «Менеджер рабочих мест» работает посредством служб termidesk-taskman, termidesk-celery-beat, termidesk-celery-worker. Происходит плавный переход на работу только со службами termidesk-celery-beat, termidesk-celery-worker.

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

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

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

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

«Агрегатор» использует часть функций «Универсального диспетчера». Для упрощения описания ниже «Универсальный диспетчер», относящийся к «Агрегатору», будет назван «Агрегатором».

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

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

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

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

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

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

Функционирование Termidesk в варианте доставки ВРМ, а не терминальной сессии или приложения, невозможно без компонентов «Универсальный диспетчер», «Менеджер рабочих мест», «Агент виртуального рабочего места », «Агент узла виртуализации». Для получения ВРМ на пользовательской рабочей станции должен быть установлен компонент «Клиент».

Остальные компоненты могут расширить функциональность программного комплекса под определенные потребности, их установка является опциональной:

• «Шлюз» поможет скрыть инфраструктуру от внешних воздействий. При этом он может устанавливаться на отдельный узел, не совмещенный с «Универсальным диспетчером»;
• «Видеоагент» необходимо установить в гостевую ОС тиражируемой ВМ в случае, если нужно предоставить пользователю возможность перенаправить видеокамеру в ВРМ;
•  «Агент виртуальных смарт-карт» необходимо установить в гостевую ОС тиражируемой ВМ в случае, если нужно предоставить пользователю возможность перенаправить смарт-карты в ВРМ.

Функционирование Termidesk в варианте доставки терминальных сессий или приложений невозможно без компонентов «Универсальный диспетчер», «Менеджер рабочих мест», «Сессионный агент», STAL (для ОС Astra Linux Special Edition). Для получения терминальной сессии или приложения на пользовательской рабочей станции по-прежнему должен быть установлен компонент «Клиент». Установка компонента «Шлюз» опциональна.

Для объединения доступных пользователю ресурсов с нескольких установок (ферм) Termidesk в едином интерфейсе стоит использовать «Агрегатор», установка которого должна быть отделена от фермы Termidesk.