Схемы взаимодействия компонентов Termidesk

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

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

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

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

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

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

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

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

• termidesk-celery-beat – отслеживает очереди брокера сообщений RabbitMQ на предмет наличия заданий для выполнения (например, публикации фонда, удаления ВМ и др.). Обеспечивает передачу заданий службе termidesk-celery-worker;
• termidesk-celery-worker – обеспечивает управление питанием ВРМ и сбор информации о терминальных сессиях. Выполняет задачи, размещенные в очереди брокера сообщений RabbitMQ.

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

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

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

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

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

При использовании ПО Termidesk Viewer программа vdi-proxy не используется, подключение выполняет ПО Termidesk Viewer.

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

В текущей реализации выполняет роль 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.