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

Общая информация

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

Полезные видоматериалы:

Технологии VDI и терминального доступа

Virtual Desktop Infrastructure (VDI), или инфраструктура виртуальных рабочих столов, – это инфраструктура, обеспечивающая пользователям удаленный доступ к виртуальным рабочим местам (ВРМ).

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

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

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

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

Назначение Termidesk

Программный комплекс «Диспетчер подключений виртуальных рабочих мест Termidesk» (далее – Termidesk) – это решение для организации рабочих мест посредством протоколов удаленного доступа.

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

ВРМ;
терминальная сессия или опубликованное приложение, а именно:
- рабочий стол сервера терминалов 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 VDI

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

Разделение функционала происходит при активации соответствующего типа лицензии.

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

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

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

Для сокрытия инфраструктуры от внешних воздействий используется программа для электронной вычислительной машины «Балансировщик нагрузки Термидеск Коннект» (Termidesk Connect) с лицензией Termidesk Connect Basic. Инструкции по установке и настройке доступны по ссылкам: Инструкция по настройке Шлюза для Termidesk VDI (первый способ), Инструкция по настройке Шлюза для Termidesk VDI (второй способ).

Особенности:

для реализации функционала «Шлюза» используется лицензия Termidesk Connect Basic;
для реализации функционала балансировщика используется лицензия Termidesk Connect. При отсутствии лицензии допускается использование сторонних балансировщиков нагрузки.

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

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

Перечень компонентов Termidesk

Termidesk состоит из ряда на компонентов (см. таблицу Компоненты Termidesk), которые могут быть либо отделяемыми (подразумевает выбор роли при установке из общего пакета), либо самостоятельными (компонент устанавливается из отдельного пакета, но используется в составе общего комплекса). Такое разделение обеспечивает гибкое масштабирование системы для различных сценариев применения.

Компоненты могут быть объединены в фермы Termidesk. Ферма – логическое объединение узлов, взаимодействующих с одной базой данных (БД). На ферме размещаются ресурсы для пользователя.

Начиная с Termidesk версии 6.1 компонент «Шлюз» (пакет termidesk-gateway) не входит в основную поставку. Для замены «Шлюза» следует использовать Termidesk Connect с лицензией Termidesk Connect Basic. Инструкции по установке и настройке доступны по ссылкам: Инструкция по настройке Шлюза для Termidesk VDI (первый способ), Инструкция по настройке Шлюза для Termidesk VDI (второй способ).

Особенности:

для реализации функционала «Шлюза» используется лицензия Termidesk Connect Basic;
для реализации функционала балансировщика используется лицензия Termidesk Connect. При отсутствии лицензии допускается использование сторонних балансировщиков нагрузки.

Например, в одну ферму могут быть объединены следующие узлы:

узел с установленным «Порталом администратора»;
узел с установленным «Порталом пользователя»;
узел с установленным «Менеджером рабочих мест»;
(опционально) узел Termidesk Connect для реализации функционала «Шлюза».

Дополнительно должны быть установлены инфраструктурные сервисы:

узел с установленной БД или кластер узлов с БД;
узел с установленным брокером сообщений RabbitMQ.

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

Пример распределения компонентов и ролей:

ферма Termidesk:
- узел с установленным «Порталом администратора»;
- узел с установленным «Порталом пользователя»;
- узел с установленным «Менеджером рабочих мест»;
- (опционально) узел Termidesk Connect для реализации функционала «Шлюза»;
инфраструктурные сервисы для фермы Termidesk:
- узел с установленной БД или кластер узлов с БД;
- узел с установленным брокером сообщений RabbitMQ;
ферма «Агрегатора»:
- узел с установленным «Порталом администратора»;
- узел с установленным «Порталом пользователя»;
- узел с установленным «Менеджером рабочих мест»;
- (опционально) узел Termidesk Connect для реализации функционала «Шлюза»;
инфраструктурные сервисы для фермы «Агрегатора»:
- узел с установленной БД или кластер узлов с БД;
- узел с установленным брокером сообщений RabbitMQ (в общем случае может использоваться тот же, что в ферме Termidesk, но обязательно - отдельный виртуальный хост).

Компонент Termidesk Описание

«Универсальный диспетчер»

Отделяемый компонент, отвечающий за взаимодействие с гипервизорами, идентификацию пользователей, назначение и контроль доставки им ВРМ, предоставление терминального доступа. «Универсальный диспетчер» использует СУБД PostgreSQL (и СУБД, основанные на PostgreSQL) для хранения информации о подключениях пользователей.

«Универсальный диспетчер» предоставляет следующие веб-порталы:

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

В случае, если производится комплексная установка и выбираются оба веб-портала фермы (например, «Портал администратора» и «Портал пользователя»), будет активирован «Портал универсальный», предоставляющий все функции

«Менеджер рабочих мест»

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

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

Компонент состоит из служб:

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

Обе службы используются для управления питанием ВМ, а также отслеживания состояния компонентов инфраструктуры Termidesk.

Процесс автоматического опроса состояния компонентов осуществляется следующим образом:

компонент Termidesk помещает информацию о себе в очередь брокера сообщений RabbitMQ;
служба termidesk-celery-beat с периодичностью в 60 секунд забирает из очереди RabbitMQ список всех узлов компонентов фермы Termidesk;
служба termidesk-celery-beat создает задачу на опрос состояния;
далее служба termidesk-celery-worker выполняет задачу на опрос состояния узлов. Полученные результаты служба termidesk-celery-worker записывает в БД

«Агент»

Самостоятельный компонент, отвечающий за контролируемую доставку, взаимодействие с компонентами «Универсальный диспетчер» и «Менеджер рабочих мест».

Включается в себя:

«Агент виртуального рабочего места» – устанавливается в гостевую ОС рабочего места (ВМ, автономной машины или терминального сервера). Обеспечивает настройку рабочего места при публикации и передачу сообщений пользователю, фиксирует действия пользователей в ВРМ;
«Агент узла виртуализации» – устанавливается на хостах виртуализации ПК СВ Брест. Обеспечивает отключение (выход из сеанса работы с ОС) и сброс SPICE-сессий. Работает в качестве посредника между libvirtd и «Агентом виртуального рабочего места» через именованный virtio-`канал `/dev/virtio-ports/ru.termidesk.tvm.0;
«Сессионный агент» – устанавливается в ОС терминального сервера. Обеспечивает доставку терминальных сессий и приложений пользователю;
«Агент виртуальных смарт-карт» – устанавливается в гостевую ОС рабочего места. Обеспечивает перенаправление смарт-карт (работающих по спецификации PC/SC) с пользовательской рабочей станции в рабочее место:
- через канал /dev/virtio-ports/ru.termidesk.PCSC.0 – если установка выполняется в ОС рабочего места, размещенного на платформе виртуализации (ПК СВ Брест, oVirt, zVirt, РЕД Виртуализация, VMmanager), доступ к которому осуществляется по протоколу SPICE;
- через разделяемую память (Shared Memory, SHM) – если установка выполняется в ОС рабочего места, доступ к которому осуществляется по протоколу TERA;
«Видеоагент» – устанавливается в гостевую ОС рабочего места. Обеспечивает прием изображений с веб-камеры пользовательской рабочей станции:
- через канал /dev/virtio-ports/ru.termidesk.RealtimeStreaming.0 – если установка выполняется в ОС рабочего места, размещенного на платформе виртуализации (ПК СВ Брест, oVirt, zVirt, РЕД Виртуализация, VMmanager), доступ к которому осуществляется по протоколу SPICE;
- через разделяемую память (Shared Memory, SHM) – если установка выполняется в ОС рабочего места, доступ к которому осуществляется по протоколу TERA

Каналы должны быть активированы на платформе виртуализации.

«Клиент»

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

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

Совместно с «Клиентом» устанавливается программа доставки рабочего места Termidesk Viewer, которая входит в состав Termidesk и предоставляет следующие возможности:

перенаправление буфера обмена (определяется администратором Termidesk в политиках фонда);
вывод изображения на несколько мониторов;
создание снимка экрана;
передача файлов;
перенаправление каталогов;
перенаправление смарт-карт;
перенаправление USB-устройств;
перенаправление веб-камер;
перенаправление принтеров;
передача сочетаний клавиш;
получение статистики сеанса и состояния канала связи

«Оркестратор»

Самостоятельный компонент, отвечающий за автоматизацию развертывания Termidesk в облачных структурах

«Сервер терминалов Astra Linux» (STAL)

Самостоятельный компонент, отвечающий за организацию терминального доступа в ОС Astra Linux Special Edition

«Удаленный помощник»

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

Компонент состоит из:

серверной части, устанавливаемой на узел консультирующего специалиста или на отдельный сервер (для подключения к рабочему месту из веб-интерфейса Termidesk);
клиентской части, устанавливаемой на рабочую станцию пользователя или на рабочее место

«Виртуальный модуль Termidesk»

Самостоятельный компонент, представляющий собой образ ВМ (или диска ВМ) с предварительно установленной и настроенной ОС и набором программного обеспечения, необходимого для эксплуатации Termidesk. Компонент позволяет быстро развернуть и использовать СУБД PostgreSQL, RabbitMQ, ферму Termidesk c компонентами «Универсальный диспетчер», «Шлюз» (пакет termidesk-gateway), «Менеджер рабочих мест», а также ферму «Агрегатора»

«Termidesk Live»

Самостоятельный компонент, представляющий собой загрузочный образ ОС с предустановленным компонентом «Клиент». «Termidesk Live» поддерживает добавление приложений в ОС посредством файловой системы OverlayFS

TERA

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

TERA обеспечивает:

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

TERA устанавливается в гостевую ОС ВМ или ОС физической машины

«Ретранслятор»

Самостоятельный компонент, отвечающий за сбор и фильтрацию записей журналов, поступающих от компонентов Termidesk, и их перенаправления в централизованное хранилище журналов

«Брокер сообщений TermideskMQ»

Отделяемый компонент, отвечающий за взаимодействие между различными компонентами или приложениями, обеспечивая надежную асинхронную передачу данных

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

Схема взаимодействия компонентов и приложений

Схема взаимодействия компонентов Termidesk VDI и приложений представлена на рисунке (см. рисунок Схема взаимодействия компонентов и приложений).

Рисунок 1. Схема взаимодействия компонентов и приложений

«Универсальный диспетчер»

Компонент, отвечающий за идентификацию пользователей, назначение и контроля доставки им ВРМ, приложений и рабочих столов.

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

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

«Агрегатор»

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

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

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

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

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

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

«Менеджер рабочих мест»

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

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

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

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

«Агент»

Без установленного на соответствующем узле «Агента» сервер Termidesk не сможет корректно взаимодействовать с этим узлом. По среде установки эти «Агенты» распределяются следующим образом:

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

«Клиент»

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

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

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

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

Рисунок 2. Схема работы компонента «Клиент»

«Оркестратор»

Компонент, отвечающий за автоматизацию развертывания Termidesk в облачных структурах.

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

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

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

STAL

«Сервер терминалов Astra Linux» или STAL – компонент, отвечающий за организацию терминального доступа в ОС Astra Linux Special Edition (Server). Компонент STAL может использоваться как в Termidesk VDI, так и в Termidesk Terminal.

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

В Termidesk версии 7.0 произошла значительная переработка архитектурного решения STAL, ключевые изменения (см. рисунок Обновленная архитектура STAL):

реорганизация процессов и четкое разделение ответственности. В новой версии STAL 4.X строго определены роли каждого процесса и контракты их взаимодействия. Это упрощает анализ проблем и изолирует критические компоненты;
отказ от неэффективного прокси-сервиса (stal-proxy). Вместо отдельного потока для ретрансляции данных между сокетами (с накладными расходами на переключение контекста ядра), дескриптор входящего RDP-соединения напрямую передается процессу транспорта в сеансе пользователя. Это снижает нагрузку на систему и уменьшает задержки;
интеграция транспорта в сеанс пользователя. Процесс транспорта (stal-shadow-server) становится полноправным членом группы процессов сеанса. Это решает проблемы с корректным завершением (устраняет ошибки сегментации) и позволяет использовать общие механизмы IPC без конфликтов мандатного контроля целостности (МКЦ) в ОС Astra Linux Special Edition;
изоляция менеджера сеансов. Процесс stal-session-manager, работающий с высокими привилегиями, защищен от прямого внешнего D-BUS воздействия. Вся коммуникация с внешним миром проходит через адаптер stal-service, работающего с пониженными привилегиями;
переход на модель использования плагинов для RDP-каналов. Логика каналов (перенаправление папок, принтеров, аудио, смарт-карт и т.д.) вынесена из основного кода в динамические библиотеки (плагины). Это снижает связанность с библиотекой FreeRDP и упрощает ее обновление;
унификация поставки. Все компоненты STAL 4.X поставляются одним пакетом вместо нескольких, что упрощает установку и обновление.

Рисунок 4. Обновленная архитектура STAL

Основные модули, входящие в STAL 4.X, перечислены в таблице (см. таблицу Основные модули STAL).

Таблица 2. Основные модули STAL
Модуль	Описание
`stal-service`	Адаптер для всех взаимодействий с внешним окружением. Принимает запросы от «Сессионного агента» и RDP-клиентов. Работает с привилегиями системной учетной записи `stal-proxy`. Регистрирует интерфейс `ru.uveon.stal` на системной D-BUS. Диспетчер службы обрабатывает входящие подключения (порт 3389), извлекает идентификатор сеанса (`correlation-id`) и передает сокет в нужный транспорт
`stal-session-manager`	Управляет жизненным циклом сеансов пользователей. Запускает процессы-лидеры `stal-session`. Имеет высокий уровень привилегий. Регистрирует защищенный интерфейс `ru.uveon.stal.SessionManager` на системной D-BUS. Хранит состояние сеансов в модели `SessionStorage`
`stal-session`	Лидер процесса сеанса пользователя. Порождается менеджером сеансов (`stal-session-manager`). Запускает X-сервер (Xorg), оконный менеджер и процесс транспорта (`stal-shadow-server`). Выполняет PAM-аутентификацию и управляет группами процессов. Связан с менеджером сеансов через скрытое peer-to-peer D-BUS соединение (интерфейс `SessionPeer`)
`stal-shadow-server`	Процесс транспорта RDP. Реализует протоколы доставки изображения, перенаправления устройств и т.д. Использует библиотеку FreeRDP. Загружает плагины каналов. Работает в контексте сеанса пользователя с его привилегиями и меткой целостности (для Astra Linux Special Edition)

Процесс создания сеанса пользователя:

«Сессионный агент» отправляет запрос SessionRequest через интерфейс ru.uveon.stal в службу stal-service;
stal-service валидирует запрос и вызывает асинхронный метод CreateSession у менеджера сеансов (stal-session-manager) через интерфейс ru.uveon.stal.SessionManager;
менеджер сеансов (через фабрику сеансов) определяет учетную запись пользователя и создает контекст будущего сеанса в разделяемой памяти;
с помощью менеджера процессов запускается лидер сеанса stal-session, которому передается идентификатор региона памяти. Устанавливается peer-to-peer D-BUS соединение (интерфейс SessionPeer);
stal-session считывает контекст, выполняет аутентификацию через PAM, открывает сеанс через systemd, запускает Xorg и оконный менеджер;
лидер сообщает свой статус через SessionPeer. Менеджер сеансов обновляет состояние в SessionStorage и возвращает идентификатор сеанса (SID) «Сессионному агенту» через цепочку ответов.

Процесс подключения RDP-клиента:

«Сессионный агент» получает SID и запрашивает у stal-service создание cookie (токена) через метод ConnectTransport;
stal-service запрашивает у менеджера сеансов (stal-session-manager) CreateCookie, менеджер обращается к модели SessionStorage, получает значение cookie для данного SID и возвращает ее «Сессионному агенту»;
«Сессионный агент» передает cookie «Клиенту». «Клиент» (ПО Termidesk Viewer) запускается с параметром /correlation-id:<cookie> и подключается к порту 3389, отправляя CR-PDU с этой cookie;
stal-service извлекает значение cookie, вызывает запрос на транспорт RequestTransport у менеджера сеансов;
менеджер сеансов находит по cookie нужный сеанс и через Session вызывает у лидера создание транспорта CreateTransport;
лидер stal-session запускает stal-shadow-server и возвращает путь к IPC-сокету транспорта;
stal-service подключается к этому IPC-сокету и передает дескриптор входящего соединения (сокет «Клиента») напрямую в stal-shadow-server. После передачи соединение закрывается, а stal-service лишь контролирует разрыв соединения.

Процесс работы транспорта RDP:

stal-shadow-server загружает плагины для RDP-каналов (принтеры, звук, буфер обмена и т.д.), которые регистрируются в реестре протокола;
при подключении «Клиента» плагины активируют свои каналы. Вся обработка данных происходит непосредственно в процессе сеанса, без дополнительных прокси-потоков;
процесс транспорта связывается с лидером сеанса через модель с интерфейсом ru.uveon.stal.Session и peer-to-peer D-BUS соединением;
аутентификация пользователей на уровне транспорта выполняется через ru.uveon.stal.Session в процессе лидере сеанса;
при завершении сеанса лидер корректно завершает все дочерние процессы в необходимой последовательности, что исключает ошибки доступа к памяти.

«Брокер сообщений TermideskMQ»

Компонент, отвечающий за асинхронное выполнение задач в инфраструктуре Termidesk VDI. Является связующим звеном между процессами компонентов, создающими задачи (termidesk-vdi, termidesk-celery-beat, termidesk-celery-worker), и исполнителями (termidesk-celery-worker).

Основная цель, решаемая компонентом - снижение нагрузки на исполнителя (termidesk-celery-worker) при лавинообразном нарастании сообщений.

Ключевые параметры конфигурации брокера настраиваются в конфигурационном файле /etc/opt/termidesk-vdi/termidesk.conf (см. подраздел Конфигурационный файл termidesk.conf). Их наименования начинаются с TMQ_.

Общая схема работы компонентов c «Брокером сообщений TermideskMQ» приведена на рисунке (см. Схема работы c компонентом «Брокер сообщений TermideskMQ»).

Рисунок 5. Схема работы c компонентом «Брокер сообщений TermideskMQ»

Принцип доставки сообщений:

ферма Termidesk, либо ферма «Агрегатора» отправляет задачу в один из брокеров;
брокер немедленно возвращает подтверждение Accepted и после этого сохраняет сообщение в БД;
termidesk-tmq работает по pull-принципу, поэтому termidesk-celery-worker периодически опрашивает брокера и получает задачи из своей логической очереди (TMQ_CLIENT_ID). Брокер гарантирует, что каждая задача будет выдана только одному termidesk-celery-worker;
после передачи задачи в `termidesk-celery-worker`она удаляется из БД, что исключает ее повторную обработку.

При сбое на этапе сохранения или передачи задача может быть потеряна - это сознательный компромисс в пользу производительности и минимизации блокировок.

При накоплении сообщений (росте очереди) рекомендуется добавить дополнительные хосты с termidesk-celery-worker или увеличить ресурсы существующих.

Для быстрого переключения на работающие ноды полезно уменьшить таймаут ожидания (TMQ_TIMEOUT_AWAIT_GETTING_MESSAGE).

Таким образом поток выполнения задачи представляет собой следующее:

генерация - задача создается в termidesk-celery-beat (по расписанию), «Универсальном диспетчере» (по действию администратора или персонала) или в termidesk-celery-worker (в момент публикации фонда РМ, задачи на проверку машин в поставщике ресурсов);
отправка - задача через протокол ZMQ и через mTLS proxy (если используется) отправляется на ноду брокера (или на одну из нод при использовании кластера, выбор выполняется по алгоритму Round-robin);
прием - брокер отправляет подтверждение отправителю и после этого сохраняет задачу в БД;
выдача - termidesk-celery-worker запрашивает задачи у брокера, а он в ответ выдает один экземпляр задачи из логической очереди (TMQ_CLIENT_ID), потом удаляет ее из БД;
исполнение - termidesk-celery-worker распределяет задачу между своими внутренними процессами (исполнителями) и выполняет ее;
мониторинг - состояние очередей и сертификатов предоставляется через внутренний API и отображается в веб-портале Termidesk VDI - «Портале администратора».

Общие схемы установки

Общая схема установки решения Termidesk VDI

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

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

Фонд - совокупность ВРМ, размещенных на платформе виртуализации.

Публикация - запуск процесса наполнения фонда ВРМ в соответствии с заданными параметрами.

Рисунок 6. Архитектура Termidesk VDI

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

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

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

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

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

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

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

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

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

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

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

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

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

Общая схема установки решения Termidesk с терминальными сервисами

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

Рисунок 7. Архитектура Termidesk с терминальными сервисами

Для решения задач по доставке приложений и рабочих столов терминальных серверов с ОС 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.

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

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

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

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

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

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

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

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

STAL как отдельный сервер (см. рисунок Схема распределенной установки Termidesk VDI с отдельным сервером STAL);
STAL в Метапоставщике (см. рисунок Схема распределенной установки Termidesk VDI с метапоставщиком STAL).

Рисунок 9. Схема распределенной установки Termidesk VDI с отдельным сервером STAL

Рисунок 10. Схема распределенной установки Termidesk VDI с метапоставщиком STAL

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

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

MS RDS как отдельная настроенная инфраструктура (см. рисунок Схема распределенной установки Termidesk VDI с отдельной инфраструктурой MS RDS);
MS RDS в Метапоставщике (см. рисунок Схема распределенной установки Termidesk VDI с метапоставщиком MS RDS).

Рисунок 11. Схема распределенной установки Termidesk VDI с отдельной инфраструктурой MS RDS

Рисунок 12. Схема распределенной установки Termidesk VDI с метапоставщиком MS RDS

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

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

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

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

Рисунок 13. Схема горизонтального масштабирования Termidesk VDI

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

Сети:
- EXTERNAL NET – внешняя сеть, в которой находятся пользователи;
- MGMT NET – управляющая сеть Termidesk;
- DISPLAY NET – сеть узлов платформ виртуализации для подключения к экранам пользовательских рабочих станций;
- VM NET – сеть рабочих мест для терминирования прямых подключений (например, RDP).
Компоненты:
- балансировщик – представляет собой точку входа в Termidesk для внешних пользователей и внутренних компонент. Принимает HTTP-запросы на внешние и внутренние доменные имена Termidesk и распределяет обычные запросы между серверами Termidesk;
  
  В текущей архитектуре балансировщики могут быть реализованы программным обеспечением nginx/haproxy.
- компонент «Универсальный диспетчер» – обеспечивает работу веб-интерфейса панели управления Termidesk VDI и веб-интерфейса портала пользователя, отвечает за идентификацию пользователей, назначение и контроль доставки им рабочих мест;
- компонент «Менеджер рабочих мест» – является обработчиком фоновых задач;
- Termidesk Connect (Шлюз) – обеспечивает работу WS-подключений;
- кластер БД – обеспечивает работу при больших нагрузках на БД. Состоит из балансировщика для подключений к серверам БД и непосредственно серверов БД.

Рисунок 14. Схема горизонтального масштабирования Termidesk VDI

Облачное развертывание

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

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

Рисунок 15. Архитектура Termidesk VDI в облаке

Схемы с «Агрегатором»

Общая схема установки фермы «Агрегатора»

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

Общая схема установки Агрегатора и фермы Termidesk VDI представлена на рисунке (см. рисунок Схема установки «Агрегатора»).

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

Рисунок 16. Схема установки «Агрегатора»

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

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

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

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

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

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

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

Общая схема распределенной установки фермы «Агрегатора»

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

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

Рисунок 17. Общая схема распределенной установки «Агрегатора»