Когда речь заходит о проектировании конфигурации по отношению к инфраструктуре виртуальных рабочих мест, очень важно в самом начале определить сценарии использования и ожидаемые нагрузки. В дальнейшем это избавит от простоев и затрат на изменение архитектуры.
Мы будем говорить о двух разных подходах к решению задач по доставке рабочих мест: рассмотрим понятия терминальных и тиражируемых виртуальных рабочих мест, поговорим о том, как это работает в 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.
Наверное, при выборе решения стоит отталкиваться не только от потребностей "здесь и сейчас", но и заглядывать немного наперед, чтобы всегда иметь возможность быстро адаптироваться к неожиданным изменениям.
createaddressforsigning
у 2x.com это двацать лет назад было - там помимо проецирования приложений и в виртуализации вообще не было os а только её необходимые элементы с разницей от реально виртуализированой os да ms это тогда очень бомбило тк одну лиценцию разматывали на ферму давая проекциии в любую os (тогда чётко обяснили что на каждую задницу по лицухе да на каждое соединение общего пользования)