Nagy terhelésű rendszerek fejlesztése előadás

Holnap este a Docler Akadémia sorozatában a nagy terhelésű rendszerek fejlesztéséről tartok bemutatót.

Az előadás gyakorlat-orientáltan, a kezdetektől felépítve mutatja be a téma fontos szempontjait:

  • Mitől nagy terhelésű egy rendszer?
  • Mik az elvárások?
  • Hogyan osszuk szét a terhelést?
  • Mire kell odafigyelni, mire lesz szükség?
  • Mi az a global load balancing?
  • Rakjunk össze egy blogszolgáltatást!

Az előadást ajánlom mindenkinek, aki szeretne megismerkedni az ilyen rendszerek felépítésével és költség-vonzataival akár fejlesztés, akár projekt menedzsment oldalról.

Az előadás időpontja: 2011. január 11. kedd, 18:30
A helyszín: Docler Irodaház, 1101 Budapest, Expo tér 5-7.
Térkép: https://www.doclerholding.com/hu/contact/
További információ: http://www.facebook.com/event.php?eid=150088005041675

Az előadás ingyenes és mindenki számára nyilvános.

Minden érdeklődőt szeretettel várunk!

( sj | 2011. 01. 10., h – 13:37 )

video, pdf, ppt, whatever elerheto lesz az eloadasrol?

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Szerencsére nem bürokratikus probléma, inkább erőforrás kérdése. Én már láttam a leendő videós siteot, simítások vannak már csak hátra, ergó záros határidőn belül (néhány hét) fölkerül és elérhetőek lesznek rajta az eddigi nyilvános Docler Akadémia előadások is.

Update: fogok postolni, ha kint vannak a videók.

( Dacr (nem ellenőrzött) | 2011. 01. 10., h – 15:30 )

Annak fényében, hogy pár napja voltam bent nálatok, szerintem elmegyek, úgy is egy sarokra lakok.

Szerk.: jut eszembe! Nincs erről valami hírleveles megoldásotok? Tudom, van Facebook oldalatok rá, de azt nem nagyon szeretem használni, ha nagyon nem muszáj.

masterpiece :-)

egy aprosaggal azert hadd vitatkozzak: 10:15 korul van egy olyan allitas, miszerint, ha a session-t csak 1 gepen taroljuk, es az a gep kiesik, akkor az egesz site-unk meg fog halni. IMHO ennyire azert nem sulyos a helyzet, max. arrol lehet szo, hogy kiesel, es ujra be kell jelentkezned (immaron egy masik gepre)...

Az adatbazisoknal +1 a master-slave replikacionak, viszont hianyoltam egy caching layer beiktatasat*. A LiveJournal odakat zengett a memcached-rol, aminek az ugyes hasznalataval az sql szerver load-ja a korabbi ertekrol drasztikusan leesett.

Az egyes szolgaltatasok lekapcsolhatosagat viszont megjegyzem :-)

24:06-nal emlited, hogy a 'static' szerverbe tehetunk TB-os kapacitasu diszket. Technikailag valoban, de lehet, hogy IO-ban (ha kell, es nagy terhelesu rendszereknel valoszinuleg kell) jobban jarunk tobb kisebb szerverekkel. Egy IBM expansion-ben TB-os diszkek helyett gyakoribb a 73.6 - ~140 GB-os verzio, semmint a TB-os HDD-k. Ill. mindegyik(?) webszerver tud olyat, hogy file-okat memoriaba map-pel, igy pl. a logokat memoriabol tudja kuldeni, es nem kell hozza diszkmuvelet. Adott esetben jol johet, bar a komplexitast noveli.

27:00 korul szo van a "blog sql" es a "kozponti sql" szetvalasztasarol, ill. az utobbi ele memcached-et tenni. Ez azonban imho megint komplexitas novelo. (Adott esetben) jobb (lehet), ha csak egy(fajta) sql (cluster, ha kell) van, es az ele tesszuk a caching layert.

Erdekes viszont az, hogy egy user static dolgai ~3 gepen legyenek. Ha pedig az egyik gep kiesik, akkor a user dolgait lekoltoztetni egy ujabb gepre (hogy ujra legyen meg a 3). Mi lenne, ha ugy mereteznenk a static szerverek szamat ill. a roluk kiszolgalt usereket, hogy ha 1 kiesik, akkor a masik 2 is siman el tudja vinni a forgalmat? Igy nem kellene a koltoztetessel komplikalni a dolgot.

*: kesobb szoba kerult

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Mint az előadásban mondtam, a "kiesik" egy kicsit ambivalens, mert ha két gépről beszélünk, akkor garantálni kell, hogy tényleg meghalt a másik, különben szép kis splitbrainnek nézhetünk elébe, az pedig sessionöknél meglehetősen kellemetlen. Ez külön témakör, akár egy önálló előadást is lehetne róla tartani, mindenkinek el kell dönteni, hogy mennyire fontos a konzisztencia, rendelkezésre állás, stb.

Ami a caching layert illeti, ezt alkalmazás szintjén kell megtervezni, a gyakorlati példában ezt meg is mutattam, az adatbázis replikációhoz viszont valójában nem sok köze van, noha együtt használjuk.

A static kiszolgálásnál az volt a tapasztalatom, hogy a felhasználók valami irtózatos mennyiségű cuccot töltenek fel, viszont a nagyon nagy részét nem is nézik. Itt jó lenne, ha volna a Linux kernelben stabil ZFS támogatás, de ennek híján a storage balancernek kell megoldania azt, hogy a gyakran használt cuccok sok helyen legyenek, így eloszlik az IO terhelés.

A központi SQL szétválasztásnál már akkora méretekről beszélünk, hogy tényleg nem 2-3-4 szerverről van szó, hanem mondjuk 20-ról. Én alapvetően nem szeretem az olyan megoldásokat, amikor a rendszergazda "megoldja" a cachelést, ennek a problematikáját nyugodtan gondolja csak végig a programozó, mert annak sokkal jobb a hatásfoka.

Ami a minimum redundancy level kérdést illeti, természetesen úgy kell méretezni, hogy egy user két szerverről is tudjon üzemelni, viszont a hosszú távú fenntarthatóság jegyében mindenképpen meg kell csinálni a balance programot, hiszen valamikor akarsz FSCK-zni, disket cserélni, stb. és jobb, ha nem kell kézzel szórakozni az ilyesmivel.