Для предоставления услуги IaaS (Виртуальный дата-центр) мы в Rusonyx используем коммерческий оркестратор Flexiant Cloud Orchestrator (FCO). Это решение имеет достаточно уникальную архитектуру, что отличает его от известных широкой публике Openstack и CloudStack.
В качестве гипервизоров compute нод поддерживаются KVM, VmWare, Xen, Virtuozzo6/7, а также контейнеры от того же Virtuozzo. Из поддерживаемых хранилищ – локальное, NFS, Ceph и Virtuozzo Storage.
FCO поддерживает создание нескольких кластеров и управление ими из одного интерфейса. То есть, можно управлять кластером Virtuozzo и кластером KVM + Ceph переключаясь между ними по клику мыши.
По сути своей FCO – это комплексное решение для клауд-провайдеров, которое помимо оркестрации включает в себя еще и билинг, со всеми настройками, платежными плагинами, счетами, уведомлениями, реселлерами, тарифами и так далее. Однако, биллинг часть не способна покрыть все российские нюансы, поэтому мы отказались от ее использования в пользу другого решения.
Очень радует гибкая система распределения прав на все ресурсы облака: образы, диски, продукты, сервера, файрволы – все это можно «шарить» и выдавать права между пользователями, и даже между пользователями разных клиентов. Каждый клиент может создавать в своем облаке несколько независимых дата-центров и управлять ими из единой панели управления.
Архитектурно, FCO состоит из нескольких частей, каждая из которых имеет свой независимый код, а некоторые и свою собственную БД.
Skyline – админский и пользовательский интерфейс
Jade – бизнес логика, билинг, управление задачами
Tigerlily – координатор сервиса, управляет и координирует обмен информации между бизнес логикой и кластерами.
XVPManager – управление элементами кластера: нодами, хранилищем, сетью и виртуальными машинами.
XVPAgent – агент, устанавливаемый на ноды для взаимодействия с XVPManager
Подробный рассказ об архитектуре каждого компонента мы планируем уместить в цикл статей, если, конечно, тема вызовет интерес.
Главное преимущество FCO вытекает из его «коробочности». К вашим услугам простота и минималистичность. Для управляющей ноды выделяется одна виртуальная машина на Ubuntu, в которую устанавливаются все необходимые пакеты. Все настройки выносятся в конфигурационные файлы в виде переменная-значение:
# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…
Вся конфигурация правится изначально в шаблонах, потом запускается генератор
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Как видно, интерфейс состоит из виджетов, управление которыми доступно пользователю. Он может легко добавлять/удалять виджеты со страницы, тем самым формируя нужный ему dashboard.
Несмотря на свою закрытость, FCO – очень кастомизируемая система. Она имеет огромное количество настроек и входных точек для изменения workflow:
- Поддерживаются кастомные плагины, например можно написать свой билинг-метод или собственный внешний ресурс для предоставления пользователю
- Поддерживаются кастомные триггеры на определенные события, например добавление первой виртуальной машины клиенту при его создании
- Поддерживаются кастомные виджеты в интерфейсе, например встроить видео с youtube прямо в интерфейс пользователя.
Вся кастомизация пишется на языке FDL, который основан Lua. Если вы знаете Lua, с FDL никаких проблем не будет.
Вот пример одного из самых простых триггеров, которые мы используем. Данный триггер не разрешает пользователям делиться их собственными образами с другими клиентами. Мы делаем это для того, чтобы один пользователь не смог сформировать вредоносный образ для других пользователей.
function register()
return {"pre_user_api_publish"}
end
function pre_user_api_publish(p)
if(p==nil) then
return{
ref = "cancelPublishImage",
name = "Cancel publishing",
description = "Cancel all user’s images publishing",
triggerType = "PRE_USER_API_CALL",
triggerOptions = {"publishResource", "publishImage"},
api = "TRIGGER",
version = 1,
}
end
-- Turn publishing off
return {exitState = "CANCEL"}
end
Функция register будет вызвана ядром FCO. Она вернет имя функции, которую надо будет вызвать. Параметр “p” данной функции хранит контест вызова, и при первом вызове он будет пустым (nil). Что позволит нам зарегистрировать наш триггер. В triggerType мы показываем, что триггер вызывается ДО операции опубликования, и распространяется только на пользователей. Администраторам системы, само собой, мы разрешаем публиковать все. В triggerOptions мы детализируем операции, для которых триггер будет срабатывать.
И главное – return {exitState = “CANCEL”}, то для чего триггер и разрабатывался. Он вернет неуспех, когда пользователь попытается поделиться своим образом в панели управления.
В архитектуре FCO – любой объект (диск, сервер, образ, сеть, сетевой адаптер и др.) представлены в виде сущности Resource, у которого есть общие параметры:
- UUID ресурса
- имя ресурса
- тип ресурса
- UUID владельца ресурса
- статус ресурса (активен, неактивен)
- метаданные ресурса
- ключи ресурса
- UUID продукта, которому принадлежит ресурс
- VDC ресурса
Это очень удобно при работе по API, когда со всеми ресурсами работа ведется по одному принципу. Продукты настраиваются провайдером, а заказывает их клиент. Поскольку у нас билинг находится в стороне, то клиент может свободно-бесплатно заказывать любой продукт из панели. Посчитается он позже в билинге. Продуктом может быть – ip адрес в час, дополнительный Гб диска в час или просто сервер.
Ключами можно пометить определенные ресурсы для изменения логики работы с ними. Например, мы можем пометить три физических ноды ключом Weight, и пометить некоторых клиентов этим же ключом, тем самым выделив эти ноды персонально данным клиентам. Такой механизм мы используем для VIP-клиентов, которые не любят соседей рядом со своими VM. Сам же функционал можно применять куда шире.
Модель лицензирования подразумевает оплату за каждое ядро процессора физической ноды. Также на стоимость влияет количество типов кластеров. Если планируется использовать вместе, например, KVM и VMware, то стоимость лицензии возрастет.
FCO является полноценным продуктом, функционал его очень богат, поэтому мы планируем подготовить сразу несколько статей с детальным описанием функционирования сетевой части.
Проработав с данным оркестратором несколько лет можем отметить его, как очень годный. Увы, продукт не лишен изъянов:
- нам приходилось оптимизировать БД, поскольку запросы начинали тормозить при нарастании количества данных в них;
- после одной аварии из-за бага не отработал recovery механизм, и пришлось поднимать машины несчастных клиентов собственным набором скриптов;
- механизм детекта недоступности ноды зашит в код и не поддается кастомизации. То есть мы не можем создавать собственные политики определения недоступности ноды.
- логирование не всегда подробное. Иногда, когда нужно спуститься на очень низкий уровень для разбора определенной проблемы, не хватает исходного кода некоторых компонентов для понимания причин;
ИТОГО: в целом, впечатления от продукта хорошие. Мы находимся в постоянном контакте с разработчиками оркестратора. Парни расположены к конструктивному сотрудничеству.
Несмотря на свою простоту FCO, обладает широкой функциональностью. В будущих статьях мы планируем углубиться в следующие темы:
- организации сети в FCO
- обеспечение live-recovery и протокола FQP
- написание собственных плагинов и виджетов
- подключение дополнительных сервисов, таких как Load Balancer и Acronis
- бекап
- унифицированный механизм конфигурирования и настройки нод
- обработка метаданных виртуальных машин
P.S. Пишите в комментариях, если интересны и другие аспекты. Stay tuned!
