Egynemű házasság

Nemrég egy új főnökömnek (gyűjtöm a managereket) próbáltam elmagyarázni hogy mi a szituáció a projecten és valahogy ez a megnevezés jutott eszembe: egynemű házasság.

Az egynemű házasság alatt azt értem, hogy a projectre úgy helyeznek új munkaerőt, hogy az a projecten már meglévő fejlesztők képességeit nem kiegészíti, hanem azt lefedi.

A skálázhatóság témában szokás ezt X-axis-nak nevezni, és ott jól produkál, tipikusan webalkalmazásokat egész könnyű (ha nem csinált valaki valami turpisságot) X-axis mentén skálázni. A lényeges különbség viszont az, hogy a számítógépekkel összevetve az emberek lassan tanulnak és ráadásul sok hibával, azaz mind másként tanulnak meg valamit. Ez oda vezet, hogy kialakul pár vita és persze személyfüggő, hogy mennyi, de egyre több koordináció válik szükségessé. A problémán az sem segít, hogy az emberek természetes viselkedése a versenyzés, ez ugyanis nem minden eset válik a szoftver javára például gyakoribbá vállnak a túlmérnökölt megoldások.

Hát ennyit akartam megosztani ma, hogy én így gondolkodok erről nagy általánosságban véve, a többi bullshitet költsétek ti hozzá :)

[szerintem nem] elszállt ötletek: a VM scheduler

Szóval arra gondoltam az óév pár utolsó napján felrázlak titeket pár ötletemmel, talán pár hasznos dolog is kisül belőle. Kicsit többre gondoltam eredetileg, mint amennyi összejött, de egy hétig otthon voltam, mászkáltam erre-arra.
A legutóbbi ötlet végén utaltam egy megintcsak meló-kategóriás ötletemre az oVirt-tel kapcsolatban: szeretném kicsit okosabbá fejleszteni az oVirt VM-schedulerét. Valamennyire megvan rá a jóváhagyás is és erről a témáról beszéltem idén Barcelonában a Linux confba beágyazott oVirt workshopon.

Mi az a VM-scheduler?

A scheduler az a dolog, ami a vason kiosztja a vason, hogy mi és hol fusson. Egy ilyen nyilván minden operációs rendszer kerneljében fut nagyon frekventáltan, hogy eldöntse hogy melyik processznek adjuk oda egy kicsi időre a CPU-t. Ezek az algoritmusok egészen bonyolultak is tudnak lenni (pl gondolj csak a NUMA architektúrára) ahhoz képest, hogy nagyon gyorsan kell futniuk, tudományos cikkeket írnak róluk, satöbbi-satöbbi. Szerencsére van rá az ember, mert én ezzel nagyon nem akarnék foglalkozni.
A VM scheduler egy kicsit más kategória:

• a feladata a virtuális gép számára egy fizikai szerver kijelölése
• plusz esetenként (kellemetlen esetenként) migrációk ütemezése
• ritkábban fut: minden alkalommal, amikor Vm indul, illetve ha egy szerver terhelése túl nagy
• több erőforrás áll rendelkezésre
• viszont a teljes szerverfarm teljesítménye nagyban függ a döntés minőségétől
• a cefet-nagy sebességgel szemben én többre értékelném a skálázhatóságot és az értelmes eredményeket, persze a sebesség is szép

Mit tud ma az oVirt schedulere:  erről már írtam egy nagyon bosszús pillanatban, ugyanakkor amit írtam fentartom: a scheduler lassú, a kód zavaros és a döntései néha egészen hülyék.

Szóval mi történik ezen a fronton: egy ideje semmi, mert más (tökunalmas marhaság) feladaton kellett dolgoznom, de egyébként elkezdtem írni egy specifikációt és egy patch-et, ami a drools plannert használja fel optimalizációra. Ebből osztanék meg veletek pár alapötletet:

• A drools planner úgy dolgozik, hogy egy bizonyos felálláshoz kiszámítja a pontokat, aztán keresőalgoritmussal nekilát jobb felállást keresni. Szóval a pontszámítás a lényeges pont. A pontszámításra azt találtam ki, hogy külön kiszámítjuk minden esetleges tervhez:
• a szituáció költségeit: ide tartozik az, hogy mennyire fáj a jelenlegi helyzet, olyanok mint CPU-túlallokáció egy kis bünti, memória túlallokáció egy kicsit nagyobb bünti. A tényleges CPU és memória használat is ide kerül, csak azokra sokkal nagyobb böntit szabunk ki.
• az esetleges migráció költségeit: a migrációnak kell legyen egy alapköltsége, hogy ne dobáljuk idiótán pillanatnyi ötletek alapján a virtuális gépeket egyik gépről a másikra. Ezen kívül egyes erőforrásokat is megadóztatunk a migráció során, például a lefoglalt memóriát teljesen át kell másolni a másik gépre, ami idő persze.
  Itt üthetnek be a hard constraint-ek, pl a cél gépnek egyáltalán nincs annyi memóriája, mint amennyire a VM-nek minimum szüksége van.
• a migráció előnyeit (kompenzáció): miután megadóztattuk rendesen az aktuális helyzetet, és mindent ami esetleg kivezet innen, kell egy dolog, amit a kereső megtalálhat esetleg jobb megoldásként. Itt ilyen dolgokat lehet fdelsorolni, mint pl a CPU-overallocation a migráció után kisebb lesz. Illetve ha nagyobb akkor még arra is büntetést teszünk ki a kompenzáció helyett.

•  A schedulernek bizonyos időn belül válaszolnia kell. Egy cluster áttervezésnél én el tudnék viselni akár 4-5 másodpercet is, de kifejezetten értékelném, ha folyamatosan és inkrementálisan tervezne. A VM startnál kicsit izgágább a kedves felhasználó, általában szeretnék, ha a VM felstartolna vagy legalábbis valami választ kapnának egy másodpercen belül.
• Több VM indításakor rettenetes lenne egyenként végigmenni a VMeken és mindegyikre kiválasztani egy szervert, elindítani. Talán 2-3 VM-mel elmegy, de 50-100 VM-mel idegesítő és lassú. Egy terv kell az összes startolt VM-hez, azok szükségleteinek és a hostok képességeinek megfelelően.

Hát ennyi röviden, szóval remélem az újévben erre lesz majd időm. Lenne utánna pár további ötletem, de olyan lépésben haladunk, hogy az már tényleg scifi kategóriába tartozna.

Hát szóval ennyit erre az évre, remélem tetszett ez a pár évvégi ötlet, esetleg megihlet pár sajátot.

A tömörítéssel kapcsolatos dologba belerúgtam egyet, ha érdekel mérések a dummy warhead-en. (tudátok, a "hibás-de-sebaj" angol blogom)

Akkor legyen ennyi erre az évre :)
Boldog újévet!

elszállt ötletek: cloud storage

Nem ittam semmit esküszöm.

Mese: szóval a melóban az oVirt-tel amikor éppen akadt szabadidőm, a virtuális gépeimen a I/O sebességet teszteltem. Az oVirt támogat egy halom tárolótípust (nagyjából ugyanazt mint a libvirt). Sokmindenen múlik az I/O sebesség a tárhelyen kívül is, például egész sokat lassít rajta amikor thin provission, de hát valamit valamiért :-) Szóval kipróbáltam az NFS-t és az iSCSI tárolókat, mindkettő csalódás volt. Oké az olvasási sebességgel nem volt különösebb probléma, hozta azt a sebességet amit a merevlemezeken és a gigabites etherneten kifért. Az írás viszont botrány volt. Thin provision vagy nem, az NFS pocsék sebességet produkált és semmivel nem tudtam jobb sebességre rávenni. A fanok mondták, hogy a netapp storage-gel az NFS is egész gyors, de nem vagyok csilliárdos és éppen most nincs netapp szerverem. A munkatársak mondták hogy az iSCSI sokkal jobb lesz. Tényleg sokkal volt jobb, kereken kétszer jobb írási sebességet tudott, de ilyen kis számoknál a kétszer nagyobb még mindig kevés. Marhára kezdett érdekelni a GlusterFS, de még nem volt időm foglalkozni vele. A képzési keretemet szivesen beleölném :-) A tesztelő srácok, akiknek viszont van idejük nagyon sokat játszani, azt mondták hogy a glustertől se várjak sokkal többet, mert egyelőre egy disk az egy file, egy file az egy bricken és egy brick az egy szerveren van. Logikus, de demotiváló.
És persze a storage csapatnak se vagyok tagja. Nem is tudom van-e köztük java hegesztőmunkás. (és nem tudom kik azok, bajok vannak a nevekkel)
Szóval a kutatás teljesen befejezetlen, de pár saját pofátlan elvárással előálltam magamnak.

Ezen gondolkodtam: Mondjuk van egy szervered, benne egy sata vinyó, van egy gigabites hálózati kapcsolat, a hálózaton van még pár hasonló szerver. Mennyit lehetne kihozni ebből? Szerintem jobbat ki lehetne hozni, mint 200 MB/sec sustained R/W. A helyi sata vinyó elvisz 100-at, a gigabites etherneten keresztül a többo majdnem 100-at, és kicsit kombinálva a múltkori "talán gzip" dologgal, 200 fölé lehetne lökni, "csak" kombinálni kell az erőforrásokat. Olcsó gépen, egész jó teljesítmény. Szintén marha jól tudná javítani a random R/W sebességet, mert nem csak egy merevlemez fejét rázod, hanem amennyi van. Egy ilyet szeretnék a VM alatt. Éppen úgyis karácsony lesz mindjárt.

A másik fontos dolog: a lehetőleg VM fusson ott, ahol az adatai vannak. Nem érdemes átcipelni máshova azért, hogy aztán majd visszacipeljük. Konkrétan ilyesmiken dolgoztam is, mégpedig munkaidőben. Ki hinné hogy néha értelmes dologra is sor kerül :) Hamar le is álltunk...

Ez publikus cloud-ba nem igazán passzoló elképzelés, egy publikus cloud provider nem érdekelt abban, hogy a SLA-ban leírtaknál jobb teljesítményt adjon ha van rá lehetőség. Egy privát cloud-ban simán mehetne, had villogjanabbak vadabbul a ledek.

Ez a terület egyike azoknak, ami baromira érdekelne, ha találnék rá időt hogy foglalkozzak vele.

Legközelebb valami épkézlábabb dologgal jövök, addig megyek megmászok pár hegyet. Igen, talán a vm scheduler, bár azt a poént az elöbb lőttem le.

elszállt ötletek: peer to peer apps

Mindig jön valami legújabb webes dolog, amire rákattan mindenki. Aztán vagy a birkanyáj szellem, vagy a szakmai érdeklődés odavisz minket is. Egy ilyen szolgáltatáshoz egyre több szerverre van szükség, egyre több embert kell foglalkoztassanak, egyre magasabb hierarchiák alakulnak ki a cégben és ezek kiadásokat generálnak. A kiadásokat pedig bevételekkel kell fedezni. Ez természetes egyébként is hozzá vagyunk szokva, de sajnos ezen a ponton kezd a dolog elkurvulni:

• egyre több reklám jelenik meg (pl iwiw, index, origo)
  Aki kicsit is ért hozzá, az adblockert használ, de ez az összes felhasználó alig néhány százalékát teheti ki. Kérdezz körbe a családodban, a legtöbb ember még nem is hallott róla, hogy böngészőkbe pluginokat lehet rakni. Pedig van egy hegesztőmunkás a családban!
• privacy visszaélések jelennek meg, spamelnek (freemail tipikusan)
• a felhasználói felületen megjelennek a dark pattern-ek (kedvenc példám a go daddy)
• A fizető fél tartalmának előretolása (youtube, facebook, twitter, linkedin)
• Földrajzi régiók kizárása a free domainből (last.fm) vagy egyes tartalomból (youtube)
  Persze szerezhetsz egy proxyt, de a nagyközönségnek ez sem megoldás.
• Talán a legkevésbé elcseszett eset az, amikor a nagy felhasználóktól kérnek pénzt. (twitter firehose)

Az eleinte jól kezdődő szolgáltatás használhatósága zuhanórepülésbe kezd, a korai felhasználók menekülnek, 1-2 éven belül követi őket a nagyobb közönség. Az egész csak a pénz miatt, amit a cég és az infrastruktúra fentartására be kell szedniük.

...hogy mi lenne akkor,
na jó, ez csak elmélet...

Mi lenne akkor, ha a probléma alól megpróbálnánk kirúgni a széket úgy, ahogy a bittorrent teszi a filemegosztással. A dologba kicsit belekevernénk egy aszimetrikus titkosítást is, mindenki a rekordját egy saját kulccsal írná alá, egy publikus kulccsal lehetne olvasni, de írni nyilván nem. A hálózathoz csatlakozhatna tetszőleges node, attól függően hogy publikus vagy nem, de mindenki hostolná a saját adatait és valamennyit valaki máséból, csak hogy a redundancia is meglegyen. Az egész annyiban különbözne az elosztott adatbázistól, hogy nem csak az adatok repülnek a dróton, hanem néhány feldolgozásra vonatkozó kérés is: keresések, funkcióhívások, stb.
Nyilvánvaló előnyök:

• Az adat köztulajdon, nincs központi hivatal, ami elveheti, még az állam sem
• A felhasználók számával együtt nő a kapacítás
• A gyakran használt adatokhoz baró gyors hozzáférés
• Nincs központi szerver, ami kieshet. Ha néhány gép kiesik, csak azok az adatok vállnak elérhetetlenné, amik csak azokon a gépeken voltak meg.

Előre látható kihívások és kellemetlenségek:

• Trollok, spam és rongálók. Akár pornó is, mármint kéretlenül
• Hogy a feszegetőkről ne is beszéljünk...

Ezekre valamennyire van megoldás, spamfilterek, felhasználói interakciók a trollok jelölésére és blokkolására, satöbbi... persze a hülyeségre nincs orvosság. Milyen alkalmazásokra gondoltam tipikusan:

• social network akár - amennyiben még mindig meg akarod osztani a barátaid listáját
• akár hirdetési rendszerek is
• akár kereskedelmi rendszerek is
• tulajdonképpen akár csoportmunka jellegű szoftverek is, pl egy prezi-féle dolog, vagy egy , amin a szerver igazán csak púp

Nem fogok egyébként minden nap egy elszállt ötlettel előállni, ez csak ilyen év végi nagytakarítás :-)

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.

Cassandra: további kisérletek

Tanulgatok. Már egy pár hete hajtom a cassandrát és igazából egészen elégedett voltam vele 1 node-on. Összetúrtam 30 GB adatot hozzá a netről, meg írtam egy kis crawler jellegű programot, ami folyamatosan túr további adatokat hozzá. Mondjuk napi 2-3 GB adattal nő. Szóval az adatbázisomat szorgalmas írásnak is és olvasásnak is alávetem. Gondoltam kihúzom az adatbázisomat 2 node-ra. Ez valami marha egyszerű dolog. Felstartolsz mégegy processzt mondjuk egy másik gépen, aminek azt mondod, hogy az elsőtől ismerkedjen a cluster topológiájával. Azonnal ránéztem nodetool ring-gel, láttam hogy cassandra úgy döntött, az adatbázisom 40%-át, 9 GB adatot átküld a másik node-ra. Villámsebesen átmásolta, gigabites hálózat van a kettő gép között, sajnos inkáb a vincsi volt a szűk keresztmetszet. Az első érdekes dolog az volt, hogy bár az második node-on létrejött 9 GB, az elsőn nem tünt el. Aztán lekapcsoltam a második node-ot nodetool decommission parnaccsal, elkezdett visszareplkálni az első node-ra. Pár perc alatt kész lett, de ahelyett, hogy az adatbázis mérete megmaradt volna 30 GB, megnőtt úgy 40 GB-ra. Mégegy ugyanilyen kör után már 50 GB körül volt, aztán 60 GB körül. Ami azért bosszantó, mert még mindig csak 30 GB adatot tartok benne :-) Itt már kicsit bosszús voltam és nem akartam tovább rontani a helyzetet, hagytam ott az adatbázist, ahol van. Közben a cassandra őrült módon tekerte a merevlemezt, a crawler futott tovább, én meg elslattyogtam egyet sétálni. Most nem mentem 50 kilómétert, csak a parkba mentünk le. Mire hazaértem az adatbázis mérete visszaesett 30 GB-ra. Akkor esett le, a cassandra gyorsan szedte át az adatokat  a második node-ról, de aztán viszonylag sok időbe tellett neki újraoptimalizálni a saját adatstruktúráját. Szóval erre figyelni kell akkor, amikor a clustert buheráljuk.

A másik számomra bosszantó jelenség az az, hogy startkor valamiért végignyalogatja az összes adatfilet. 30 GB egy gépen az nem valami sok úgy egyébként, de azért nem szivesen várom meg amíg azt mind felolvassa arról az öreg sata vincsiről. Erre a dologra még nem találtam magyarázatot...

Ja és a cassandra nyithatott volna egy saját kis fejezetet a konfigurációs témánkban is, yaml konfig. Hogy szinesebb legyen a kép :-)

Amúgy idáig nagyon tréfás kis adatbázis, jó móka játszani vele. Vettem hozzá könyvet is, hogy jobban haladjak.

Lecseréltem a favicont. Hogy tetszik? :-)

Cassandra - eddig

Mostanában szabad pillanataimban a Cassandra adatbáziskezelőt próbálgatom. Ez amolyan szakmai kirándulásféle nálam, mindenféle konkrét cél nélkül kipróbálok dolgokat. Nem jutottam még messzire vele, tényleg a bemelegítő gyakorlatok: működtetés, programozás, őszintén szólva nekem a thrift is teljesen új volt - bár nem újszerű, engem a dolog valahogy nagyon emlékeztet a CORBA-ra, de nem jutottam ezzel se olyan messzire, hogy elkezdjem osztani az észt két kézzel.

Eddigi olyan igazi járatlan út szaga van a Cassandrának. A dokumentáció felületes és jobbára törött, az API minden release-ben változik, programozni kicsit hosszadalmas és fapados érzés, a hibaüzeneteihez tolmácsra van szükség. A legtragikusabbnak az üzemeltetés tűnik.

Viszont amire kitalálták, arra ailghanem jó: nagy mennyiségű adat analízis jellegű feldolgozása. Majd ha befejeztem a teszteket akkor valószinűleg én is azt mondom majd, hogy baró és tetszik. De  legtöbb embernek nincsen annyi adata, hogy ilyenekre legyen szüksége. Ez egy igencsak speciális eszköz. Kéremszépen legyenek szivesek megtekinteni a wikipédiát, ami kiválló példa arra, hogy a legtradícionálisabb LAMP architektúra is képes top 10 weboldalra jellemző terhelést elvinni. A lenézett és döglődő MySQL szolgálja ki.

Komolyan tartok tőle, hogy a NoSQL felhasználók jelentős része valójában csak a szép új technológia miatt nyomul az új generációs adatbáziskezelők körül.