2012. december 31., hétfő

[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!

2012. december 21., péntek

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.

2012. december 20., csütörtök

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 :-)

2012. december 19., szerda

elszállt ötletek: powersave license

Arra gondoltam, hogy ha pénzes private cloud-ot fejlesztenék (mint ahogy valójában, csak az ingyen van/support szerződéses), akkor csinálnék egy olyan licenszelési módot, hogy power-saving license. Ez azt jelentené, hogy amennyi áramot megtakarít neked a cluster azzal, hogy a felesleges kapacitást kikapcsolja, na annak a felét kérnénk el licenszdíjként. Nyilán a másik fele az ügyfélé maradna.

Szerintem egész attraktív licenszelési mód, hogy azt mondjuk hogy csak a megspórolt villanyszámládból kérünk egy kicsit. Ugyanakkor valójában nem hozna keveset. Egy PC jellegű gép ha folyamatosan működik, akkor 5-10000 forintnyi villanyszámlát csinál. Akár csak egy kis cég szerverszobájában is pörög ilyenből néhány tucatnyi. Sok múlik azon persze, hogy mennyire van overcommit-olva a szerverfarmod, de kicsit okosan, megtakaríthatod az üzemidő jónéhány százalékát, ebből szerverenként havonta pár-ezer forintnyi zseton jönne, ami nem sok, de sok szerverrel felszorozva már szép. Menj be a szerverszobába és számold meg a dobozokat :)

Szóval a dolog szépsége az lenne, hogy nagyon olcsónak tűnik, de nem az, és ennek ellenére amikor kifizetted akkor még mindig nagyon olcsónak tűnik :-)

2012. december 18., kedd

elszállt ötletek: ami a tömörítésből még hiányzik

Van egy mondás, miszerint egy rendszerben egy adott pillanatban csak egy komponens a bottleneck. Ezt megfigyelheted akkor is, amikor egyik gépről nagyobb mennyiségű adatot pumpálsz át etherneten: vagy a merevlemez, vagy a hálózat lesz teljesen leterhelve, a processzor meg közben vakarja a tökeit.
Arra gondoltam, hogy ezen kicsit megpróbálok segíteni, de ha egyszerűen csak bedobok egy tetszőleges tömörítő algoritmust a sorba, akkor könnyen lehet, hogy a CPU-t rúgom agyon és ezzel azt nevezem ki új bottleneck-nek, míg innentől a hálózat forgalom lesz alacsony. Minden vason külön ki kellene találnom hogy mennyire jó ötlet egy tömörítést közbedobni, és nem akarom, mert már a másodiknál is nagyon unnám.

Egy olyan InputStream/OutputStream párosra gondoltam, ami egy kellően nagy bufferrel rendelkezik. Az output része az írásra itélt adatokat csomagokra bontaná és egy szálon figyelné hogy melyik mennyi idő tellik el a beérkezés és a bufferből távozás között. Ha úgy becsülné meg, indítana egy szálat, ami a buffer egy részét egy tömörítő algoritmussal betömörítené és hozzátenne egy nagyon rövid headert (pl 1 byte) ami jelezné hogy tömörítve van-e és ha igen milyen algoritmussal. Az input része csak csekkolná ezt a headert és szükség esetén kitömörítené a csomagot. Nyilván ez egy kicsi overhead.

Így a viszonylag gyenge hálózati kapcsolatot kicsit felgyógyíthatnám egy processzorral, de annélkül, hogy esetleg bizonyos esetekben nagyon durván kiszúrjak magammal.

Egy másik kapcsolódó ötlet az az lenne, hogy egy olyan tömörítő input/output streameket próbálnék ki, amelyek ellenőrzik (lehetőleg csak egyszer) hogy az adott rendszeren létezik-e az adott tömörítő algoritmusnak natív változata. Ha van akkor azon átpipe-olva tömörítené az adatokat, ha pedig nincs, akkor egy java implementációra terhelné. A natív implementációk általában véve gyorsabbak, még azzal együtt is, hogy context-switch ésatöbbi.

Szóval ez csak szimpla tuning. Nincs autóm, úgyhogy azt nem tudom brümmögtetni :-) Ja és nem is szeretnék, mert nem szeretem a brümmögést :-D

Hát ennyi lenne az ötlet, jöhetnek a kövek.

2012. december 17., hétfő

BS szótár: upstream és downstream

Egyes open source szoftverek esetében (pl ovirt) gyakran kerül szóba az upstream és downstream verzió, majdnem minden esetben amikor felhasználókkal beszélünk akkor a felhasználó visszakérdez hogy "Az up/downstream vajon mi?"

Cefet egyszerű: az upstream az a "community edition" megfelelője, a downstream meg a pénzes cók. Csak ezt így nem illik mondani :-)