Termidesk. Terminal или VDI?

7f4e8ad7051e8ff7641f71d69c40c50a.png

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

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

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

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

Описание обозреваемого стенда

Рассматривать будем самую актуальную на сегодняшний день инсталляцию: Termidesk 5.1. Она состоит из брокера подключений на одной ВМ (виртуальной машине) и STAL (сервере терминалов Astra Linux),  оба стенда базируются на Astra Linux.

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

  • CPU: 2 ядра

  • RAM: 4 ГБ

  • Диск: 40 ГБ

Точно так же сконфигурирована машина с установленным диспетчером подключений Termidesk.

Путь первый — терминальные решения или Termidesk Terminal

Termidesk Terminal — самый популярный вариант. На самом деле, здесь прелесть в том, что его уже достаточно, чтобы закрыть потребность в исчерпывающем решении для быстрого построения инфраструктуры терминальных рабочих мест. Это особенно актуально, если у вас в планах импортозамещение с сокращением расходов на инфраструктуру. Звучит привлекательно. Настолько, что зачастую многие сразу идут по этому пути. Почему бы и нет, ведь этого должно быть достаточно?!

Форма поставщика ресурсов Терминальный сервер уже включает минимум необходимых параметров в одном месте. Это дает возможность сделать последующую публикацию без лишних кликов. Детальное руководство по процессу публикации ресурса можно найти в одной из наших статей на Habr.

Форма поставщика ресурсов Терминальный сервер

Форма поставщика ресурсов Терминальный сервер

А почему вообще выбранный путь отличается высокой скоростью и простотой развертывания? Это связано с тем, что здесь используется один ресурс — сервер — как единая точка, куда будут направляться подключения всех пользователей.

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

Такая конфигурация сразу дает положительные эффекты от внедрения. Например, публикация через терминальный сервер унаследованных Windows-приложений: если компания находится в процессе миграции с таких решений, как Microsoft Office, Adobe Acrobat Pro и других, доступных только для ОС Windows.

В результате при публикации браузера Firefox у нас получается следующая картина. В среднем, при обычной работе с 10 вкладками, потребление RAM составляет от 900 МБ для одной пользовательской сессии. Потребление CPU при обычной работе составляет обычно менее 5%. Очевидно, что узким местом здесь является объем оперативной памяти.

Ресурсов нашего стенда хватит в среднем на 4 пользовательских сессии. Когда речь идет о десятках пользователей, то увеличение ресурсов сервера — это относительно простая операция для масштабирования, чтобы избежать деградации производительности. Но что, если пользователей становится существенно больше? Понятно, что бесконечно увеличивать ресурсы одного сервера — не самая лучшая идея.

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

Начнем сначала и вернемся в исходную точку, где ключевой для нас вопрос — это выбор решения. 

Путь второй. Новые возможности — Termidesk VDI

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

Ключевое отличие Termidesk VDI — это поддержка большего числа компонентов и расширенный функционал. Мы рассмотрим метапоставщик, где проблема масштабирования может быть решена совсем иначе. Это происходит за счет тиражирования предварительно подготовленного и сконфигурированного золотого образа сервера терминалов. В нашем случае это STAL (сервер терминалов Astra Linux).

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

А с релизом 5.1 метапоставщик получил уникальную технологию интеллектуальной балансировки между терминальными серверами на основе метрик (CPU, RAM, HDD). В форме создания поставщика это выглядит как новый переключатель «Балансировка по метрикам».

Балансировка по метрикам. Переключатель

Балансировка по метрикам. Переключатель

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

Балансировка по метрикам. Возможности

Балансировка по метрикам. Возможности

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

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

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

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

Параметры балансировки по метрикам в диспетчере

Параметры балансировки по метрикам в диспетчере

К примеру, если среди сценариев работы пользователей выделяется какое-то конкретное приложение, то его можно выделить в качестве отдельного метафонда. Тогда во время сессии будут передаваться только данные для одного приложения (оконные элементы, графика). Это уменьшает нагрузку на сетевой трафик, а также снижает использование CPU и RAM на стороне сервера, поскольку пользователь не загружает полное окружение рабочего стола. Помимо прочего, фонды приложений значительно упрощают поддержку и администрирование фондов виртуальных рабочих мест, особенно в плане безопасности. И происходит всё это по той же самой причине — пользователю доставляется только непосредственно окно приложения, которое он запросил.

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

Мы обобщили особенности каждого из двух подходов к организации удаленных рабочих мест и получили такую картину:

Возможности

Termidesk Terminal

Termidesk VDI

Балансировка подключений

Не применяется

По умолчанию (Round Robin) и модифицированная (Least Connections)

Масштабирование

Через добавление ресурсов терминального сервера

Через тиражирование базового образа

Требует полностью развернутой инфраструктуры терминальных серверов

Требует

Не требует

Поддержка протокола удаленного доступа Tera

Есть

Есть

Компонент Удаленный помощник

Нет

Есть

Планировщик — управление расписанием задач ВМ / фондов ВРМ

Нет

Есть

Поддержка подключения к фондам автономных машин (в том числе ФизПК, ВМ)

Нет

Есть

Поддержка платформ виртуализации через API

Нет

Есть

Перенаправление и оптимизация периферийных устройств

Нет

Есть

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

Но на сегодняшний день многие организации уже используют решения на базе терминальных серверов. Для мягкого перехода — миграции — прекрасно подходит конфигурация терминального поставщика ресурсов в Termidesk. Пример, который я привел ранее с Microsoft Office, Adobe Acrobat Pro — это капля в море программ, с которых может быть затруднительно сразу перейти на решения отечественных компаний. Но уже сейчас мы можем увидеть высокий темп, с которым наше ПО становится не просто необходимой заменой западного, а лучшей альтернативой.

Результаты

Выбор конфигурации для будущей инфраструктуры виртуальных рабочих мест — это во многом ключевой этап для многих компаний. Уже сейчас мы видим, как такие крупные игроки, как, например,  Сбербанк осуществляют масштабный переход на отечественные решения в области виртуализации. Среди успешных внедрений хочется отметить еще такие примеры, как импортозамещение в ОЭЗ «Алабуга».

Инфраструктура на основе Termidesk VDI уже сейчас предлагает больше возможностей, чем может потребоваться на старте, по сравнению с более консервативным подходом с использованием Termidesk Terminal. Но и использование терминальных серверов закрывают потребность в быстром, но мягком переходе с таких решений как, например, Microsoft RDS.

Наверное, при выборе решения стоит отталкиваться не только от потребностей «здесь и сейчас», но и заглядывать немного наперед, чтобы всегда иметь возможность быстро адаптироваться к неожиданным изменениям.

© Habrahabr.ru