Если каждому сотруднику ставить виртуальную машину руками — VDI не имеет смысла: сто ноутбуков настроить быстрее. Смысл появляется, когда рабочие места штампуются из одного эталона. В VDI этот эталон называется золотой репликой, а набор рабочих мест из него — пулом. Разбираем, как это устроено в AirCloud: от создания реплики до того, что происходит с данными сотрудника, когда он выходит из системы.
Что такое золотая реплика
Золотая реплика — эталонный образ рабочего стола: операционная система, установленные программы, настройки, агент платформы. Из него создаются все машины пула, поэтому сто рабочих мест разворачиваются так же быстро, как одно, и выглядят одинаково.
Важный нюанс: реплика создаётся не из установочного образа, а из готовой виртуальной машины и её снапшота. Жизненный цикл такой:
1. Создать обычную виртуальную машину.
2. Установить ОС, программы, драйверы и агент платформы.
3. Снять снапшот.
4. Превратить снапшот в золотую реплику.
5. Создать из реплики пул.
Реплики принято версионировать понятными именами — например, «win11-office-v1», — и перед публикацией проверять на тестовом пуле. Обновление программ во всём парке рабочих мест — это новая версия реплики и пересоздание пула, а не обход сотни машин.
Генерализация: почему сто копий не конфликтуют
Если просто клонировать машину сто раз, получится сто машин с одинаковыми системными идентификаторами — Windows такое не любит, домен тем более. Поэтому при создании реплики платформа выполняет генерализацию: разворачивает временную машину из снапшота, запускает внутри стандартную процедуру обезличивания Windows, которая стирает уникальные идентификаторы, и сворачивает результат обратно в образ. Для этого в машине должен стоять агент платформы — без него генерализация не запустится.
При разворачивании пула каждая машина получает своё имя по шаблону — например, «vdi-office-{n}», — и при необходимости автоматически вводится в домен.
Генерализация из интерфейса сегодня работает для Windows. Для Linux-рабочих столов автоматическая кастомизация через cloud-init находится в разработке; сейчас Linux-машины готовятся вручную.
Связанные и полные клоны
Из реплики машины пула создаются одним из двух способов:
- Связанный клон — все машины читают общий неизменяемый диск реплики, а свои изменения каждая пишет в собственный тонкий слой. Пул связанных клонов занимает заметно меньше места, чем полные копии, создаётся быстрее и обновляется заменой реплики; фактический расход зависит от того, сколько живут машины и сколько в них меняется.
- Полный клон — каждая машина получает полную независимую копию диска. Дольше и дороже по месту, зато машина ни от чего не зависит.
Для типовых офисных рабочих мест почти всегда выбирают связанные клоны. Полные — для машин, которые будут жить долго и сильно меняться.
Плавающие и закреплённые пулы
Второй выбор — как машины назначаются людям:
- Плавающий пул: при входе сотрудник получает любую свободную машину. Вышел — машина возвращается в пул, по желанию с очисткой диска. Идеально для колл-центров, операционистов, сменной работы: сто человек в смену — сто машин, а не триста.
- Закреплённый пул: за сотрудником закреплена его машина, и он всегда попадает на неё. Все его файлы и настройки на месте. Для тех, кому нужно персональное рабочее место с историей.
Для плавающих пулов данные пользователя выносят на сетевые папки и перемещаемые профили — тогда сотрудник получает свои документы на любой машине. Как это ложится на резервное копирование — отдельная тема: закреплённые машины бэкапят, плавающие пересоздаются из реплики, а сетевые папки и перемещаемые профили резервируют отдельно — пересоздание машины их не восстанавливает.
Размер пула и предзапуск
Пул описывается тремя числами: минимум машин, максимум и сколько держать заранее включёнными. Утром, когда все входят одновременно, предзапущенные машины отдаются мгновенно, а платформа в фоне поднимает следующие. В спокойное время лишние машины гасятся — и это уже работа балансировщика, который может отправить освободившиеся серверы в гибернацию.
Архитектурный предел пула — 10 000 машин; в синтетических тестах — около 5000 машин на 25 узлах. Реальная плотность зависит от профиля нагрузки и оборудования.
Оверкоммит на уровне реплики
Ресурсы рабочему столу задаются как гарантированный минимум и допустимый максимум процессора и памяти. В AirCloud оверкоммит — насколько плотно можно упаковать машины сверх физических ресурсов — задаётся на уровне реплики, то есть один раз для всего пула. Бухгалтерии — плотнее, разработчикам — с запасом. Горячее добавление ресурсов работает в пределах заданного максимума, если его поддерживает гостевая ОС.
Сеть и хранилище
Сетевые настройки машины пула наследуют от реплики: порт-группа, способ получения адреса. Для рабочих столов используются внешние хранилища — NFS, iSCSI или Fibre Channel; если хранилище стало недоступно, машины пула переходят в состояние «деградировано», и это видно в консоли до того, как позвонят пользователи. Размещение по узлам — вручную на конкретный сервер или автоматически по решению балансировщика.
Что видит сотрудник
Ничего из описанного. Он открывает клиент, видит иконку своего рабочего стола и через несколько секунд работает. Политики безопасности — что можно с USB, буфером обмена, печатью — приезжают вместе с машиной из настроек пула, подробнее в статье про защищённый рабочий стол.
Чем это отличается от массового развёртывания серверов
Реплики и пулы — инструмент для рабочих столов. Для серверных машин — тестовых стендов, филиальных серверов, окружений разработки — используется другой механизм: шаблоны, снапшоты и клонирование. О нём — в статье про массовое развёртывание виртуальных машин.
Хотите увидеть, как из одной реплики поднимается пул на сто рабочих мест и сколько это занимает на вашем оборудовании, — запросите демо.