В данной статье я попытаюсь максимально просто описать принципы работы двух основных методов развертывания виртуальных машин в инфраструктуре Citrix.
Принцип работы MCS
Citrix Machine Creation Services является одним из двух типов массового автоматизированного развертывания виртуальных машин и в сравнении с Provisioning Services (PVS) MCS является встроенным функционалом XenDesktop.
Нижеследующие шаги описывают процесс создания каталога виртуальных машин для их дальнейшего развертывания механизмом MCS.
Создание виртуальных машин в каталоге можно условно разделить на следующие этапы:
1. Будем исходить из того, что ваша виртуальная машина полностью проинсталлирована и готова к развёртыванию. Прежде всего необходимо сделать снимок виртуальной машины (Snapshot), если его не сделать вручную, то он будет сделан автоматически и ему будет присвоено имя состоящие из имени каталога и даты.
2. На базе основного диска и снепшота будет создана новая версия, так называемый Base Disk. Base Disk является основой для последующего создания виртуальных машин каталога.
3. Средствами гипервизора создается (клонируется) заданное при конфигурации количество виртуальных машин. При применении гипервизора vSphere используется технология Linked Clone.
Описание: Types of Clone: Full and Linked
Каждая созданная виртуальная машина состоит из двух дисков:
a. Difference (Delta) Disk – на этом диске содержится временная информация, используемая операционной системой. После каждой перезагрузки вся записанная информация удаляется. Difference Disk можно считать аналогом Write Cache Disk в PVS.
b. Identity Disk – на нем сохраняется информация, делающую систему уникальной, например SID, имя компьютера, пароль. Размер диска составляет всего 16 MB.
4. Для каждой машины создается учетная запись в Active Directory.4. Для каждой машины создается учетная запись в Active Directory.
5. После перезагрузки, созданные виртуальных машины получают IP-адрес от DHCP-сервера.
Каждая последующая актуализация системы требует повторения шагов от 1 до 3.
Full Clone
MCS Full Clone – создание полноценной копии виртуальной машины
В версии XenDesktop 7.11 появилась возможность выбора, использовать ли Full Clone или Linked Clone. Основное преимущество Full Clone, — это возможность создания резервной копии виртуальной машины, что в свою очередь упрощает процесс миграции виртуальных машин.
Использование технологии Full Clone имеет, к сожалению, и недостатки, а именно: значительно увеличивается время создания / обновления каталогов, требуется больше места на СХД и Full Clone применима только для настольных операционных систем (Windows 10).
Принцип работы PVS
PVS - это технология, которая обеспечивает одновременную загрузку операционной системы по сети с помощью стриминга на множество целевых систем (виртуальных или физических). Целевые компьютеры, в отличие от классического ПК, не имеют жесткого диска с установленной операционной системой и запускаются непосредственно из сети. Передачи нескольких сотен мегабайт уже достаточно для старта операционной системы и регистрации пользователя в ней. Например, окно регистрации в системе Windows 10 появляется после загрузки 250 MB.
Ключевым элементом инфраструктуры PVS является Provisioning Server. Сервер PVS не только отвечает за управление средой PVS, но и является центральной точкой потоковой передачи vDisk-ов. Все настройки конфигурации хранятся в базе данных MS SQL. По сравнению с MCS, PVS не является частью XenApp / XenDesktop.
Для достижения высокой доступности требуется как минимум два сервера PVS. Серверы PVS используют протокол IPC для связи друг с другом.
Следующие шаги описывают принцип работы PVS:
- PVS Streaming Service предоставляет файл (PXE-Bootstrap File: ARDBP32.BIN) для начальной загрузки. PXE-Bootstrap File содержит инструкции для запроса виртуального диска.
- На основании MAC-адреса проверяется, имеет ли целевая система запись в базе данных PVS.
- vDisk передается по сети целевой системе. Передача данных осуществляется по UDP протоколу.
Master Image - vDisk
Для создания vDisk-а необходимо на операционной системе (серверной или настольной) установить PVS Target Device. Задача PVS Target Device сконвертировать диск операционной системы в vhd-файл (с версии 7.7 у вас есть выбор между VHD и VHDX) и сохранить его в соответствующей папке (PVS Store). Для конвертации используется XenConvert Tool.
В папке PVS Store сохраняются файлы следующих типов:
- .vhdx (vhd) – диск операционной системы
- .lok – файл блокировки доступа, активен если vDisk используется
- .pvp – конфигурационный файл vDisk
- .avhd - (z.B. .1.avhdx) – файл с последними сохранёнными изменениями (Differencing Disk)
Методы загрузки
Существует три различных способа загрузки целевых систем в среде PVS: DHCP, PXE и BDM:
1. DHCP Метод
DHCP является наиболее широко используемым и пожалуй самым популярным методом. Клиент получает IP-адрес от DHCP-сервера, который включает в себя следующие параметры:- Option 66 – здесь указывается IP-адрес PVS сервера - Option 67 – имя файла загрузки (ARDBP32.bin)
2. PXE Метод
Клиент получает только IP-адрес с сервера DCHP, так как на DHCP-сервере не настроены опции 66 и 67. PVS сервер сам реагирует на запрос клиента и отвечает ему передавая параметры опций 66 / 67. Данный метод крайне редок и не всегда возможен, ввиду определённой зависимости от конфигурации сети.
3. BDM (Boot Device Manager)
В этом случае целевая система запускается непосредственно с физического загрузочного носителя (CD). Этот метод бывает единственно возможным для использования PVS, так как опции 66 / 67 уже используются другими системами (например, SCCM или Matrix42).
Пошаговое описание процесса загрузки
1. Получение IP адреса - целевое устройство получает IP-адрес от DHCP сервера. Вместе с IP-адресом передаются также адрес TFTP-сервера (Option 66) и название файла загрузки (Option 67).
2. Загрузка Bootstrap файла - загрузочный файл (ARDBP32.bin) скачивается с TFTP-сервера на целевое устройство.
3. Процесс входа в систему PVS - после того, как целевое устройство получило IP-адрес и скачало загрузочный файл, оно регистрируется на PVS-сервере, чтобы начать стриминг vDisk-а.
4. Single Read Mode – целевое устройство начинает отправлять запросы на PVS-сервер в так называемом режиме одиночного чтения и делать это до тех пор, пока операционная система не начнет загружать драйверы, и не загрузит BNISTACK-драйвер.
5. BNISTACK / MIO Read Mode – заключительная фаза загрузки системы. BNISTACK загружается в память и продолжает управлять коммуникацией между сервером и целевым устройством. BNISTACK использует параллельно несколько потоков для связи с сервером PVS. Multiple Input/Output - один канал используется для запроса и множество для получения ответа от сервера PVS.
PVS Store
Store – это место физического хранения для vDisk-ов. Данная папка может находиться как на любом из PVS-серверов, так и на общем хранилище (Shared Storage). Важно позаботиться о достаточном количестве места на диске и быстром доступе к нему (IOPS performance).
Использование совместного хранилища (Shared Storage) не требует дополнительных механизмов для синхронизации vDisks-ов.
Сервера PVS не имеют встроенных механизмов для репликации vDisk-ов между собой. Для этого чаще всего используется простой и удобный метод, - скрипт на основе команды robocopy. Использование распределенной файловой системы (DFS) также возможно.
Write Cache
В стандартном режиме (Standard Mode) vDisk доступен только для чтения (read only), и все данные, которые обычно записываются на системный диск виртуальной машины, переносятся в Write Cache. Существует несколько различных режимов настроек Write Cache.
Write Cache - это временная память, содержащая данные, созданные операционной системой во время работы, а также информация, которую следует сохранить после перезагрузки (например, журналы событий, сигнатуры вирусов, кэш App-V). Write Cache Disk также является типичным местом для хранения Pagefile-файла.
Write-Cache файл (vdiskdiff.vhdx) постоянно растет в течении работы системы и обнуляется только после перезагрузки. vdiskdiff фактически и является следующими опциями “Cache on Target Device Hard Drive” и „Cache in device RAM withoverflow on hard disk“
Текущая версия PVS предлагает шесть различных опций для хранения Write-Cache. У каждого варианта есть свои плюсы и минусы. Рекомендуется использовать „Cache in device RAM with overflow on hard disk“
Возможные варианты размещения Write Cache
Кэш на жестком диске целевого устройства (Cache on device hard disk)
В данном случае Write Cache расположен на жестком диски целевого устройства. До недавнего времени данный вариант был самым предпочтительным решением.
Постоянный кэш на жестком диске целевого устройства и сервера (Cache on device hard disk persisted / Cache on server, persistent)
Как следует из названия, речь идет о постоянном, не сбрасываемом после перезагрузки файла кэша.
Write Cache в рабочей памяти целевого устройства (Cache in device RAM)
Если вы хотите получить максимально возможную производительность, то этот вариант будет наиболее предпочтителен, но крайне дорогостоящим.
Write Cache на жестком диске PVS сервера (Cache on server)
Данный способ наиболее неэффективный из всех перечисленных. Write Cache расположен на PVS-сервере, доступ к которому осуществляется по сети.
Write Cache в рабочей памяти целевого устройства с переполнением на жесткий диск (Cache in device RAM with overflow on hard disk)
Данная опция представляет собой идеальный баланс между производительностью и стоимостью. Опция имеет два уровня. Вначале все изменения хранятся в памяти виртуальной машины. Размер памяти, вернее его максимальное значение для каждого виртуального диска настраивается в конфигурации. Не забывайте о том, что выделенная память будет взята из общей памяти виртуальной машины. Когда выделенная память будет заполнена, наименее востребованные данные, будут перемещены из области ОЗУ в файл (vdiskdif.vhdx) на жестокий диск виртуальной машины. В настоящее время данная опция является рекомендованной производителем.
Режим доступа к vDisk
Private Mode - в этом случае vDisk находится в состоянии записи и соединен только с одной виртуальной машиной.
Standard Mode - vDisk доступен только для чтения и используется многими виртуальными машинами одновременно.
Иными словами, в Private Mode диск всегда имеет отношение 1:1, в стандартном режиме всегда соотношение 1:n.
Обновление vDisk-а
Как вы можете видеть на приведенных ниже рисунках, целевое устройство может быть загружено с разных версий диска. Differencing Disk (.avhdx) – это всегда зависимый от предыдущей версии снимок файловой системы, по функциональности сравнимый со снапшотом. Все .avhdx-файлы последовательно нумеруются. Differencing Disk используется для установки программного обеспечения, обновлений или исправлений.
Существует три различных метода доступа: обслуживание (Maintenance), тестирование и рабочий (Produktion)
Maintenance - является доступной для записи версией, которая может использоваться только одной виртуальной машиной, чаще всего специально созданной для этих целей.
Test - это версия, предназначенная только для чтения, используемая для тестирования.
Produktion – рабочая версия, из которой загружены все виртуальные машины каталога
Дополнительная полезная информация
Подробные диаграммы и описание процесса загрузки (постер): Citrix Provisioning Services Boot Process
Best Practices for Configuring Provisioning Services Server on a Network (CTX117374) - Прочитать
Guidance on PVS Ports and Threads - Прочитать
Understanding Write Cache in Provisioning Services Server (CTX119469) - Прочитать
Size Matters: PVS RAM Cache Overflow Sizing - Прочитать
Достаточно много полезной информации вы найдете в этом видео - Citrix Synergy 2016 - SYN219 - Getting up close and personal with MCS and PVS
Всегда рад Вашим отзывам, комментариям и конструктивной критике