Для прадастаўлення паслугі IaaS (Віртуальны дата-цэнтр) мы ў выкарыстоўваем камерцыйны аркестратар (FCO). Гэтае рашэнне мае досыць унікальную архітэктуру, што адрознівае яго ад вядомых шырокай публіцы Openstack і CloudStack.
У якасці гіпервізараў compute нод падтрымліваюцца KVM, VmWare, Xen, Virtuozzo6/7, а таксама кантэйнеры ад таго ж Virtuozzo. З падтрымоўваных сховішчаў - лакальнае, NFS, Ceph і Virtuozzo Storage.
FCO падтрымлівае стварэнне некалькіх кластараў і кіраванне імі з аднаго інтэрфейсу. Гэта значыць, можна кіраваць кластарам Virtuozzo і кластарам KVM + Ceph перамыкаючыся паміж імі па кліку мышы.
Па сутнасці сваёй FCO - гэта комплекснае рашэнне для клаўд-правайдэраў, якое акрамя аркестрацыі ўключае ў сябе яшчэ і білінг, з усімі наладамі, аплатнымі убудовамі, рахункамі, апавяшчэннямі, рэсэлерамі, тарыфамі і гэтак далей. Аднак, білінг частка не здольная пакрыць усе расейскія нюансы, таму мы адмовіліся ад яе выкарыстання на карысць іншага рашэння.
Вельмі радуе гнуткая сістэма размеркавання правоў на ўсе рэсурсы аблокі: вобразы, дыскі, прадукты, сервера, файрвалы - усё гэта можна "шарыць" і выдаваць правы паміж карыстальнікамі, і нават паміж карыстальнікамі розных кліентаў. Кожны кліент можа ствараць у сваім воблаку некалькі незалежных дата-цэнтраў і кіраваць імі з адзінай панэлі кіравання.
Архітэктурна, FCO складаецца з некалькіх частак, кожная з якіх мае свой незалежны код, а некаторыя і сваю ўласную БД.
Гарызонт - адмінскі і карыстацкі інтэрфейс
Нефрыт - бізнес логіка, білінг, кіраванне задачамі
Тыгерлілі - Каардынатар сэрвісу, кіруе і каардынуе абмен інфармацыі паміж бізнес логікай і кластарамі.
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
- бекап
- уніфікаваны механізм канфігуравання і налады нод
- апрацоўка метададзеных віртуальных машын
З.Ы. Пішыце ў каментарах, калі цікавыя і іншыя аспекты. Stay tuned!
Крыніца: habr.com