Немного о дизайне VDI. Часть 7. Виртуальные машины

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI

7.1 Служебные виртуальные машины

К служебным ВМ относятся серверы, обеспечивающие работу VDI инфраструктуры: vCenter Server, View Connection Server, Unified Access Gateway, View Composer и пр.

В официальной документации VMware приводится информация к требуемым аппаратным ресурсам и перечень совместимых ОС и СУБД для каждого компонента VDI инфраструктуры. Зачастую служебные ВМ поставляются производителем в виде готовых виртуальных апплайнсов с заранее определенной аппаратной конфигурацией.

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

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

7.2 Клиентские виртуальные машины

Сайзинг и требования к вычислительным ресурсам для клиентских ВМ зависят от различных факторов:

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

7.3 Сайзинг вычислительных ресурсов

В моей практике оценка необходимых процессорных ресурсов является наиболее трудоемкой частью сайзинга виртуальных десктопов. Нехватка процессорных ресурсов приводит к снижению производительности и увеличению времени отклика приложений, и как следствие – к недовольству пользователей, особенно в тех случаях, когда виртуальные рабочие станции заменяют собой достаточно производительные и современные ПК с мощными процессорами. Избыток процессорных ресурсов влечет за собой увеличение стоимости реализации проекта – высокопроизводительные процессоры (например Intel Xeon Platinum) с большей тактовой частотой и большим количеством ядер стоят ощутимо дороже процессоров среднего ценового диапазона, к тому же обладают более высоким энергопотреблением и тепловыделением, что также повышает требования к инженерной инфраструктуре ЦОД.

При планировании процессорных ресурсов следует учитывать не только нагрузку, создаваемую ОС и приложениями, но также нагрузку, создаваемую служебным ПО, в первую очередь Horizon Agent. При кодировании изображения в высоком разрешении с часто меняющейся картинкой (например, при воспроизведении видео), нагрузка на процессор может достигать 25-40% (в зависимости от частоты и кол-ва ядер, выделенных ВМ). Другим ресурсоемких служебным ПО являет ПО антивирусной защиты, также может приводить к росту загрузки процессорных ресурсов, особенно в случае Antivirus Storm – одновременной массовой проверки антивирусным ПО большого количества виртуальных десктопов.

Показатель консолидации (соотношение виртуальных ядер vCPU к физическим pCPU) зависит от многих факторов и должен определяться на этапе пилота. В среднем для VDI сценариев показатель консолидации составляет от 6 до 12 vCPU на один pCPU. Если возможность провести полноценный пилот отсутствует, то рекомендуется воспользоваться утилитами для проведения нагрузочного тестирования, эмулирующими работу пользователей с VDI, например, Login VSA или VMware View Planner.

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

vSphere предоставляет следующие технологии управления оперативной памятью:

vSphere предоставляет следующие технологии управления оперативной памятью: Transparent Page Sharing (TPS), Memory Ballooning, Memory Compression, VM Swap.

При проектировании VDI следует определиться с тем, планируете ли вы использовать overcommit по памяти или нет, т.е. возможны ли ситуации, когда ВМ будет выделено памяти больше, чем имеется на сервере/кластере или нет. В качестве примера такой ситуации – сбой одного или нескольких серверов, что приведет к нехватке вычислительных ресурсов до момента их починки или замены. Использование overcommit в разумных пределах позволяет снизить стоимость VDI, однако следует помнить, что overcommit негативно сказывается на производительности, приводя к повышенной загрузке процессора (при использовании TPS и Memory Compression) и дисковой подсистемы (при использовании Memory Ballooning и VM Swap).

TPS – технология дедупликации страниц оперативной памяти. За счет того, что в VDI инфраструктурах на каждом хосте работает большое количество однотипных ВМ, показатели экономии при использовании TPS могут достигать 30% и более. Однако следует помнить о  следующих нюансах, которые могут снизить эффектность работы TPS.

Современные гостевые ОС и сам гипервизор ESXi могут выделять оперативную память для ресурсоемких приложений большими страницами, что позволяет снизить накладные расходы на управление памятью. TPS отлично работает при дедупликации страниц памяти размером 4 КБ и практически не работает для больших страниц (2 МБ). Кроме того использование механизма безопасности Address space layout randomization (ASLR), по умолчанию включенного в современных ОС, также снижает  эффективность работы TPS.

Начиная с vSphere 5 появился механизм подсаливания (salting), который позволяет ограничивает область работы механизма дедупликации памятью одной виртуальной машиной или набором виртуальных машин, имеющих общий ключ. Это позволяет исключить вероятность неавторизованного доступа к содержимому памяти одной ВМ из другой ВМ, платой за это также является снижение эффективности работы TPS. Более подробно о работе механизма написано в статье: https://kb.vmware.com/kb/2097593.

Другой механизм экономии памяти – Memory Ballooning требует для работы использования файла подкачки в гостевой ОС, что увеличивает размер дискового пространства, которое занимают ВМ на хранилище.

Резервирование оперативной памяти позволяет задать гарантированый объем памяти, который будет выделен ВМ при запросе. Для ВМ возможно частичное или полное резервирование памяти.

Полное резервирование памяти требуется для включения Fault Tolerance, а также подключения к ВМ графических ускорителей в режиме vDGA или vGPU.

При резервировании памяти пропорционально уменьшается объем файла подкачки ВМ (.vswp), так что если вы не планируете использовать memory overcommit, то резервирование памяти позволит снизить объем дискового пространства, занимаемого ВМ.

Помимо памяти, выделяемой непосредственно ВМ, следует помнить и о накладных расходах (overhead). При включении ВМ гипервизор резервирует часть памяти для обеспечения работы ВМ – поддержку таблицы страниц памяти, работу виртуальных устройств и пр. Размер Overhead зависит от объема памяти и количества ядер, которые были выделены виртуальной машине. https://docs.vmware.com/en/VMware-vSphere/5.5/com.vmware.vsphere.resmgmt.doc/GUID-B42C72C1-F8D5-40DC-93D1-FB31849B1114.html. Современные версии ESXi используют файл подкачки VMX Swap для того, чтобы уменьшить объем резервируемой памяти.

7.4 Сайзинг дискового пространства 

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

• виртуальные диски ВМ, на которых размещается ОС, приложения, данные пользователей;
• файл конфигурации ВМ и журналы ВМ (.vmx и .log файлы);
• файл подкачки ВМ (.vswp файл).

VMware Horizon предоставляет различные механизмы, позволяющие оптимизировать использование дискового пространства виртуальными десктопами. К таким механизмам относятся:

• Thin Provisioning – позволяет создавать виртуальные диски без предварительной резервации дискового пространства, которые растут по мере их заполнения данными.
• Linked Clones – позволяет создавать разностные (дельта) диски, которые используют единый мастер образ для однократного хранения общего набора данных (ОС, базовый набор приложений) и дельта диски, в которые записываются все изменения, сделанные в конкретной ОС. В инфраструктуре VMware работа Linked Clones основана на механизме снапшотов. В зависимости от объема изменений и того, как часто выполняется Recompose или Refresh ВМ, показатель экономии варьируется от 50 до 95% (для постоянных Linked Clone ВМ средний показатель экономии составляет 70%).
• Space Reclamation – связан с технологиями Thin Provisioning и Linked Clones. По умолчанию, тонкие диски растут по мере заполнения их данными, однако, в случае удаления данных внутри гостевой ОС, размер тонкого диска автоматически не уменьшается и требует ручного запуска команды на стороне хоста. Space Reclamation позволяет проводить процедуру уменьшения тонкого диска созданного с использованием технологии Linked Clones по расписанию.
• Откат изменений (Refresh) / удаление ВМ. Для non-persistent floating виртуальных машин возможно настроить механизм, выполняющий очистку всех изменений, сделанных пользователем после завершения сеанса работы. Это позволяет держать размер виртуального диска Linked Clone ВМ на минимальном уровне. Другой механизм, который также может использоваться и для Full Clone VM является автоматическое удаление и пересоздание ВМ после завершения работы.
• Вынос временных файлов и файла подкачки гостевой ОС на временный (non-persistent) диск. Диски автоматически обнуляются при выключении ВМ, высвобождая место, уменьшая фрагментацию дельта дисков, их размер, скорость роста.

Помимо оптимизаций VMware, многие современные массивы поддерживают технологии оптимизации использования дискового пространства: Thin provisioning lun, дедупликация, компрессия, аппаратная поддержка linked clones (vSphere API for Composer Array Integration). 

Следует помнить, что далеко не все механизмы экономии хорошо сочетаются друг с другом. Например, экономия дискового пространства при использовании all-flash массивов с дедупликацией при создании full-clone десктопов достигает 10-кратной и более значений, тогда как для linked-clone десктопов показатели дедупликации редко превышают 1.5-2.

Важным шагом по уменьшению размера дисков ВМ является оптимизация дискового пространства внутри гостевой ОС.

Так, например, одним из шагов, позволяющих существенно уменьшить объем занимаемого дискового пространства является интеграция обновлений в дистрибутив и установка ОС из обновленного дистрибутива вместо установки всех обновлений в существующую гостевую ОС.

Другим вариантом является уменьшения и фиксация максимального размера файла подкачки или вынесение его на отдельный виртуальный диск (при условии выделения достаточного объема оперативной памяти виртуальной машине).

Удаление встроенных приложений, вроде Metro приложений Windows, Internet Explorer или Windows Media Player (если они не требуются для работы) позволит уменьшить занимаемое дисковое пространство и не тратить ресурсы на обновление неиспользуемых компонентов. 

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

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

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

Наконец, одним из самых эффективных и быстрых вариантов доставки является использование механизма App Volumes, позволяющий распростарнять приложения на десятки и сотни ВМ одновременно без необходимости предварительной установки на каждый десктоп.

7.5 Графические адаптеры

В любой виртуальной машине присутствует виртуальный графический адаптер (VMware SVGA 3D), который используется для рендеринга изображения и в качестве фреймбуффера для вывода изображения в консоль MKS (Mouse, Keyboard, Screen) и на виртуальные дисплеи при подключении к десктопу по протоколам PCoIP или Blast. При сайзинге конфигурации ВМ важно правильно оценить объем памяти, который требуется зарезервировать для виртуального графического адаптера. При выставлении слишком большого разрешения, например, при подключении к десктопу с клиентского устройства оборудованного 4К монитором, в случае нехватки видеопамяти вместо изображения пользователи будут видеть черный экран.

Виртуальный графический адаптер не используется, когда пользователи подключаются к десктопу по протоколу RDP (т.к. за прорисовку экрана отвечает протокол RDP), или при использовании режимов ускорения vDGA или vGPU (в этом случае за прорисовку экрана будет отвечать физический графический адаптер, подключенный к ВМ). В этих случаях следует выделять виртуальному графическому адаптеру минимально возможный объем памяти для экономии ресурсов.

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

• Без ускорения (параметр Enable 3D Support отключен). Обработка графики выполняется центральным процессором сервера. Видеопамять виртуального выделяется целиком из оперативной памяти сервера. Максимальный объем памяти, выделяемой одной ВМ, составляет 128 МБ.
• Software 3D – при включении данного режима каждой ВМ выделяется дополнительная память (3D Memory) объемом от 32 до 512 МБ (которая также берется из оперативной памяти сервера), использующаяся для рендеринга графики. Для этих целей также используется центральный процессор. В данном режиме поддерживаются
• vSGA (Virtual Shared Graphics Acceleration) – ВМ использует виртуальный графический адаптер, однако функции по обработке графики перекладываются на совместимый графический адаптер, установленный в сервере. vSGA также поддерживает выделение видеопамяти от 32 до 512 МБ, однако только половина видеопамяти выделяется из оперативной памяти сервера, вторую половину памяти выделяет физический графический адаптер.
• vDGA (Virtual Dedicated Graphics Acceleration) – режим при котором графический адаптер монопольно выделяется одной ВМ при помощи технологии DirectPath I/O. В гостевой ОС устанавливается драйвер от производителя адаптера, вся обработка и вывод графики осуществляется физическим графическим адаптером.
• Virtual Shared Pass-Through Graphics Acceleration. В данном режиме графический адаптер разделяется на несколько частей/виртуальных GPU, каждый из которых выделяется своей ВМ. Реализация данного режима различается у NVIDIA и AMD. Для ускорителей NVIDIA технология носит название vGPU и предполагает деление графического адаптера на основании профилей, указанных в настройках ВМ в момент запуска ВМ. Для графических адаптеров AMD технология MxGPU предполагает предварительное разделение адаптера на части нужного размера, после чего отдельные виртуальные GPU презентуются ВМ. Данный режим обеспечивает меньшую производительность, но большую гибкость и лучшую консолидацию по сравнению с vDGA.

Следует помнить, что режимы vDGA и vGPU помимо ускорения трехмерной графики также могут использоваться для аппаратного декодирования видео с помощью встроенных кодеков, кодирования изображения для протокола VMware Blast, а также для выполнения математических расчетов и ускорения работы приложений (например, для приложений, которые поддерживают CUDA или OpenCL).

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

Режим	Без ускорения	Software 3D	vSGA	vDGA	vGPU	MxGPU
Поддерживаемые версии DirectX	11, 10, 9	10, 9	10, 9	Зависит от адаптера	Зависит от адаптера	Зависит от адаптера
Производительность	Очень низкая	Очень низкая	Низкая	Очень высокая	Высокая	Высокая
Тип графического адаптер / Драйвер	VMware SVGA 3D	VMware SVGA 3D	VMware SVGA 3D	AMD / Intel / NVIDIA	NVIDIA	AMD
Максимальный объем видеопамяти	128 МБ	512 МБ	512 МБ	Зависит от адаптера	Зависит от адаптера	Зависит от адаптера
Аппаратное ускорение графики	Нет	Нет	Да	Да	Да	Да
Монопольное использование графического ускорителя одной ВМ	-	-	Нет	Да	Нет	Нет
Требуется зарезервировать память (Memory Reservation)	Нет	Нет	Нет	Да	Да	Да
Поддержка High Availabilit	Да	Да	Да	Нет	Да	Нет
Поддержка vMotion / DRS	Да	Да	Да	Нет	Нет	Нет
Поддержка аппаратного кодирования Blast	Нет	Нет	Нет	Да, для NVIDIA	Да	Нет

7.6 Конфигураторы ВМ

Помимо сайзинга вычислительных ресурсов вручную могут использоваться специализированные утилиты.

Пожалуй, самым известным независимым инструментом является калькулятор VDI calculator (http://myvirtualcloud.net/vdi-calculators-2/) за авторством Andre Leibovici. Калькулятор может выполнять сайзинг для различных платформ, типов рабочих столов, типов хранилищ, предоставляет огромное количество параметров для настройки, и рекомендуется в качестве основного инструмента для сайзинга или самопроверки.

VSAN TCO and Sizing Calculator (https://vsantco.vmware.com/vsan/SI/SIEV) от VMware пригодится в тех случаях, когда вы планируете развернуть VDI на базе хранилища VSAN.  Калькулятор прост в освоении и позволяет получить на руки рекомендуемые аппаратные конфигурации серверов (из списка VSAN Ready Nodes).

7.7 Оптимизация образа

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

Пожалуй, самым популярным инструментом для оптимизации ОС является VMware OS Optimization Tool доступный для загрузки с сайта (https://labs.vmware.com/flings/vmware-os-optimization-tool). Помимо встроенных шаблонов вы также можете использовать шаблоны сторонних разработчиков, например, шаблон, подготовленный login vsi: https://www.loginvsi.com/blog/520-the-ultimate-windows-10-tuning-template-for-any-vdi-environment.

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

Часть 8. Подсистема хранения
Часть 9. Сетевая подсистема

Часть 10. Организация подключения и безопасность

Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление