Немного о дизайне VDI. Часть 4. Подсистема VMware Horizon

Продолжение цикла статей о дизайне VDI. Предыдущие части доступны по ссылкам:

Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура

4.1 Общие сведения

Рассмотрев верхнеуровневую архитектуру, перейдет к разбору каждого компонента в отдельности. VMware Horizon можно назвать сердцем VDI инфраструктуры. VMware Horizon (ранее известный как VMware View) включает в себя набор ПО, обеспечивающего управление виртуальной инфраструктурой, создание и управление жизненным циклом виртуальных десктопов и терминальных серверов, предоставление доступа к опубликованным приложениям из единого портала и сквозную аутентификацию, контроль за подключением пользователей, а также ряд дополнительных функций, таких как туннелирование подключений при доступе из Интернет, управление профилями и рабочим окружением пользователей, доставку приложений, мониторинг, управление образами. VMware Horizon доступен в трех редакциях: Standard, Advanced и Enterprise и лицензируется по пользователям или конкурентным подключениям. Более подробно о лицензировании VMware Horizon написано в Главе 6. Лицензирование VDI.

Несмотря на то что Horizon предполагает наличие виртуальной инфраструктуры VMware vSphere, многие из его компонентов могут быть установлены на физических серверах или на ВМ, работающих на сторонних гипервизорах.

Большинство инсталляций VMware Horizon включает в себя следующие основные компоненты:

• View Connection Server – центральный компонент VDI инфраструктуры Horizon, выступает в качестве брокера, который является единой точкой подключения для пользователей при доступе к своим виртуальным десктопам. Connection Server управляет процедурой создания, обновления, удаления и назначения пользователям виртуальных десктопов. Кроме того, Connection Server может выступать в качестве сервера туннелирования (прокси-сервера), через который будет передаваться трафик от клиента до виртуального десктопа.
• View Composer – сервер, отвечающий за создание и обновление linked-clone десктопов.
• View Security Server – выделенный сервер туннелирования, обычно размещается в сегменте DMZ и выполняет функции сервера туннелирования, через который внешние пользователи подключаются к своим десктопам. Данный сервер всегда работает в связке с одним из серверов View Connection Server.
• Unified Access Gateway (ранее Access Point) – альтернатива серверу безопасности View Security Server, призванный в недалеком будущем заменить его. Виртуальный апплайнс на базе ОС Linux, предназначен для туннелирования подключений к десктопам. Кроме того, UAG может использовать для публикации компонентов Identity Manager и AirWatch (выступать в качестве reverse-proxy севрера). Более подробно об отличиях Security Server и UAG написано в Главе 10. Организация подключения и безопасность.
• Horizon Agent – агент, который устанавливается на виртуальный или физический десктоп или терминальный сервер. Содержит службы, драйверы и ПО, необходимое для создания и управления сервером View Connection Server, подключение по протоколам PCoIP и Blast, а также работы различных функций, таких как: Virtual Printing, проброс USB устройств, Multimedia Redirection, Scanner redirection, Real-Time Audio Video и прочих. Агент может быть установлен на каждом десктопе отдельно, либо интегрирован в эталонный образ, из которого в дальнейшем создаются виртуальные десктопы. Для корректной работы агента, требуется, чтобы его версия совпадала с версией брокеров VMware Horizon Connection Server. Использование отличных версий агента поддерживается только на период обновления инфраструктуры. Это следует помнить при выборе клиентской ОС для виртуального десктопа. Так, например, VMware Horizon 6.0 был последней версией, поддерживающей установку агента на ОС Windows XP и Windows Vista.
• Horizon Agent Direct Connection Plugin – расширение для агента, позволяющее клиентским устройствам подключаться к виртуальному десктопу напрямую, в обход брокера Horizon. Может использоваться для небольших VDI инсталляций, где не требуется централизованного управления, а также в качестве запасного варианта подключения в случае недоступности брокера.
• Horizon Client – клиентское ПО, которое устанавливается на устройства под управлением Windows, MAC OS X, Linux, iOS, Android или Chrome OS, превращая их в "тонкие клиенты", которые могут подключаться к десктопам Horizon. Помимо возможности подключения Horizon Client обеспечивает работу сквозной аутентификации, подключения локальных дисков, проброса принтеров, сканеров и других периферийных устройств в ВРС. Разные клиентские ОС поддерживают разный набор функциональных возможностей.
• vCenter Server – позволяет централизованно настраивать и управлять хост-серверами виртуализации VMware ESXi. Серверы View Connection Server не взаимодействуют с хостами виртуализации напрямую, а используют для этого сервер vCenter, поэтому от его доступности напрямую зависит возможность выполнения операций запуска, выключения, создания, обновления и удаления виртуальных десктопов.
• Хост-сервер виртуализации – физический сервер с установленным гипервизором VMware ESXi, который обеспечивает запуск и работу виртуальных машин – виртуальных десктопов, а также инфраструктурных ВМ, в которых установлены служебные компоненты Horizon – View Connection Server, User Access Gateway, vCenter Server и т.д.

Реже в VDI инфраструктурах Horizon может встретить следующие компоненты:

• Identity Manager – предоставляет доступ к порталу самообслуживания, на котором могут быть опубликованы виртуальные десктопы и терминальные приложения с фермы Horizon, а также веб-сервисы и приложения, виртуализованные средствами VMware ThinApp. Identity Manager позволяет настроить сквозную аутентификацию, таким образом, что пользователь, однократно аутентифицировавшийся на портале Identity Manager, может подключиться к своему десктопу без необходимости повторно вводить пароль.
• ThinApp – средство для виртуализации прикладного ПО. За счет использования технологий упаковки приложения в один исполняемый файл, виртуализации файловой системы и реестра, ThinApp позволяет запускать на одном десктопе несколько версий одного и того же приложения или несовместимые друг с другом приложения, а также обеспечивать простую доставку и обновление ПО при использовании floating и/или non-persistent десктопов, не сохраняющих изменения. Подробнее о вариантах доставки и обновления ThinApp приложений в инфраструктуре Horizon вы можете прочитать в данной статье http://blog.vmpress.org/2010/10/vmware-view-45-thinapp-46.html . 
• App Volumes – ПО для быстрой доставки и обновления приложений для виртуальных машин. App Volumes позволяет устанавливать приложения на виртуальные диски (app stacks), которые затем подключаются к одному или нескольким виртуальным десктопам, и приложения в реальном времени появляются в гостевых ОС. Администратор может добавлять приложения, назначая их на компьютер или конкретному пользователю, так что пользователь будет иметь одинаковый набор приложений, независимо от того, к какому десктопу он подключился. Также App Volumes позволяет создавать writable volumes, которые сохраняют все изменения, сделанные пользователями на десктопах, включая установку приложений, сохранение файлов в профилях и настройку ОС.
• Persona Management – средство управления перемещаемыми профилями пользователей. Обладает большей гибкостью по сравнению со стандартными перемещаемыми профилями Windows, позволяет исключать из репликации определенные каталоги или типы файлов, настраивать периодическую синхронизацию профилей с файловым сервером, ускорять вход пользователя в систему за счет загрузки с сервера только необходимых для работы файлов, а не всего профиля целиком.
• User Environment Manager предназначен для централизованного управления настройками приложений и рабочего окружения пользователей.  В отличие от Persona Manager или перемещаемых профилей Windows, UEM сохраняет и подгружает настройки гранулярно на уровне отдельных приложений в момент их запуска. Также UEM позволяет выполнять подключение принтеров, монтирование сетевых дисков, ассоциацию расширения файлов с приложениями, применять пользовательские локальные групповые политики.
• Mirage – ПО, предназначенное для резервного копирования и восстановления рабочих станций, а также установки и обновления ОС и приложений при помощи заранее созданных образов. Mirage применяется в тех случаях, когда нет возможности обеспечить перевод пользователей на VDI, например, для обновления и установки ПО на физические десктопы.
• vRealize Operations for Horizon – средство для мониторинга VDI инфраструктуры, включая платформу виртуализации VMware vSphere, физические серверы, виртуальные десктопы. Помимо стандартных метрик доступности, производительности и загрузки ресурсов, предоставляет информацию о подключениях – утилизацию канала, величину задержек, процент потерянных пакетов, что позволяет оперативно обнаружить проблемы с каналами передачи данных в VDI средах.
• Enrollment server – дополнительный компонент, который нужен для работы механизма True SSO при использовании аутентификации через RSA SecurID или RADIUS сервер.

Небольшое отступление касательно управления образами и ПО VMware Mirage. VMware Mirage входит в состав Advanced и Enterprise реакций Horizon, однако его возможности по интеграции с VDI инфраструктурами крайне ограничены – поддерживаются только Full Clone десктопы и только в сценариях установки ОС или приложений из образов (более подробно о сценариях использования Mirage для VDI можно узнать из документа Image Management for View Desktops using Mirage). По этой причине я не планирую рассматривать его в данном цикле статей. Если вам интересна тема Mirage, то по ссылке http://blog.vmpress.org/2016/05/windows-thin-pc-vmware-mirage-i.html вы можете ознакомиться с описанием процедуры его настройки и подготовки эталонного образа.

Для работы VDI инфраструктуры Horizon требуются следующие вспомогательные службы и серверы:

• DNS.
• Active Directory.
• DHCP.
• Syslog – сбор и хранения журналов с View Connection Server, vCenter Server, ESXi и других компонентов.
• Microsoft SQL Server – сервер управляющий базами данных, используемых в работе View Composer, View Connection Server, App Volumes, vCenter Server, Mirage.
• Файловый сервер – в VDI инфраструктурах используется для хранения перемещаемых профилей, перенаправляемых каталогов и файлами, домашних каталогов, настроек приложений UEM пользователей. Также может использоваться для хранения приложений, упакованных при помощи ThinApp, и образов ОС и приложений Mirage.
• Сервер резервного копирования. Используется для резервного копирования и восстановления служебных ВМ и десктопов. При резервном копировании десктопов важно помнить, что все linked-clone десктопы при восстановлении превратятся в full-clone ВМ, а для non-persistent или floating десктопов достаточно будет копировать эталонный образ, из которого создается ВМ.
• Сервер мониторинга отслеживает состояние компонентов VDI инфраструктуры и уровень загрузки ресурсов. Помимо vRealize Operations for Horizon, для VDI инфраструктуры может быть настроен мониторинг другими популярными средствами вроде Zabbix, SolarWinds или BMC Patrol. Так, например, View Connection Server включает в себя пакеты Management Pack для мониторинга средствами Microsoft System Center Operations Manager.

4.2 Архитектура VMware Horizon

В архитектуре Horizon выделяется такое понятие как Pod – это группа серверов View Connection Server, которые обслуживают определенный набор десктопов и между которыми выполняется периодическая репликация конфигурации. Один сервер View Connection Server поддерживает до 4000 одновременных подключений (до 2000 в Horizon 7.1 или более старых). В одном блоке может быть от одного до семи серверов (5 активных + 2 резервных), таким образом, один блок может обслуживать до 20000 одновременных подключений. В каких случаях может потребоваться больше одного сервера в Pod?

• Для обеспечения отказоустойчивости. Между серверами в рамках одного блока выполняется периодическая репликация конфигурации, таким образом, выход одного или нескольких серверов View Connection Server не повлияет на доступность VDI инфраструктуры (до тех пор, пока оставшиеся серверы справляются с нагрузкой).
• Балансирование нагрузки. Распределение нагрузки между View Connection Server может выполняться различными способами, от простого указания конкретного сервера в настройках клиента или DNS Round Robin, до использования Microsoft NLB или выделенного балансировщика (F5 BIG-IP, Citrix NetScaler ADC, VMware NSX Edge Load Balancer и других).
• Настройка разных политик подключения на разных серверах. Ряд настроек, таких как двухфакторная аутентификация, аутентификация по смарт-картам, туннелирование подключений задаются на уровне Connection Server. При развертывании нескольких серверов можно задавать разные настройки, например, для внутренних пользователей разрешить подключение к виртуальной рабочей станции напрямую, а для Интернет пользователей – туннелированное подключение через Security Server.

В масштабных инсталляциях несколько блоков могут объединяться в федерацию (Cloud Pod Architecture), поддерживающую до 140000 подключений. Помимо поддержки большего числа одновременных подключений федерация также может использоваться в качестве одного из вариантов обеспечения катастрофоустойчивой VDI конфигурации, когда один блок размещается на одной площадке, а второй блок – на другой. В случае отказа одной из площадок пользователи смогут подключиться к серверам на второй площадке и получить доступ к резервным десктопам. Более подробно о вариантах построения катастрофоустойчивых конфигураций будет рассказано в Главе 11. Доступность, резервное копирование и аварийного восстановление.

В рамках федерации между серверами View Connection Server реплицируется информация о глобальных назначениях (Global Entitlement), которые включают в себя один или несколько локальных пулов десктопов. Пользователи, подключившись к любому серверу View Connection Server в федерации, могут увидеть локальные и глобальные пулы и назначенные им десктопы. Таким образом может быть организовано несколько территориально-распределенных точек подключения к VDI, расположенных в разных регионах (странах, континентах), благодаря чему пользователи, которые часто бывают в разъездах, смогут подключаться к ближайшей точке с минимальными задержками и потерями пакетов.

4.3 Типы виртуальных десктопов

Несмотря на то, что в большинстве своем виртуальные десктопы представляют собой виртуальные машины, современные платформы VDI предоставляют возможность подключения к физическим десктопам, а также терминальным серверам. Десктопы различаются типу – создаваемые вручную, или автоматически из единого образа, по методу создания: полные клоны, дельта-клоны, мгновенные клоны. Каждый из типов десктопа может быть оптимален для решения тех или иных задач. Для сотрудников колл-центра подойдут десктопы, созданные с использованием дельта-клонов или мгновенных клонов без привязки к конкретному пользователю (floating). Типовым пользователям, которым требуется возможность установки персональных приложений, может подойти дельта-клоны в связке с ThinApp или App Volumes. Разработчикам или тестировщикам, которые имеют административные права на десктопы и могут самостоятельно устанавливают на него различное ПО, могут подойти full-clone десктопы. Рассмотрим каждый из критериев:

• Тип пула: Automated или Manual
• Метод создания десктопа из образа: Full Clone, Linked Clone, Instant Clone
• Привязке к пользователю: Dedicated или Floating
• Длительности хранения изменений: Persistent, Non-persistent

4.4 Тип пула

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

Автоматические (Automated) пулы, в которых виртуальные десктопы создаются и добавляются автоматически средствами Horizon без участия администратора. В момент создания пула администратор выбирает эталонный образ, содержащий ОС и набор базовых приложений (например, программы для просмотра и редактирования документов, веб-браузеры, программы для обмена мгновенными сообщениями, ПО для безопасности), из которого будут создаваться новые десктопы в данном пуле, а также количество создаваемых ВМ. Horizon самостоятельно выполняет создание и настройку требуемого числа новых виртуальных десктопов в соответствии с политикой наименования, выполняет кастомизацию гостевой ОС и добавляет компьютер в домен.

Ручные (Manual) пулы включают в себя десктопы, которые были вручную созданы и настроены администраторами. Это могут быть десктопы созданные из разных образов, имеющие разные версии ОС и установленные приложения, разную аппаратную конфигурацию и т.д. Одним из сценариев применения ручных пулов является добавление в Horizon физических рабочих станций. Ручные пулы также могут использоваться для ВМ, процедура создания и настройки которых выполняется при помощи сторонних средств и требует дополнительных операций, например, виртуальные машины, к которым подключены графические адаптеры в режиме vDGA. Важным преимуществом Manual пулов является возможность миграции ВМ на другие хост-серверы/кластеры/хранилища без необходимости пересоздания ВМ.

4.5 Метод создания десктопа из образа

Для автоматизированных пулов существует несколько способов создания и настройки виртуальных десктопов из эталонного образа.

Full Clone – полные копии. Horizon выполняет развертывание ВМ из шаблона (VM Template) VMware vSphere, выбранного администратором, и затем выполняет настройку, используя механизм Customization Specification (Sysprep). Данный вариант развертывания является длительным и требует много дискового пространства, поскольку создается полная копия ВМ. С точки зрения дальнейшего обслуживания и патч-менеджмента Full Clone’ы ничем не отличаются от физических рабочих станций, что с одной стороны, позволяет использовать существующие механизмы – WSUS, SCCM, с другой – вы лишаетесь преимуществ централизованного обновления ВМ из единого образа.

Linked Clones – дельта копии. Принцип работы Linked Clones основан на механизме снапшотов ВМ. Администратор подготавливает эталонную ВМ, из которой создается реплика. Все ВМ, создаваемые в Linked Clone пуле являются дельта копиями (зависимыми копиями) реплики. Диск реплики используется для чтения неизменяемых (общих) данных. Если десктопу требуется что-то записать, то изменения записываются в дельта-диск. Для управление процедурой создания и обновления Linked Clones десктопов используется выделенная служба – View Composer.

Помимо delta-диска у Linked Clone ВМ присутствует также Identity диск, который хранит служебную информацию гостевой ОС: имя компьютера, SID, информацию о членстве в домене.

Linked Clone позволяет существенно сэкономить дисковое пространство по сравнению с полными клонами, особенно в тех случаях, когда объем изменений в создаваемых десктопах небольшой или используются non-persistent десктопы.

Для того, чтобы уменьшить количество изменений, которые записываются внутри ВМ, и не раздувать дельта-диск, в момент создания пула возможно добавить для десктопа дополнительный disposable диск, на который переносится файл подкачки и временные файлы гостевой ОС. Такой виртуальный диск является independent non-persistent, все данные с диска автоматически удаляются после перезагрузки ВМ.

Обновление Linked Clone ВМ может быть выполнено централизованно при помощи механизма Recompose. Для этого администратор выбирает новый эталонный образ эталонного образа, из которого создается новая реплика, и существующие ВМ привязываются к новому диску реплики. При обновлении ВМ средствами Recompose все дельта-диски пересоздаются, а изменения, выполненные в гостевой ОС, удаляются. В этом заключается, пожалуй, главный недостаток данного механизма, поскольку это приводит к удалению всех пользовательских данных и приложений, добавленных в десктоп после развертывания ВМ.

Для решения проблемы с постоянным хранением данных пользователей для dedicated linked clone пулов может быть настроен persistent виртуальный диск, куда будут автоматически перенаправлены профили пользователей, хранящиеся на компьютере. Recompose не затрагивает persistent диск, а значит, после замены образа, данные пользователей останутся на месте.

Следует помнить, что persistent диски не предназначены для хранения приложений. Даже если указать persistent диск в качестве места установки приложения, после выполнения Recompose изменения в реестре, и файлы с системного диска будут удалены, что может нарушить работу приложения. Это не касается приложений, упакованных ThinApp, которые просто могут быть скопированы на persistent диск и ярлыки на которые могут быть добавлены на рабочий стол пользователя.

Для решения этой проблемы могут использоваться сторонние средства, в частности: автоматическая установка приложения при Microsoft SCCM или аналогов, упаковка и стриминг приложений при помощи ThinApp, использование VMware App Volumes. Более подробно о вариантах написано в Главе 12. Дополнительные сервисы.

Помимо обновления через Recompose десктопы поддерживают операции Rebalance и Refresh. Rebalance позволяет перераспределить десктопы по хранилищам. Это полезно в тех случаях, когда на текущих хранилищах заканчивается дисковое пространство, вы добавляете в пул новое хранилище и хотите равномерно распределить между ними ВМ. Также это единственный поддерживаемый способ переноса Linked Clones десктопов с одного хранилища на другое. Операция Refresh выполняет обнуление изменений десктопов, и возвращает их в исходное состояние на момент создания. Это позволяет восстановить работоспособность десктопа, а также уменьшить занимаемое дисковое пространство.

Instant Clone – мгновенные клоны. Метод, который применяется для non-persistent VM, позволяет в реальном времени за несколько секунд создавать клоны эталонной ВМ. Instant Clones позволяют существенно снизить потребление дискового пространства и оперативной памяти. Поскольку клоны создаются из включенной машины, то их память дедуплицирована сразу после создания. Такие ВМ также расходуют меньшего дискового пространства, чем Linked Clones, и автоматически удаляются после завершения сеанса пользователя.

Instant Clone доступен только в редакции Horizon Enterprise и имеет ограничение по поддерживаемым функциям:

• В качестве механизма кастомизации ВМ поддерживается только QuickPrep.
• Не поддерживает VAAI и VCAI.
• Не поддерживается размещение ВМ на локальных хранилищах ESXi.

Более подробно об Instant Clones можно прочитать в документе https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-view-instant-clone-technology.pdf

4.6 Длительности хранения изменений

Automated пулы возможно разделить по длительности хранения изменений, сделанных на десктопах, на постоянные (Persistent) и непостоянные (Non-persistent).

Как можно понять из названия, для постоянных десктопов все изменения сделанные внутри гостевой ОС сохраняются, для непостоянных – изменения периодически затираются. Доступны следующие политики удаления:

• Удаление после завершения сеанса (Logoff).
• Удаление раз в N дней.
• Удаление после роста ВМ на N ГБ.

Для Full Clones десктопов очистка выполняется путем удаления и пересоздания ВМ с нуля, для Linked clones десктопов также доступна функция Refresh, которая возвращает состояние ВМ из снапшота, сделанного сразу после создания и настройки ВМ из эталонного образа.
Автоматическая очистка десктопов позволяет сэкономить дисковое пространство и контролировать занимаемое десктопами дисковое пространство и может пригодиться для организации киосков или развертывании десктопов для пользователей, выполняющих однотипные задачи - операторы call-центра, кассиры, студенты в учебных классах.

4.7 Привязка к пользователю

По способу привязки пользователей десктопы делятся на выделенные (dedicated) и плавающие (floating). Dedicated десктоп закрепляется за одним конкретным пользователем, и только он может к нему подключиться. Dedicated десктопы используются в качестве полноценной замены персональных рабочих станций пользователей, как правило, такие десктопы настраивают на сохранение изменений, сделанных пользователями (Persistent). Важно помнить, что при использовании Dedicated пулов только один десктоп в пуле может быть привязан к пользователю. Если по какой-либо причине вам необходимо выдать и привязать к пользователю несколько выделенных десктопов, то вам потребуется создать несколько dedicated pool’ов.

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

4.8 Дополнительные возможности пулов

На уровне пулов также можно настраивать работу следующих механизмов оптимизации:

• Storage Accelerator.
• Space Reclamation.
• VCAI.

Storage Accelerator (известный также как CBRC – Content Based Read Cache) – технология оптимизация работы дисковой подсистемы за счет кэширования блоков, запрашиваемых ВМ при выполнении операций чтения, в оперативной памяти хост-серверов. Использование Storage Accelerator позволяет существенно снизить пиковую нагрузку на диски в момент одновременного включения десктопов (boot storm), входа пользователей (logon storm) или антивирусной проверки (antivirus storm). На хост-серверах резервируется определенный объем оперативной памяти (от 100 МБ до 2 ГБ, в версии vSphere 6.5 и новее - до 32 ГБ). Для каждого виртуального диска с включенным ускорением создается digest файл, содержащий хэш файл блоков данных, для того, чтобы хост-сервер мог находить одинаковые блоки на дисках разных ВМ и более эффективно использовать кэш в оперативной памяти. При выполнении операции чтения хост-сервер проверяет – находится ли запрашиваемый блок в кэше, если – да, то хост отдает данные из памяти, если – нет, то читает с диска. Для обеспечения консистентности данных Storage Accelerator и оптимального использования кэша хост-сервер периодически пересоздает digest файлы для дисков виртуальных машин (для виртуальных десктопов Horizon, по умолчанияю, раз в 7 дней).

Space Reclamation - технология, работающая в связке с постоянными Linked-Clone десктопами, которая позволяет уменьшать размер delta-дисков. Delta-диски - это снапшоты, которые хранят изменения, выполненные в ВМ в процессе ее работы, и растут по мере записи в них новых данных. Однако при удалении файлов, delta-диски автоматически не уменьшаются в размерах, что приводит к росту занятого дискового пространства. Для решения этой проблемы в vSphere 5.1 была добавлена поддержка новых типов дисков и снапшотов – Space Efficient Sparse. Для данных дисков может запускаться операция сжатия (shrink), которая удаляет из дисков пустые области и уменьшает их размер.

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

Пару слов следует сказать о VCAI (View Composer API for Array Integration). Это API для интеграции с NFS системами хранения, которое предоставляет возможность создания Linked Clones ВМ при помощи снапшотов, создаваемых средствами системы хранения, вместо использования снапшотов VMware. В основе работы VCAI лежит функция Native Snapshots for Linked Clones, являющаяся частью VAAI для работы с файловыми хранилищами.

К сожалению, несмотря на свои плюсы, вроде более быстрого создания Linked Clone ВМ и более эффектной утилизации дискового пространства, VCAI практически не используется из-за крайне скудного перечня официально поддерживаемых массивов (для версии Horizon 7.0 поддерживаются только СХД производства Datrium, Fujitsu и Tintri). Полный перечень СХД, поддерживающих VCAI: https://www.vmware.com/resources/compatibility/pdf/vi_vcai_guide.pdf.
Кроме того, VCAI имеет следующие ограничения:

• Ограниченная поддержка Storage Accelerator.
• Не поддерживаются Space Efficient (Sparse SE) виртуальные диски и Space Reclamation.
• Реплика и дельта диски не могут находиться на разных хранилищах.

С появлением и развитием VVOLs применимость VCAI постепенно сходит на нет, поэтому использование данного варианта создания десктопов вряд ли заслуживает внимания.

Продолжение доступно по ссылкам:

Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины
Часть 8. Подсистема хранения
Часть 9. Сетевая подсистема

Часть 10. Организация подключения и безопасность
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление