Самый практичный вопрос от тех, кто сам ведёт инфраструктуру, звучит как арифметика: «Семь команд, у каждой по десять стендов, в каждом по три машины — это автоматизируемо?» За этими цифрами — больше двухсот виртуальных машин, которые нужно разворачивать заново к каждому релизу, тесту или учебному семестру. Вручную это «прямо большая беда». Разберём, как решается развёртывание виртуальных машин в промышленных масштабах.
Почему ручное развёртывание не масштабируется
Создать одну машину вручную — дело пяти минут: выбрать образ, задать ресурсы, установить ОС, настроить сеть. Но когда таких машин двести, а пересоздавать их нужно к каждому прогону, ручной подход превращается в многочасовую рутину с неизбежными ошибками: где-то не та сеть, где-то забыли пакет, где-то разъехались версии.
Задача одна и та же для очень разных организаций: развернуть десятки одинаковых машин под тестовое окружение, под филиалы, под временную проектную команду, под учебный полигон. Решение тоже одно — массовая автоматическая раскатка из шаблонов.
Шаблоны: один эталон — сотни копий
Шаблон виртуальной машины — это эталон: одна машина, настроенная до конца — ОС, пакеты, конфигурация сети, нужный софт, — из которой потом штампуются идентичные копии. Те, кто работал в зарубежных экосистемах, знают этот подход по скриптовым инструментам массового управления.
В AirCloud логика простая: один раз готовится эталонный стенд, например «сервер приложений с нужным стеком», затем из него разворачивается нужное количество одинаковых машин; время раскатки зависит от размера диска, типа клона и хранилища. Семь команд по десять стендов — раскатываются из шаблона, а не собираются руками.
Что умеет платформа при клонировании:
- полный клон машины с независимой копией диска;
- импорт образов из других гипервизоров с автоматической конвертацией — RAW, VMDK, QCOW2, VHD, VHDX и другие форматы, — что упрощает перенос уже готовых эталонов;
- автозаполнение параметров: платформа знает настройки кластера и сама подставляет сеть, проверяет корректность адресов — меньше ручного ввода, меньше ошибок;
- REST API с документацией — раскатку можно встроить в собственные скрипты и конвейеры.
Мгновенное клонирование из работающей машины без остановки находится в разработке — сейчас клонирование делается из выключенной машины или снапшота.
Снапшоты: ломать без последствий
Вторая половина задачи — откат. В тестовой и учебной среде машины существуют для того, чтобы их ломали: инженер должен иметь право снести систему, перенастроить сеть «не туда», уронить сервис — и понять, что произошло. Но к следующему прогону стенд должен быть как новый.
Это решают снапшоты — мгновенные снимки состояния машины. Сломал — откатил в исходную точку: обычно это быстро, а снапшот с памятью восстанавливается дольше, в зависимости от её объёма. В AirCloud снапшоты бывают классические и с памятью, их можно выстраивать в ветки: базовое состояние, от него — «после установки обновления», от него — «после миграции базы», и между любыми точками можно прыгать.
> Мне очень хочется отдать решение в руки инженеров и посмотреть, как они умудрятся сломать так, что снапшот не откатится.
>
> — команда разработки AirCloud
Для бизнеса это те же тестовые окружения: прогнал рискованное обновление, не понравилось — откатил весь стенд снапшотом. Снапшот при этом не заменяет резервную копию: он лежит рядом с машиной и погибнет вместе с хранилищем.
Точные лимиты: чтобы стенды не подрались за процессор
Массовое развёртывание хорошо работает в связке с тонким управлением ресурсами. Когда из шаблона разворачивается двести машин на скромном железе, важно, чтобы они не подрались за процессор. В AirCloud каждой машине задаётся гарантированный минимум и допустимый максимум процессора и памяти, а под капотом ресурсы нарезаются на уровне ядра вплоть до доли гигагерца — по процессору и памяти один стенд не положит остальные, пока сумма гарантий не превышает ресурсы узла; дисковую и сетевую нагрузку ограничивают отдельно.
Размещение по узлам можно доверить балансировщику: он сам расставит новые машины по кластеру в режиме производительности или плотности.
Сколько ест сама платформа
Для стендов на скромном железе важен и вопрос накладных расходов: сколько ресурсов съедает слой управления, ещё до первой полезной машины. В AirCloud центральный сервер управления в номинале потребляет порядка полутора виртуальных процессоров и около двух гигабайт памяти — это номинал для типовой инсталляции; для кластеров на десятки узлов ресурсы управляющей машины уточняем при проектировании. Управляющая машина помещается даже на одном сервере, не отбирая ресурсы у стендов.
Учебный полигон как частный случай
Для университетов и учебных центров всё описанное складывается в готовый полигон: эталонные шаблоны для быстрой раскатки, снапшоты для безопасных экспериментов, точные лимиты для плотной упаковки. Студенту полезно своими руками уронить узел и увидеть, как машины перезапускаются на других узлах, — отказоустойчивость нельзя понять по слайдам.
А рабочие столы?
Шаблоны и клоны — инструмент для серверных машин. Для виртуальных рабочих столов сотрудников используется другой механизм — золотые реплики и пулы с генерализацией, связанными клонами и плавающим назначением. О нём — в статье про золотую реплику и пулы VDI.
Коротко
Ручное развёртывание виртуальных машин не масштабируется: сотни машин нужно раскатывать из шаблонов автоматически. Шаблоны дают быстрый массовый деплой одинаковых стендов, снапшоты — быстрый откат после поломок, точные лимиты — плотную и безопасную упаковку. Как все эти компоненты собираются в единую платформу — в разборе системы виртуализации. Хотите развернуть тестовое окружение или учебный полигон — напишите нам, поможем с шаблонами.