Flexiant Cloud Orchestrator: со што доаѓа

За да обезбедиме услуги на IaaS (Виртуелен центар за податоци), ние Русоникс ние користиме комерцијален оркестратор Флексибилен облак оркестратор (FCO). Ова решение има прилично уникатна архитектура, што го разликува од Openstack и CloudStack, познати на пошироката јавност.

KVM, VmWare, Xen, Virtuozzo6/7, како и контејнери од истиот Virtuozzo се поддржани како хипервизори на пресметковни јазли. Поддржани опции за складирање вклучуваат локално, NFS, Ceph и Virtuozzo Storage.

FCO поддржува создавање и управување со повеќе кластери од еден интерфејс. Односно, можете да управувате со кластерот Virtuozzo и кластерот KVM + Ceph со префрлање помеѓу нив со кликнување на глувчето.

Во својата суштина, FCO е сеопфатно решение за облак-провајдерите, кое, покрај оркестрацијата, вклучува и наплата, со сите поставки, додатоци за плаќање, фактури, известувања, препродавачи, тарифи итн. Сепак, делот за наплата не е способен да ги покрие сите руски нијанси, па затоа ја напуштивме неговата употреба во корист на друго решение.

Многу сум задоволен од флексибилниот систем за дистрибуција на правата до сите ресурси на облак: слики, дискови, производи, сервери, заштитен ѕид - сето ова може да се „сподели“ и да се доделат права помеѓу корисниците, па дури и помеѓу корисници на различни клиенти. Секој клиент може да создаде неколку независни центри за податоци во својот облак и да управува со нив од една контролна табла.

Архитектонски, FCO се состои од неколку делови, од кои секој има свој независен код, а некои имаат своја база на податоци.

Skyline – администратор и кориснички интерфејс
Jade – деловна логика, наплата, управување со задачи
Тигарли – координатор на услуги, управува и ја координира размената на информации помеѓу деловната логика и кластерите.
XVPMменаџер – управување со елементи на кластерот: јазли, складирање, мрежа и виртуелни машини.
XVPA агент – агент инсталиран на јазли за интеракција со 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. Ако го знаете Луа, нема да има проблеми со ФДЛ.

Еве пример за еден од наједноставните предизвикувачи што ги користиме. Овој активирач не им дозволува на корисниците да споделуваат свои слики со други клиенти. Ова го правиме за да спречиме еден корисник да создаде злонамерна слика за други корисници.

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 ги детализираме операциите за кои активира активирањето.

И главната работа е враќањето {exitState = „CANCEL“}, поради што е развиен активирањето. Ќе врати неуспех кога корисникот ќе се обиде да ја сподели својата слика во контролната табла.

Во архитектурата FCO, секој објект (диск, сервер, слика, мрежа, мрежен адаптер, итн.) е претставен како ентитет на ресурси, кој има заеднички параметри:

• UUID на ресурси
• име на ресурс
• тип на ресурси
• UUID на сопственик на ресурси
• статус на ресурси (активен, неактивен)
• метаподатоци за ресурсите
• клучеви за ресурси
• UUID на производот што го поседува ресурсот
• ресурс VDC

Ова е многу погодно кога работите со користење на API, кога сите ресурси се работат според истиот принцип. Производите се конфигурирани од провајдерот и нарачани од клиентот. Бидејќи нашата наплата е на страна, клиентот може слободно да нарача кој било производ од панелот. Подоцна ќе се пресмета во наплатата. Производот може да биде IP адреса на час, дополнителен GB диск на час или само сервер.

Копчињата може да се користат за обележување на одредени ресурси за да се промени логиката на работа со нив. На пример, можеме да означиме три физички јазли со клучот Тежина и да означиме некои клиенти со истиот клуч, а со тоа да ги распределиме овие јазли лично на овие клиенти. Овој механизам го користиме за ВИП клиенти кои не ги сакаат соседите покрај нивните VM. Самата функционалност може да се користи многу пошироко.

Моделот за лиценцирање вклучува плаќање за секое процесорско јадро на физички јазол. На цената влијае и бројот на типови на кластери. Ако планирате да користите KVM и VMware заедно, на пример, цената на лиценцата ќе се зголеми.

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

Работејќи со овој оркестратор неколку години, можеме да го означиме како многу соодветен. За жал, производот не е без недостатоци:

• моравме да ја оптимизираме базата на податоци бидејќи барањата почнаа да се забавуваат како што се зголемуваше количината на податоци во нив;
• по една несреќа, механизмот за наплата не функционираше поради грешка, и моравме да ги вратиме автомобилите на несреќните клиенти користејќи наш сопствен сет на скрипти;
• Механизмот за откривање недостапност на јазолот е вметнат во кодот и не може да се прилагоди. Односно, не можеме да креираме сопствени политики за утврдување на недостапност на јазол.
• логирањето не е секогаш детално. Понекогаш, кога треба да се спуштите на многу ниско ниво за да разберете одреден проблем, немате доволно изворен код за некои компоненти да разберат зошто;

ВКУПНО: Во принцип, впечатоците од производот се добри. Во постојан контакт сме со развивачите на оркестратори. Момците се расположени за конструктивна соработка.

И покрај неговата едноставност, FCO има широка функционалност. Во идните написи планираме да навлеземе подлабоко во следните теми:

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

З.Ј. Напишете во коментар ако ве интересираат други аспекти. Останете со нас!

Извор: www.habr.com