2013. október 10., csütörtök

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.

2013. augusztus 4., vasárnap

Szavazz Seamplex-re!

Idén sem regisztráltam a blogot a gloden blog-ra, úgyhogy gondoltam megkérlek titeket: ha szavaztok, támogassátok Bakai Balázs blogját, a seamplex-et.

2013. július 29., hétfő

Két OOM Design Pattern

Van pár dolog, amiért nem szól se a checkstyle, se a findbugs, de egyébként nagyon egyszerű megtalálni és csillió van belőle, legalábbis melóban.

Az egyik az, amikor deklarálsz egy HashMap-et és úgy hívod, hogy cache, vagy odakommentezed, hogy ez egy cache. Ez sajnos nem igazán cache lesz, sajnos nagyon gyakran inkább egy OOM. Tipikusan amikor vagy egy singletonban találod, vagy eleve a "cache" statikus. Ilyenkor általában nem gondol az ember azokra a dolgokra, amik megkülönböztetnek egy igazi cache-t a HashMap-től: weak reference, TTL, méret korlátok, stb.

A másik ilyen tipikus gebasz, amivel találkozni szoktam forráskódban, az az amikor valaki felfertőzi a finalize metódust (amikor ilyet találok, mindig elkezdem keresni hogy erre vajon mi oka lehet) és odakommenteli rá, hogy "destructor". A finalize metódus nem destruktor. Ha nem olvastad a javadoc-ot, akkor erre akkor jössz rá, amikor a finallize metódusba valami lassú műveletet pakolt az elkövető. Szerintem ilyenkor leginkáb a HIV vírushoz hasonlít a hatása, lelassítja annyira a GC-t, hogy ne tudjon takarítani és természetesen OOM lesz a vége.

Ez ilyen könnyű győzelem, amennyiben megengedik hogy kijavítsd.

"Ennyi volt a Design Pattern mára,
fiatalember vigyázzon, rádzsael a paprikára!"

2013. július 24., szerda

Master Bean Design Pattern

Master Bean, a google szerint
A Master Bean pattern az, amikor akár EJB, akár spring, akár valami custom házitechnológia bevetése esetén van egy központi ojjektum, ebben található hivatkozás minden DAO, manager, service satöbbi objektumra és minden egyéb kód, a DAO, manager, service satöbbi objektumokat is beleértve ebből az objektumból keresi meg amire szüksége van.
Láttam különböző implementációkat, ezt a Master Bean-t van amikor injektálják, van amikor ősi singleton patternként getInstance()-elik és van olyan is amikor valami izgalmas módszerrel lookup()-olják.

Egyéb elnevezések és hasonló koncepciók: God Object, registry

A Facade nem keverendő a Master Bean-nel, mert a Facade a hívásokat delegálja általában több service objektum több metódusának, a Master Bean pedig csak visszaad egy hivatkozást magára a service objektumra.

Ennyi lenne a design pattern mára. Légkondi megy?

többnejű programming

Egyik nap ebéd közben azt mondtam a munkatársaimnak, hogy szerintem ahhoz hogy valamiből igazán jó legyél, ahhoz erősen fókuszálni kell arra a területre. Emiatt pedig csak 1 dologból lehetsz igazán jó, a többiből csak tűrhető. Például Albert Einstein fantasztikusan jó volt fizikából, emellett még egész tűrhetően hegedült. Ha több dologból is igazán jó akarsz lenni, akkor több dologra is fókuszálnod kellene, ez viszont ütközik a fókusz definíciójával. Milyen fókusz az, hogy fókuszálsz a ruby, a python, a linux kernel és a java technológiákra?

Nos az eredmény az volt, hogy leüvöltöttek. Mint amikor gimiben megkérdeztem hogy a kereszténység miért egyistenhit, amikor van egy rakás szent, angyal, ördög, satöbbi, teljesen kiakadt tőlem a tanár.
Azt mondják az egész csak idő-management kérdése. Ezt én nem értem, megfelelő idő-managementtel ki lehet bővíteni még 8 órával a napot?
Ez a dolog a red hat-nél valószinűleg azért van, mert a java programozónak is egész jelentős bash és linux teszten kell keresztülmenni felvételikor, ellenben szerintem a vizsgáztatók elég keveset tudnak kérdezni java témakörben. A legtöbben tehát a bash rémes szintaxisán és a python követhetetlen csomagrendszerén véreznek el, nem pedig a JPAQL részletkérdésein.

Elhiszem, hogy tűrhető python programozó lesz valaki, míg java programozásban igazán jó, de nem lehet valaki Rambó és Batman egyidejűleg. Még ha agymunkával bírná is, nem fér bele a napba.

2013. június 9., vasárnap

MongoDB - pár tapasztalat

Mostanában szabadidőmben MongoDB-re írogatok mindenfélét, gondoltam írok egy kicsit alaposabb beszámolót arról hogy milyen marhaságokat csináltam eddig vele. A legutóbbi régen volt és nagyon felületes.

Bosszantó apróságok


Nyugodtan kezdhetjük a rossz hírekkel, nem lesznek nagyon rosszak, inkább csak bosszantó apróságok.

Az egyik ilyen az, hogy 32-bites rendszeren a mongodb behúzza a kéziféket és max 2 GB méretű adatbázist enged. Ez lófüffy, fogalmazzuk talán inkáb úgy, hogy 32-bites rendszereken a mongodb röpképtelen.

A másik apróság, amibe belefutottam még az elején, az az hogy a OpenVZ virtuális gépeken valami okból memóriaszivárgás van a MongoDB szerverben és ettől teljesen használhatatlan. Bevallom nem néztem igazán utánna, de itt került fel az OpenVZ a ganajlistára. Miféle virtualizációs technológia az, amivel egy adott szoftver a vendég operációs rendszerben behal? Gubancos, gondolom.

Sokkal inkáb bosszantó a MongoDB hanyag viselkedése a tárhellyel. Az alapbeállításokkal  folyamatosan logolja az összes adatmódosítást, ami rettenetes méretű logokat eredményez nálam. Kicsit kellett keresgetnem hogy hogyan lehet kikapcsolni.

A másik tárhely-kellemetlenség 3 GB-os journal, amit az adatbázis inicializálásakor létrehoz. Bár a memóriafogyasztása egyébként nagyon frankó lenne, ez a 3 GB journal kicsi adatbázisokhoz nagyjábol diszkvalifikálja. Ki lehet kapcsolni, akkor kicsit visszavesz a sebességből és egy esetleges crash teljesen hazavágja. Akkor most gondolkozzunk el rajta hogy mit szeretnénk inkáb.

Klassz dolgok


Szóval az egyik klassz dolog amit igazán kedvelek a MongoDB-ben, az UPSERT, ami az "insert or update"-re egy rövidítés. Ez pl log feldolgozáskor marha gyors tud lenni és az alkalmazáson is nagyon sokat egyszerűsíthet. Az upsert egyszerűen úgy működik, hogy megmondod a keresőfeltételt és egy dokumentumot. Ha talál a keresőfeltételnek megfelelő dokumentumot, akkor ahhoz hozzávágja az új dokumentumot, tehát azokat a kulcsokat, amik a régiben voltak, azokat felülírja (itt lehet trükközni), ha nincs ilyen kulcs, akkor hozzáteszi a dokumentumhoz. Amennyiben nem talált ilyen dokumentumot, akkor csinál egyet, ami megfelel ennek a keresésnek, azaz benne lesz a keresett kulcs és a bedobott dokumentum.

Nézzük a fent említett okosítást: például nekem hasznos az, hogy egy dokumentumban egy tömbhöz fűzök hozzá értékeket illetve érték párokat. Erre jó a PUSH, amivel a régi doksiban nem írja felül a régi értéket, hanem csak hozzáappendel. Ez upsert esetében is teljesen jól muzsikál.

Az marha sokat segít, hogy nem kell csekkolni, hogy egy dokumentum létezik-e már a feldolgozás során.

A sebesség a másik baró dolog. Eleinte voltak olyan tévhiteim, hogy az adatmennyiséggel egy beágyazott derby is el fog boldogulni. A derby hozta is a formáját az első pár órában, amikor azonban a memória méreténél nagyobbra nött az adatbázis mérete, beleállt a földbe a teljesítménye.

Trükkök


Relációs adatbázishoz szokott barátaim: egy pár dolgot át kell gondoljunk, amikor mongodb országba települünk.

Például relációs adatbázisokban nagyjából magánügy, hogy hogy nevezed a tábláidat és az oszlopokat, a teljesítményre aligha van hatással, mert nem kerül bele minden rekordba, legfeljebb amikor lekérdezést küldünk az adatbáziszervernek akkor kicsit több byte-ot küldünk. Nem nagy ár, ezért inkáb érthetőre próbáljuk faragni a relációs sémát szép oszlopnevekkel. A különbség egy dokumentum-alapú, séma-nélküli adatbázisnál az, hogy minden dokumentumban benne vannak a kulcs-nevek, így a rövidebbet jobb sebességgel jutalmazza az adatbázis szerver.
Én pofátlanul mindent egy-két betűsre rövidítettem. Ezt a dolgot ha valaki átvenné tőlem, nagyon gyűlölne.

Ezzel kapcsolatban jut eszembe az _id kérdése. A mongoDB minden dokumentumba beletesz egy _id nek nevezett, 12-byte hosszú azonosítót, amiben a szerver azonosítója, egy random szám, valami sorszám, a heti lottó nyerőszámok és ilyesmi tlálható. Az én alkalmazásomhoz nem volt igazán hasznos, de egy databig nem jöttem rá erre:
A dokumentumodnak amúgy is kell valami, ami amolyan elsődleges kulcs. Egyszerűen ezt a dolgot hívd _id-nak. Még akkor is, ha az "id", az "azon", és a "customerid" elsőre jobban tetszik. Az _id ugyanis nem kell, hogy a fenti szám legyen. Lehet szöveg, szám, akármi. Értelmesnek tűnik saját ID-t csinálni.

Emellett persze az _id az a dolog, ami mindig indexelve van, nem is kell kérni és nem is lehet kikapcsolni.

Indexek: meg tudom erősíteni, hogy amit nem indexelsz, arra a lekérdezés egészen lassú lesz. Ezt gondolom gondoltad :) Az indexek viszont rendesen meglendítik a memóriahasználatot, szóval okosan azzal az indexel.

Még egy trükk, amiért lehet hogy máglyára küldenétek. Olyanra is volt szükségem, hogy egy dátumokhoz számértékeket rendeljek. Eleinte így csináltam:
[{k: Date(), v: 1}, {k: Date(), v: 3}, {k: Date(), v: 4}]

Ez kicsit terjengős dolog, úgyhogy azt találtam ki, hogy a dátumot szöveggé alakítom, mégpedig egy nagyon tömör szöveggé (amire összeütöttem egy 75 vagy 76 digitből álló számrendszert, az még könnyen olvasható) és az így adott dátumokhoz simán csak a számot rendelem. Ilyen lett:

[{"8V3": 1}, {"8V4": 3}, {"8V5": 4}]

Ennél én sajnos nem tudok tovább egyszerűsíteni, de ha egy dátum csak egyszer fordulhat elő, akkor csinálhatnám így is:

{"8V3": 1, "8V4": 3, "8V5": 4}

Ez ocsmány trükknek tűnhet, de nagyon sokat segített az adatbázis  méretének redukálásában. Illetve vehetek nagyobb gépet is persze. Vagy kérhetek karácsonyra.

DAO kérdések


No utolsó beteg design patternem következik így vasárnap este...

Relációs adatbázisoknál a resultset-eket tipikusan egy listává alakították át a DAO-k, ehhez az egész resultsetet elösször végigolvasták és objektumokká formálták. Na ez nagy adathalmazokhoz soha nem volt jó ötlet, de olyan ritkán kellett ilyesmit csinálni. És most mintha mást se kellene.

Szóval én meg akartam tartani a listát mert olyan egyszerűen lehet vele bánni, viszont eszem ágában sem volta teljes eredményhalmazt berángatni a memóriába. Szóval a megoldás egy olyan lista lett, ami Closable is. Így viszont a DAO metódosukat hívó kódnak be kell zárnia a listát. Ez a része szokatlan és kicsit bizonytalan vagyok a kérdésben. A problémát azért megoldotta.


Kotlin nyelven azért egészen egyszerű a dolog a (szerényen dokumentált) use funkció segítségével.

dao.getBlaList().use { it.each{ ... } }



Ezt nyugodtan fikázzátok le, nem garantálom hogy átírom de garntáltan érdekel a véleményetek! No ennyi mára, boldog hétfőt!

Tartozom még egy beszámolóval a linux konferenciáról, nem éppen java de volt java is.

2013. május 17., péntek

Google Compute Engine árak

A Google Compute Engine-n ha csinálsz egy 1 TB-os merevlemezt, akkor az a mai árazás szerint az havi 102 USD-be fog kerülni. 102 USD az ma 23.000 forint vagy úgy 2.000 korona. Ebben még nincs benne az ÁFA - ami Magyarországon a legkevésbé sem elhanyagolható tényező.
Ezért az árért a sarki hardver boltban alkudozás nélkül kapsz egy 1 TB-os merevlemezt 2 év garanciával, ebben már benne van az ÁFA is.

A GCE minden I/O műveletet kiszámláz. A bevásárolt merevlemez ilyet nem csinál, viszont áramot zabál.

Sebesség: Egy GCE gépemen kipróbátam egy dd paranccsal felszívni egy 20 GB-os lemez tartalmát a /dev/null-ba. Elsőre 90 MB/sec sebesség jött ki, de aztán egy másik diskről próbáltam ugyanezt és azzal csak 30 MB/sec jött. Az írási sebességben voltak hasonló eltérések, de az persze egy kategóriával lassabb volt. A Compute Engine SLA egy szóval nem említi, hogy mennyivel kellene jönnie. Bízzuk a szerencsére.
Ugyanez egy sima merevlemeznél mondjuk elég egyszerű, egy sima bolti SATA vincsitől számíthatsz 100 MB/sec sustained read, és úgy 80-90 MB/sec sustained write sebességre.

Ha már GCE SLA: Jól értem hogy 5% unplanned downtime esetén visszakapom az ár felét? Több mint egy nap havonta és csak a fele? Ez nem hangzik jól, annyinál már az egészet hagynám a fenébe. És havi fél óra downtime belefér? Nem tűnik úgy, hogy nagy megbízhatóság lett az árba belekalkulálva.

A GCE csak egy példa. Sokkal olcsóbban is lehet virtuális szervert szerezni a sufni webappjainknak, de szerintem még sokat kell hogy alakuljon a publikus felhők árazása.