Por provizi IaaS (Virtuala Datuma Centro) servoj, ni ni uzas komercan orkestranton (FCO). Ĉi tiu solvo havas sufiĉe unikan arkitekturon, kiu distingas ĝin de Openstack kaj CloudStack, konataj de la ĝenerala publiko.
KVM, VmWare, Xen, Virtuozzo6/7, same kiel ujoj de la sama Virtuozzo estas subtenataj kiel komputaj nodaj hiperviziiloj. Subtenataj stokaj opcioj inkluzivas lokan, NFS, Ceph kaj Virtuozzo Storage.
FCO subtenas la kreadon kaj administradon de multoblaj aretoj de ununura interfaco. Tio estas, vi povas administri Virtuozzo-grupon kaj KVM + Ceph-grupon ŝanĝante inter ili per musklako.
En ĝia kerno, FCO estas ampleksa solvo por nubaj provizantoj, kiu, krom orkestrado, ankaŭ inkluzivas fakturadon, kun ĉiuj agordoj, pagaj kromaĵoj, fakturoj, sciigoj, revendantoj, tarifoj ktp. Tamen la faktura parto ne kapablas kovri ĉiujn rusajn nuancojn, do ni forlasis ĝian uzon favore al alia solvo.
Mi estas tre kontenta pri la fleksebla sistemo por distribuado de rajtoj al ĉiuj nubaj rimedoj: bildoj, diskoj, produktoj, serviloj, fajroŝirmiloj - ĉio ĉi povas esti "dividita" kaj donita rajtojn inter uzantoj, kaj eĉ inter uzantoj de malsamaj klientoj. Ĉiu kliento povas krei plurajn sendependajn datumcentrojn en sia nubo kaj administri ilin de ununura kontrolpanelo.
Arkitekture, FCO konsistas el pluraj partoj, ĉiu el kiuj havas sian propran sendependan kodon, kaj kelkaj havas sian propran datumbazon.
Ĉielo - administranto kaj uzantinterfaco
jado – komerca logiko, fakturado, tasko-administrado
Tigrolilio – serva kunordiganto, administras kaj kunordigas la interŝanĝon de informoj inter komerca logiko kaj aretoj.
XVPMManager - administrado de cluster-elementoj: nodoj, stokado, reto kaj virtualaj maŝinoj.
XVPAgent - agento instalita sur nodoj por interagi kun XVPManager
Ni planas inkluzivi detalan rakonton pri la arkitekturo de ĉiu komponanto en serion de artikoloj, se, kompreneble, la temo vekas intereson.
La ĉefa avantaĝo de FCO devenas de ĝia "boksita" naturo. Simpleco kaj minimumismo estas je via servo. Por la kontrolnodo, unu virtuala maŝino en Ubuntu estas asignita, en kiu ĉiuj necesaj pakaĵoj estas instalitaj. Ĉiuj agordoj estas metitaj en agordajn dosierojn en formo de variablo-valora:
# 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"
…
La tuta agordo estas komence redaktita en ŝablonoj, poste la generatoro estas lanĉita
#build-config kiu generos vars-dosieron kaj ordonos al la servoj relegi la agordon. La uzantinterfaco estas bela kaj povas esti facile markita.
Kiel vi povas vidi, la interfaco konsistas el fenestraĵoj, kiuj povas esti kontrolitaj de la uzanto. Li povas facile aldoni/forigi widgets de la paĝo, tiel kreante la panelo kiun li bezonas.
Malgraŭ ĝia fermita naturo, FCO estas tre agordebla sistemo. Ĝi havas grandegan nombron da agordoj kaj enirpunktoj por ŝanĝi la laborfluon:
- Propraj kromprogramoj estas subtenataj, ekzemple, vi povas skribi vian propran fakturan metodon aŭ vian propran eksteran rimedon por provizi la uzanton.
- Propraj ellasiloj por certaj eventoj estas subtenataj, ekzemple, aldonante la unuan virtualan maŝinon al kliento kiam ĝi estas kreita
- Propraj fenestraĵoj en la interfaco estas subtenataj, ekzemple, enkonstruante YouTube-videon rekte en la uzantinterfacon.
Ĉiu personigo estas skribita en FDL, kiu baziĝas sur Lua. Se vi konas Lua, ne estos problemoj kun FDL.
Jen ekzemplo de unu el la plej simplaj ellasiloj, kiujn ni uzas. Ĉi tiu ellasilo ne permesas al uzantoj dividi siajn proprajn bildojn kun aliaj klientoj. Ni faras tion por malhelpi unu uzanton krei malican bildon por aliaj uzantoj.
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
La registra funkcio estos vokita de la FCO-kerno. Ĝi resendos la nomon de la vokota funkcio. La parametro "p" de ĉi tiu funkcio konservas la alvokan kuntekston, kaj la unuan fojon kiam ĝi estas vokita, ĝi estos malplena (nil). Kiu permesos al ni registri nian ellasilon. En triggerType ni indikas, ke la ellasilo estas alvokita ANTAŬ la publikiga operacio, kaj nur influas uzantojn. Kompreneble, ni permesas al sistemaj administrantoj publikigi ĉion. En triggerOptions ni detaligas la operaciojn por kiuj la ellasilo pafos.
Kaj la ĉefa afero estas reveni {exitState = "CANCEL"}, tial la ellasilo estis evoluigita. Ĝi revenos malsukceson kiam la uzanto provos dividi sian bildon en la kontrolpanelo.
En la FCO-arkitekturo, ajna objekto (disko, servilo, bildo, reto, retadaptilo, ktp.) estas reprezentita kiel Rimeda unuo, kiu havas oftajn parametrojn:
- Rimedo UUID
- nomo de rimedo
- rimeda tipo
- UUID de posedanto de rimedo
- stato de rimedo (aktiva, neaktiva)
- metadatenoj de rimedoj
- rimedoŝlosiloj
- UUID de la produkto kiu posedas la rimedon
- rimedo VDC
Ĉi tio estas tre oportuna kiam oni laboras per API, kiam ĉiuj rimedoj estas funkciantaj laŭ la sama principo. Produktoj estas agorditaj de la provizanto kaj menditaj de la kliento. Ĉar nia fakturado estas flanke, la kliento povas libere mendi ajnan produkton de la panelo. Ĝi estos kalkulita poste en fakturado. La produkto povas esti IP-adreso por horo, plia GB da disko je horo, aŭ nur servilo.
Ŝlosiloj povas esti uzataj por marki iujn rimedojn por ŝanĝi la logikon labori kun ili. Ekzemple, ni povas marki tri fizikajn nodojn per la Pezo-ŝlosilo, kaj marki kelkajn klientojn per la sama ŝlosilo, tiel asignante ĉi tiujn nodojn persone al ĉi tiuj klientoj. Ni uzas ĉi tiun mekanismon por VIP-klientoj, kiuj ne ŝatas najbarojn apud siaj VM-oj. La funkcio mem povas esti uzata multe pli vaste.
La licencadmodelo implikas pagi por ĉiu procesorkerno de fizika nodo. La kosto ankaŭ estas trafita de la nombro da arettipoj. Se vi planas uzi KVM kaj VMware kune, ekzemple, la kosto de la permesilo pliiĝos.
FCO estas plentaŭga produkto, ĝia funkcieco estas tre riĉa, do ni planas prepari plurajn artikolojn samtempe kun detala priskribo de la funkciado de la reta parto.
Laborinte kun ĉi tiu orkestranto dum pluraj jaroj, ni povas marki ĝin kiel tre taŭga. Ve, la produkto ne estas sen difektoj:
- ni devis optimumigi la datumbazon ĉar konsultoj komencis malrapidiĝi dum la kvanto da datumoj en ili pliiĝis;
- post unu akcidento, la reakira mekanismo ne funkciis pro cimo, kaj ni devis reakiri la aŭtojn de malfeliĉaj klientoj uzante nian propran aron de skriptoj;
- La mekanismo por detekti nodmalhaveblecon estas fiksita en la kodon kaj ne povas esti personecigita. Tio estas, ni ne povas krei niajn proprajn politikojn por determini la nehaveblecon de nodo.
- arbohakado ne ĉiam estas detala. Kelkfoje, kiam vi bezonas malsupreniri al tre malalta nivelo por kompreni apartan problemon, vi ne havas sufiĉe da fontkodo por ke iuj komponantoj komprenu kial;
SUMO: Ĝenerale, la impresoj de la produkto estas bonaj. Ni estas en konstanta kontakto kun la programistoj de orkestroj. La uloj estas pretaj al konstrua kunlaboro.
Malgraŭ ĝia simpleco, FCO havas larĝan funkciecon. En estontaj artikoloj ni planas profundiĝi en la jenajn temojn:
- retigado ĉe FCO
- disponigante viv-reakiron kaj FQP-protokolon
- skribante viajn proprajn kromaĵojn kaj fenestraĵojn
- konektante kromajn servojn kiel Load Balancer kaj Acronis
- sekurkopio
- unuigita mekanismo por agordi kaj agordi nodojn
- prilaborado de virtuala maŝina metadatenoj
ZY Skribu en la komentoj se vi interesiĝas pri aliaj aspektoj. Restu agordita!
fonto: www.habr.com