Flexiant Cloud Orchestrator: waarmee dit geëet word

Flexiant Cloud Orchestrator: waarmee dit geëet word

Om IaaS (Virtual Data Center) dienste te verskaf, het ons Rusonyx ons gebruik 'n kommersiële orkestreerder Flexiant Cloud Orchestrator (FCO). Hierdie oplossing het 'n taamlik unieke argitektuur, wat dit onderskei van Openstack en CloudStack, bekend aan die algemene publiek.

KVM, VmWare, Xen, Virtuozzo6/7, sowel as houers van dieselfde Virtuozzo word ondersteun as rekenaarnode-hiperviseerders. Ondersteunde bergingsopsies sluit plaaslike, NFS, Ceph en Virtuozzo Storage in.

FCO ondersteun die skepping en bestuur van veelvuldige groepe vanaf 'n enkele koppelvlak. Dit wil sê, jy kan 'n Virtuozzo-kluster en 'n KVM + Ceph-kluster bestuur deur met 'n muisklik tussen hulle te wissel.

In sy kern is FCO 'n omvattende oplossing vir wolkverskaffers, wat benewens orkestrasie ook fakturering insluit, met alle instellings, betaling-inproppe, fakture, kennisgewings, herverkopers, tariewe, ensovoorts. Die faktuurdeel is egter nie in staat om alle Russiese nuanses te dek nie, daarom het ons die gebruik daarvan laat vaar ten gunste van 'n ander oplossing.

Ek is baie tevrede met die buigsame stelsel vir die verspreiding van regte na alle wolkhulpbronne: beelde, skywe, produkte, bedieners, firewalls - dit alles kan "gedeel" word en regte toegeken word tussen gebruikers, en selfs tussen gebruikers van verskillende kliënte. Elke kliënt kan verskeie onafhanklike datasentrums in hul wolk skep en dit vanaf 'n enkele beheerpaneel bestuur.

Flexiant Cloud Orchestrator: waarmee dit geëet word

Argitektonies bestaan ​​FCO uit verskeie dele, wat elkeen sy eie onafhanklike kode het, en sommige het hul eie databasis.

Skyline - admin en gebruikerskoppelvlak
Jade – besigheidslogika, fakturering, taakbestuur
Tigerlily – dienskoördineerder, bestuur en koördineer die uitruil van inligting tussen besigheidslogika en klusters.
XVPManager – bestuur van groepelemente: nodusse, berging, netwerk en virtuele masjiene.
XVPAgent – 'n agent geïnstalleer op nodusse om met XVPManager te kommunikeer

Flexiant Cloud Orchestrator: waarmee dit geëet word

Ons beplan om 'n gedetailleerde storie oor die argitektuur van elke komponent in 'n reeks artikels in te sluit, as die onderwerp natuurlik belangstelling wek.

Die grootste voordeel van FCO spruit uit sy "boks" aard. Eenvoud en minimalisme is tot u diens. Vir die beheernodus word een virtuele masjien op Ubuntu toegeken, waarin al die nodige pakkette geïnstalleer is. Alle instellings word in konfigurasielêers geplaas in die vorm van 'n veranderlike-waarde:

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

Die hele konfigurasie word aanvanklik in sjablone geredigeer, dan word die kragopwekker geloods
#build-config wat 'n vars-lêer sal genereer en die dienste sal beveel om die konfigurasie weer te lees. Die gebruikerskoppelvlak is mooi en kan maklik gebrandmerk word.

Flexiant Cloud Orchestrator: waarmee dit geëet word

Soos u kan sien, bestaan ​​die koppelvlak uit widgets wat deur die gebruiker beheer kan word. Hy kan maklik legstukke van die bladsy byvoeg/verwyder en sodoende die dashboard skep wat hy benodig.

Ten spyte van sy geslote aard, is FCO 'n hoogs aanpasbare stelsel. Dit het 'n groot aantal instellings en toegangspunte om die werkvloei te verander:

  1. Gepasmaakte inproppe word ondersteun, byvoorbeeld, jy kan jou eie faktuurmetode of jou eie eksterne hulpbron skryf om die gebruiker te voorsien van
  2. Gepasmaakte snellers vir sekere gebeurtenisse word ondersteun, byvoorbeeld om die eerste virtuele masjien by 'n kliënt te voeg wanneer dit geskep word
  3. Gepasmaakte widgets in die koppelvlak word ondersteun, byvoorbeeld om 'n YouTube-video direk in die gebruikerskoppelvlak in te sluit.

Alle aanpassing is geskryf in FDL, wat gebaseer is op Lua. As jy Lua ken, sal daar geen probleme met FDL wees nie.

Hier is 'n voorbeeld van een van die eenvoudigste snellers wat ons gebruik. Hierdie sneller laat gebruikers nie toe om hul eie beelde met ander kliënte te deel nie. Ons doen dit om te verhoed dat een gebruiker 'n kwaadwillige beeld vir ander gebruikers skep.

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

Die registerfunksie sal deur die FCO-kern geroep word. Dit sal die naam van die funksie terugstuur wat genoem moet word. Die "p" parameter van hierdie funksie stoor die oproepkonteks, en die eerste keer dat dit genoem word, sal dit leeg wees (nul). Wat ons in staat sal stel om ons sneller te registreer. In triggerType dui ons aan dat die sneller voor die publiseerbewerking aangeroep word en slegs gebruikers affekteer. Natuurlik laat ons stelseladministrateurs toe om alles te publiseer. In triggerOptions beskryf ons die bedrywighede waarvoor die sneller sal afvuur.

En die belangrikste ding is terugkeer {exitState = "CANCEL"}, en daarom is die sneller ontwikkel. Dit sal mislukking gee wanneer die gebruiker probeer om hul beeld in die beheerpaneel te deel.

In die FCO-argitektuur word enige voorwerp (skyf, bediener, beeld, netwerk, netwerkadapter, ens.) voorgestel as 'n Hulpbron-entiteit, wat algemene parameters het:

  • Hulpbron UUID
  • hulpbron naam
  • tipe hulpbron
  • Hulpbroneienaar UUID
  • hulpbronstatus (aktief, onaktief)
  • hulpbron-metadata
  • hulpbronsleutels
  • UUID van die produk wat die hulpbron besit
  • hulpbron VDC

Dit is baie gerieflik wanneer u 'n API gebruik, wanneer alle hulpbronne volgens dieselfde beginsel gewerk word. Produkte word deur die verskaffer gekonfigureer en deur die kliënt bestel. Aangesien ons faktuur aan die kant is, kan die kliënt vrylik enige produk vanaf die paneel bestel. Dit sal later in fakturering bereken word. Die produk kan 'n IP-adres per uur, 'n bykomende GB skyf per uur, of net 'n bediener wees.

Sleutels kan gebruik word om sekere hulpbronne te merk om die logika van werk daarmee te verander. Ons kan byvoorbeeld drie fisiese nodusse met die Gewig-sleutel merk, en sommige kliënte met dieselfde sleutel merk, en sodoende hierdie nodusse persoonlik aan hierdie kliënte toeken. Ons gebruik hierdie meganisme vir BBP-kliënte wat nie van bure langs hul VM's hou nie. Die funksionaliteit self kan baie wyer gebruik word.

Die lisensiëringsmodel behels die betaling vir elke verwerkerkern van 'n fisiese nodus. Die koste word ook beïnvloed deur die aantal groeptipes. As jy byvoorbeeld beplan om KVM en VMware saam te gebruik, sal die koste van die lisensie styg.

FCO is 'n volwaardige produk, die funksionaliteit daarvan is baie ryk, so ons beplan om verskeie artikels gelyktydig voor te berei met 'n gedetailleerde beskrywing van die funksionering van die netwerkdeel.

Nadat ons vir etlike jare met hierdie orkeseerder gewerk het, kan ons dit as baie geskik merk. Helaas, die produk is nie sonder gebreke nie:

  • ons moes die databasis optimaliseer omdat navrae begin verlangsaam het namate die hoeveelheid data daarin toegeneem het;
  • na een ongeluk het die herstelmeganisme nie gewerk nie weens 'n fout, en ons moes die motors van ongelukkige kliënte herwin deur ons eie stel skrifte te gebruik;
  • Die meganisme vir die opsporing van die onbeskikbaarheid van nodus is in die kode gekoppel en kan nie aangepas word nie. Dit wil sê, ons kan nie ons eie beleide skep om die onbeskikbaarheid van 'n nodus te bepaal nie.
  • logboek is nie altyd gedetailleerd nie. Soms, wanneer jy na 'n baie lae vlak moet daal om 'n spesifieke probleem te verstaan, het jy nie genoeg bronkode vir sommige komponente om te verstaan ​​hoekom nie;

TOTAAL: Oor die algemeen is die indrukke van die produk goed. Ons is voortdurend in kontak met die orkestreerder-ontwikkelaars. Die ouens is geneig tot konstruktiewe samewerking.

Ten spyte van sy eenvoud, het FCO wye funksionaliteit. In toekomstige artikels beplan ons om dieper in die volgende onderwerpe te delf:

  • netwerk by FCO
  • verskaffing van regstreekse herstel en FQP-protokol
  • die skryf van jou eie plugins en widgets
  • bykomende dienste soos Load Balancer en Acronis te koppel
  • ondersteuning
  • verenigde meganisme vir die opstel en konfigurasie van nodusse
  • verwerking van virtuele masjien metadata

ZY Skryf in die kommentaar as jy belangstel in ander aspekte. Bly ingeskakel!

Bron: will.com

Voeg 'n opmerking