Norėdami teikti IaaS (Virtual Data Center) paslaugas, mes naudojame komercinį orkestrantą (FCO). Šis sprendimas turi gana unikalią architektūrą, kuri išskiria jį iš plačiajai visuomenei žinomų Openstack ir CloudStack.
KVM, VmWare, Xen, Virtuozzo6/7, taip pat konteineriai iš to paties Virtuozzo palaikomi kaip skaičiavimo mazgų hipervizoriai. Palaikomos saugojimo parinktys apima vietinę, NFS, Ceph ir Virtuozzo saugyklą.
FCO palaiko kelių grupių kūrimą ir valdymą iš vienos sąsajos. Tai reiškia, kad galite valdyti „Virtuozzo“ ir „KVM + Ceph“ klasterį, perjungdami juos vienu pelės paspaudimu.
Iš esmės FCO yra visapusiškas sprendimas debesų paslaugų teikėjams, kuris, be orkestravimo, taip pat apima atsiskaitymą su visais nustatymais, mokėjimo papildiniais, sąskaitomis faktūromis, pranešimais, perpardavėjais, tarifais ir pan. Tačiau atsiskaitymo dalis nepajėgi aprėpti visų rusiškų niuansų, todėl atsisakėme jos naudojimo ir pasirinkome kitą sprendimą.
Labai džiaugiuosi lanksčia visų debesų išteklių teisių paskirstymo sistema: vaizdais, diskais, produktais, serveriais, ugniasienėmis – visa tai galima „dalytis“ ir suteikti teises tarp vartotojų ir net tarp skirtingų klientų vartotojų. Kiekvienas klientas savo debesyje gali sukurti kelis nepriklausomus duomenų centrus ir valdyti juos iš vieno valdymo skydelio.
Architektūriniu požiūriu FCO susideda iš kelių dalių, kurių kiekviena turi savo nepriklausomą kodą, o kai kurios turi savo duomenų bazę.
Skyline - administratorius ir vartotojo sąsaja
nuvarytas – verslo logika, atsiskaitymas, užduočių valdymas
Tigrinė lelija – paslaugų koordinatorius, vadovauja ir koordinuoja keitimąsi informacija tarp verslo logikos ir klasterių.
XVPManager – klasterio elementų valdymas: mazgai, saugykla, tinklas ir virtualios mašinos.
XPAgentas – mazguose įdiegtas agentas, skirtas sąveikauti su XVPManager
Į straipsnių seriją planuojame įtraukti išsamų pasakojimą apie kiekvieno komponento architektūrą, jei, žinoma, tema sukels susidomėjimą.
Pagrindinis FCO pranašumas kyla iš jo „dėžutės“ pobūdžio. Paprastumas ir minimalizmas yra jūsų paslaugoms. Valdymo mazgui Ubuntu yra skirta viena virtuali mašina, kurioje yra įdiegti visi reikalingi paketai. Visi nustatymai pateikiami konfigūracijos failuose kintamosios reikšmės pavidalu:
# 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"
…
Visa konfigūracija iš pradžių redaguojama šablonuose, tada paleidžiamas generatorius
#build-config, kuris sugeneruos vars failą ir nurodys paslaugoms iš naujo perskaityti konfigūraciją. Vartotojo sąsaja yra graži ir gali būti lengvai priskiriama prekės ženklui.
Kaip matote, sąsają sudaro valdikliai, kuriuos gali valdyti vartotojas. Jis gali lengvai pridėti / pašalinti valdiklius iš puslapio ir taip sukurti jam reikalingą prietaisų skydelį.
Nepaisant uždaro pobūdžio, FCO yra labai pritaikoma sistema. Jame yra daugybė nustatymų ir įvesties taškų, skirtų darbo eigai pakeisti:
- Palaikomi pasirinktiniai įskiepiai, pavyzdžiui, galite parašyti savo atsiskaitymo metodą arba savo išorinį šaltinį, kad suteiktumėte vartotojui
- Palaikomi pasirinktiniai tam tikrų įvykių aktyvikliai, pavyzdžiui, pirmosios virtualios mašinos įtraukimas į klientą, kai jis sukuriamas
- Palaikomi pasirinktiniai sąsajos valdikliai, pavyzdžiui, „YouTube“ vaizdo įrašo įterpimas tiesiai į vartotojo sąsają.
Visi pritaikymai yra parašyti FDL, kuris yra pagrįstas Lua. Jei pažįstate Lua, su FDL problemų nekils.
Štai vieno iš paprasčiausių mūsų naudojamų aktyviklių pavyzdys. Šis aktyviklis neleidžia vartotojams bendrinti savo vaizdų su kitais klientais. Tai darome, kad vienas vartotojas nesukurtų kenkėjiško vaizdo kitiems vartotojams.
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
Registro funkciją iškvies FCO branduolys. Jis grąžins funkcijos, kuri bus iškviesta, pavadinimą. Šios funkcijos parametras „p“ saugo skambučio kontekstą, o pirmą kartą jį iškvietus jis bus tuščias (nulis). Tai leis mums užregistruoti aktyviklį. TriggerType nurodome, kad aktyviklis iškviečiamas PRIEŠ paskelbimo operaciją ir turi įtakos tik vartotojams. Žinoma, leidžiame sistemos administratoriams viską skelbti. Skiltyje „TriggerOptions“ išsamiai aprašome operacijas, kurioms suaktyvinamas aktyviklis.
Ir pagrindinis dalykas yra grąžinimas {exitState = “CANCEL”}, todėl buvo sukurtas trigeris. Jei vartotojas bandys pasidalyti savo vaizdu valdymo skydelyje, jis grįš į gedimą.
FCO architektūroje bet koks objektas (diskas, serveris, vaizdas, tinklas, tinklo adapteris ir t. t.) yra vaizduojamas kaip išteklių objektas, turintis bendrus parametrus:
- Šaltinis UUID
- ištekliaus pavadinimas
- išteklių tipas
- Ištekliaus savininko UUID
- išteklių būsena (aktyvus, neaktyvus)
- išteklių metaduomenys
- išteklių raktai
- Produkto, kuriam priklauso išteklius, UUID
- išteklių VDC
Tai labai patogu dirbant naudojant API, kai visi resursai dirbami tuo pačiu principu. Produktus konfigūruoja tiekėjas ir užsako klientas. Kadangi mūsų atsiskaitymas yra šone, klientas gali laisvai užsisakyti bet kokį produktą iš skydelio. Jis bus paskaičiuotas vėliau atsiskaitant. Produktas gali būti IP adresas per valandą, papildomas GB disko per valandą arba tiesiog serveris.
Raktai gali būti naudojami tam tikriems ištekliams pažymėti, kad būtų pakeista darbo su jais logika. Pavyzdžiui, mes galime pažymėti tris fizinius mazgus naudodami svorio raktą, o kai kuriuos klientus pažymėti tuo pačiu raktu, tokiu būdu priskirdami šiuos mazgus šiems klientams asmeniškai. Šį mechanizmą naudojame VIP klientams, kuriems nepatinka kaimynai šalia jų VM. Pats funkcionalumas gali būti naudojamas daug plačiau.
Licencijavimo modelis apima mokėjimą už kiekvieną fizinio mazgo procesoriaus branduolį. Išlaidoms įtakos turi ir klasterių tipų skaičius. Pavyzdžiui, jei planuojate kartu naudoti KVM ir VMware, licencijos kaina padidės.
FCO yra visavertis produktas, jo funkcionalumas yra labai turtingas, todėl planuojame parengti kelis straipsnius iš karto su išsamiu tinklo dalies veikimo aprašymu.
Kelerius metus dirbę su šiuo orkestru, galime pažymėti kaip labai tinkamą. Deja, produktas nėra be trūkumų:
- turėjome optimizuoti duomenų bazę, nes didėjant duomenų kiekiui jose užklausos pradėjo lėtėti;
- po vienos avarijos atkūrimo mechanizmas neveikė dėl klaidos, o nelaimingų klientų automobilius teko atgauti naudojant savo scenarijų rinkinį;
- Mazgo neprieinamumo aptikimo mechanizmas yra įtrauktas į kodą ir negali būti pritaikytas. Tai reiškia, kad mes negalime sukurti savo politikos mazgo nepasiekiamumui nustatyti.
- medienos ruoša ne visada detalizuojama. Kartais, kai reikia nusileisti iki labai žemo lygio, kad suprastumėte konkrečią problemą, kai kuriems komponentams nepakanka šaltinio kodo, kad suprastumėte kodėl;
IŠ VISO: Apskritai įspūdžiai apie produktą yra geri. Nuolat palaikome ryšį su orkestrantų kūrėjais. Vaikinai nusiteikę konstruktyviai bendradarbiauti.
Nepaisant savo paprastumo, FCO turi platų funkcionalumą. Kituose straipsniuose planuojame gilintis į šias temas:
- tinklų kūrimas FCO
- teikiant tiesioginį atkūrimą ir FQP protokolą
- rašydami savo papildinius ir valdiklius
- jungiantis papildomas paslaugas, tokias kaip Load Balancer ir Acronis
- atsarginė kopija
- vieningas mazgų konfigūravimo ir konfigūravimo mechanizmas
- apdoroja virtualios mašinos metaduomenis
ZY Rašykite komentaruose, jei jus domina kiti aspektai. Sekite naujienas!
Šaltinis: www.habr.com