Авторы: Евгения Шумахер, Илья Стечкин
Представляем вашему вниманию второй материал, посвященный программам валидации, которые предлагает 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). С точки зрения того где “живут” приложения: запущены на виртуальных машинах в облаке (in cloud applications) и дополняющие MOS (running alongside cloud). Приложения, запускаемые в облаке, бывают двух основных типов: те, которые приспособлены для работы в облаке (cloud native applications), и те, которые создавались без учета роста популярности облачных решений. Последние можно интегрировать в OpenStack-клауд, но для этого придется потрудиться.
Поговорим про in-cloud приложения. Они “живут” на виртуальных машинах, которые соединены в облако, которое управляется, например, с помощью OpenStack, на серверах в ЦОДе, который построил Джек. Или Вася. Или еще кто-нибудь.
Как поставить приложение на виртуальную машину? Сперва нужно ее (ВМ) создать, потом — установить на нее операционную систему, а следующим шагом — установить приложение. Сделать это можно “дедовским способом” — с помощью Glance image, который содержит в себе и операционную систему, и приложение. Казалось бы, при чем тут валидация? Так вот…
Предположим, что у вас есть приложение, которое вы хотели бы провалидировать. Мы предлагаем создать для него 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 услышит наши рекомендации и добавит возможность маркировать провалидированные приложения.
Представляем вашему вниманию второй материал, посвященный программам валидации, которые предлагает 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). С точки зрения того где “живут” приложения: запущены на виртуальных машинах в облаке (in cloud 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 услышит наши рекомендации и добавит возможность маркировать провалидированные приложения.
Поделиться с друзьями