Flexiant Cloud Orchestrator: какво представлява

За предоставяне на 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"
…

Цялата конфигурация се редактira първоначално в шаблоните, след което се стартира генератор
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.

Както се вижда, интерфейсът се състои от джаджи, управлението на които е достъпно за потребителя. Той може лесно да добавя/премахва джаджи от страницата, като по този начин оформя желания от него dashboard.

Въпреки своята затвореност, FCO е много персонализируема система. Тя има огромно количество настройки и входни точки за промяна на работния процес:

1. Поддържат се персонализирани приставки, например можете да напишете свой метод за плащане или собствен външен ресурс за предоставяне на услуги на потребителя
2. Поддържат се персонализирани тригери за определени събития, например добавяне на първа виртуална машина на клиента при неговото създаване
3. Поддържат се персонализирани уиджети в интерфейса, например интегриране на видео от 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 – всеки обект (диск, сървър, образ, мрежа, мрежов адаптер и др.) се представя под формата на ресурс, който има общи параметри:

• UUID на ресурса
• име на ресурса
• тип на ресурса
• UUID на собственика на ресурса
• статус на ресурса (активен, неактивен)
• метаданни на ресурса
• ключове на ресурса
• UUID на продукта, на който принадлежи ресурсът
• VDC на ресурса

Това е много удобно при работа с API, когато с всички ресурси работите по един и същ принцип. Продуктите се конфигурират от доставчика, а клиентът ги поръчва. Тъй като нашата система за фактуриране е отделна, клиентът може лесно и безплатно да поръчва всеки продукт от панела. Той ще бъде фактуриран по-късно. Продуктът може да бъде – IP адрес на час, допълнителен GB дисково пространство на час или просто сървър.

С ключове можете да обозначите определени ресурси за промяна на логиката на работа с тях. Например, можем да обозначим три физически ноди с ключа Weight и да обозначим някои клиенти с този същ ключ, така че да изтъкнем тези ноди специално за тези клиенти. Този механизъм използваме за VIP клиенти, които не обичат съседите до своите VM. Самата функция може да се прилага и в по-широк контекст.

Моделът на лицензиране предвижда заплащане за всяко ядро на процесора на физическата нода. Също така, цената се влияе от броя на типовете клъстери. Ако е планирано да се използват заедно, например, KVM и VMware, тогава цената на лиценза ще се увеличи.

FCO е напълно функционален продукт с много богати функции, затова планираме да подготвим няколко статии с подробно описание на функционирането на мрежовата част.

След работа с този оркестратор в продължение на няколко години можем да го оценим като много добър. За съжаление, продуктът не е без недостатъци:

• бяхме принудени да оптимизираме базата данни, тъй като заявките започваха да забавят при увеличаване на количеството данни в тях;
• след една авария поради бъг, механизма за възстановяване не сработи, и се наложи да активираме машините на ощетените клиенти с наш набор от скриптове;
• механизмът за детектиране на недостъпност на нода е вграден в кода и не подлежи на кастомизация. Тоест, не можем да създаваме собствени политики за определяне на недостъпността на нода.
• логването не винаги е подробно. Понякога, когато е нужно да задълбочим в много ниско ниво за разглеждане на определен проблем, липсват изходния код на някои компоненти за разбиране на причините;

ИТОГ: като цяло, впечатленията от продукта са положителни. Ние сме в постоянен контакт с разработчиците на оркестратора. Момчетата са склонни към конструктивно сътрудничество.

Въпреки своята простота, FCO притежава широка функционалност. В бъдещите статии планираме да задълбочим в следните теми:

• организация на мрежата в FCO
• осигуряване на live-recovery и протокол FQP
• позволяване на собствени плъгини и уиджети
• свързване на допълнителни услуги, като Load Balancer и Acronis
• бекъп
• унифициран механизъм за конфигуриране и настройка на нодове
• обработка на метаданни на виртуални машини

З.Ы. Пишете в коментарите, ако ви интересуват и други аспекти. Останете на линия!

Източник: habr.com