Ebben az iparban olyan factory-k vannak, amiknek nincs kéményük, managerek, akik nem járnak meetingre és engine-k, amik nem vontatnak semmit. Nyilván kicsit lököttek is vagyunk. Ebbe fog most az alábbi is passzolni egy kicsit, elég absztrakt lesz és annyi időt szánok rá a magyarázatra, amíg a managerem fel nem ébred.
Az előző bejegyzésekben már említettem a 2000es évek IaaS architektúrájának egy tipikus elemét, a schedulert.
A különbség az oVirt, a Cloudstack és más IaaS platformok schedulere és a kerub plannere között az, hogy míg a schedulereket akkor hívja meg a rendszer, amikor be kell ütemezni egy új virtuális gépet, a planner minden eseményt megkap. Minden eseménynél értékeli, hogy az új helyzet minden expectationt (azaz SLA contract) kielégít-e. Például a virtuális gép, aminek futnia kell, az tényleg fut, és olyan környezetben és hardweren amit kért a felhasználó.
Minden event az tényleg minden eventet jelent, amikor a szerver jelenti az éppen aktuális terheltségét az egy event, amikor a VM módosult, az szintén egy event.
Amikor az expectation nem teljesül, akkor a planner lépéseket gyárt le lépés-factory-k segítségével. A factory egyetlen dolgot kap: a jelenlegi helyzetet, ami magába foglalja a VM-ek, virtuális merevlemezek satöbbi, valamint a fizikai eszközök statikus (nem változó), dinamikus (állapot) és konfigurációs adatait. Ez alapján egyetlen dolgot csinálnak: listát a
lehetséges lépésekből. A factory-k teljes mértékben tesznek arra, hogy van-e valami értelme a műveletnek, csak legyártják a lépéseket és kész.
Minden legenerált lépés az aktuális állapotot transzformálja egy másik állapotra. A progmatos állapottér-model elkötelezett hívei azonnal vegyék le a kezüket a farkukról, fúj gusztustalan! Szóval például egy bizonyos fajta lépés az egyik hostról átpakolja a másik hostra az egyik VM-et (nevezzük migrációnak), egy másik egy hostot kapcsol ki, (nevezhetjük power managementnek, de bug is lehet)
A lépéseknek persze van költsége, különböző költségtípusok, például idő, számítási és IO igény, vagy akár a kockázat, hogy valami gixer üt be, az is egyfajta költség.
Ezen kívül a lépéseknek vannak erőforrás igényei is, például egy host osztott vagy kizárólagos használata, tárhely vagy számítási kapacítás, illetve a virtuális erőforrások, amit használnak. Ez a feladatok koordinálásához kell, pl hogy ne tervezzen keresztbe már folyamatban lévő ügyek végrehajtásával, ne kapcsoljuk ki azt a hostot amit egy másik terv éppen bekapcsolt valamilyen célból, ilyesmi.
Nyilván minden lépéshez kell egy végrehajtó kód is, mert a lépés önmagában olyan absztrakt hogy fingja nincs melyik lábbal induljon el, csak az állapotteret transzformálja. A végrehajtónak viszont van kapcsolata a konkrét anyagi világgal, ez többnyire egy ssh kapcsolat egy vagy több kiszolgálóhoz.
hmm mi hiányzik még... ja persze, hogy ez mitől kezdene működni... Az már egyszerű, csak egy kereső algoritmus. Egy depth-first backtrack-et csináltam rá, ezt nevezhetjük átmeneti megoldásnak, mert valószinűleg más keresés gyorsabb lenne, de ez is tűrhetően párhuzamosítható.
Ennek az eredménye az, hogy a kerub
keres egy módot arra, hogy a kéréseknek megfelelően futtassa a virtuális gépeket, merevlemezeket, hálózatot, satöbbi. A többi IaaS megnézi, hogy van-e passzoló host és ha nincs akkor pl nem indul a vm, csókolom.
Az biztosan gyanús már az elejétől, hogy a planner elég rendesen busy-box, mert minnél több a VM és a host, annál több event érkezik és annál több expectation-t kell ellenőrizni. Másrészt az egyre több factory egyre több lépést generál az egyre több VM-re. Ezek sajnos problémák, bár van rá ötletem, a keresési probléma egyébként is exponenciálisan növekedik. Jelenleg egy pár szűkítés van érvényben a factory-kra a kielégítetlen elvárások típusa alapján, de sokat az érne, ha nem kellene minden elvárást mindig kiértékelni, ha a factory-k listája lazy módon értékelődne ki.
Meglátjuk meddig jutok el vele, de a cél egyébként nem matematikai értelemben vett optimális állapot hanem csak egy egész jó :)
