Создание Linux- и Windows-образов для частных облаков OpenStack

В статье предлагается новый способ построения образов Linux® и Windows® для частных облаков, созданных с помощью облачной операционной системы OpenStack. Нынешние методы создания образов для сред OpenStack являются весьма обременительными и трудоемкими. Авторы статьи предлагают интерактивную, основанную на самообслуживании методику, которая упрощает построение образов как операторам частных облаков, так и их конечным пользователям

Облачная операционная система OpenStack с открытым исходным кодом - это функционально насыщенная, обладающая высокой степенью масштабируемости платформа для всех типов облачных вычислений. На OpenStack базируются несколько публичных облачных сервисов, а также реализации частных облаков во многих организациях. Однако платформе OpenStack по-прежнему не хватает многих функций для частных облаков, особенно для сред, ориентированных на разработку и тестирование. К примеру, построение образов является весьма непростым процессом. В данной статье предлагается новый, более совершенный метод создания образов для частных облаков OpenStack. Мы проверили этот новый метод на платформе QEMU/KVM, однако теоретически он также применим для других гипервизорных платформ.

Прежде чем рассматривать новый метод, коротко напомним, как в настоящее время создаются образы в OpenStack.

Существующие способы создания образов в среде OpenStack

Процессы создания Linux-образов или Windows-образов в OpenStack состоят из нескольких трудоемких шагов.

Linux-образы

В официальном руководстве OpenStack Virtual Machine Image Guide детально описано семь требований, которые должны быть удовлетворены, чтобы Linux-образ был полностью функционален в облаке OpenStack (некоторые из этих требований можно выполнить посредством установки пакета cloud-init). Руководство Image Guide рекомендует пользователям перед созданием собственных образов прочитать соответствующий длинный раздел этого документа. Эта мера призвана гарантировать поддержку создаваемыми образами необходимых пользователям функций OpenStack.

Linux-образы можно создавать в ручном режиме или с помощь соответствующих инструментов (VMBuilder, Oz или imagefactory) для конкретных дистрибутивов. Вне зависимости от используемого метода, чтобы приступить к созданию собственного Linux-образа, вам потребуются следующие элементы.

• Установочные CD/DVD-диски операционной системы (ОС) или файлы соответствующих ISO-образов.
• Linux-машина с активированным гипервизором KVM/QEMU. Утилиты графического интерфейса (GUI) virt-manager/virt-viewer (могут потребоваться для некоторых дистрибутивов).
• cloud-init или написанные самостоятельно эквивалентные скрипты для конкретной ОС.
• Такие утилиты, как guestfish, guestmount, или такие инструменты, как virt-* для внесения изменений в образы.

Если все необходимые условия выполнены, можно приступать к созданию собственных Linux-образов согласно следующим обобщенным шагам.

1. Создайте виртуальную машину и установите ОС с помощью утилиты virt-manager или virt-install.
2. Сконфигурируйте ОС в соответствии со своими потребностями (например, установив необходимое программное обеспечение связующего уровня) и в соответствии с требованиями OpenStack, установив cloud-init или эквивалентные скрипты.
3. Измените созданный образ с помощью guestfish, guestmount или virt-* в соответствии с требованиями OpenStack.
4. Загрузите новый образ в сервис образов OpenStack и проверьте загруженный образ.

Windows-образы

Веб-сайт OpenStack до сих пор не содержит подробного примера создания Windows-образов. Чтобы создаваемые вами Windows-образы были полностью функциональными, необходимо как минимум выполнить следующие шаги.

• Установите драйвер VirtIO
• Активируйте протокол RDP (Remote Desktop Protocol) и сконфигурируйте его таким образом, чтобы его не блокировал брандмауэр.
• Сконфигурируйте протокол ICMP (Internet Control Message Protocol) таким образом, чтобы его не блокировал брандмауэр.
• Разбейте диск на разделы и измените размеры root-раздела при начальной загрузке (с помощью cloudbase-init).
• Обработайте пользовательские данные и другие метаданные (с помощью cloudbase-init).
• Активируйте Windows-инструмент Sysprep (System Preparation) для настройки гостевой ОС.

Для большинства вариантов использования частного облака последние два шага в этом списке не обязательны. Кроме того, разбиение диска на разделы и изменение размеров root-раздела при начальной загрузке можно осуществить вручную или с помощью скрипта. Чтобы Windows-образы могли работать в облаке OpenStack, необходимо установить драйвер VirtIO. Кроме того, необходимо установить пакет драйверов VirtIO-Win.

После удовлетворения вышеописанных минимальных требований процесс создания Windows-образа выглядит следующим образом.

1. Создайте виртуальную машину с IDE-диском и с сетевым адаптером AMD PCnet32 или Realtek rt8139.
2. Установите ОС.
3. Сконфигурируйте ОС в соответствии со своими потребностями (например, установив необходимое программное обеспечение связующего уровня) и в соответствии с требованиями OpenStack, установив cloudbase-init или эквивалентные скрипты.
4. Завершите работу виртуальной машины
5. Добавьте небольшой диск VirtIO и сетевой адаптер VirtIO.
6. Запустите виртуальную машину и установите драйверы VirtIO для диска VirtIO и для сетевого адаптера VirtIO.
7. Перезапустите виртуальную машину, проверьте ОС, а затем завершите работу виртуальной машины.
8. Загрузите новый образ в сервис образов OpenStack и проверьте этот образ.

В качестве альтернативного варианта выполните следующие шаги.

1. Создайте виртуальную машину со следующими компонентами
   • Диск VirtIO
   • Сетевой адаптер PCnet32 или rt8139
   • Дополнительный накопитель CD-ROM для драйвера диска VirtIO (для версий Windows начиная с Windows Vista и Windows Server 2008 и выше) или дополнительный накопитель гибких дисков для драйвера диска VirtIO (для версий Windows вплоть до Windows Server 2003 R2).
2. Установите ОС с требуемым драйвером диска VirtIO.
3. Сконфигурируйте ОС в соответствии со своими потребностями (например, установив необходимое программное обеспечение связующего уровня) и в соответствии с требованиями OpenStack, установив cloudbase-init или исполнив эквивалентные скрипты.
4. Завершите работу виртуальной машины
5. Добавьте сетевой адаптер VirtIO.
6. Запустите виртуальную машину и установите драйверы VirtIO для сетевого адаптера VirtIO.
7. Перезапустите виртуальную машину, проверьте ОС, а затем завершите работу виртуальной машины.
8. Загрузите новый образ в сервис образов OpenStack и проверьте этот образ.

Недостатки

Несмотря на некоторые преимущества (такие как широкая доступность инструментов с открытым исходным кодом для создания Linux-образов), нынешние методы создания образов для OpenStack нельзя назвать простыми. Создание Windows-образов может показаться несколько проще, чем создание Linux-образов, поскольку нет необходимости изменять образы с помощью таких инструментов, как guestfish. Однако на данный момент не существует никаких автоматических инструментов для создания полнофункциональных Windows-образов для OpenStack, поэтому конечным пользователям или операторам приходится создавать эти образы в ручном режиме. Если тестировщикам или разработчикам из группы глобализации необходимы Windows-образы, эти образы должны быть различными для каждой языковой версии, - а количество используемых языков может исчисляться десятками. Для облачных операторов задача подготовки всех Windows-образов со всеми требуемыми языковыми версиями представляется невыполнимой.

Создание как Linux-, так и Windows-образов для частного облака является трудоемкой работой для конечных пользователей - и даже для опытных облачных операторов. Более того, организация может не располагать достаточными ресурсами для создания образов конечными пользователями - например, дополнительным гипервизором KVM/QEMU, который требуется для создания Linux-образов. В описываемом сценарии создание всех образов, которые требуются конечным пользователям, превратилось бы в сложнейшую задачу для облачных операторов.

И, наконец, новые образы необходимо загружать в сервис образов OpenStack. Этот процесс может занимать много времени в зависимости от производительности сети между источником образа и сервисом образов платформы OpenStack. По этой же причине неоднократная верификация новых образов также может занимать много времени.

Предлагаемый новый метод построения образов для OpenStack

Если бы платформа OpenStack позволяла пользователям создавать образы в диалоговом режиме, то им было бы гораздо легче создавать такие образы, которые бы полностью удовлетворяли их потребности. Мы предлагаем новый метод создания образов, при котором пользователи создают новые образы в диалоговом режиме с помощью информационной панели OpenStack, предоставляемой облачный сервисом. При наличии такой возможности конечные пользователи не нуждаются в дополнительном гипервизоре и не обязаны сами загружать образы в сервис образов платформы OpenStack. Пользователю достаточно иметь файлы ISO-образов CD/DVD-дисков для установки ОС.

Концептуальное представление

В концептуальном смысле идеальный процесс создания нового образа для платформы OpenStack применительно к конечным пользователям выглядит следующим образом.

1. Загрузите файлы ISO-образов CD/DVD-дисков для установки ОС в сервис образов платформы OpenStack.
2. Из загруженного ISO-образа запустите новый экземпляр.
3. Установите ОС при посредстве консоли VNC/SPICE (Virtual Networking Computing/Simple Protocol for Independent Computing Environments) в информационной панели OpenStack.
4. Произведите конфигурирование в соответствии со своими потребностями и установите нужные пакеты программного обеспечения.
5. Внесите изменения согласно требованиям OpenStack в ручном режиме или запустите скрипты, предоставленные оператором сервиса - например, скрипты для установки cloud-init, для получения открытого SSH-ключа, для задействования SSHD remote login/RDP и т. д.
6. Сделайте снимок экземпляра.
7. В случае необходимости выполните команду glance image-update над этим снимком для преобразования этого снимка в образ и добавления других метаданных.

Предварительные условия

Чтобы гарантировать успешное создание образов с помощью нового метода, необходимо соблюдение нескольких условий.

• Наличие функционирующей информационной панели (или веб-интерфейса), доступных всем конечным пользователям.
• Наличие VNC-прокси или SPICE-прокси, работающего надлежащим образом и доступного всем конечным пользователям.
• Наличие репозитария cloud-init или эквивалентных скриптовых инструментов, доступных всем конечным пользователям.
• Наличие ISO-образа драйвера VirtIO-win, доступного в сервисе образов OpenStack всем конечным пользователям.

Теперь мы продемонстрируем осуществимость нового метода.

Анализ осуществимости

Два самых важных аспекта нашего нового метода - как осуществляется поддержка ISO-образа и как осуществляется сборка блочного устройства для экземпляра, запущенного из ISO-образа.

Нынешняя поддержка ISO-образов

Платформа OpenStack поддерживает ISO-образы. Запуск экземпляра из ISO-образа также поддерживается. Однако установка гостевой ОС из ISO-образа в экземпляр, запущенный из ISO-образа, поддерживается недостаточно полно. Чтобы установка оказалась успешной, должны быть соблюдены определенные строгие условия.

• В гостевых ОС в ISO-образах по умолчанию должны быть активированы драйверы устройств VirtIO.
• Для временного диска (ephemeral disk) необходимо задать flavor (шаблон виртуального оборудования в терминологии OpenStack), размер которого отвечает потребностям гостевой ОС.
• Информационная панель и novncproxy-сервер OpenStack должны функционировать надлежащим образом.

При соблюдении всех этих условий гостевую ОС из ISO-образа можно успешно установить на временном диске экземпляра, запущенного из этого ISO-образа. И, конечно, вы сможете работать под управлением гостевой ОС, как и с другими экземплярами. Однако нынешний механизм OpenStack для снимка экземпляра не позволяет успешно преобразовать экземпляр в снимок экземпляра или в образ экземпляра. Снимок экземпляра будет включать только root-диск экземпляра. Другие блочные устройства (block device), в том числе временные диски и тома, будут проигнорированы.

Нынешний порядок операций для сборки блочных устройств экземпляра

На рис. 1 показан порядок операций для сборки блочных устройств в среде OpenStack Nova в случае начальной загрузки KVM/QEMU-экземпляра из ISO-образа.

Нынешний порядок операций для сборки блочных устройств

Пояснения по потоку работ на рис. 1.

1. Nova извлекает ISO-образ из Glance и настраивает его как корневой диск экземпляра виртуальной машины с устройством (device) типа CD-ROM и с шиной (bus) типа IDE.
2. Nova создает временный диск и настраивает его как второй диск экземпляра виртуальной машины с устройством (device) типа диск и с шиной типа VirtIO. Однако этот шаг выполняется только в том случае, если в шаблоне (flavor) экземпляра задан размер временного диска.
3. Пользователь устанавливает гостевую ОС с root-диска (CD-ROM экземпляра) на временный диск (второй диск экземпляра) и осуществляет ее пошаговое конфигурирование с помощью VNC-консоли.
4. Пользователь создает моментальный снимок этого экземпляра виртуальной машины, а Nova сохраняет этот снимок в сервисе Glance.

На первый взгляд вышеописанный порядок операций позволяет создать новый образ виртуальной машины "с нуля". Однако получаемый в этом случае образ является копией исходного ISO-образа. Это объясняется тем, что в снимок включается только root-диск (первое блочное устройство экземпляра, фактически это CD-ROM экземпляра, если он был запущен из ISO-образа), а временный диск игнорируется. Таким образом, на нынешней платформе OpenStack вы сможете запустить экземпляры из ISO-образа и установить ОС в ISO-образе для запущенных экземпляров со сконфигурированным временным диском, однако вы не сможете сделать снимок временного диска с установленной ОС. Чтобы преодолеть эту проблему, необходимо скорректировать порядок операций по сборке блочных устройств экземпляра.

Предлагаемый новый порядок операций для сборки блочных устройств экземпляра

Вы можете изменить сборку блочного устройства таким образом, чтобы создавать временный диск, который имеет надлежащие размеры и гарантированно настроен как root-диск для экземпляров, запущенных из ISO-образа. После таких изменений root-диск, включенный в снимок экземпляра, будет временным диском с установленной ОС - а это именно то, что нам нужно.

На рис. 2 показан порядок операций для сборки блочных устройств в случае начальной загрузки экземпляра из ISO-образа после внесений изменений в драйвер libvirt (объясняются в разделе Подтверждения концепции данной статьи).

Измененный порядок операций для сборки блочных устройств

Измененный порядок операций по сборке блочного устройства при запуске экземпляра из ISO-образа выглядит следующим образом.

1. Nova создает файл диска виртуальной машины и настраивает его как корневой диск экземпляра виртуальной машины. По умолчанию шина устройства настраивается как VirtIO.
2. Nova извлекает ISO-образ гостевой ОС из Glance и настраивает его как второе дисковое устройство (CD-ROM).
3. Nova извлекает ISO-образ драйвера VirtIO из Glance и настраивает его как третье дисковое устройство (CD-ROM).
4. Пользователь устанавливает гостевую ОС со второго дискового устройства (первое CD-ROM-устройство) и конфигурирует ее нужным образом.
5. Если драйвер VirtIO по умолчанию не включен в гостевую ОС, то третье дисковое устройство (второе CD-ROM-устройство) используется для установки драйвера VirtIO для гостевой ОС.
6. Пользователь создает моментальный снимок этого экземпляра, а Nova сохраняет этот снимок в сервисе Glance.

Как было указано в разделе Нынешняя поддержка ISO-образов, снимок экземпляра включает только корневой диск экземпляра, вне зависимости от типа этого корневого диска. В измененном потоке работ корневой диск - это новый дисковый файл, созданный Nova; он содержит гостевую ОС, установленную с CD-ROM-устройства с образом ОС (второй диск экземпляра).

Когда мы и планировали, результатом является снимок нового экземпляра, установленного из ISO-образа ОС - вместо копии исходного ISO-образа.

Подтверждение концепции

Чтобы убедиться в том, что новый метод создания образов работает как планировалось, мы внесли определенные модификации в программный код Nova - главным образом, в драйвер libvirt. Обратитесь в раздел Загрузка для получения соответствующего программного кода. В частности, мы изменили python-модули libvirt/driver.py и libvirt/blockinfo.py. Наши комментарии в этих файлах указывают на измененные нами методы класса и методы экземпляра.

Для подтверждения нашей концепции мы использовали следующую среду.

Аппаратные средства:

• Стоечный сервер форм-фактора 2U
• Два четырехъядерных процессора Xeon
• Оперативная память 12 x 8 ГБ
• 4 SAS-диска по 900 ГБ в конфигурации RAID10
• 4 сетевых адаптера 1 Гбит/с Ethernet

Программное обеспечение.

• Red Hat Enterprise Linux 6 update 4 в качестве гипервизора
• RDO, релиз Grizzly

Мы протестировали измененный код в одноузловой среде RDO Grizzly, в многоузловой среде установки RDO Grizzly и в среде на основе официального релиза OpenStack Grizzly.

Тестирование и результаты

В этом разделе описывается простой процесс тестирования, а также некоторые примеры тестирования, которые мы выполнили с измененным модулем Nova с целью создания образов виртуальной машины с помощью нашего нового метода.

Процесс тестирования

Процесс тестирования состоит из следующих шагов.

1. Создайте ISO-образ ОС для Glance.
2. Проверьте существующий шаблон (flavor) на предмет того, что корневой диск имеет необходимые вам размеры. При необходимости создайте новый шаблон.
3. Запустите экземпляр из этого ISO-образа ОС с подходящим шаблоном.
4. После запуска экземпляра выполните отображаемые на экране установочные шаги для установки ОС из VNC-консоли информационной панели.
5. Установите нужные вам приложения и сконфигурируйте ОС согласно требованиям OpenStack, например, установите cloud-init или эквивалентные скрипты для задействования сервиса SSHD remote login/RDP и т. д.
6. Создайте снимок вновь установленного экземпляра.
7. Обновите информацию о снимке, изменив тип образа на image, для чего запустите glance image-update, или воспользуйтесь информационной панелью, если она предоставляет такую функциональность.

Результаты тестирования

После внесения изменений в драйвер libvirt блочные устройства экземпляров, запущенных из ISO-образа, выглядят, как показано в листинге 1.

Блочные устройства экземпляров, запущенных из ISO-образа

В таблице 1 показаны результаты тестирования для нескольких распространенных операционных систем.

Результаты тестирования

Заключение

Наш новый метод создания образов обладает следующими преимуществами:

• Простота создания новых образов для OpenStack.
• Простота верификации создаваемых новых образов.
• Доступность механизма самообслуживания всем конечным пользователям.

... и недостатками:

• Образы могут не поддерживать полную функциональность - особенно в том, что касается разбиения диска на разделы и изменения размеров корневого раздела при начальной загрузке.
• Не поддерживаются версии Windows до чем Windows Server 2003 R2 включительно (однако их поддержку можно реализовать ценой существенного усложнения последовательности операций сборки посредством добавления драйверов накопителей на гибких дисках для старых версий Windows).
• Не поддерживаются старые версии Linux, не имеющие поддержки драйвера устройств VirtIO.

В настоящее время в большинстве публичных облачных сервисов типа IaaS на базе OpenStack экземплярам предоставляется корневой диск фиксированного размера в базовом образе и - при посредстве сервиса томов - дополнительное дисковое пространство для экземпляров. В частных облаках большая часть требований к экземплярам направлена на такие аспекты, как установленное программное обеспечение связующего уровня, версии/редакции гостевых ОС, flavor-шаблоны для экземпляров и т.п. Как и в публичных облачных сервисах, требования к размеру дискового хранилища могут быть удовлетворены посредством предоставления корневого диска фиксированного среднего размера и достаточного количества томов. По указанной причине возможность разбиения дисков на разделы и изменения размера корневого раздела при начальной загрузке не являются насущной необходимостью для большинства частных облаков.

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

Загрузка