IaaS (Virtual Data Center) -palveluiden tarjoamiseksi me käytämme kaupallista orkesteria (FCO). Tällä ratkaisulla on melko ainutlaatuinen arkkitehtuuri, mikä erottaa sen suuren yleisön tuntemista Openstackista ja CloudStackista.
KVM, VmWare, Xen, Virtuozzo6/7 sekä saman Virtuozzon kontit ovat tuettuja laskentasolmuhypervisoreina. Tuetut tallennusvaihtoehdot sisältävät paikallisen, NFS-, Ceph- ja Virtuozzo-tallennustilan.
FCO tukee useiden klustereiden luomista ja hallintaa yhdestä käyttöliittymästä. Eli voit hallita Virtuozzo-klusteria ja KVM + Ceph -klusteria vaihtamalla niiden välillä hiiren napsautuksella.
FCO on ytimenään pilvipalveluntarjoajille tarkoitettu kokonaisvaltainen ratkaisu, joka sisältää orkestroinnin lisäksi myös laskutuksen, kaikki asetukset, maksulaajennukset, laskut, ilmoitukset, jälleenmyyjät, tariffit ja niin edelleen. Laskutusosa ei kuitenkaan pysty kattamaan kaikkia venäläisiä vivahteita, joten luovuimme sen käytöstä toisen ratkaisun hyväksi.
Olen erittäin tyytyväinen joustavaan järjestelmään kaikkien pilviresurssien oikeuksien jakamiseen: kuviin, levyihin, tuotteisiin, palvelimiin, palomuuriin - kaikki tämä voidaan "jakaa" ja myöntää oikeuksia käyttäjien kesken ja jopa eri asiakkaiden käyttäjien kesken. Jokainen asiakas voi luoda pilveen useita itsenäisiä datakeskuksia ja hallita niitä yhdestä ohjauspaneelista.
Arkkitehtonisesti FCO koostuu useista osista, joista jokaisella on oma itsenäinen koodinsa ja joillakin on oma tietokanta.
Siluetti – järjestelmänvalvoja ja käyttöliittymä
Jade – liiketoimintalogiikka, laskutus, tehtävien hallinta
Tiikerililja – palvelukoordinaattori, hallinnoi ja koordinoi tiedonvaihtoa liiketoimintalogiikan ja klustereiden välillä.
XVPManager – klusterielementtien hallinta: solmut, tallennustila, verkko ja virtuaalikoneet.
XVPAgent – solmuihin asennettu agentti, joka on vuorovaikutuksessa XVPManagerin kanssa
Aiomme sisällyttää artikkelisarjaan yksityiskohtaisen tarinan kunkin komponentin arkkitehtuurista, jos aihe tietysti herättää kiinnostusta.
FCO:n tärkein etu johtuu sen "laatikollisesta" luonteesta. Yksinkertaisuus ja minimalismi ovat palveluksessasi. Ohjaussolmulle on varattu yksi Ubuntun virtuaalikone, johon on asennettu kaikki tarvittavat paketit. Kaikki asetukset sijoitetaan asetustiedostoihin muuttujan arvon muodossa:
# 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"
…
Koko kokoonpanoa muokataan aluksi malleissa, minkä jälkeen generaattori käynnistetään
#build-config, joka luo vars-tiedoston ja käskee palveluita lukemaan asetukset uudelleen. Käyttöliittymä on mukava ja se voidaan helposti brändätä.
Kuten näet, käyttöliittymä koostuu widgeteistä, joita käyttäjä voi hallita. Hän voi helposti lisätä/poistaa widgetejä sivulta ja luoda siten tarvitsemansa kojelaudan.
Suljetusta luonteestaan huolimatta FCO on erittäin muokattavissa oleva järjestelmä. Siinä on valtava määrä asetuksia ja aloituspisteitä työnkulun muuttamiseksi:
- Mukautettuja laajennuksia tuetaan, esimerkiksi voit kirjoittaa oman laskutustavan tai oman ulkoisen resurssin tarjotaksesi käyttäjälle
- Tiettyjen tapahtumien mukautettuja laukaisuja tuetaan, esimerkiksi ensimmäisen virtuaalikoneen lisääminen asiakkaalle, kun se luodaan
- Käyttöliittymän mukautettuja widgetejä tuetaan, esimerkiksi YouTube-videon upottaminen suoraan käyttöliittymään.
Kaikki mukautukset on kirjoitettu FDL:llä, joka perustuu Luaan. Jos tunnet Luan, FDL:n kanssa ei ole ongelmia.
Tässä on esimerkki yhdestä yksinkertaisimmista käyttämistämme laukaisuista. Tämä laukaisin ei salli käyttäjien jakaa omia kuviaan muiden asiakkaiden kanssa. Teemme tämän estääksemme yhtä käyttäjää luomasta haitallista kuvaa muille käyttäjille.
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
FCO-ydin kutsuu rekisteritoimintoa. Se palauttaa kutsuttavan funktion nimen. Tämän funktion parametri "p" tallentaa puhelukontekstin, ja kun sitä kutsutaan ensimmäisen kerran, se on tyhjä (nolla). Tämän avulla voimme rekisteröidä laukaisumme. TriggerType-kohdassa ilmoitamme, että triggeri kutsutaan ENNEN julkaisutoimintoa, ja se vaikuttaa vain käyttäjiin. Tietenkin sallimme järjestelmänvalvojien julkaista kaiken. TriggerOptions-kohdassa kerromme toiminnot, joita varten laukaisin käynnistyy.
Ja tärkein asia on palauttaa {exitState = “CANCEL”}, minkä vuoksi laukaisu kehitettiin. Se palauttaa virheen, kun käyttäjä yrittää jakaa kuvansa ohjauspaneelissa.
FCO-arkkitehtuurissa mikä tahansa objekti (levy, palvelin, kuva, verkko, verkkosovitin jne.) esitetään resurssikokonaisuutena, jolla on yhteiset parametrit:
- Resurssi UUID
- resurssin nimi
- resurssityyppi
- Resurssin omistajan UUID
- resurssin tila (aktiivinen, ei-aktiivinen)
- resurssin metatiedot
- resurssiavaimet
- Resurssin omistavan tuotteen UUID
- resurssi VDC
Tämä on erittäin kätevää, kun työskentelet API:lla, kun kaikkia resursseja käytetään saman periaatteen mukaisesti. Tuotteet konfiguroi toimittaja ja tilaa asiakas. Koska laskutuksemme on sivussa, asiakas voi vapaasti tilata minkä tahansa tuotteen paneelista. Se lasketaan myöhemmin laskutuksessa. Tuote voi olla IP-osoite tunnissa, ylimääräinen gigatavu levyä tunnissa tai pelkkä palvelin.
Näppäimillä voidaan merkitä tiettyjä resursseja ja muuttaa niiden kanssa työskentelyn logiikkaa. Voimme esimerkiksi merkitä kolme fyysistä solmua Paino-avaimella ja merkitä joitain asiakkaita samalla avaimella ja siten allokoida nämä solmut henkilökohtaisesti näille asiakkaille. Käytämme tätä mekanismia VIP-asiakkaille, jotka eivät pidä naapureista virtuaalikoneensa vieressä. Itse toiminnallisuutta voidaan käyttää paljon laajemmin.
Lisenssimalliin kuuluu maksaminen fyysisen solmun jokaisesta prosessoriytimestä. Kustannuksiin vaikuttaa myös klusterityyppien määrä. Jos aiot käyttää esimerkiksi KVM:ää ja VMwarea yhdessä, lisenssin hinta nousee.
FCO on täysimittainen tuote, sen toiminnallisuus on erittäin rikas, joten aiomme laatia useita artikkeleita kerralla yksityiskohtaisella kuvauksella verkko-osan toiminnasta.
Koska olemme työskennelleet tämän orkestraattorin kanssa useita vuosia, voimme merkitä sen erittäin sopivaksi. Valitettavasti tuote ei ole ilman puutteita:
- meidän piti optimoida tietokanta, koska kyselyt alkoivat hidastua niiden tietojen määrän kasvaessa;
- yhden onnettomuuden jälkeen palautusmekanismi ei toiminut bugin takia, ja jouduimme palauttamaan onnettomien asiakkaiden autot omalla skriptisarjallamme;
- Solmun epäkäytettävyyden havaitsemismekanismi on kytketty koodiin, eikä sitä voida mukauttaa. Eli emme voi luoda omia käytäntöjämme solmun epäkäytettävyyden määrittämiseksi.
- kirjaaminen ei aina ole yksityiskohtaista. Joskus, kun sinun täytyy mennä hyvin alhaiselle tasolle ymmärtääksesi tietyn ongelman, sinulla ei ole tarpeeksi lähdekoodia, jotta jotkut komponentit ymmärtäisivät miksi;
YHTEENSÄ: Yleisesti ottaen vaikutelmat tuotteesta ovat hyvät. Olemme jatkuvasti yhteydessä orkesterin kehittäjiin. Kaverit ovat valmiita rakentavaan yhteistyöhön.
Yksinkertaisuudestaan huolimatta FCO:lla on laaja toiminnallisuus. Tulevissa artikkeleissa aiomme syventää seuraavia aiheita:
- verkostoituminen FCO:ssa
- tarjoaa live-palautuksen ja FQP-protokollan
- kirjoittaa omia laajennuksiasi ja widgettejäsi
- yhdistämällä lisäpalvelut, kuten Load Balancer ja Acronis
- varmuuskopioida
- yhtenäinen mekanismi solmujen määrittämiseen ja konfigurointiin
- käsittelee virtuaalikoneen metatietoja
ZY Kirjoita kommentteihin, jos olet kiinnostunut muista näkökohdista. Pysy kanavalla!
Lähde: will.com