No kerub-agent

A legtöbb IaaS egy agent nevű szoftverre épít, ami minden host-on fut. Ez egyrészt egy olyan szoftver, ami a kommunikációt bonyolítja a controller és a host között, másrészt egy absztrakciós réteg is.
Az ovirt-ben ez egy VDSM nevű python script, ami XML-eket kap a kontrollertől és azt lefordítja másféle XML-be, konkrétan a libvirt XML formátumába, másrészt pedig néha operációs rendszer parancsokra, szóval kicsit többet csinál mint egy XSLT processzor :)
A cloudstack-nek egy java agentje van. Elsőre kicsit soknak tünhet akár fél gigát is beáldozni a host memóriájából egy ilyen, viszonylag erőforrásigényes processznek, de tipikusan a cloudstack felhasználók TB-ben mérik a host memóriát és fél giga nem kategória. A java-t inkáb azért nem tartom szuperfrankó választásnak agenthez, mert brutálisan béna az operációs rendszerekkel az integrációja, például a processz kezelés, meg persze mindenkinek vannak ellenérzései a JNI-vel szemben. JNI pedig van, persze hogy van...
Viszont itt nyilván előny, hogy a java fejlesztő, aki a kontrollert buherálja, az az agentet is simán buherálhatja minden további tanulmányok nélkül.

Mindkettő http protokolt használ: kapcsolódunk, kezetrázunk, bemutatkozunk, valami teljesen minimális dolgot közlök veled aztán elbúcsúzunk és fél másodperc múlva újrakezdjük. Az oVirt még emellett egy döbbenetes dolgot is csinál a tranzakciókkal, ami a MS-SQL-ből PostgreSQL-re való áttérés (és talán egy súlyos félreértés) eredménye.


Amikor azon gondolkodtam, hogy hogyan tudnék jó agentet a kerubhoz, elösször is inkáb azon gondolkodtam hogyan lehetne megúszni az egészet, mert nincs rá időm. Másodszor pedig szerettem volna megszabadulni a kommunikációs overhead-tól, pl xml parsing.

Végülis az, hogy nincs agent, azt nevezhetjük félrevezető marketing-baromságnak, mert valamilyen szoftvernek futnia kell, amivel kommunikálunk. Ennyi lett: OpenSSH, az OpenBSD klasszikus SSH szervere, ami fut linuxon, windowson (cygwin), mindenféle BSD-n és solarison, ráadásul többnyire része egy szerver alaptelepítésnek.


Az absztrakciós réteg... egy része ott van a kontrollerben, mert annak tudnia kell, hogy milyen operációs rendszerhez beszél, az absztrakciók nagy része viszont elment. Eleinte csináltam abstrakciót a hypervisor-elé, de később találtam jobb megoldást és mostanában lassan eltávolítom ezeket a kerub-ból.

Ez most hosszú lett, mert vasárnap van, legyen legközelebb például az, hogy mit csinál a planner és miért nem kellenek az absztrakciók.

kerub - az "expectation"

Az expectation (elvárás) az a dolog, ami a kerub nagy planner-egyenletének az egyik oldala. Elvárásokat határozhat meg az ember virtuális erőforrásokhoz (virtuális gép, virtuális merevlemez, hálózat) teljesítményükre, megbízhatóságukra, futási környezetükre vonatkozóan.
Pár ilyen elvárás:

• Redundancia - egy merevlemezre megmondhatjuk hogy mennyi másolat kell hogy legyen belőle - esetleg egy vagy több hoston tarthatjuk-e a másolatokat.
• Kölcsönös kizárás (not-same-host) virtuális gépre és virtuális merevlemezekre lehet használni, például ha két tomcatunk között session replikációt játszunk, akkor igazán hülye dolog lenne a IaaS-tól ha ugyanazon a kiszolgálón hagyná futni őket. Ha a kiszolgáló elszáll, mindkettő tomcat bebukik. Hasonlóan pl scale-out adatbázisok (cassandra) merevlemezeinél.
• Host-tal kapcsolatos elvárások, pl ECC-memória, tápegységek száma, vagy akár a gyártó is (még van ember, aki hisz az IBM-ben pl, mindenki hülyének tartja de van pénze)
• Nyilván I/O teljesítmény, CPU teljesítmény és satöbbi elvárások

És így tovább, ilyenből egész sok van...

Műsorváltozás - kerub

Kicsit másként fogom használni ezt a blogot most egy ideig, mert nagyon kevés időm van rá, hogy ide írjak. Ez nem feltétlenül baj, mert nektek meg kevés időtök van rá, hogy elolvassátok, csak nem fogok rajta sokáig töprengeni, itt landol majd sokminden mint vasárnap hajnalban a diszkó elött a járdán.

Szóval mostanában ezen a kerub nevű dolgon dolgozok. A kerub egy IaaS prototípus. Arról, hogy IaaS alighanem mindenkinek az OpenStack jut eszébe. A legtöbb barátom OpenStack-en dolgozik vagy dolgozott, egy egész hadsereg lehet rajta. És mennyi ZS...

Nade kerub... Mi is lenne az alapötlet? Csak mert az egy jó kezdőlépés lenne ugye :)
A kerub-ot azért kezdtem el, mert ki akartam próbálni egy másmilyen megközelítést a virtuális gépek schedulerére. Bár a kernel scheduler abszolut tudományos dolog, sajnos a cloud rendszerek schedulerei enterprise agybajok.
A kerub schedulerétől elösször is azt akartam, hogy ne okozzon sok seggfájást, találja ki, hogyan tudja kielégiteni a felhasználók elvárásait.
Ja mert ez a tényleg fontos ötlet, a felhasználóknek elvárásaik vannak, mindig minden pillanatban azt nézi a kerub, hogy ezek az elvárások teljesülnek-e, illetve hogyan lehet kielégíteni őket. Nem kell servicenow ticketet nyitni, mint melóban, kerub tudja ha baj van és dolgozik is rajta.

Akkor legyen most gyorsan csak ennyi :)