Za zagotavljanje storitev IaaS (Virtual Data Center) smo uporabljamo komercialnega orkestratorja (FCO). Ta rešitev ima precej edinstveno arhitekturo, ki jo razlikuje od širši javnosti poznanih Openstack in CloudStack.
KVM, VmWare, Xen, Virtuozzo6/7, kot tudi vsebniki iz istega Virtuozza so podprti kot hipervizorji računalniških vozlišč. Podprte možnosti shranjevanja vključujejo lokalno shranjevanje, NFS, Ceph in Virtuozzo Storage.
FCO podpira ustvarjanje in upravljanje več gruč iz enega vmesnika. To pomeni, da lahko upravljate gručo Virtuozzo in gručo KVM + Ceph s preklapljanjem med njima s klikom miške.
FCO je v svojem bistvu celovita rešitev za ponudnike oblakov, ki poleg orkestracije vključuje tudi obračunavanje, z vsemi nastavitvami, plačilnimi vtičniki, računi, obvestili, prodajalci, tarifami itd. Vendar pa obračunski del ne more pokriti vseh ruskih odtenkov, zato smo njegovo uporabo opustili v korist druge rešitve.
Zelo sem zadovoljen s prilagodljivim sistemom razdeljevanja pravic za vse vire v oblaku: slike, diske, izdelke, strežnike, požarne zidove - vse to je mogoče "deliti" in podeliti pravice med uporabniki in celo med uporabniki različnih odjemalcev. Vsak odjemalec lahko ustvari več neodvisnih podatkovnih centrov v svojem oblaku in jih upravlja z ene nadzorne plošče.
Arhitekturno je FCO sestavljen iz več delov, od katerih ima vsak svojo samostojno kodo, nekateri pa svojo bazo podatkov.
Skyline – skrbniški in uporabniški vmesnik
Jade – poslovna logika, obračunavanje, vodenje opravil
tigerlily – koordinator storitve, vodi in koordinira izmenjavo informacij med poslovno logiko in grozdi.
XVPManager – upravljanje elementov gruče: vozlišča, shranjevanje, omrežje in virtualni stroji.
XVPAgent – agent, nameščen na vozliščih za interakcijo z XVPManager
Načrtujemo, da bomo podrobno zgodbo o arhitekturi posamezne komponente vključili v serijo člankov, če bo tema seveda vzbudila zanimanje.
Glavna prednost FCO izhaja iz njegove »škatlaste« narave. Enostavnost in minimalizem sta vam na voljo. Za nadzorno vozlišče je dodeljen en virtualni stroj na Ubuntuju, v katerega so nameščeni vsi potrebni paketi. Vse nastavitve so shranjene v konfiguracijskih datotekah v obliki vrednosti spremenljivke:
# 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"
…
Celotna konfiguracija se najprej uredi v predlogah, nato se zažene generator
#build-config, ki bo ustvaril datoteko vars in ukazal storitvam, da ponovno preberejo konfiguracijo. Uporabniški vmesnik je prijeten in ga je mogoče zlahka označiti.
Kot lahko vidite, je vmesnik sestavljen iz gradnikov, ki jih lahko upravlja uporabnik. Z lahkoto lahko doda/odstrani pripomočke s strani in tako ustvari nadzorno ploščo, ki jo potrebuje.
Kljub svoji zaprti naravi je FCO zelo prilagodljiv sistem. Ima ogromno nastavitev in vstopnih točk za spreminjanje poteka dela:
- Podprti so vtičniki po meri, na primer, lahko napišete svoj način obračunavanja ali svoj zunanji vir, da uporabniku zagotovite
- Podprti so sprožilci po meri za določene dogodke, na primer dodajanje prvega virtualnega stroja odjemalcu, ko je ustvarjen
- Podprti so pripomočki po meri v vmesniku, na primer vdelava YouTubovega videa neposredno v uporabniški vmesnik.
Vse prilagoditve so napisane v FDL, ki temelji na Lua. Če poznate Luo, s FDL ne bo težav.
Tukaj je primer enega najpreprostejših sprožilcev, ki jih uporabljamo. Ta sprožilec uporabnikom ne dovoljuje, da svoje slike delijo z drugimi odjemalci. To počnemo, da enemu uporabniku preprečimo ustvarjanje zlonamerne slike za druge uporabnike.
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
Funkcijo register bo poklicalo jedro FCO. Vrnil bo ime funkcije, ki jo želite poklicati. Parameter »p« te funkcije shrani kontekst klica in ob prvem klicu bo prazen (nič). Kar nam bo omogočilo registracijo našega sprožilca. V triggerType označujemo, da je sprožilec priklican PRED operacijo objave in vpliva samo na uporabnike. Seveda sistemskim skrbnikom omogočamo objavo vsega. V triggerOptions podrobno opisujemo operacije, za katere se sproži sprožilec.
In glavna stvar je return {exitState = “CANCEL”}, zato je bil sprožilec razvit. Ko bo uporabnik poskušal deliti svojo sliko na nadzorni plošči, bo vrnil napako.
V arhitekturi FCO je vsak predmet (disk, strežnik, slika, omrežje, omrežni adapter itd.) predstavljen kot entiteta vira, ki ima skupne parametre:
- UUID vira
- ime vira
- vrsto vira
- UUID lastnika vira
- status vira (aktivno, neaktivno)
- metapodatki vira
- ključi virov
- UUID izdelka, ki je lastnik vira
- vir VDC
To je zelo priročno pri delu z API-jem, ko vsi viri delujejo po istem principu. Izdelke konfigurira ponudnik in naroči naročnik. Ker je naše obračunavanje ob strani, lahko naročnik poljubno naroči kateri koli izdelek iz panela. Obračuna se naknadno pri obračunu. Produkt je lahko IP naslov na uro, dodaten GB diska na uro ali samo strežnik.
S ključi je mogoče označiti določene vire in spremeniti logiko dela z njimi. Na primer, lahko označimo tri fizična vozlišča s tipko Weight in označimo nekaj odjemalcev z istim ključem, s čimer ta vozlišča osebno dodelimo tem odjemalcem. Ta mehanizem uporabljamo za VIP stranke, ki ne marajo sosedov poleg svojih VM. Sama funkcionalnost se lahko uporablja veliko širše.
Licenčni model vključuje plačilo za vsako procesorsko jedro fizičnega vozlišča. Na ceno vpliva tudi število vrst grozdov. Če nameravate na primer uporabljati KVM in VMware skupaj, se bodo stroški licence povečali.
FCO je polnopravni izdelek, njegova funkcionalnost je zelo bogata, zato nameravamo pripraviti več člankov hkrati s podrobnim opisom delovanja omrežnega dela.
Po večletnem sodelovanju s tem orkestrom ga lahko označimo kot zelo primernega. Žal izdelek ni brez pomanjkljivosti:
- bazo smo morali optimizirati, ker so se poizvedbe začele upočasnjevati, ko se je količina podatkov v njih povečevala;
- po eni nesreči obnovitveni mehanizem ni deloval zaradi hrošča in morali smo obnoviti avtomobile nesrečnih strank z lastnim naborom skriptov;
- Mehanizem za zaznavanje nerazpoložljivosti vozlišča je vgrajen v kodo in ga ni mogoče prilagoditi. To pomeni, da ne moremo ustvariti lastnih pravilnikov za ugotavljanje nerazpoložljivosti vozlišča.
- beleženje ni vedno podrobno. Včasih, ko se morate spustiti na zelo nizko raven, da bi razumeli določen problem, nimate dovolj izvorne kode za nekatere komponente, da bi razumeli, zakaj;
SKUPAJ: Na splošno so vtisi o izdelku dobri. Smo v stalnem stiku z razvijalci orkestra. Fantje so nagnjeni k konstruktivnemu sodelovanju.
Kljub svoji preprostosti ima FCO široko funkcionalnost. V prihodnjih člankih se nameravamo poglobiti v naslednje teme:
- mreženje pri FCO
- zagotavljanje obnovitve v živo in protokola FQP
- pisanje lastnih vtičnikov in pripomočkov
- povezovanje dodatnih storitev, kot sta Load Balancer in Acronis
- rezerva
- poenoten mehanizem za konfiguriranje in konfiguriranje vozlišč
- obdelava metapodatkov virtualnega stroja
ZY Zapišite v komentarje, če vas zanimajo drugi vidiki. Ostani na vezi!
Vir: www.habr.com