1. Існуючі способи створення образів в середовищі OpenStack
2. Linux-образи
3. Windows-образи
4. недоліки
5. Пропонований новий метод побудови образів для OpenStack
6. концептуальне уявлення
7. попередні умови
8. аналіз здійсненності
9. Нинішня підтримка ISO-образів
10. Нинішній порядок операцій для складання блокових пристроїв примірника
11. Нинішній порядок операцій для складання блокових пристроїв
12. Пропонований новий порядок операцій для складання блокових пристроїв примірника
13. Змінений порядок операцій для складання блокових пристроїв
14. підтвердження концепції
15. Тестування і результати
16. процес тестування
17. результати тестування
18. Блокові пристрої примірників, запущених з ISO-образу
19. результати тестування
20. Висновок
21. Завантаження

У статті пропонується новий спосіб побудови образів 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-образу

<Disk type = 'file' device = 'disk'> <driver name = 'qemu' type = 'qcow2' cache = 'none' /> <source file = '/ var / lib / nova / instances / 290124e3-a267- 4223-bd69-661fac2035eb / disk.newos '/> <target dev =' vda 'bus =' virtio '/> <address type =' pci 'domain =' 0x0000 'bus =' 0x00 'slot =' 0x04 'function = '0x0' /> </ disk> <disk type = 'file' device = 'cdrom'> <driver name = 'qemu' type = 'qcow2' cache = 'none' /> <source file = '/ var / lib / nova / instances / 290124e3-a267-4223-bd69-661fac2035eb / disk '/> <target dev =' hda 'bus =' ide '/> <readonly /> <address type =' drive 'controller =' 0 'bus = '0' target = "0" unit = "0" /> </ disk> <disk type = 'file' device = 'cdrom'> <driver name = 'qemu' type = 'qcow2' cache = 'none' /> <source file = '/ var / lib / nova / instances / 290124e3-a267-4223-bd69-661fac2035eb / disk.virtio' /> <target dev = 'hdb' bus = 'ide' /> <readonly /> <address type = 'drive' controller = '0' bus = '0' target = "0" unit = '1' /> </ disk>

У таблиці 1 показані результати тестування для декількох поширених операційних систем.

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

Гостьова ОС Результати Windows XP Невдало * Windows Server 2003 R2 Невдало * Windows 7 Успішно Windows 8 Успішно Windows Server 2012 Успішно RHEL5.9 Успішно RHEL6.4 Успішно SLES10 sp4 Успішно SLES11 sp3 Успішно * Примітка. Тестування з використанням Windows XP і Windows Server 2003 R2 закінчилося невдачею, оскільки для драйверів VirtIO не було знайдено накопичувача для гнучких дисків. Основна причина полягає в тому, що ранні версії Windows аж до Windows Server 2003 R2 підтримують завантаження додаткових дискових драйверів тільки з гнучкого диска. У цій статті ми додали для драйвера VirtIO лише додатковий накопичувач CD-ROM (див. Мал. 2 ), Проте для старих версій Windows в порядок операцій по збірці блокових пристроїв варто було б додати додатковий драйвер для приводу гнучких дисків.

Висновок

Наш новий метод створення образів має наступні переваги:

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

... і недоліками:

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

В даний час в більшості публічних хмарних сервісів типу IaaS на базі OpenStack екземплярів надається кореневої диск фіксованого розміру в базовому образі і - за допомогою сервісу томів - додатковий дисковий простір для примірників. У приватних хмарах велика частина вимог до примірників спрямована на такі аспекти, як встановлене програмне забезпечення сполучного рівня, версії / редакції гостьових ОС, flavor-шаблони для примірників і т.п. Як і в публічних хмарних сервісах, вимоги до розміру дискового сховища можуть бути задоволені за допомогою надання кореневого диска фіксованого середнього розміру і достатньої кількості томів. Із зазначеної причини можливість розбиття дисків на розділи і зміни розміру кореневого розділу при початковому завантаженні не є нагальною потребою для більшості приватних хмар.

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

Завантаження

описание

имя

Розмір

Приклад програмного коду

39 КБ