Данная статья задержалась на два года, поскольку именно два года назад я познакомился с VDI на базе Citrix XenDesktop и немного обескуражившей меня фичей Personal vDisk (PvD). На тот момент я отвечал за инфраструктуру VDI, управляемую продуктом Fujitsu PanoLogic. Использовались Full clones, и это была боль. Только представьте установку обновлений на 1000+ виртуальных машин, расположенных не на флеш-массиве.
Мы присматривались к VMware View (ныне Horizon) с её Linked Clones, но сильно смущал тот факт, что обновление базового образа (Gold Image) приводит все десктопы, на нём основанные, к практически девственному виду, лишая пользователя любовно установленных приложений. Разработчики точно были бы не рады, да и остальные привыкли к хорошему.
И когда нам дали поиграться с Citrix XenDesktop, тогда ещё 7.2 или 7.3, я пришёл в восторг. Потому что при использовании PvD все изменения, сделанные внутри виртуальной машины, сохранялись даже после обновления мастер-образа. И под «все» я имею ввиду не только настройки профиля или документы на рабочем столе (это достигается и в VMware), но и установленные и даже удалённые(!) приложения. Когда я поделился обнаруженными результатами с коллегами VMware'щиками из другой организации, они сказали, что это невозможно, потому что не объяснимо.
На практике, конечно, чудеса случаются редко, и объяснение происходящему есть.
Оба производителя VDI-решений подходят к реализации инфраструктуры на базе разностных дисков по-своему. У VMware это выглядит вот так:
По понятным причинам на Replica ничего писать нельзя, вся запись идёт на Delta.
Internal хранит идентификационную информацию о компьютере (такую как пароль AD).
Persistent Disk можно создать для данных, которые нужно хранить всегда. Сюда можно перенести профиль, Redirected Folders и Home Directory.
Disposable Disk, наоборот, обнуляется после каждой перезагрузки. Сюда можно перенести данные, которые совсем не нужно хранить (pagefile, temp) в целях уменьшения размера Delta и нагрузки на него.
А так выглядит картина в XenDesktop при использовании MCS (она ближе к используемой VMware, чем PVC)
Difference — для перенаправления записи.
Identity — для хранения идентификационных данных компьютера.
PvD — Personal vDisk для хранения постоянных данных. С виду похоже на Persistent disk VMware. В системе он виден как диск P: (по умолчанию) и если на него зайти, то увидим пользовательские данные (профиль).
Однако, как я уже писал, при использовании PvD, виртуальная машина «запоминает» не только пользовательские настройки и данные, но и установленные и даже удалённые приложения. Даже после обновления мастер-образа. Проводил следующие эксперименты.
Установка ПО
1. Создал мастер-образ с Windows 7 (VD-template).
2. Создал виртуальный десктоп на основе него (VD01).
3. В виртуальном десктопе установил 7zip (в C:\Program Files).
4. Обновил мастер-образ (установил в него Adobe Reader) и применил его к пулу.
5. Залогинился в VD01. 7zip на месте. И Adobe Reader тоже.
6. Создал новый десктоп на базе этого же мастер-образа (VD02). Adobe Reader присутствует. 7zip — нет.
Удаление ПО
1. Залогинился в VD01. Удалил Adobe Reader.
2. Обновил мастер образ (установил несколько обновлений Windows в VD-template) и применил к пулу.
3. Залогинился в VD01. 7zip на месте, Adobe Reader удалён. Обновления присутствуют.
4. В VD02 Adobe Reader на месте. Обновления присутствуют. 7zip нет.
5. Создал новый десктоп VD03. Та же картина, что и в VD02.
Чертовски восхитительно!
Осталось понять, как он это делает. Ну да не буду более ходить вокруг да около и нагнетать интригу.
Технически PvD представляет собой два диска в одном. Первый — это то, что мы видим в виде диска P: внутри виртуального десктопа. На него перенаправляются данные профиля, и тут ничего необычного. Второй — это виртуальный vhd-диск UserData.vhd, который лежит на первом. Он тоже монтируется в систему, хотя его не видно в проводнике. И в него перенаправляется запись на объектном (не блочном) уровне.
При первом использовании на PvD копируется информация об объектах из основного образа, которая располагается тут: C:\CitrixPvD\Settings\Inventory. Далее в Inventory фиксируются данные о проделанных пользователем изменениях и ссылках на них.
После обновления мастер-образа, перед его выключением и снятием снапшота для применения в пул, на нём нужно провести обновление Inventory. Если вы забудете, система напомнит об этом при попытке выключения.
После распространения нового мастер-образа, виртуальные десктопы при первом запуске перечитывают Inventory нового образа и сравнивают с записями на PvD. В ходе этого процесса и определяется, что появилось нового, а что должно быть перенаправлено.
Данная процедура приводит к тому, что первый вход пользователя в систему после обновления мастер-образа может занимать продолжительное время (10-15 минут, в зависимости от количества проделанных изменений). Поначалу, не зная деталей работы этого механизма, я попортил несколько десктопов, нетерпеливо перезагружая их в этот момент. Хорошо, что в тестовой среде.
При этом, если выяснится, что в мастер-образе появились объекты, ранее устанавливаемые пользователем и хранимые в PvD, они будут вычищены из PvD в целях экономии места, а ссылки на них заменены на те, что ведут на основной образ. Другими словами, если я в примерах выше установил бы 7zip в мастер-образ, VD01 удалил бы его из PvD и стал использовать тот, который общий для всех. При условии совпадения версий.
Разные варианты сценариев с конфликтами версий я не тестировал.
Немного деталей и ограничений PvD
- Поддерживаются все гипервизоры, поддерживаемые решением XenDesktop — Hyper-V, VMware ESXi и, конено, Xen.
- Поддерживаются только клиентские гостевые ОС (Windows 7-10).
- Не требуются права администратора для работы в гостевой ОС (хотя без прав локального администратора пользователь немного сможет накастомизировать).
- Не может быть использован для изоляции ПО. Например, не получится с помощью PvD запускать две разных версии MS Office или Internet Explorer. Для решения этой задачи нужно использовать другие технологии. Но если кому-то надо использовать Office 2003 вместо установленного в основном образе 2013, то вполне себе вариант.
- Не совместимо с приложениями, использующими драйверы 0-уровня и сетевого стека (miniports/protocol drivers). Их стоит ставить в основной образ.
- Апдейты ОС также не стоит устанавливать на PvD во избежание конфликтов.
- С антивирусами гостевой ОС, в принципе, совместим, но могут быть нюансы. И проблемы.
- Не стоит делать backup/restore изнутри ОС, поскольку бэкап-агент не сможет определить, какая часть данных относится к основному образу, а какая к PvD. При восстановлении все данные будут записаны в PvD, просто потому что вся запись перенаправляется туда. Бэкап и восстановление следует делать на уровне гипервизора и с его стороны.
Менеджмент и настройки (совсем чуть-чуть, не имел большой практики)
Минимальный размер PvD — 3 ГБ. Максимальный ограничен тем, что поддерживает СХД.
По умолчанию данные профиля (диск P:) и данные ОС (UserData.vhd) распределяют использование места по принципу 50/50. Изменить это соотношение можно изменением следующего ключа реестра:
HKEY_LOCAL_MACHINE\Software\Citrix\personal vDisk\Config
Value: PercentOfPvDForApps
По умолчанию выставлено 50
Если исправить на 80, 80% места будет зарезервировано под приложения, а 20% — под данные профиля.
Можно вообще запретить перенаправление профиля на PvD (например, если вы используете Roaming Profiles)
«HKLM\Software\Citrix\personal vDisk\Configuration»
Value: «EnableUserProfileRedirection»
0: Profile is not directed to the PvD
1: Profile is redirected to the PvD
PvD может быть сброшен к исходному состоянию либо из Desktop Director, либо из самого десктопа с помощью команды
C:\Program Files\citrix\personal vdisk\bin\ctxpvd –s reset
(в командной строке от администратора)
Сброс не затрагивает пользовательский профиль. По сути, просто UserData.vhd заменяется исходным пустым шаблоном, взятым отсюда: C:\ProgramData\Citrix\personal vDisk
Напоследок небольшое отвлечённое умозаключение.
Ошибка "Failed to load reg hive [\Device\IvmVhdDisk00000001\CitrixPvD\Settings\RingCube.dat]." наводит на предположение, что решение PvD основано на разработке vDesk компании RingCube, которая была приобретена Citrix в 2011 за 46,67 млн долларов.
И в качестве окончательного резюме замечу, что решение, конечно, очень интересное и делает жизнь администратора VDI несравненно удобнее. Хотя едва ли может считаться панацеей — хоть заявляется поддержка «почти всего стандартного ПО», нужно проверять различные сценарии и не исключены возможные конфликты версий или проблемы с отдельным ПО.
Да и что в нашем [IT] мире может считаться панацеей?
Как я говорил, статья опоздала на два года — к тому времени, как я нашёл информацию о механизмах работы PvD, я сменил работу и потерял возможность писать статьи вообще, ввиду сверхвысокой загруженности. За это время появились новые технологии подключения кастомных приложений в VDI — App Volumes у VMware, Unidesk у Citrix вот появился… Но это немного другие истории.
Сейчас я сменил работу ещё раз, отдалился от виртуализации, но терзало ощущение незавершённого дела…
Спасибо за внимание! Хоть я и закрывал собственный гештальт данной статьёй, надеюсь, что ещё кому-то будет полезно, или хотя бы интересно.
Комментарии (0)