Mirantis Unlocked validation program. Частина 2: Hard and Soft

Автори: Євгенія Шумахер, Ілля Стечкин

Представляємо вашій увазі другий матеріал, присвячений програмам валідації, які пропонує Mirantis своїм партнерам. минулому пості ми розповідали про те, кому і для чого потрібно валідувати fuel-плагіни. Сьогодні поговоримо про валідації додатків і «заліза».
«Залізна» логіка


Ця історія, скоріше, про Linux. Тому що головне завдання Hardware compatibility program перевірити, що Linux бачить конкретне обладнання і може з ним працювати. Здавалося б, все більш-менш просто: якщо Linux бачить, то і OpenStack бачить. Проте...

Припустимо, у нас є модель сервера з певними мережевими картами і ми перевіряємо, що MOS (читай Ubuntu, тому що це хостова ОС для хмарної інфраструктури в нашому дистрибутиві) бачить це «залізо» і ці мережеві (networking) карти. Є прийнятий в індустрії термін HCL (Hardware Compatibility List) — список сумісності програмного забезпечення і обладнання з операційною системою. Чому ж ми не можемо просто взяти «зовнішній» список, наприклад, від Canonical? Справа в тому, що Fuel — основний інструмент розгортання MOS (Mirantis OpenStack), використовує механізм bootstrap-images.

Отже, Fuel майстер-нода знаходить всі сервери, які до неї підключені і починає процес провижининга. Він полягає в тому, що на ноду ставиться бутстрап-імідж, який може бути заданий оператором Fuel. Так-так, ви можете встановити будь користувальницький пакет з репозиторію за замовчуванням або підключеного зовнішнього сховища, використовуючи скрипт fuel-bootstrap builder. Як це працює, можна дізнатися здесь (не бійтеся, англійська за посиланням є, звичайно, але коду там багато більше, ніж базікання).

І тільки через кілька кроків після цього відбувається установка хостової операційної системи. Таким чином, перевірки «класичної версії операційної системи буває недостатньо, тому що властивості бутстрап-іміджу можуть від неї часом відрізнятися. Можлива, повертаючись до початку статті, ситуація, при якій Ubuntu „бачить“ мережеву карту, а бутстрап — ні.

Безумовно, Mirantis не виробляє операційну систему. Але в силу технологічних особливостей розгортання MOS, ми змушені створювати подобу HCL, щоб убезпечити наших користувачів від неприємних сюрпризів.

Але оскільки Mirantis OpenStack сьогодні один з найпопулярніших дистрибутивів OpenStack, очевидно, вендори, які виробляють „залізо“, зацікавлені в попаданні в наш список — це їх спосіб відрекомендуватися користувачам. Процедура валідації для цих компаній досить проста і докладно описана на нашому сайті. А користувачам можемо порекомендувати познайомитися зі списком „перевірених постачальників“ обладнання та перевірити, чи потрапляють до нього виробники „заліза“, наявного у вашому розпорядженні.

Звичайно, в 99% випадків Ubuntu HCL працює для MOS, тим більше, що там міститься більш докладна інформація, ніж в MOS HCL.

Тому ми завжди рекомендуємо спочатку заглянути в наш HCL, але обов'язково перевірити і в Ubuntu HCL теж. Все-таки Linux-вендор знає краще.

Програми: „захмарні“ і хмарні


Передмова
Почнемо з опису того, які бувають „додатка“ з точки зору MOS (Mirantis OpenStack). З точки зору того де „живуть“ додатка: запущені на віртуальних машинах в хмарі (cloud in applications) і доповнюючі MOS (running alongside cloud). Додатки, що запускаються в хмарі, бувають двох основних типів: ті, які пристосовані для роботи в хмарі (cloud native applications), і ті, які створювалися без урахування зростання популярності хмарних рішень. Останні можна інтегрувати в OpenStack-клауд, але для цього доведеться потрудитися.

Поговоримо про in-cloud програми. Вони „живуть“ на віртуальних машинах, які з'єднані в хмару, яка управляється, наприклад, з допомогою OpenStack, на серверах в Цоді, який побудував Джек. Або Вася. Або ще хто-небудь.

Як поставити на додаток віртуальну машину? Спершу треба її (ВМ) створити, потім — встановити на неї операційну систему, а наступним кроком — встановити додаток. Зробити це можна „дідівським способом“ — з допомогою Glance image, який містить в собі операційну систему, і додаток. Здавалося б, при чому тут валідація? Так ось…

Валідація in-cloud додатків
Припустимо, що у вас є додаток, яке ви хотіли б провалидировать. Ми пропонуємо створити для нього Glance image, а потім виконати вправу, описане вище, використовуючи інфраструктуру, керовану MOS (Mirantis OpenStack — до речі, тільки що вийшла нова, дев'ята версія дистрибутива). Ми виступаємо провайдером інфраструктури. Ви надаєте Glance image і розгортаєте його на ВМ під управлінням MOS. Завдання процесу валідації — підтвердити той факт, що ваша програма коректно працює з MOS.

Але ж для деяких додатків знадобиться не одна виртуалка, а кілька запущених сервісів. Як автоматизувати що на рівні додатків? На цьому рівні стека на допомогу прийдуть Murano-образи і Heat-шаблони.

Програми-сусіди
А як же інші додатки, ті які „сусіди“?

Розберемо приклад додатків, які живуть поруч з OpenStack. Наприклад, Talligent(біллінг). Для нас це теж додаток, так як воно не впроваджується у OpenStack на рівні інфраструктури (через OpenStack драйвери), але взаємодіє з кластером на рівні API (за зовнішнім протоколами). Talligent збирає статистику по використанню хмари: він, наприклад, звертається до Nova, щоб отримати інформацію про кількість віртуальних машин, створених у певному тенанте конкретним користувачем.

Такого роду програми прямого відношення до процесу application validation не мають, але ми з ними працюємо все одно. У них є 2 способи інтеграції з OpenStack взагалі і з MOS зокрема. Перший спосіб — можна поставити додаток в ручному режимі: розгорнути кластер під управлінням MOS, розгорнути Talligent і попросити інженерів налаштувати взаимодейтсвие між ними. Другий спосіб — це fuel-плагін. У другому випадку — див. наші пости про розробку fuel-плагінів і їх валідацію.

Межі можливостей
Якщо процес валідації fuel-плагінів або опенстек-драйверів ми описали докладно, виступаючи з позиції експертів, які точно знають як інтегруватися в OpenStack інфраструктуру, то у випадку з додатками ми поки не володіємо такою експертизою. Валідація додатків передбачає чіткий розподіл ролей: ми надаємо інфраструктуру, а виробник (розробник додатка) тестує своє дітище на цій інфраструктурі. Тому на першому етапі валідації ми багато спілкуємося з розробником/вендором додатків, обговорюємо, що потрібно для того, щоб показати, що програма дійсно стабільно працює.

Візьмемо модний приклад — NFV (Network Function Virtualization).Суть технології в тому, щоб замінити телеком „залізо“ додатком, запущеним на віртуальній машині. Є таке рішення — Virtual SBC ( Session Border Controller — контролера сесій — дуже затребувана телекомунікаційними компаніями розробка Metaswitch. Її можна запускати на віртуальній машині, керованою в тому числі і OpenStack. Ми (Мирантис) не можемо сказати, як перевірити якість роботи цього додатка (адже ми не експерти), але ми можемо зробити так, щоб OpenStack працював, як потрібно цього додатка.
Вендор VNF додатки пред'являє певні вимоги до інфраструктури. Ми задовольняємо ці вимоги, налаштовуючи необхідну для тестування програми інфраструктуру. Далі партнер встановлює додаток і випробовує його згідно з написаним ним Тест Планом. Ми ж у підсумку дивимося на результати тестів, що надаються вендором.

В плані надання NVFI (Network Function Infrastructure) можливі такі сценарії: інфраструктуру для цієї програми можна налаштувати вручну або автоматично (наприклад, включити опцію Huge Pages). Може бути і так, що вручну налаштувати інфраструктуру можна (пошаманив з конфігураційними файлами OpenStack), і додаток буде працювати коректно, а автоматично настроїти конфігурацію хмари так як вимагає того VNF не можна, тобто конкретна версія Fuel (інструмент розгортання OpenStack і подальшого управління клаудом) може не підтримувати установку параметрів, необхідних даними додатком. Такі деталі завжди описуються в документі, який є важливим артефактом процесу валідації — runbook.

Основна ідея сертифікації — ми говоримо вендору: „Покажи нам цифри і тест-кейси… Постав свою програму на нашу інфраструктуру і доведи, що воно насправді працює“.

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

Висновок: зовнішні ознаки валідації
На жаль, на сьогоднішній день в Community Application Catalog не ставиться ніяких відміток про сертифікації. Але ми плануємо створення власного каталогу провалидированных додатків. А прямо зараз цю інформацію можна знайти у нас на сайті в партнерському каталозі. Втім, ми переконані в тому, що відмітка про сертифікацію під певний дистрибутив підвищить рівень задоволення користувачів (customer satisfaction) і дозволить уникнути конфліктів очікувань і реальності. А тому сподіваємося, що команда Community App Catalog почує наші рекомендації і додасть можливість маркувати провалидированные програми.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.