2011. október 29., szombat

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

2011. október 19., szerda

multitenancy

Egyik este miután a több munkatársamtól is okosodtam virtualizációról és cloudról, operációs rendszerekről, kicsit már kiégett aggyal ez a történet állt össze a fejemben (bár valószinűleg nem első alkalommal)

Úgy kezdődött, hogy célgép. Mint pl az IBM csodálatos lyukkártyás rendszere még az 1940-es években amivel (a Corporation cimű film, emlékeztek... és más források szerint) oly sok embert továbbítottak a másvilágra. Ezek csak erre az 1 dologra voltak jók, nem volt cserélhető programjuk. Ahhoz képest azért igazán drágák voltak, de még így is sok pénzt takarítottak meg.
Ahogy tellett az idő, az emberek szerettek volna jobb befektetést csinálni, azzal, hogy többféle dologra használják a gépet. Így született a program. Eleinte 1 program futott egy időben egy gépen, de cserélhető volt. Ennél nem nehéz jobbat elképzelni: szeretnénk, ha egy időben egy gépen több program is futhatna.
Hát rohadtul leegyszerűsítve valami ilyen igényből született az operációs rendszer. Persze az OS pár szép dologgal jön még: filerendszer, hogy ne kelljen a disk-kezeléssel a programnak foglalkoznia, felhasználók, I/O, hálózat, felhasználók, memóriakezelés, sorolhatnám... tök jó helyen vannak ott. Kell mind.

Amikor viszont már több felhasználó több programja fut az 1 szál drága vasunkon, akkor igen valószinűvé válik, hogy össze fognak veszni az erőforrásokon. A felhasználók is, de a programok még inkáb. Gondolom nem kell példákat hozni memória-zabáló programokra, vagy CPU-zabólókra. Ez még a kissebbik baj lenne, de a konfigurációjuk is igencsak elburjánzott. Itt példaként említeném a hosts filet, amibe mindenki mindenféle ocsmányságot beletol, amit a DNS admin nem akart megcsinálni. Aztán vannak a szoftver-függőségek, kifejezetten az enterprise genyákon pl az SAP-nek meg az Oracle-nek kötelező valami olyan oprendszert venni, ami tanúsított ésatöbbi. Az adminisztrációval is kezdtek bajok lenni. Szóval oda jutottunk, hogy majdnem minden nagyobb rendszerünkhöz mégiscsak külön szervert veszünk. Bár mostanra nem egetrengetően drága egy szerver, azért mégiscsak drága _minden_ szoftverünkhüz külön szervert venni. Valahogy tényleg egyre több és több szoftvert használunk ahogy egyre több dolgot próbálunk számítógéppel csinálni.

Kis kitérő: amit a java csinál több szoftver-rendszer békés együttélése címén egy VM-en belül az a gyakorlatban ritkán vezet boldogsághoz. Igen, nem nyúlhatsz bele immutable objektumokba, nem babrálhatsz bele másik webapp kódjába, de ennyi és kész. A másik app felzabálja a memóriát vagy agyonhajtja a GC-t, felstartol 1000 idióta szálat, beblokkolja az összes http listener szálat, elfelejti zárni a streameket és kifutsz a file handle-kből, sorolhatnám. Van még itt ez az extrémebb eset is a the daily WTF-ről, nagyon gonosz. Ezer módon lehet az együttélés két java webapp között zűrös. Persze a jó programokra ez nem vonatkozik, de azokkal nincs is semmi gebasz, most a hülyékről van szó. Nem tudom a hülyék többen vannak-e, de azok több időmet viszik el.

A kis kitérő után eljutottunk a virtualizációhoz, ami lehetővé tette, hogy egy vason több oprendszer is futhasson a saját agyontákolt konfigurációival, a összebuherált szoftvereivel és nem vesznek össze, nem is tudnak egymásról.
Egyvalami nagyon nem tetszik még ebben: Rohadt nagy, drága szerverek. Ellentétes az általam tapasztalt valósággal.  Egy hazai Pince Programming Kft-nél, de akár a százmilliós kormányzati projecten is a következőképpen működik a fejlesztői infrastruktúra: a rendszergazditól elkunyizzátok azt a Juliska néni leselejtezett gépét, amit már odacsűrt a kukára de még nem vitték el. Kicsit köhög a vincsi de még megy. Toltok rá Kedvenc Linuxot, Jenkinst, subversiont, gitet, sonart vagy amit akartok, berúgjátok az asztal alá és hajtjátok. Néha a takinéni kirángatja belőle a drótot (miközben letörli a képernyődet vizes ronggyal, pl amivel felmosott), ilyenkor kicsit kurblizni kell. Néha a rendszergazdi ellopja és kidobja megint, a kukásoktól visszaszerzitek. Ez így nektek ismerősen hangzik?

A másik probléma a nagy szerverekkel: egyszer minden gép befosik. Én olyat még nem láttam, ami nem. Jöhettek a legendákkal a befalazott gépekről, amit a nagybátyád unokatestvérének régi munkatársa másodkézből hallott. Amikor a crash megtörténik, nem 1 rendszered fekszik hanyatt, hanem mind. Kellemetlen.

Szóval magánvélemény erről a sima virtualizációról:

  • Szerintem tipushiba 1 böszme nagy gépet venni és arra tenni az összes VM-et. Ez mainframe-szerű maszturbáció. Ott fog állni az összes engineer és fogdossák a nagy gépet hogy jajjdejó. Persze jó én is birom ezeket a nagy böszme dobozokat, de több kicsi géppel jobban jársz teljesítmény és biztonság szempontjából is.
  • Az nagyon fontos, hogy a virtuális gépek ne legyenek szerverhez kötve, mert amikor égnek, együtt megy füstbe a valódi vassal a virtuális géped.
Szóval végülis odajutottunk a cloud-hoz. A virtualizáció csak egy lépés volt és a következő lépés a cloud. Vannak publikus cloud-ok, amik egész olcsón rohadtul nagy számítási kapacitást árulnak. Vannak private cloud-ok, amik a saját vasadon lehetővé teszik, hogy a virtuális gépeidet futtasd.

Ami nekem az egészben furcsa, hogy pl egy virtuális gépen egy java VM-et futtatunk. A host OS is és a Guest OS is virtuális memóriát kezel. Hány layer virtualizáción mentünk keresztül? Meg mennyire is lett ez az egész komplex?

2011. október 17., hétfő

OFF: Döglött méhecske

A múlt héten a google bejelentette, hogy leállítja a buzz-t és pár másik API-ját, mert nem termeltek elég forgalmat. Nem vagyok tisztában azzal, hogy mi az "elég" egy google-méretű galaktikus birodalomnak, de ez nem az első eset, hogy "így jártunk". Néhány példa, amiből tanulhatunk:
  • A wave programot leállították, azóta az apache incubatorban látható (nem akarom olvasgatni, nálam a trehány kód kategóriába tartozik)
  • A translate API fizetőssé vált. A translate nagyon igéretes dolog volt annak idején, de aztán sehova se fejlődött. Ma a google translate a félrefordítás szinonímája, nem olyasmi amiért az ember igazán szivesen fizetne is akár. A translate toolkit is évek óta gondozatlanul áll, pedig az is nagyon hasznos kis eszköz lenne.
  • Többezer feltöltött maplet után a google maps is egyszerűen kidobta azt a soksok időt amit a rá fejlesztők beleöltek, megtartottak pár layert.
  • A google books talán amazon-killer akart lenni. Hát, azt hiszem lecsúszott róla. A book preview azért klassz.
  • A google checkout szintén megragadt amerikában és a britteknél. Akkor meg a boltok nyilván inkáb paypal-hez integrálódnak, az van kb mindenhol. Nem szeretném megpróbálni visszatartani a lélegzetemet addig, amig Magyarországon használhatóvá válik.
  • A buzz-t twitter-killernek szánhatta talán a google. Ha annak szánta, akkor eleve bukásra volt itélve.
  • A google+, aminek a javára kinyírják a buzz-t, alighanem ott lesz valamelyik a jövő évi takarítás áldozatai között. Már most ha bemegyek, a legfrissebb új dolog amit látok talán pár hetes. Jó oké van benne egy-két jó ötlet, amiből tanulhat a lófacebook ha akar.
Szóval ha azt a célt tűzik ki minden új projectüknek, hogy csak akkor tartják életben, ha totálisan átforgatta a teljes internetet és kinyírta a facebook-ot és a twittert, akkor kát a gőzért, egy-két éves periódus után minden projectjüket le fogják állítani. A google+-t is, ez gondolom már most gyanús a legtöbb embernek.

Ebből mindenesetre azt a következtetést vontam le, hogy túlságosan is google-fan voltam idáig. Túl sokat építettem a google szolgáltatásaira és aztán ezeket a szolgáltatásokat a google szépen egyenként kihúzta. Az ember kicsit másra számít egy nagy cégtől. Az nagyon szimpi, hogy a google nem áll be a sorba, nagyon becsülöm érte, de én a jövőben N+1-szer meggondolom, mielött bármilyen API-jukra építek valamit.

Pillanatnyi ötlethiányban szenved az informatika. A social networkok kiábrándulási fázisba érkeztek, Steve Jobs, az apple mágusa meghalt. A microsoft úgy 10 éve nem jött elő semmi újjal. A google nem tud olyan ötlettel előállni, ami túlél egy telet. A sun behalt. Az Oracle képtelen foglalkozni a java közösséggel. Szerintem most kell keresni a következő hullámot. Vajon mi lesz az?

2011. október 11., kedd

Platform

Folyik a platform háború...

A platform filozófia kicsit más, mint a szolgáltatás filozófia. A szolgáltatód ha kifexik vagy nem sikerül egy vitás kérdésben egyetérteni, akkor szépen átmész egy másik szolgáltatóhoz, csókolom. Ilyen pl egy internet-szolgáltató, video-encoder, DNS-szolgáltató. Fáj, nyilván, de pótolható, csak egyetlen dolgot csinált neked, a többi ezret másikat valaki más. Mindenesetre amikor a platformot húzzák ki a lábad alól, akkor sokkal nagyobb gebaszban vagy. A platform egy rakás integrált szolgáltatás. A válogatás többnyire nagyon limitált lehetőség, egy csomagban kapod az egészet és boldogulj vele ahogy tudsz. Nekem ez az ellenszenves vele, én jobban szeretek válogatni.
Azért persze igérik, hogy minőségileg ezek a platformok jobbak, mint amiket összebuherálnak az emberek amúgy. Ez szerintem kb ezt jelenti: az általános problémákat (hálózat-kiesés, adatvesztés, session replikáció problémák, satöbbi) ami mindenkit érint, legnagyobb priorítással kezelik, míg a speciális esetekkel kapcsolatban jó eséllyel magadra maradsz. Ez érthető, ilyen egynek lenni a millóból. Nekem ez őszintén szólva szimpatikusabb is. Nem fognak a management éppen aktuális legmagasabb priorítású projectje miatt speciális httpd url rewrite-okat megcsinálni, senki sem kap külön gépeket, ahol csak az ő cókmókja fut, nem dobnak be egy külön JAR filet valakinek az appszerverbe, csak azért mert szerinte az kell. Mindenkire ugyanazok a szabályok vonatkoznak. A házi-platformok örökké halálra vannak hackolva. Izgalmas proxy beállítások és url-rewriteok, nem is beszélve a összepatchelt appszerverekről, amibe beledobálták a xerces tizezer évvel ezelötti verzióját, mert az jó volt valakinek, a többiek meg majd megszokják. Persze mindegyik PaaS-nak megvan a saját problémája, pl a cron cuccok a gúglinál.

Lényegében nincs más kifogásom a PaaS ellen, csak az a cefet-nagy bizalom és lelkesedés, amivel az emberek belemennek (hype). Ezt a platform kérdést mindenki úgy képzeli el, mint a bal oldali képen (ahol persze ő nem a sikoltozó tinilány a szinpad elött, hanem természetesen szólógitáros énekes rockmetálisten) aztán X hóbap eltelltével baromi sokan érzik úgy, hogy inkáb a jobb oldali képen látható objektumhoz hasonlít a platformjuk.

Platform
Platform
Uram, a halálcsillag platformja támadásra készen áll, várjuk az utasításait.

2011. október 7., péntek

Átkeresztelés

Amíg fordul a GWT-s csoda és újraindul az appszerver, de még nem feküdt meg totálisan a gépem, ezt a kis ötletemet osztanám veletek:

Jó, muszáj a termék nevét beleírni a packagekbe, de ne írd bele se osztályokba, se változókba, adatbázis táblák és view-k neveibe, konfigurációs paraméterekbe ha lehet. Semmibe, amit nem akartok majd átírni minden egyes installációban, amikor átnevezik a projectet. Minnél kevesebb, annál jobb :-)
Olyan projecten dolgozol, amit nem neveznek át? Jajj, dehogynem nevezik. Van, aki semmi mással nem foglalkozik. Majd meglátod! :-)