Az IaaS (Virtual Data Center) szolgáltatások nyújtásához mi kereskedelmi hangszerelőt használunk (FCO). Ez a megoldás meglehetősen egyedi architektúrával rendelkezik, ami megkülönbözteti a nagyközönség által ismert Openstacktől és CloudStacktől.
A KVM, VmWare, Xen, Virtuozzo6/7, valamint ugyanazon Virtuozzo konténerei támogatottak számítási csomópont-hipervizorként. A támogatott tárolási lehetőségek közé tartozik a helyi, az NFS, a Ceph és a Virtuozzo Storage.
Az FCO támogatja több fürt létrehozását és kezelését egyetlen felületről. Vagyis egy Virtuozzo-fürtöt és egy KVM + Ceph-fürtöt kezelhetsz, ha egy egérkattintással váltasz közöttük.
Lényegében az FCO egy átfogó megoldás a felhőszolgáltatók számára, amely a hangszerelésen túl a számlázást is tartalmazza, minden beállítással, fizetési bővítményekkel, számlákkal, értesítésekkel, viszonteladókkal, tarifákkal stb. A számlázási rész azonban nem képes minden orosz árnyalatot lefedni, ezért ennek használatát egy másik megoldás javára elhagytuk.
Nagyon elégedett vagyok a rugalmas rendszerrel, amely lehetővé teszi az összes felhő-erőforrás jogainak elosztását: képek, lemezek, termékek, szerverek, tűzfalak – mindez „megosztható” és jogokat biztosíthat a felhasználók, sőt a különböző kliensek felhasználói között is. Minden ügyfél több független adatközpontot hozhat létre a felhőjében, és kezelheti azokat egyetlen vezérlőpultról.
Építészetileg az FCO több részből áll, amelyek mindegyikének saját független kódja van, és néhánynak saját adatbázisa van.
Láthatár – admin és felhasználói felület
gebe – üzleti logika, számlázás, feladatkezelés
Tigris liliom – szolgáltatáskoordinátor, irányítja és koordinálja az üzleti logika és a klaszterek közötti információcserét.
XVPManager – klaszterelemek kezelése: csomópontok, tárolók, hálózati és virtuális gépek.
XVPAgent – a csomópontokra telepített ügynök az XVPManagerrel való interakcióhoz
Terveink szerint az egyes komponensek architektúrájáról egy cikksorozatban részletes történetet is beiktatunk, ha természetesen a téma felkelti az érdeklődést.
Az FCO fő előnye „dobozos” jellegéből fakad. Az egyszerűség és a minimalizmus az Ön szolgálatában. A vezérlő csomópont számára egy virtuális gép van lefoglalva az Ubuntu-n, amelybe az összes szükséges csomag telepítve van. Minden beállítás konfigurációs fájlba kerül változó érték formájában:
# 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"
…
A teljes konfigurációt kezdetben sablonokban szerkesztjük, majd elindul a generátor
#build-config, amely létrehoz egy vars fájlt, és parancsot ad a szolgáltatásoknak, hogy olvassák újra a konfigurációt. A felhasználói felület szép és könnyen márkásítható.
Mint látható, a felület widgetekből áll, amelyeket a felhasználó vezérelhet. Könnyedén hozzáadhat/eltávolíthat widgeteket az oldalról, ezáltal létrehozhatja a számára szükséges irányítópultot.
Zárt jellege ellenére az FCO egy nagymértékben testreszabható rendszer. Rengeteg beállítással és belépési ponttal rendelkezik a munkafolyamat megváltoztatásához:
- Egyéni beépülő modulok támogatottak, például megírhatja saját számlázási módját vagy saját külső erőforrásait, hogy a felhasználó számára
- Bizonyos események egyéni triggerei támogatottak, például az első virtuális gép hozzáadása az ügyfélhez annak létrehozásakor
- A kezelőfelület egyéni widgetjei támogatottak, például YouTube-videó beágyazása közvetlenül a felhasználói felületbe.
Minden testreszabás FDL-ben van megírva, amely Lua-n alapul. Ha ismeri Luát, nem lesz probléma az FDL-lel.
Íme egy példa az általunk használt egyik legegyszerűbb triggerre. Ez a trigger nem teszi lehetővé a felhasználók számára, hogy megosszák saját képeiket más ügyfelekkel. Ezt azért tesszük, hogy megakadályozzuk, hogy egy felhasználó rosszindulatú képet hozzon létre a többi felhasználó számára.
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
A regiszter függvényt az FCO kernel fogja meghívni. Visszaadja a meghívandó függvény nevét. Ennek a függvénynek a „p” paramétere tárolja a hívási környezetet, és az első meghívásakor üres lesz (nulla). Ez lehetővé teszi számunkra, hogy regisztráljuk a triggerünket. A triggerType-ban azt jelezzük, hogy az eseményindítót a közzétételi művelet ELŐTT hívják meg, és csak a felhasználókat érinti. Természetesen megengedjük a rendszergazdáknak, hogy mindent közzétegyenek. A triggerOptions szakaszban részletezzük azokat a műveleteket, amelyeknél a trigger aktiválódik.
És a fő dolog az {exitState = “CANCEL”} visszatérés, ezért fejlesztették ki a triggert. A hibaüzenetet küldi vissza, ha a felhasználó megpróbálja megosztani a képét a vezérlőpulton.
Az FCO architektúrában minden objektum (lemez, szerver, kép, hálózat, hálózati adapter stb.) erőforrás-entitásként jelenik meg, amelynek közös paraméterei vannak:
- Erőforrás UUID
- erőforrás neve
- erőforrás típusa
- Erőforrás-tulajdonos UUID
- erőforrás állapota (aktív, inaktív)
- erőforrás metaadatok
- erőforrás kulcsok
- Az erőforrást birtokló termék UUID-azonosítója
- erőforrás VDC
Ez nagyon kényelmes, ha API-t használ, amikor minden erőforrás ugyanazon elv szerint működik. A termékeket a szolgáltató konfigurálja és az ügyfél rendeli meg. Mivel számlázásunk oldalt van, az ügyfél szabadon rendelhet bármilyen terméket a panelről. Később a számlázáskor kerül kiszámításra. A termék lehet óránként IP-cím, óránként további GB lemez, vagy csak egy szerver.
A kulcsok bizonyos erőforrások megjelölésére használhatók a velük való munka logikájának megváltoztatásához. Például megjelölhetünk három fizikai csomópontot a súlykulccsal, és megjelölhetünk néhány klienst ugyanazzal a kulccsal, így ezeket a csomópontokat személyesen hozzárendelhetjük ezekhez a kliensekhez. Ezt a mechanizmust olyan VIP ügyfeleknél használjuk, akik nem szeretik a szomszédokat a virtuális gépeik mellett. Maga a funkcionalitás sokkal szélesebb körben használható.
A licencelési modell magában foglalja a fizikai csomópont minden processzormagjának fizetését. A költségeket a klasztertípusok száma is befolyásolja. Ha például a KVM és a VMware együttes használatát tervezi, a licenc költsége megnő.
Az FCO egy teljes értékű termék, funkcionalitása igen gazdag, ezért egyszerre több cikk elkészítését tervezzük a hálózati rész működésének részletes leírásával.
Miután több éve dolgoztunk ezzel a hangszerelõvel, nagyon alkalmasnak jelölhetjük. Sajnos a termék nem hibátlan:
- optimalizálnunk kellett az adatbázist, mert a lekérdezések lassulni kezdtek, ahogy nőtt a bennük lévő adatmennyiség;
- egy baleset után a helyreállítási mechanizmus egy hiba miatt nem működött, és szerencsétlen ügyfelek autóit kellett visszaszereznünk saját szkriptkészletünk segítségével;
- A csomópont elérhetetlenségének észlelésének mechanizmusa a kódba van bekötve, és nem testreszabható. Vagyis nem hozhatunk létre saját szabályzatot egy csomópont elérhetetlenségének meghatározására.
- a naplózás nem mindig részletes. Néha, amikor nagyon alacsony szintre kell lemenni egy adott probléma megértéséhez, nincs elég forráskódod egyes összetevőkhöz, hogy megértsd, miért;
ÖSSZESEN: Általánosságban elmondható, hogy a termék benyomásai jók. Folyamatos kapcsolatban vagyunk a hangszerelő fejlesztőkkel. A srácok hajlamosak a konstruktív együttműködésre.
Egyszerűsége ellenére az FCO széles funkcionalitással rendelkezik. A következő cikkeinkben a következő témákban tervezünk mélyebbre ásni:
- hálózatépítés az FCO-nál
- élő helyreállítási és FQP protokollt biztosít
- saját beépülő modulok és widgetek írása
- további szolgáltatások, például a Load Balancer és az Acronis összekapcsolása
- biztonsági mentés
- egységes mechanizmus a csomópontok konfigurálásához és beállításához
- virtuális gép metaadatainak feldolgozása
Z.Y. Írd meg kommentben, ha más szempontok is érdekelnek. Maradjon velünk!
Forrás: will.com