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

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

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

Пользователи

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

• по подразделениям;

• по типу выполняемых задач;

• по иерархии — у топов и мидл-менеджеров своя специфика; 

• по географическому признаку — откуда наши пользователи. 

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

• работники, выполняющие небольшие повторяющиеся задачи с небольшим набором ПО (task worker);

• работники умственного труда, занятые анализом и обработкой информации (knowledge worker);

• работники, выполняющие большие проекты, требующие вычислительных мощностей (power worker);

• работники “в полях”, которые вводят минимальное количество информации (kiosk workers). 

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

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

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

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

О каких типах может идти речь (очень упрощенно, для примера):

1. По возможностям персонализации:

   • Random non-persistent, или pooled. За пользователем не закрепляется конкретное виртуальное рабочее место. После завершения сессии десктоп "обнуляется", а данные пользователя не сохраняются. 

   • Static persistent, или dedicated. За пользователем изначально закрепляется конкретное рабочее место с персональным набором приложений. При наличии прав в ОС пользователь может кастомизировать рабочее место: добавлять новые приложения, создавать папки и прочее. После завершения сеанса все эти изменения, как и результаты работы, сохраняются на персональный виртуальный диск, и следующий сеанс можно продолжить с того же места.

2. По способам управления набором ПО и ресурсами:

   • Рабочие места с полным диском. Набор ПО и используемые ресурсы настраиваются на каждом виртуальном рабочем месте под пользователя.

   • Рабочие места с разностным диском. Набор ПО и ресурсы берутся из общего набора и расширяются под клиентский профиль.

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

Вопрос же со специализированным ПО стоит рассмотреть отдельно.

Программное обеспечение

Если пользователю на рабочем месте нужно узкоспециализированное ПО, то при самостоятельном внедрении могут возникнуть дополнительные трудности с лицензированием. Есть вендоры с отдельной политикой лицензирования для виртуальных сред, поэтому перенести лицензии с on-premise инфраструктуры для такого ПО не получится. Так что проверяем список ПО и с этой точки зрения.

На этом же этапе определяемся, насколько компания готова поддерживать политику использования сотрудниками персональных средств — BYOD (bring your own device) и BYOA (bring your own app). Если специалист привык работать на своем ультратонком ноутбуке в конкретной операционной системе и готов использовать только свои настройки, переход на VDI может стать проблемой. Если рабочий стол от компании окажется неудобным, пользователь “проголосует ногами” и будет использовать привычные средства.

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

Тестирование и еще раз тестирование

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

В нашей практике был кейс, в котором заказчик использовал самописную CRM. На ноутбуках пользователей система работала без проблем. При тестировании на VDI обнаружилось, что ПО использует одно ядро процессора. На ноутбуке приложение давало небольшую нагрузку на GPU, а вот в виртуальном рабочем месте нагрузка на vCPU не давала пользователю выполнять работу в соответствии с требованиями. Поэтому клиент решил дорабатывать свое ПО.

Для требовательных графических приложений сразу предусматриваем виртуальные рабочие места с vGPU и тестируем, тестируем! Желательно изучить особенности ПО при установке и обновлении. Как оно будет себя вести, если размножить его с помощью клонирования виртуальных машин?

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

Интернет-канал конечного пользователя

Даже самая продуманная инфраструктура виртуальных рабочих мест не поможет, если пользователи подключаются через нестабильное сетевое соединение с узкой полосой пропускания. По возможности, заранее узнаем у пользователей, какое соединение они используют. Если в выбранном варианте есть задержки, то можно предложить способы сократить время ожидания. А вот соединение с потерей пакетов, к сожалению, не позволит обеспечить нормальную работу. 

Минимальная пропускная способность сетевого соединения зависит от задач. Если пользователь смотрит или редактирует видео, использует видео-конференц-связь, то требования к сети растут. Звук с микрофона и изображение с камеры в этом случае идет по интернету на сервер VDI, затем в приложение, затем на сервер видео-конференц-связи и только потом к собеседнику. Так что апгрейда может потребовать и сама инфраструктура рабочих мест, и канал каждого собеседника. 

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

Информационная безопасность

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

Если в организации есть выделенные специалисты по ИБ, подключаем их к проекту сразу на этапе планирования. Требования и ограничения ИБ могут привести к пересмотру первоначального плана. 

Что стоит предусмотреть:

• доступ к передаче информации между виртуальным рабочим местом и домашним ПК пользователя через буфер обмена, копирование или вставку файлов;

• сбор и анализ журналов с разных слоев и компонентов инфраструктуры;

• защиту от DDoS;

• дополнительные факторы аутентификации пользователя;

• межсетевое экранирование (инфраструктуры и каждого рабочего места);

• антивирусную защиту;

• запись сессий пользователей;

• систему защиты от утечек информации;

• обеспечение организационных мер.

Резервное копирование

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

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

• Будем ли копировать сами виртуальные рабочие столы? Если виртуальный десктоп перестанет работать, будет ли быстрее восстановить его из резервной копии или просто развернуть новый виртуальный рабочий стол из шаблона? Какие пользовательские настройки ПО в этом случае придется настраивать заново?

• Какое средство резервного копирования подходит?

• Где и как долго будем хранить резервные копии? Не имеет смысла хранить резервные копии на той же системе хранения данных, что и виртуальные рабочие столы.

• Сколько займет время восстановления? В идеале восстановление резервной копии тоже стоит протестировать, и зафиксировать фактическое время развертывания.

Мониторинг инфраструктуры рабочих мест

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

Вот какая информация поможет увидеть достоверную картину:

• сколько времени проходит от клика мыши на пользовательском устройстве до результата нажатия на экране;

• сколько сетевых пакетов теряется между точкой подключения пользователя и инфраструктурой виртуальных рабочих столов;

• каковы задержки интернет-канала инфраструктуры виртуальных рабочих мест;

• каковы задержки до конечной точки подключения пользователя;

• как быстро запускается рабочий стол;

• как быстро загружается профиль пользователя;

• сколько времени занимает применение групповых политик или других настроек.

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

Метрик намного больше, но этим требуется особое внимание.

Временные регламенты пользовательских сессий

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

Вот пример, как это настроено у одного из наших заказчиков:

- при бездействии пользователя он отключается от десктопа через 2 часа;
- через 4 часа осуществляется выход из системы (logout).

Конкретные настройки зависят от ваших требований. Мы лишь обращаем внимание на этот момент.

Печать документов

Печать документов из виртуального рабочего места может стать узким меcтом. Неискушенный сотрудник c “плохим” интернетом может попытаться отправить тяжелый файл на домашний принтер. В лучшем случае, версия документа для печати съест весь трафик при передаче с VDI на личное устройство и окажется на бумаге через час. В худшем — результат печати вообще не удовлетворит пользователя.

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

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