Цели?
Добавить поддержку libVirt как плагин к cloudify. Это позволит добавить поддержку низкоуровневых провайдеров виртуализации без удаленного доступа, таких как:
- KVM,
- QEMU,
- Xen
- Virtuozzo
- VMWare ESX
- LXC
- и BHyve.
Почему дешевая?
- Мы можем запустить на любом оборудовании, даже самом дешевом, кластер не нужен.
- Поддерживает что угодно где возможен запуск QEmu и можно запустить на arm/x86/powerPC/… или на чем угодно, что нужно в данный момент?
- Или LXC? Без эмуляции или виртуализации…
- Не нужна дорогая лицензия на VMWare vSphere/vCloud Director, только минимальная esx лицензия.
Изначальный план.
Создать для каждого libVirt объекта свой тип, например для pci устройства, интерфейса или домена.
А если немного подумать?
Не, в таком виде не взлетит. Только потратим время с подобным планом, так как нужно будет предоставить полную документации для всех типов в новом виде, и обосновать почему такое представление гораздо лучше стандартного. Поэтому новый план такой:
- Поддержка на уровне xml шаблона для верхнего уровня описаний объектов в libvirt, который будет распространяться вместе с плагином, пользователю нужно будет только предоставить значения для подстановки в шаблон.
- Реализовать простейший пример с несколькими виртуальными машинами объединенными в одной сети.
- Реализовать в каком-то виде получение адресов машин для подключения через ssh.
- Проверить идею с каким нибудь провайдером отличающимся от qemu.
Почему реализовывать именно ввиде плагина для cloudify?
Это наиболее знакомый мне продукт для оркестрации виртуальных окружений. Основные его достоинства возможность применения для управления и мониторинга любых систем начиная от систем IoT(internet of things) до крупных промышленных объектов. В базовой поставке есть примеры от управления классической инфраструктурой облаков до телекоммуникационной инфраструктуры, как SDN(software defined networks) когда работаем с виртуализированными сетями и соединениями до NS(Network Service, сервисы предоставленные инфраструктурой) и VNF(virtualized network functions, сервисы предоставленные через отдельные виртуальные машины запущенные на инфраструктуре), когда мы переходим на следующий уровень где каждый объект представляет собой уже сложный функционал, такой как интроспекция трафика, антивирусные продукты или управление высокоуровневый маршрутизацией и адресацией(MPLS/BGP или классический dhcp), когда нужно предоставить полный пакет сервисов для конечного клиента определенный по базовым шаблонам с возможностью широкого изменения в зависимости от потребностей клиента. Как пример подобных низкоуровневых протоколов может служить netconf или загрузка на устройство конфигурации через классический ssh доступ. Продукт представлен двумя версиями:
полностью свободной open source(apache2) версией которая содержит полностью работоспособную минимальную установку, позволяющую использовать весь функционал, предоставляет возможность управлять инфраструктурой и получать все метрики с инфраструктуры и предоставляющая RestApi для работы с управления и мониторинга.
И платная версия предоставляющая расширенные возможности управления и управления правами доступа и объединения нескольких серверов менеджмента в кластер, дополнительные плагины и дополнительные функции и web ui. Более подробно о различиях и предоставляемых дополнениях лучше уточнять на сайте.
Для управления не большими инфраструктурами достаточно и функционала доступного в open source версии, api достаточно простой и можно реализовать клиента который удовлетворяет всем потребностям необходимым для того чтобы попробовать и оценить технологию.
В классическом виде существует два вида установок:
- Распределённая когда существует выделенный сервер с которого выполняются все установки, и возможно выполнение одновременно нескольких независимых установок.
- И более простой вариант, когда используя полностью те же описания установки, можно запустить все с текущего хоста, так мы теряем возможность выполнять сразу несколько установок и использовать функционал вида масштабирования и восстановления, но позволяющий отследить все процессы происходящие в системе.
А теперь термины используемые в продукте:
- Blueprint - описание установки, в универсальном варианте не содержит никаких паролей и настроек конечных компонентов, только их типы и взаимосвязи. Используется yaml в формате Tosca, по-сути это список входных данных(inputs), результирующие данные(outputs), которые содержат информацию необходимую для обслуживания, например автоматически сгенерированные пароли и адреса элементов в инфраструктуре, и список объектов для которых указан их тип и зависимости. Для каждого типа через плагин реализовать необходимы инфраструктурных действия(создать машину или сеть, загрузить машины и выполнить скрипты инициализации cloudinit), или указать какой скрипт нужно выполнить(Bash/Python/PowerShell) на текущем хосте или удаленном. Реализованы плагины для всех коммерческих инфраструктур: Aws, OpenStack, vCenter, и плагины для запуска скриптов/команд на удаленном хосте.
- Deployment - полное описание того что мы хотим получить с заполненными пробелами в желаемой конфигурации, такими как пароли и при желании изначальное количество компонентов каждого типа.
- Execution - когда мы уже получили полные данные о состоянии нужной нам инфраструктуры, мы можем вызывать install execution для создания нужной нам инфраструктуры(до этого было только описание без реального исполнения). После завершения которой продукт начинает автоматически мониторить состояние инфраструктуры до момента когда мы вызовем uninstall, когда все будет откачено до первоначального состояния. Между циклами install/uninstall система автоматически если это описано в blueprint масштабирует и восстанавливает компоненты при сбоях. При желании все эти действия можно выполнить принудительно или вызывать вами описанные действия, например вы описали процесс перевода в режим пониженного использования ресурсов и хотите по какому-то внешнему событию выполнить его.
Как следствие нам нужно реализовать наш собственный плагин/дополнение которое будет описывать действия по созданию домена и сети в рамках libVirt. Можно конечно обойтись скриптами, но в таком случае нам нужно будет таскать с собой все скрипты преобразующие конфигурацию компонента в рамках cloudify в конфигурацию понятную libvirt, и в рамках плагина мы вынесем весь универсальный код в плагин, а вот действия специфичные под наши текущие нужды мы выполним через скрипты. И как результат в скрипты мы перенесен код загрузки исходных образов с интернета и клонирования образа под каждую виртуальную машину с генерацией уникального сетевого адреса. А в плагине оставим код для создания виртуальной машины(и сети) с образа, где мы используем результаты ранее указанных скриптов.
Так как мы не можем предугадать все желательные для пользователя шаблоны, например пользователь может желать другую архитектуру с другим набором устройств, также предоставим возможность в параметрах менять XML шаблон.
Теперь немного уточним почему идея когда мы описываем полную структуру компонента в blueprint может оказаться не удобна при использовании: для сложных и больших структур пользователю не нужно контролировать все элементы компонента. И когда мы преобразуем yaml blueprint ->python dictionary -> xml, пользователю нужно учитывать каждый шаг преобразования и ему будет удобнее сразу использовать XML, если он хочет использовать описание libvirt XML format, или ему удобнее указать минимальные параметры на которые он хочет влиять, подобные объёму памяти и списку подключенных сетей с дисками. Но совершенно не жаждет указывать тип системных часов или расположение в пространстве PCI устройств видеокарты.
Это все :-) Всем спасибо кто дочитал до сего момента
Ссылки: