В нише доступных на сегодня продуктов для виртуализации рабочих мест не такой уж скудный выбор: Termidesk, Veil VDI, HostVM VDI, Горизонт-ВС VDI. Но Termidesk выбивается из общего ряда, потому что за ним стоит мощный производитель (ГК Astra Linux). Было любопытно потестдрайвить платформу и понять, на что она способна. Расскажу о своих впечатлениях от знакомства, при чем здесь OpenUDS и почему поставить Termidesk в один ряд с зарубежными VDI — так себе идея.
Что умеет Termidesk?
Функционал у Termidesk на текущий момент исключительно базовый. Это управление жизненным циклом виртуальных рабочих мест (ВРМ) и безопасная доставка ВРМ за счет их публикации средствами шлюза, входящего в состав решения. Termidesk предоставляет базовые рабочие места с простыми протоколами доступа к ним (RDP, SPICE, VNC). Публикация приложений терминальных ферм и терминальных сессий пока недоступна. Виртуализации приложений тоже нет. Есть поддержка 3D VDI при использовании протокола от партнера из мира облачного гейминга — Loudplay, — но без автоматизации развертывания таких ВРМ.
Официально не найти информации о том, что Termidesk — это «переработка» Open Source платформы OpenUDS. Но когда я с ним возился, время от времени сталкивался с различными артефактами UDS: то в логах, то во внутренних конфигах или скриптах проскакивал его «шлейф». В то же время Termidesk в отдельных аспектах далеко ушел от «открытой» платформы в своей основе. Например, интерфейс его полностью переработан и ничем не напоминает OpenUDS.
Кстати, к самому интерфейсу есть вопросы. Он исключительно на русском языке и выглядит супераскетично. В версии 3.0, с которой я начал тестирование, не было автообновления веб-страницы. Постоянно приходилось жать F5 и обновлять страницу, чтобы видеть завершение операций. В следующем релизе этот функционал уже добавился. Логическая структура интерфейса специфична. Даже если вы уже имели дело с VDI, то при знакомстве с интерфейсом Termidesk это не поможет — с наскока с ним поработать не получится.
Чем еще отличается Termidesk от OpenUDS при беглом обзоре, так вот этим функционалом:
поддержкой распределенной и отказоустойчивой установки компонентов брокера (об этом подробнее будет дальше);
наличием простой и понятной ролевой модели с возможностью разграничить доступ на разных уровнях (админы, хелпдеск);
поддержкой внешних syslog-серверов;
поддержкой автоматизации управления (CLI, REST API);
поддержкой ввода в домен AD Linux-ВРМ.
Архитектура и защита компонентов
Termidesk позиционируется как кросс-платформенный продукт, не привязанный к определенному гипервизору. Есть поддержка ПК СВ «Брест», VMware vSphere, oVirt/zVirt — эти решения поддерживаются «из коробки»; Aerodisk vAir, OpenStack — поддерживаются через установку дополнительных модулей. Получается, продукт может подойти компаниям, где уже есть одна или несколько платформ виртуализации или планируется миграция с существующей западной платформы виртуализации на отечественную.
Расскажу подробнее, как устроен Termidesk. Диспетчер подключений (он же брокер VDI в привычной терминологии) работает под управлением ОС Astra Linux (Common Edition или Special Edition 1.6-1.7 (режим «Орел» и «Смоленск» для редакции «Брест»)). Установить его у меня получилось легко — я просто следовал инструкции. В минимальной инсталляции все инфраструктурные компоненты разворачиваются в рамках одной ВМ.
В состав служб диспетчера подключений входят:
веб-портал администратора и пользователя;
служба планировщика для работы с системой виртуализации;
шлюз подключений.
Для установки диспетчера подключений нужна заранее подготовленная БД на базе СУБД PostgreSQL из состава Astra Linux SE или дистрибутив PostrgePro.
На самом виртуальном рабочем месте устанавливается агент, который соединяется с диспетчером, а на пользовательском АРМ — программный клиент.
В продуктивных инсталляциях диспетчер подключений можно защитить, используя схему резервирования HA. В ней одна нода диспетчера подключений находится в активном режиме, другая — в пассивном. В случае сбоя работы активной ноды происходит переключение на пассивную.
Звучит неплохо по сравнению с другими российскими VDI. Но все же это не «коробка», из которой все само волшебно работает. Для защиты компонентов диспетчера подключений используется утилита keepalive, а также набор скриптов, которые будут отвечать за его отработку отказов. СУБД в такой схеме задействована как внешний сервис и должна быть защищена своими средствами кластеризации. На деле мне не довелось пройти весь этот путь, и как оно работает — не знаю, но сама возможность такой защиты радует.
Отдельно про шлюз для удаленных подключений. Этот компонент можно встретить далеко не во всех отечественных VDI, и с этой стороны его наличие — плюс Termidesk. С другой — по его поводу всплывает множество «но». Например, при использовании шлюза на каждую пользовательскую сессию требуется 50 Мб оперативной памяти. А если подключений сотни и тысячи, то система становится требовательна к ресурсам. Есть ограничения на размер самого шлюза. Он может поддерживать не более 250 подключений, а это довольно жесткое ограничение. В будущих релизах вендор обещает полностью переработать архитектуру шлюза, но пока приходится работать с чем есть.
Сам же диспетчер подключений поддерживает до 1000 активных сессий пользователей (по заявлениям вендора).
Второй режим работы брокера — это режим разделенной установки компонентов. В нем каждую из служб можно вынести в отдельную ВМ и связать между собой, используя вышеупомянутый способ или внешний балансировщик нагрузки в зависимости от того режима, который поддерживает сама служба.
Важно отметить, что в текущей реализации установщика нельзя выбрать варианты инсталляции — всегда устанавливаются все службы, а это неудобно. При такой установке важно не «перезатереть» имеющуюся БД. Установщик про это ничего не знает, и надо быть очень аккуратным — операция требует ручного контроля администратора.
Развертывание виртуальных рабочих мест
Termidesk поддерживает два типа виртуальных рабочих мест. Индивидуальные ВРМ с сохранением их состояния, они же Persistent в привычной терминологии. Или коллективные, которые возвращаются к исходному состоянию после завершения сеанса — Non Persistent, это реализовано через полное удаление ВРМ и создание новой. Из интересных особенностей — брокер со временем начинает переиспользовать порядковые номера уже удаленных ВРМ, а также их MAC-адреса. Этот механизм никак не настраивается, но он есть, и в целом от него больше пользы, чем вреда.
Для ВРМ заявлено большое количество поддерживаемых гостевых операционных систем: Astra Linux, Alt Linux, Red OS, Debian, Ubuntu, CentOS, Windows 7, 8, 10 и Server. Про Windows 11 данных пока нет.
Платформа работает с клиентскими устройствами различных аппаратных архитектур: ARM, MIPS, x86, в том числе Baikal-М (протестирован на стенде и даже работал).
Программный клиент работает на Windows и Linux. Есть возможность работы через браузер, но с ограниченным функционалом и поддержкой протоколов: поддерживается VNC и SPICE в режиме просмотра экрана ВРМ.
Прежде чем перейти к созданию ВРМ, нужно подключить необходимый набор компонентов — систему виртуализации (в Termidesk это называется «поставщик ресурсов») и службу каталогов («домены аутентификации»).
Мое знакомство с Termidesk пошло по хардкорному сценарию. Потому что сначала я решил подключить платформу виртуализации ПК СВ «Брест». И оно оказалось самым трудным из всех.
У этой платформы свой дистрибутив Termidesk for Astra, который, как и ПК СВ «Брест», требует обязательной интеграции со службой каталогов FreeIPA/ALD.
1 способ. Сама процедура подключения сервера сложнее, чем привычный ввод IP-адреса сервера управления виртуализацией, логина и пароля. Нужно проставить несколько параметров, но в документации от вендора не так много подробностей о том, что они значат и в какой комбинации их надо использовать.
Пытаясь подключить ПК СВ «Брест», я прошел через отчаяние, надежду, злость («Да будешь же ты работать наконец!»), снова отчаяние и смирение — ОК, попробуем привлечь поддержку вендора. Оказалось, что при интеграции с ПК СВ «Брест» первым способом должна быть включена опция «Запуск ВМ от имени служебного пользователя» и указана УЗ админа «Бреста» — вот и вся магия.
2 способ. Еще есть возможность подключить ПК СВ «Брест», используя делегацию запуска ВМ от другой учетной записи. Но здесь тоже все непросто. Потратив уйму времени, перебирая разные варианты и словив ошибку, по которой было видно, что на «Бресте» чего-то не хватает, я расспросил вендора. И действительно, на «Брест» нужно было установить дополнительный модуль, чтобы такой вариант подключения заработал.
К слову, похожая ситуация случилась, когда на «Бресте» никак не работали связные клоны для ВРМ. Я увяз в попытках найти причину этого, искал следы с разных сторон. Снова потрачено время, а потом за пять минут вендор подсказал, что нужно было подключить подходящий тип хранилища — но это уже особенности «Бреста».
Эти истории показывают проблемную область Termidesk — недостаток документации. Она есть, но с исключительно базовой информацией, а вот ответов на каверзные вопросы не дает.
Но все пережитое с СВ «Брест» стоило того. Как и было заявлено производителем, эта платформа создавала полные и связные клоны.
Подключение к zVirt прошло относительно легко. Но и тут есть особенность. Важно отключить ограничение на количество возможных сессий учетной записи, которой Termidesk подключается к zVirt.
Что у меня не получилось в Termidesk с zVirt, так это использовать в качестве ВРМ заранее подготовленные администратором ВМ — это называется «статичной ВМ». Казалось бы, самый простой вариант: укажи требуемую ВМ, но — увы! — диспетчер подключений отказывался видеть выбранную ВМ, и история закончилась ничем. Вендор говорит, что на его стенде этот вариант подключения работает — магия в чистом виде)
С подключением к Vmware vSphere проблем не было. Однако есть маленькая, но очень неприятная деталь: при создании шаблона ВРМ нужно обязательно указать кластер хранилищ данных, а не отдельные хранилища. И это серьезное ограничение, потому что кластеры хранилищ данных есть далеко не во всех компаниях — для этого нужна специальная, более дорогая лицензия VMware vSphere, да и не у всех есть потребность в кластере. Но без кластера подключение к Termidesk невозможно. Вендор обещает данное недоразумение исправить в будущих релизах.
Еще один нюанс подключения Termidesk к системам виртуализации. Делая это, мы выбираем шаблоны ВРМ и указываем шаблон имени будущих рабочих мест. В Termidesk, если предполагается использовать один образ с разными схемами именования, то его нужно будет добавить столько раз, сколько будет таких схем. То есть схема именования задается не в настройках пула ВРМ, как обычно это бывает, а заранее, в шаблоне ВРМ. Собственно, то же самое можно сказать и про сам шаблон — определяется он на уровне платформы виртуализации.
Домены аутентификации Termidesk
В отличие от зарубежных VDI, в Termidesk есть возможность использовать внутреннюю базу пользователей, не привязанную к какой-то службе каталогов. В реализации Termidesk for Astra в перечне поддерживаемых доменов аутентификации есть и отечественные аналоги службы каталогов AD — FreeIPA и ALD, которая обязательна, как и для ПК СВ «Брест».
В Termidesk подключение службы каталогов Active Directory организовано через LDAP-коннектор, к тому же выяснилась одна неприятная особенность — нельзя подключать корень домена в качестве источника для поиска групп и пользователей. Обязательно должны быть указаны OU или контейнер, в котором располагаются и пользователь, и группа безопасности (вложенные OU участвуют в поиске). А это отдельная беда — далеко не у всех заказчиков используется такое размещение этих объектов. И тем более сложнее обойти это, если речь идет о тысячах пользователей. Также была диагностирована проблема с перепутанными атрибутами логина и именем пользователя. Радостная новость — в версии 3.2 этих неприятностей нет.
Протоколы доступа к ВРМ
На сегодня в Termidesk доступны такие протоколы доставки: RDP, SPICE, VNC.
VNC — самый нефункциональный из них. Кроме просмотра экрана, он больше ничего предложить не может. Отзывчивость пользовательского интерфейса оставляет желать лучшего. Единственный его плюс — работа через HTML5 в браузере.
У RDP лучшая из всех отзывчивость пользовательского интерфейса, можно «пробросить» принтеры, диски, смарт-карты. Конфигурировать параметры RDP можно только через диспетчер подключений и только то, что доступно к выбору.
Основной протокол решения — SPICE. С его помощью можно пробросить устройства (raw-трафик без сжатия на текущий момент), имеется поддержка смарт-карт. Отзывчивость пользовательского интерфейса я бы оценил на «троечку»: не хватает плавности и скорости отклика. Этот протокол доступен только на платформах виртуализации на базе KVM, ввиду особенности его работы подключение к ВРМ при использовании SPICE идет не напрямую в ВРМ, как с RDP, а в консоль ВМ платформы виртуализации.
И как вы догадываетесь, если у вас VMware, то вы будете вынуждены использовать только протоколы RDP и VNC.
Дополнительных политик по оптимизации и настройке протоколов в текущих релизах нет. Также как и нет SSO для ВРМ: на всех шагах подключения придется вводить пароль. Но вендор над этим работает.
Управление ВРМ
Расскажу про управление жизненным циклом ВРМ подробнее, потому что этот функционал имеет свои нюансы. Во-первых, в Termidesk используется своя терминология. Например, «фонды рабочих мест» означает «пулы рабочих мест».
Во-вторых, каждый шаг по управлению ВРМ в Termidesk требует предварительной подготовки. Чтобы совершить операцию, часто нужно вернуться назад, отменив начатое, и сделать нужные настройки. И этой логикой пропитан весь Termidesk. Например, во время создания фонда РМ понимаешь, что нужно что-то изменить или добавить — значит, придется выйти из окна создания фонда и перейти в нужную часть меню, чтобы создать новые или изменить заранее подготовленные политики (шаблон ВРМ, тип развертывания ВРМ (постоянное или коллективное), ввод ВРМ в домен, протоколы доступа и доступ пользователей).
Также из особенностей можно отметить создание так называемых кеша ВРМ 1-го уровня (подготовленные к подключению пользователя запущенные ВРМ) и 2-го уровня (подготовленные к подключению пользователя, но выключенные ВРМ). Функционал не новый, но терминология оригинальная от Termidesk.
Еще несколько непривычно выглядит работа с шаблоном, из которого будут разворачиваться ВРМ. Обычно им выступает снепшот «золотого образа». В Termidesk используется только актуальное состояние ВМ. Получается, что если нужно вернуться к предыдущей версии образа, то эта задача ложится на плечи админа, а платформа взять ее на себя не может. Из хорошего — в версии 3.2 для zVirt функционал со снепшотами уже реализован. Также важно отметить, что управлять операцией подмены образа администратор никак не может: есть одна кнопка «публикация», при нажатии на которую происходит формирование нового материнского клона ВРМ и пересоздание всех ВРМ.
Самая короткая глава
Это глава про мониторинг. Сейчас его в Termidesk практически нет — только журналы логов и аудит событий в табличной форме. На главной странице из интересного можно отметить пиктограммы со статусом и общим количеством ВРМ, фондов ВРМ, поставщиков ресурсов. Доступна информация по общему количеству лицензий и числу активных сессий — на этом все.
Что имеем в итоге
Я бы не стал сравнивать Termidesk с западными аналогами. Слишком велика пропасть между бэкграундом их развития и, как следствие, степенями зрелости продуктов. Пока 100% заменой зарубежным платформам Termidesk стать не может. Он уступает и по функциональности, и по удобству использования.
Must have'ом при обращении к Termidesk должно стать пилотное внедрение. Впрочем, этот совет стал банальностью и актуален для большинства российских продуктов. Ну а если есть интерес посмотреть VDI вживую, можем устроить знакомство с ним в нашем шоуруме по виртуализации. Писать можно сюда: infrastructure@jet.su.
Еще одна боль, с которой производителю предстоит разобраться, — это недостаток информации и документации о продукте и его обновлениях. Публичного портала по этому поводу нет. По каждому релизу очень хочется видеть полное описание исправленных багов и доработки функционала. Сейчас подробности можно узнать только из личного контакта с вендором.
В то же время Termidesk выделяют две вещи, которые вселяют оптимизм.
Отзывчивость вендора, во-первых. Чувствуется заинтересованность в обратной связи. Я отправил описание нескольких найденных огрехов производителю, и они вошли в список будущих исправлений. Ну и, если были какие-то сложности с продуктом, специалисты Termidesk помогали разобраться.
Во-вторых, обнадеживает скорость развития платформы. Пока я ее тестировал, вышло несколько значимых обновлений. Производитель придерживается классической схемы развития продукта, выпуская раз в год «большой» релиз и несколько минорных. Но поскольку Termidesk сейчас активно развивается, то и в его минорных релизах появляются серьезные изменения. Например, за время моего изучения платформы вышла новая версия 3.2, в которой была исправлена крупная ошибка работы с доменом AD и еще горстка детских болезней.
В общем, с любопытством ждем, как эволюционирует Termidesk в будущем.
Андрей Шарашкин
Инженер-проектировщик вычислительных комплексов «Инфосистемы Джет»
Комментарий производителя
Денис Мухин, директор по развитию компании «Увеон — облачные технологии»:
В 4 квартале 2022 мы планируем добавить в Termidesk функции поддержки терминальных ферм и сессий, публикации приложений и SSO. Также мы предоставим пользователям возможность отслеживать статусы всех компонентов решения. На данный момент на сайте Termidesk представлена исключительно базовая часть документации с возможностью стандартного развёртывания продукта. В ближайшее время мы выложим описание дополнительных настроек эксплуатации.
