Flexiant Cloud Orchestrator: с какво се яде

За да предоставим IaaS (Виртуален център за данни) услуги, ние Русоникс ние използваме търговски оркестратор Flexiant Cloud Orchestrator (FCO). Това решение има доста уникална архитектура, която го отличава от Openstack и CloudStack, познати на широката публика.

KVM, VmWare, Xen, Virtuozzo6/7, както и контейнери от същото Virtuozzo се поддържат като хипервайзори на изчислителни възли. Поддържаните опции за съхранение включват локално, NFS, Ceph и Virtuozzo Storage.

FCO поддържа създаването и управлението на множество клъстери от един интерфейс. Това означава, че можете да управлявате клъстер Virtuozzo и клъстер KVM + Ceph, като превключвате между тях с щракване на мишката.

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

Много съм доволен от гъвкавата система за разпределяне на права върху всички облачни ресурси: изображения, дискове, продукти, сървъри, защитни стени - всичко това може да се „споделя“ и да се предоставят права между потребители и дори между потребители на различни клиенти. Всеки клиент може да създаде няколко независими центъра за данни в своя облак и да ги управлява от един контролен панел.

Архитектурно FCO се състои от няколко части, всяка от които има свой независим код, а някои имат собствена база данни.

Силует – администраторски и потребителски интерфейс
нефрит – бизнес логика, таксуване, управление на задачи
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 файл и ще нареди на услугите да прочетат отново конфигурацията. Потребителският интерфейс е приятен и може лесно да се брандира.

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

Въпреки затворения си характер, 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

Функцията за регистриране ще бъде извикана от FCO ядрото. Той ще върне името на функцията, която ще бъде извикана. Параметърът „p“ на тази функция съхранява контекста на повикването и при първото извикване ще бъде празен (нула). Което ще ни позволи да регистрираме нашия тригер. В triggerType показваме, че тригерът се извиква ПРЕДИ операцията за публикуване и засяга само потребителите. Разбира се, позволяваме на системните администратори да публикуват всичко. В triggerOptions ние подробно описваме операциите, за които тригерът ще се задейства.

И основното нещо е return {exitState = “CANCEL”}, поради което е разработен тригерът. Той ще върне грешка, когато потребителят се опита да сподели изображението си в контролния панел.

В FCO архитектурата всеки обект (диск, сървър, изображение, мрежа, мрежов адаптер и т.н.) се представя като ресурсен обект, който има общи параметри:

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

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

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

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

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

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

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

ОБЩО: Като цяло впечатленията от продукта са добри. Ние сме в постоянен контакт с разработчиците на оркестратора. Момчетата са настроени за конструктивно сътрудничество.

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

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

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

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