Kicsi felhőt!

Azt, hogy otthagytam a fizetett oVirt maintainer állást és ingyen dolgozok a CloudStack-en, azt lehet amolyan kritikaféleségnek felfogni? Vagy pofátlanságnak? Mindegy, ez történt. Most a CloudStack-en foltozgatok apróságokat, főleg teszteket írok és leak-eket foltozok, remélem lesz időm kicsit jobban belemélyedni és pár új feature-t implementálni. Persze plusszok és minuszok mindkét oldalon vannak.

Tiszta aljasság részemről, de nagyon sokat töröm a fejem egy kutatási célú felhő projecten, ami ezeket az ötleteket demózná:

1. No Host Agent. Az oVirt egy VDSM nevű python programot használ host agentnek. A CloudStack egy java programot hajt. Mindkettő http protokolon keresztül beszélget a management szerverrel. Illetve a szerver beszélget vele.
   Vajon erre szükség van? Szerintem meg lehet csinálni sima SSH kapcsolattal is, így megszabadulunk a poll-tól, folyamatosan folyó információk jönnek a host és a VM-ek állapotáról, valamint nincs szükség pár másodpercenként újra SSL handshakelni. Az oVirt-et teljesen halálra lehet szívatni 20-30 hosttal. SSH kapcsolattal akár egy Raspberry PI is képes többszáz host-tal egyszerre folyamatos kapcsolatot tartani, miközben adatok áramlanak róluk. Ezt már kipróbáltam. Nincs szükség külön szoftver fejlesztésére, az openssh mindenhol ott van és az overhead minimális.
2. Scheduler. Az oVirt schedulere volt az, ahol végleg feladtam a reményt. A régi tervemhez szeretnék visszatérni és optaplanner segítségével egy optimalizációs algoritmusra bízni a cloud terheléselosztását. Mint ahogyan már meg is tettem, még csak nem is elsőként.
3. Event driven. Már sokszorosan sikerült kiakasztani azzal, hogy minden eseményfeldolgozást cron/quartz jobokként futtatunk. Felhasználóként sem tudom élvezni, amikor minden gombnyomásra várnom kell több másodpercet. Lásd SSH, lásd websocket, lásd long poll, halálfaszaakármi. Utálok számítógépekre várni.
4. Flyweight. Az az ötetem, hogy a rendszernek futnia kell tudni emberileg elfogadható válaszidőkkel egy Raspberry PI B modellen. Nem az az ötlet, hogy az egy megfelelő célhardware, hanem hogy kicsi belépési küszöb legyen a használatához. Host rendszernek minnow board, legányolt desktop gépek. Bármi, amiben van egy ethernet csatlakozó.
5. Primitív. 1 db war file. Jetty vagy Tomcat.
6. Új koncepció: Követelmény. Az oVirt és a CS is szép webes GUIk, ahol megcsinálhatod a storage domain-t, megmondhatod, hogy melyik VM melyik hoston és processzoron fusson, migrálhatod, megmondhatod hol legyen a storage, satöbbi. Ha nekem akár csak 10 hostot kellene eligazgatnom, legkevésbé sem akarnék ilyesmivel foglalkozni. Ez a droidok sportja. Én a követelményeket akarnám meghatározni a rendszernek: Az X VM reggel 8 és du 4 között mindenképpen menjen! A "tomcat" VM poolból legalább 4 gép legyen folyamatosan elérhető és különböző hostokon fussanak (failover). Ilyesmi.
   Cserébe pár koncepciót szivesen kinyírnék. Ilyen pl a cluster fogalma. A cluster olyan hostok halmaza, amelyek egy adott minimális processzor kompatibilitásnak megfelelnek és így képesek az arra a processzoron futó VMek futtatására. Ezt a koncepciót is a követelmény venné át illetve a processzormodellt simán meg tudjuk vizslatni (/proc/cpuinfo)
7. Kérdés: Szükség van-e tranzakciókra? Az oVirt tranzakció workaroundjaitól mindenkinek lerúgja az agya a láncot, ha elmesélem, javítása pedig nincs napirenden. A CS-nek is vannak vicces dolgai, de működik és az egyszerűsítése folyamatban van. Viszont egyáltalán: van szükségünk tranzakciókra? Az adatbázis az egyetlen tranzakcionális erőforrás az egész rendszerben, a hostok, a hálózat, a storage, a virtuális gépek, mind totál figyelmen kívül hagyják.
8. Scale out. Van pár ötletem arra, hogy az optimalizációs feladatokat hogyan futtatnám több gépen, de még kiróbálásra várnak.

Ennyi, nagyon lerövidítve. Ez elég drasztikusan térne el a jelenlegi IaaS szoftverektől, így nem hiszem, hogy lenne értelme megpróbálni bármelyikbe is beletuszkolni.