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

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

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

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

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

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

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

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

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

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

Termidesk состоит из ряда компонентов, которые могут быть либо отделяемыми (подразумевает выбор роли при установке из общего пакета), либо самостоятельными (компонент устанавливается из отдельного пакета, но используется в составе общего комплекса): 

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

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

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

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

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

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

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

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

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

• «Клиент» подключается к указанному серверу («Диспетчеру подключений») и передает учетные данные пользователя, с которыми он хочет подключит ься;
• «Диспетчер подключений» запрашивает сервер каталогов для аутентификации пользователя;
• при успешной аутентификации «Диспетчер подключений» посылает команду серверу терминалов  о подключении аутентифицированного пользователя через сессионный агент;
• от сессионного агента на сервер терминалов поступает запрос на создание сессии. Взаимодействие выполняется посредством dbus ;
• при успешном создании сессии агент сообщает «Диспетчеру подключений» о готовности к работе;
• пользователь получает доступ в сессию через «Клиент», который в свою очередь запускает соответствующее приложение (mstsc/wfreerdp или xfreerdp) для ее отображения.

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

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

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

Соединения от «Шлюза» формируются напрямую (без WS) по протоколу SPICE на гипервизор, по протоколу RDP в гостевую ОС или сервер терминалов.

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

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

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

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

Общая схема взаимодействия 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.

Распределенная схема установки

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

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

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

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

В случае, если планируется использование Termidesk VDI со STAL, схема приобретет следующий вид.

Схема распределенной установки Termidesk VDI с инфраструктурой Microsoft (Active Directory,  Remote Desktop Services) и доменом аутентификации ALD Pro представлена на рисунке. 

Отказоустойчивая схема установки

В отказоустойчивом режиме балансировка серверов Termidesk осуществляется в режиме «Primary-Secondary» (также «Active-Passive»). Отказоустойчивость БД выполняется средствами СУБД.

Отказоустойчивая схема установки представлена на рисунке.

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

С целью увеличения производительности распределенной инфраструктуры 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.

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

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

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

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

КОМПОНЕНТЫ TERMIDESK

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

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

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

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

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

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

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

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

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

• агент ВРМ - выполняет взаимодействие с диспетчером Termidesk, конфигурирует ВРМ, фиксирует действия пользователя, реализует передачу управляющих сообщений;
• агент узла виртуализации - взаимодействует с гипервизором через модуль  libvirt. Работает в качестве посредника между libvirtd и агентом ВРМ через virtio канал /dev/virtio-ports/ru.termidesk.tvm.0, управляя тем самым ВМ, на которой запущен агент ВРМ;
• сессионный агент - активирует возможность множественного доступа пользователей к удаленным рабочим столам и приложениям;
• видеоагент - выполняет перенаправление видеокамеры с пользовательской рабочей станции в ВРМ. Принимает изображения с камеры через virtio канал /dev/virtio-ports/ru.termidesk.RealtimeStreaming.0;
• агент виртуальных смарт-карт - выполняет перенаправление подключенных к пользовательской рабочей станции смарт-карт в ВРМ. Работает с каналом /dev/virtio-ports/ru.termidesk.PCSC.0.

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

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

• устанавливаются в гостевую ОС:  агент ВРМ, видеоагент, агент виртуальных смарт-карт;
• устанавливается на узел виртуализации: агент узла виртуализации;
• устанавливается на узел сервера терминалов: сессионный агент.

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

• при использовании протокола SPICE будет запущен termidesk-viewer;
• при использовании протокола RDP будет запущено одно из приложений в зависимости от используемой ОС: wfreerdp.exe, mstsc.exe, xfreerdp.

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

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

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

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

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

• сессионный агент устанавливает политику разрешения перенаправления дисков для терминальной сессии;
• STAL выполняет запуск сервера freerdp-shadow с каналом RDPDR (клиент шины DBus ru.uveon.stal.rdpdr);
• при первом обращении в шину запускается STAL-RDPDR (менеджер сессионной шины DBus ru.uveon.stal.rdpdr); 
• служба xfreerdp передает служебную информацию через протокол 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 передает служебную информацию через протокол 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 в варианте доставки ВРМ, а не терминальной сессии или приложения, невозможно без компонентов «Универсальный диспетчер», «Менеджер рабочих мест», «Агент ВРМ », «Агент узла виртуализации». Для получения ВРМ на пользовательской рабочей станции  должен быть установлен компонент  «Клиент».

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

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

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