Основные технические подробности решения VMware Horizon View

• 19.03.2020
• 11733

Автор
Иван Первицкий (NCSE, VCP, MCSE)
Ведущий системный инженер

Для решения VMware Horizon View (Virtual Desktop Infrastructure) необходима инфраструктура VMware vSphere (сервер управления vCenter и хотя бы один хост ESXi, на котором и будут работать все пользовательские виртуальные машины (ВМ)). В идеале — это должен быть кластер из двух или более хостов ESXi и общее хранилище (SAN или NAS - не важно). В случае отказа сервера, все ВМ автоматически перезапустятся на других узлах кластера (т.к. все узлы имеют доступ к общему хранилищу, где лежат сами ВМ).

• Архитектура решения
• Повышение безопасности решения с помощью двухфакторной аутентификации
• Варианты организации рабочих мест
• Коротко о технологии AppVolumes
• Протоколы доступа

Архитектура решения

Устанавливается брокер соединений во внутренней сети (серверный VLAN), устанавливается шлюз удаленных подключений в DMZ. Между шлюзом и брокером создается IPSec VPN туннель встроенными средствами.

Шлюз публикуется на каком-либо устройстве (NAT на Cisco ASA, к примеру), и во внешнем DNS создается А-запись для удобства внешних подключений. Обязательно наличие SSL сертификата из доверенного центра для защиты от MITM атак.

Пользователь с любого устройства в браузере с поддержкой HTML5 или через специальный клиент Horizon Client (есть для всех видов ОС, в том числе для Android или IOS) вводит адрес сервера и попадает на шлюз. Далее, после ввода логина и пароля, шлюз через VPN туннель обращается к брокеру, а тот в свою очередь делает запрос авторизации и аутентификации у службы каталогов Active Directory (AD). AD сверяет креденшелсы пользователя и предоставляет тикет на вход. Брокер сообщает шлюзу, что пользователя можно пропускать, и формирует для пользователя список предоставленных ему виртуальных машин и приложений.

1 – это протокол XML API over HTTPS, для авторизации и аутентификации. 2 – это RDP, Blast, PCoIP, о которых речь ниже.

Ниже представлена схема с архитектурой, в которой используются 2 шлюза и 2 брокера для дополнительной отказоустойчивости. Коннект извне идет на VIP адрес балансировщика.

Выглядит окно клиента после авторизации следующим образом:

Как видно выше, не обязательно выделять пользователю полноценный рабочий стол. Мы можем опубликовать отдельно взятое приложение, которое запустится на сервере, а с точки зрения пользователя, как будто на его локальном устройстве (можно на мобильном устройстве или Linux ОС открыть 1с или полноценный MS Office). Полезно, если пользователю не нужен весь рабочий стол, а лишь часть приложений (например, только почтовый клиент MS Outlook).

Еще одной особенностью решения является возможность запрета пользователям (или группам пользователей) копировать информацию на физический рабочий стол в рамках сессии: USB, shares, SD-card и др.

Повышение безопасности решения с помощью двухфакторной аутентификации

Можно повысить безопасность данного решения с помощью двухфакторной аутентификации, тогда в этом случае необходимо добавить в инфраструктуру дополнительный сервер (наиболее предпочтительным вариантом будет RSA SecurID). Пользователю будут предоставлены аппаратные или программные (приложение на Windows, Android или iPhone) ключи, которые каждую минуту генерируют новый 4-8-значный код. Перед вводом доменных учетных данных пользователю необходимо ввести этот код. Подобное спасает от кражи доменных учетных данных в общественных сетях или при целенаправленной атаке. Даже получив логин/пароль, злоумышленник не сможет войти в систему, не зная кода SecurID, который каждую минуту меняется.

Выделенные ВМ отличаются от персональных ПК тем, что у них отсутствует аппаратная составляющая и, как следствие, нечему ломаться (процессы внутри ОС в расчет не берем). Управление всем парком ВМ осуществляется из единой консоли.

Варианты организации рабочих мест

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

1. Стандартная виртуальная машина с набором приложений (не самый хороший вариант, но более привычный для администратора). В данном варианте для большинства рабочих мест берется 4GB RAM, 2 vCPU, 80HDD (дополнительно можно добавить до 512MB RAM под видеопамять).

   Создается золотой образ, в котором присутствует ОС и типовой набор приложений. Из этого образа тиражируются ВМ в необходимом количестве. Стоит учитывать, что, если у нас 100 рабочих мест, нам необходимо 8ТБ на дисковом хранилище.

2. Стандартная виртуальная машина с набором приложений по технологии Linked Clone.

   Создается золотой образ, в котором присутствует ОС и приложения, и кладется на SSD диск (в идеале Read Intensive). Этот образ конвертируется в шаблон. Из шаблона разворачивается необходимое количество идентичных ВМ. Дело в том, что эти ВМ не имеют своего системного диска, они все одновременно читают с шаблона на SSD дисках. В качестве ресурса для записи изменений к каждой ВМ администратор в праве назначить дельта-диск для данных профиля и диск для временных данных (тот же кэш), который всегда обнуляется при выходе из системы. Экономия очевидна. Вместо 8ТБ на 100 машин нам требуется 100*6ГБ(4 для профиля и 2 для временных файлов) = 600GB и 80GB для золотого образа. Профили также можно хранить в сетевой папке, тогда дельта-диск не потребуется вовсе.

   Создаются такие ВМ из образа на порядок быстрее, чем при работе с физическими ПК. Все, что нужно администратору, – создать пул, указать образ и количество ВМ. 1000 машин могут быть созданы за час (все упирается в производительность дисковой подсистемы). Обновляется точно также. Меняется исходная ВМ (из которой делали шаблон, доступный всем для чтения) – ставятся обновления, ПО и т.д., формируется новый шаблон и указывается в настройках пула, что теперь необходимо использовать этот шаблон (также необходимо указать время, когда пользователи не работают). И все - 1000 рабочих мест обновлены.

Дополнительно можно добавить в это решение двухфакторную аутентификацию. Об этой технологии мы уже писали выше.

Коротко о технологии AppVolumes

Однако это еще не все. Есть относительно новая технология – AppVolumes, которая запаковывает приложения в контейнеры и формирует из этих контейнеров жёсткие диски для виртуальных машин. Теперь не обязательно при подготовке золотого образа устанавливать приложения. Достаточно поставить ОС и указать, каким пользователям, какие приложения необходимы. Пользователь подключается к своей ВМ (на которой только ОС), видит в меню «Пуск», в котором есть весь необходимый набор ПО. При логоне к каждой ВМ линкуются диски с контейнеризованными приложениями, а при логофе открепляются от ВМ. Если с одной и той же машиной работают 2 человека, то каждый, подключившись, будет видеть только свой набор ПО (бухгалтер – 1С, дизайнер – Photoshop). Для администратора это очень удобно, т.к. стоит только один раз создать контейнер и дальше его можно назначать любым пользователям по требованию без физической установки этого приложения на клиентах.

Протоколы доступа

Еще важный момент, о котором стоит упомянуть – протокол доступа. У решения Horizon, помимо стандартного RDP, который не очень хорошо оптимизирован под слабые каналы связи, есть собственные разработки – PcoIP и Blast.

PcoIP идеально подходит для распределенной филиальной сети с узкими каналами. Достаточно просто указать для конкретного пользователя или группы необходимое число кадров в секунду. Глаз воспринимает 24 кадра, но мы можем выставить значительно меньшее количество кадров (например, от 1 до 10 для слабых каналов), что вполне хватает для восприятия и работы с офисным пакетом приложений. В данном случае пользователю будут передаваться только изменения в картинке на экране вместо потокового изменения изображения (для просмотра видео не подходит).

Blast позволяет подключаться к рабочему столу Windows 10 через обычный браузер. Данный протокол также хорошо оптимизирован для работы в сетях со слабой пропускной способностью.

1. Implementing VMware Horizon 7 2nd Revised edition
2. Mastering VMware Horizon 7 - Second Edition