Integráció - röviden

Minden integrációs projectnél végül oda jut a párbeszéd, hogy az integráló fél/kliens felteszi a kérdést: Hogyan oldjuk meg azokat a problémákat, amelyek az én rendszeremben jelentkeznek és a te rendszeredből jönnek?
Erre ez az általános válasz a szolgáltatók részéről: Azok a problémák, amik a te rendszeredben jelentkeznek, azok a tieid.

Cluster - magánvélemény + ötlet

Azok a clusterezési technológiák és szoftverek, amik uniform szervereket várnak el futtatókörnyezetként, komoly hátrányban vannak azokkal szemben, amelyek képesek a hardware különbségeit (pl memória méret, elérési sebesség, sustainable és random IO, CPU-k száma és sebessége, hálózat, satöbbi) kezelni. Ugyanis az ügyfelek nem szeretnék évekkel vagy akár csak hónapokkal előre megvenni a hardware kapacítást. Pl egyes projectek esetében nem nagyon lehet kitalálni, hogy mekkora kapacításra van szükség. Meg hát nem is tudják, kapnak egy adott összeget egy üzleti évre és legközelebb majd a következő üzleti évben lehet hardware-t vásárolni. Akkor már más lesz a kinálat. Még ha mindig a listán is van a régi szerver tipus, akkor is valószinűleg más hardware fogja akkor megérni, más az akciós, satöbbi.

Például nekem a cassandra, amikor teszteltem nagyon makacsul ragaszkodott ahhoz, hogy egyenlően ossza fel a keyspace-t minden alkalommal, amikor új node-t csatlakoztatok.

Ezt gondoltam csak azért írom ide fel, mert nem olvastam egy könyvben sem eddig, ez amolyan magánvélemény.

Ötlet: Csak példaként egy private cloud-ba érdekes lehetne olyan logikát írni, ami felstartol mégegy mongodb szervert, ha a cluster átlagos terhelése X főlé nő, lekapcsol egyet, ha Y alá csökken, megtart tartalékba Z-t mindig. Nyilván nem csinál ilyet az oVirt, de más rendszerek biztosan igen. Bocsi, hogy megint oVirt lett belőle...
Ez persze a fizikai vasakon futó rendszereken nem segít, nem "silver bullet", de egy egyszerű megoldás lenne a probléma java részére.

oVirt or oVirt

Néhány további a múltkori dolgokhoz az oVirt-tel kapcsolatban, most nem annyira felhasználói oldalról, kicsit inkáb belülről.

Poll

Az oVirt hogy bármilyen információt beszerezzen a futó VM-ekről, poll-ozgatja a host-gépeken futó agentet (ennek VDSM a neve). Az agenttel csak két problémám van:

• Új szoftvert írni XML-RPC-re? Ez komoly? Akkor már miért nem CORBA? :)
• Néha úgy tünik az alatta levő libvirt-tel hamarabb szótértenék. Például oda lehet callback-eket is regisztrálni.

A pollozás mellett amit nem szeretek, az az, hogy a leszedett információt egyszerűen belecsapjuk az adatbázisba és nem csinálunk semmit, várjuk hogy valaki megkérdezze. Ezzel kapcsolatban borzasztóan kiváncsi vagyok, hogy vajon miért. Egy tranzakciós adattárolóban tartunk valamit, ami tökre nem tranzakciós. Minden alkalommal amikor kellene tudni, egy Host-on mennyi szabad memória van, az adatbázisból kérdezzük le.
Szóval szerintem:

• A host éppen aktuális állapotát nem adatbázisban kellene tartani, hanem a memóriában vagy elosztott cache-ben. Az adatbázis nem cache!
• A hostot lehet hogy kell poll-ozni időnként, hogy életben van-e még, de sokkal hatékonyabb lenne ha streamelné az adatokat, ha már van agent
• A streamelt eseményeket akár JMS sorban priorítási sorrendben lehetne feldolgozni, tetszőleges szálon. Ezeknek az eseményeknek kellene elindítania a döntési folyamatokat. (pl hogy a host túlterhelt, valamelyik Vm-et át kell migrálni máshova)

Kereső

A kereső egy tipikus szent tehén, senki sem mer hozzányúlni. Nagyjából úgy van most, ahogy átportolták .net-ből. A másik nehézség, hogy jó részét megosztv használja a GWT frontend és a backend, így aztán tényleg nehéz is hozzányúlni, de azért egyszerűsítgetni simán lehet benne mert nagyon cifrán redundáns.
A kereső egy apró baja az, hogy SQL lekérdezéseket gyárt, nem holmi lucene vagy hasonló okoskodás. Az SQL se rossz persze, de a postgres-nek rettenetes bajai vannak a generált lekérdezéseivel. Degeneráltak a lekérdezései. Szóval a kereső is jól tökönrúgja az adatbázist, de a kód ami a lekérdezést generálja tényleg nehéz eset, elösször kicsit egyszerűsíteni kellene rajta, de azt nem lehet, mert így "működik".

Kompenzációs tranzakciók

Hallottál már olyanról, hogy kompenzációs tranzakciók? Én csak véletlenül futottam bele régebben, de soha nem láttam alkalmazva. Ez a megoldás azért lett bevezetve, mert a kommunikáció a hostokkal lassú, közben lockolunk rekordokat és a postgresql-nek nincs read uncommited tranzakció izolációs szintje. Mondjuk még mielött tiltakozni kezdenél, hogy azért van más épkézláb megoldás: persze van. De mindenesetre valahogy úgy jött ki, hogy egy bizonyos táblába tol az oVirt mindent, és lezárja az adatbázis tranzakciót, egy tranzakciók feletti tranzakciót csinál. Aztán ha N adatbázis tranzakció után belefut egy hibába, akkor megpróbálja visszacsinálni ezek alapján a rekordok alapján.

1. Ez kézzel hímzett megoldás, rettenetesen sok kódsor szolgálja
2. Nem biztos hogy sikerül a kompenzációs tranzakció, és akkor megakadunk ott, ahova nem akartunk eljutni
3. Ha kompenzáció nem sikerül az engine indításakor, akkor az engine el se indul. A felhasználó meg néz hogy mivan.
4. Bár a tranzakciókat igazán egyidejű hozzáférésre találták ki, a kompenzációs tranzakcióknál teljesen para az egyidejű hozzáférés.

Nem lenne nehéz megoldani, hogy a Host műveleteket az oVirt asszinkron kezelje. Küldözgessen JMS üzeneteket, vagy akármi. Én egyébként szivesebben barátkoznék a gonosz MySQL-lel is akár, mint hogy egy tranzakciós rendszer tetejébe workaroundként mégegy tranzakciós rendszert húzzak.

Adatbázis

Á igen, rendesen tökönrúgjuk az adatbázist a HOST/VM státusz adatok örökös írogatásával, a hülye kereső lekérdezésekkel, de ez nem fáj nagyon, amíg nincsen sok VM-ed. (Mondjuk miért használnál olyasmit, mint az oVirt, ha nincs sok VM-ed?)
Viszont helyenként rendesen tökön rúgjuk szegény PostgreSQL-t olyanokkal is, hogy egy ciklusban kérdezünk le valamit belőle, ahelyett, hogy egy értelmes lekérdezést írnánk. Ez nekem az egyik legfájdalmasabb dolog, mert ez direkt van így és nem értem miért kell hogy így legyen. Nemrég kellett egy bugot kijavítsak és első nekifutásra kicsit okosítottam a lekérdezésen, de ezt nem fogadta el a reviewer (aki szerintem beletette a bugot). Az elfogadott megoldásban kénytelen voltam iterációban kérdezgetni az adatbázisból. Ez a rendszered növekedésével exponenciális terhelésnövekedéshez vezet. Baromi zavaró, amikor ilyeneket csináltatnak velem.

"Mindenki más faszával szereti verni a csalánt"
- ZTutto