История страницы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• при использовании протоколов 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 приведена на рисунке.

Для того чтобы пользователь после запуска «Клиента» получил приложение или терминальный доступ к 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.