Orkestruesi Flexiant Cloud: me çfarë vjen

Orkestruesi Flexiant Cloud: me çfarë vjen

Për të ofruar shërbime IaaS (Virtual Data Center), ne Rusoniks ne përdorim një orkestrues komercial Orkestruesi Flexiant Cloud (FCO). Kjo zgjidhje ka një arkitekturë mjaft unike, e cila e dallon atë nga Openstack dhe CloudStack, të njohura për publikun e gjerë.

KVM, VmWare, Xen, Virtuozzo6/7, si dhe kontejnerët nga i njëjti Virtuozzo mbështeten si hipervizorë të nyjeve llogaritëse. Opsionet e ruajtjes së mbështetur përfshijnë hapësirën lokale, NFS, Ceph dhe Virtuozzo Storage.

FCO mbështet krijimin dhe menaxhimin e grupimeve të shumta nga një ndërfaqe e vetme. Kjo do të thotë, ju mund të menaxhoni një grup Virtuozzo dhe një grup KVM + Ceph duke kaluar midis tyre me një klikim të mausit.

Në thelb, FCO është një zgjidhje gjithëpërfshirëse për ofruesit e reve kompjuterike, e cila përveç orkestrimit përfshin edhe faturimin, me të gjitha cilësimet, shtojcat e pagesave, faturat, njoftimet, rishitësit, tarifat, etj. Sidoqoftë, pjesa e faturimit nuk është në gjendje të mbulojë të gjitha nuancat ruse, kështu që ne braktisëm përdorimin e saj në favor të një zgjidhjeje tjetër.

Jam shumë i kënaqur me sistemin fleksibël për shpërndarjen e të drejtave në të gjitha burimet e cloud: imazhe, disqe, produkte, serverë, mure zjarri - e gjithë kjo mund të "ndahet" dhe të jepen të drejta midis përdoruesve, madje edhe midis përdoruesve të klientëve të ndryshëm. Çdo klient mund të krijojë disa qendra të pavarura të të dhënave në renë e tij kompjuterike dhe t'i menaxhojë ato nga një panel i vetëm kontrolli.

Orkestruesi Flexiant Cloud: me çfarë vjen

Arkitekturisht, FCO përbëhet nga disa pjesë, secila prej të cilave ka kodin e vet të pavarur, dhe disa kanë bazën e tyre të të dhënave.

Horizont – administratori dhe ndërfaqja e përdoruesit
lodh – logjika e biznesit, faturimi, menaxhimi i detyrave
tigër zambak – koordinator i shërbimit, menaxhon dhe koordinon shkëmbimin e informacionit ndërmjet logjikës së biznesit dhe grupimeve.
XVPMmenaxher – menaxhimi i elementeve të grupimit: nyjet, ruajtja, rrjeti dhe makinat virtuale.
XVPAgent – një agjent i instaluar në nyje për të bashkëvepruar me XVPManager

Orkestruesi Flexiant Cloud: me çfarë vjen

Ne planifikojmë të përfshijmë një histori të detajuar rreth arkitekturës së secilit komponent në një seri artikujsh, nëse, sigurisht, tema ngjall interes.

Avantazhi kryesor i FCO-së buron nga natyra e tij "e kuti". Thjeshtësia dhe minimalizmi janë në shërbimin tuaj. Për nyjen e kontrollit, është ndarë një makinë virtuale në Ubuntu, në të cilën janë instaluar të gjitha paketat e nevojshme. Të gjitha cilësimet vendosen në skedarët e konfigurimit në formën e një vlere të ndryshueshme:

# 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"
…

I gjithë konfigurimi fillimisht redaktohet në shabllone, më pas lansohet gjeneratori
#build-config i cili do të gjenerojë një skedar vars dhe do të urdhërojë shërbimet të rilexojnë konfigurimin. Ndërfaqja e përdoruesit është e këndshme dhe mund të markohet lehtësisht.

Orkestruesi Flexiant Cloud: me çfarë vjen

Siç mund ta shihni, ndërfaqja përbëhet nga miniaplikacione që mund të kontrollohen nga përdoruesi. Ai mund të shtojë/heqë lehtësisht miniaplikacione nga faqja, duke krijuar kështu pultin që i nevojitet.

Pavarësisht natyrës së tij të mbyllur, FCO është një sistem shumë i personalizueshëm. Ka një numër të madh cilësimesh dhe pikash hyrëse për ndryshimin e rrjedhës së punës:

  1. Shtojcat e personalizuara mbështeten, për shembull, ju mund të shkruani metodën tuaj të faturimit ose burimin tuaj të jashtëm për t'i siguruar përdoruesit
  2. Aktivizuesit e personalizuar për ngjarje të caktuara mbështeten, për shembull, shtimi i makinës së parë virtuale te një klient kur krijohet
  3. Miniaplikacionet e personalizuara në ndërfaqe mbështeten, për shembull, futja e një videoje në YouTube drejtpërdrejt në ndërfaqen e përdoruesit.

I gjithë personalizimi është shkruar në FDL, i cili bazohet në Lua. Nëse e njihni Luan, nuk do të ketë probleme me FDL.

Këtu është një shembull i një prej nxitësve më të thjeshtë që përdorim. Ky aktivizues nuk i lejon përdoruesit të ndajnë imazhet e tyre me klientët e tjerë. Ne e bëjmë këtë për të parandaluar që një përdorues të krijojë një imazh me qëllim të keq për përdoruesit e tjerë.

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

Funksioni i regjistrit do të thirret nga kerneli FCO. Do të kthejë emrin e funksionit që do të thirret. Parametri "p" i këtij funksioni ruan kontekstin e thirrjes dhe herën e parë që thirret do të jetë bosh (nil). E cila do të na lejojë të regjistrojmë këmbëzën tonë. Në triggerType ne tregojmë se aktivizuesi thirret PARA operacionit të publikimit dhe prek vetëm përdoruesit. Sigurisht, ne i lejojmë administratorët e sistemit të publikojnë gjithçka. Në triggerOptions ne detajojmë operacionet për të cilat do të aktivizohet këmbëza.

Dhe gjëja kryesore është kthimi {exitState = "CANCEL"}, kjo është arsyeja pse u zhvillua këmbëza. Do të kthejë dështimin kur përdoruesi përpiqet të ndajë imazhin e tij në panelin e kontrollit.

Në arkitekturën FCO, çdo objekt (disk, server, imazh, rrjet, përshtatës rrjeti, etj.) përfaqësohet si një entitet i burimit, i cili ka parametra të përbashkët:

  • UUID i burimit
  • emri i burimit
  • lloji i burimit
  • UUID i zotëruesit të burimit
  • statusi i burimit (aktiv, joaktiv)
  • meta të dhënat e burimeve
  • çelësat e burimeve
  • UUID e produktit që zotëron burimin
  • burim VDC

Kjo është shumë e përshtatshme kur punoni duke përdorur një API, kur të gjitha burimet punohen sipas të njëjtit parim. Produktet konfigurohen nga ofruesi dhe porositen nga klienti. Duke qenë se faturimi ynë është anash, klienti mund të porosisë lirisht çdo produkt nga paneli. Do të llogaritet më vonë në faturim. Produkti mund të jetë një adresë IP në orë, një GB shtesë disk në orë ose thjesht një server.

Çelësat mund të përdoren për të shënuar burime të caktuara për të ndryshuar logjikën e punës me to. Për shembull, ne mund të shënojmë tre nyje fizike me çelësin Pesha, dhe të shënojmë disa klientë me të njëjtin çelës, duke i alokuar këto nyje personalisht te këta klientë. Ne e përdorim këtë mekanizëm për klientët VIP që nuk i pëlqejnë fqinjët pranë VM-ve të tyre. Vetë funksionaliteti mund të përdoret shumë më gjerësisht.

Modeli i licencimit përfshin pagesën për çdo bërthamë procesori të një nyje fizike. Kostoja ndikohet gjithashtu nga numri i llojeve të grupimeve. Nëse planifikoni të përdorni KVM dhe VMware së bashku, për shembull, kostoja e licencës do të rritet.

FCO është një produkt i plotë, funksionaliteti i tij është shumë i pasur, kështu që ne planifikojmë të përgatisim disa artikuj menjëherë me një përshkrim të detajuar të funksionimit të pjesës së rrjetit.

Duke punuar disa vite me këtë orkestrator, mund ta shënojmë si shumë të përshtatshëm. Mjerisht, produkti nuk është pa të meta:

  • na u desh të optimizonim bazën e të dhënave sepse pyetjet filluan të ngadalësohen ndërsa sasia e të dhënave në to rritej;
  • pas një aksidenti, mekanizmi i rikuperimit nuk funksionoi për shkak të një defekti dhe na u desh të rikuperonim makinat e klientëve fatkeq duke përdorur grupin tonë të skripteve;
  • Mekanizmi për zbulimin e padisponueshmërisë së nyjeve është i lidhur në kod dhe nuk mund të personalizohet. Kjo do të thotë, ne nuk mund të krijojmë politikat tona për përcaktimin e padisponueshmërisë së një nyje.
  • Regjistrimi nuk është gjithmonë i detajuar. Ndonjëherë, kur ju duhet të zbrisni në një nivel shumë të ulët për të kuptuar një problem të caktuar, nuk keni kod burimor të mjaftueshëm për disa komponentë për të kuptuar pse;

TOTALI: Në përgjithësi, përshtypjet e produktit janë të mira. Ne jemi në kontakt të vazhdueshëm me zhvilluesit e orkestruesit. Djemtë janë të prirur për bashkëpunim konstruktiv.

Pavarësisht nga thjeshtësia e tij, FCO ka funksionalitet të gjerë. Në artikujt e ardhshëm ne planifikojmë të thellohemi më thellë në temat e mëposhtme:

  • rrjetëzimi në FCO
  • duke siguruar rikuperim të drejtpërdrejtë dhe protokoll FQP
  • duke shkruar shtojcat dhe miniaplikacionet tuaja
  • duke lidhur shërbime shtesë si Load Balancer dhe Acronis
  • rezervë
  • mekanizëm i unifikuar për konfigurimin dhe konfigurimin e nyjeve
  • përpunimi i meta të dhënave të makinës virtuale

Z Y. Shkruani në komente nëse jeni të interesuar për aspekte të tjera. Qëndroni të sintonizuar!

Burimi: www.habr.com

Shto një koment