Az IaaS (Virtuális adatközpont) szolgáltatás nyújtásához mi kereskedelmi orchestrátort használunk (FCO). Ez a megoldás elég egyedi architektúrával rendelkezik, amely megkülönbözteti a közismert Openstacktől és CloudStacktől.
A compute csomópontok esetén a KVM, VmWare, Xen, Virtuozzo6/7, valamint a Virtuozzo által biztosított konténerek támogatottak. A támogatott tárolók közé tartozik helyi, NFS, Ceph és Virtuozzo Storage.
Az FCO támogatja több klaszter létrehozását és azok kezelését egyetlen felületen. Vagyis lehetőség van a Virtuozzo klaszter és a KVM + Ceph klaszter közötti váltásra egy kattintással.
Lényegében az FCO egy átfogó megoldás a felhőszolgáltatók számára, amely az orchestrálás mellett magában foglalja a billinget is, minden beállítással, fizetési pluginokkal, számlákkal, értesítésekkel, viszonteladókkal, tarifa- és sok mással. Azonban a billing rész nem képes lefedni a teljes orosz sajátosságokat, ezért egy másik megoldás mellett döntöttünk.
Nagyon örvendetes a rugalmas jogkezelési rendszer az összes felhőforrásra: képek, lemezek, termékek, szerverek, tűzfalak – mindez megosztható és jogokat adhatunk felhasználók, sőt különböző ügyfelek közötti felhasználók számára is. Minden ügyfél létrehozhat a saját felhőjében több független adatközpontot, és kezelheti őket egyetlen kontrollpanelből.
Architekturálisan az FCO több részből áll, mindegyik saját független kóddal, és néhány saját adatbázissal is rendelkezik.
Skyline – adminisztrációs és felhasználói felület
Jade – üzleti logika, billing, feladatkezelés
Tigerlily – a szolgáltatás koordinátora, irányítja és koordinálja az információcserét a üzleti logika és a klaszterek között.
XVPManager – a klaszter elemeinek kezelése: csomópontok, tároló, hálózat és virtuális gépek.
XVPAgent – a csomóponton telepített ügynök, amely interakciót biztosít a XVPManagerrel
A komponenst alkotó elemek architektúrájáról részletesen szeretnénk egy cikkciklust összeállítani, ha természetesen a téma felkelt egy kis érdeklődést.
A FCO fő előnye a "do-it-yourself" megközelítéséből fakad. Az egyszerűség és minimalizmus áll az Ön rendelkezésére. A vezérlőcsomópont számára egy virtuális gép van fenntartva Ubuntu rendszerrel, amelyen minden szükséges csomag telepítve van. Minden beállítás konfigurációs fájlokba kerül változó-érték formátumban:
# 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"
…
Az egész konfiguráció először sablonokban módosul, majd elindul a generátor.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Ahogy látható, az interfész widgetekből áll, amelyeket a felhasználó kezelhet. Könnyedén hozzáadhatja vagy eltávolíthatja a widgeteket az oldalról, így kialakítva a kívánt műszerfalat.
Bár zárt rendszer, a FCO rendkívül testre szabható. Rengeteg beállítással és belépési ponttal rendelkezik a workflow módosításához:
- Támogatottak a testreszabott pluginek, például írhat saját számlázási módszert vagy saját külső szolgáltatást a felhasználó számára.
- Támogatottak a testreszabott eseményekhez kötött triggerek, például az első virtuális gép hozzáadása a kliens számára a létrehozásakor.
- Támogatottak a testreszabott widgetek az interfészben, például be lehet ágyazni egy youtube videót közvetlenül a felhasználói felületbe.
Minden testreszabás FDL nyelven készül, amely a Lua alapjaira épül. Ha ismeri a Lua-t, az FDL-lel nem lesznek problémák.
Itt van az egyik legkisebb trigger példája, amit használunk. Ez a trigger megakadályozza a felhasználókat abban, hogy saját képfájljaikat megosszák más kliensekkel. Ezt azért tesszük, hogy egy felhasználó ne tudjon kártékony képfájlt létrehozni más felhasználók 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 register függvényt a FCO magja hívja meg. Ez visszaadja a meghívandó függvény nevét. A "p" paraméter tárolja a hívási kontextust, és az első híváskor üres (nil) lesz. Ez lehetővé teszi számunkra, hogy regisztrálhassuk a triggerünket. A triggerType-ban azt mutatjuk, hogy a trigger a közzététel előtt, és csak a felhasználók számára működik. Az adminisztrátorok természetesen minden közzétételét megengedjük. A triggerOptions-ban részletezzük azokat a műveleteket, amelyekre a trigger aktív lesz.
És a legfontosabb – a return {exitState = "CANCEL"}, ez az, amire a triggereket kidolgoztuk. Ez a közzétételi panelen történő képfájl megosztásakor kudarcot fog jelezni.
Az FCO architektúrában bármilyen objektum (lemez, szerver, kép, hálózat, hálózati adapter stb.) Resource entitásként van megjelenítve, amelynek közös paraméterei vannak:
- Az erőforrás UUID-ja
- Az erőforrás neve
- Az erőforrás típusa
- Az erőforrás tulajdonosának UUID-ja
- Az erőforrás státusza (aktív, inaktív)
- Az erőforrás metadatái
- Az erőforrás kulcsai
- A termék UUID-ja, amelyhez az erőforrás tartozik
- Az erőforrás VDC-je
Ez nagyon kényelmes API használatakor, amikor minden erőforrással egy elv alapján dolgoznak. A termékeket a szolgáltató állítja be, míg a megrendelését az ügyfél adja le. Mivel a számlázás tőlünk független, az ügyfél szabadon és díjmentesen megrendelhet bármilyen terméket a panelből. Az majd később számít be a számlázásba. A termék lehet – óránkénti IP cím, további GB lemez óránként vagy egyszerűen egy szerver.
A kulcsokkal meg lehet jelölni bizonyos erőforrásokat a velük való munka logikájának megváltoztatásához. Például megjelölhetjük három fizikai node-t a Weight kulccsal, és néhány ügyfelet ugyanezzel a kulccsal, így ezeket a node-kat személyre szabva kiemelve az adott ügyfeleknek. Ezt a mechanizmust VIP-ügyfelek számára használjuk, akik nem szeretik, ha szomszédaik vannak a VM-jeik mellett. Maga a funkció szélesebb körben is alkalmazható.
A licencelési modell minden fizikai node processzorának magja után fizetendő díjat feltételez. Az árat befolyásolja a klaszterek típusainak száma is. Ha például a KVM és a VMware együtt történő használatát tervezik, akkor a licenc ára növekedni fog.
Az FCO egy teljes értékű termék, amelynek funkciója nagyon gazdag, ezért több cikket is tervezünk előkészíteni a hálózati rész működéséről.
Több évnyi munka után ezzel az orchestrálónál megjegyezhetjük, hogy nagyon jónak bizonyult. Sajnos, a termék nem mentes a hibáktól:
- optimalizálnunk kellett az adatbázist, mivel a lekérdezések lassulni kezdtek, amikor a benne tárolt adatok száma nőtt;
- egy baleset után, ami egy hibából adódott, a helyreállítási mechanizmus nem működött, és muszáj volt a szerencsétlen ügyfelek gépeit a saját skriptek készletével helyreállítani;
- a node elérhetetlenségének érzékelésére szolgáló mechanizmus a kódba van beépítve, és nem testreszabható. Ez azt jelenti, hogy nem tudunk saját elérhetetlenségi politikákat létrehozni.
- A naplózás nem mindig részletes. Néha, amikor nagyon alacsony szintre kell lemerülnünk egy adott probléma elemzéséhez, hiányzik egyes komponensek forráskódja az okok megértéséhez;
ÖSSZEGZÉS: Összességében a termékkel kapcsolatos benyomások jók. Folyamatos kapcsolatban állunk az orkiesztrátor fejlesztőivel. A srácok nyitottak a konstruktív együttműködésre.
Egyszerűsége ellenére az FCO széles funkcionalitással rendelkezik. A jövőbeli cikkekben tervezzük, hogy elmélyedünk a következő témákban:
- a hálózat szervezése az FCO-ban
- live-recovery és az FQP protokoll biztosítása
- saját pluginek és widgetek írása
- további szolgáltatások, például Load Balancer és Acronis csatlakoztatása
- biztonsági másolat
- egységes konfigurációs és beállítási mechanizmus a node-okhoz
- virtuális gépek metaadatainak feldolgozása
Ui. Írjatok a megjegyzésekbe, ha érdekelnek más szempontok is. Maradjatok velünk!
Forrás: habr.com
