Nagy terhelésű rendszerek cikksorozathoz kapcsolódó előadás
Itt a Weblaboron született három cikk a nagy terhelésű rendszerek fejlesztése témakörében. Ez inspirálta a soron következő Docler Akadémia előadást.
Az előadás 2011. január 11-én 18.30-kor kezdődik, a cikkeket kiegészítendően a fő hangsúlya az alkalmazás üzleti és műszaki tervezésén lesz.
Az előadás tervezett időtartama: kb. 1 óra.
- Az előadás időpontja
- 2011. január 11., 18.30
- A téma
- Bevezetés a nagy terhelésű rendszerek fejlesztésébe
- Az előadó
- Pásztor János (proclub)
- A helyszín
- Docler Irodaház, 1101 Budapest, Albertirsai u. 3-11.
Az előadás mindenki számára nyilvános és ingyenes, előzetes regisztráció nem szükséges.
■
sajnálom
Összefoglaló lesz írva az előadásról? Esetleg stream, vagy videófelvétel? :)
Igen
Más: ha esetleg van last minute kérésed, kérdésed, azokat nyugodtan tedd föl itt vagy az esemény Facebook oldalán, igyekszem rá válaszolni.
php
Illetve én arra lennék kíváncsi például, hogy a nagy terhelésre szánt kódokat hogyan kell felkészíteni a több szerveres kiszolgálásra. Több helyen olvastam, hogy nem elég pusztán a szerverek számát sokszorozni, nagyon fontos, hogy a programkód is fel legyen készítve a többszerveres futásra.
A másik kérdés, ami foglalkoztat: Adott például a facebook.com, ami mögött tudjuk, hogy rengeteg szerver és terhelés elosztó áll. Tudom azt is, hogy lehetséges (és bizonyos esetben szükséges is) egymás mellé több terhelés elosztót tenni, ugyanakkor nem világos, hogy az egyetlen domain cím, hogyan találja meg az akár 10 - csak mondtam valamit - load balancer-emet.
Ha ezekre is kitérsz, nagyon megköszönöm.
Tamás
kérdés
Olvastam arról, hogy alapvetően az oldal legtöbbet használt funkcióit kell szétszedni először úgy, mint képek, adatbázis, frontend. Gyakorlatban ez hogyan valósítható meg?
Az adatbázis része világos, hiszen a MySQL biztosít cluster manager programot, amivel viszonylag egyszerűen felépíthető az adatbázis oldal. Hogyan kell és érdemes a fájlokat tárolni, ha a cél elsősorban a redundancia - a fájlok biztonsága -, és a sebesség mondjuk csak a második szempont? (Feltételezem, hogy ez minden nagyobb oldalnál ebben a sorrendben van)
Te, mint szakember, milyen operációs rendszert ajánlasz ennek az egésznek a kivitelezésére? Magam részéről a CentOS-t tanulmányoztam ebből az irányból és legjobb tudomásom szerint a Google is ezt használja. Persze ez nem jelenti azt, hogy nekem is ezt kell.
Végül pedig, mi a véleményed - a számomra újnak számító - nginx-ről egy ilyen sokszerveres környezetben? Érdemes-e használni, vannak-e vele jó tapasztalataid, esetleg negatívak?
Köszönöm a válaszokat!
az eloadas tematikajabol lathato
komplex rendszerek nagyobb, onallo komponensekre bontasa tenyleg gyakori, es valoban ott erdemes kezdeni, ahol konyen meghuzhato ez a hatar, tehat konnyen szetvalaszthatoak a rendszerek(es itt nem csak technikai szempontbol, hanem a rendszerek kozti logikai dependenciakat figyelembe veve), valamint ertelemszeruen ott erdemes kezdeni.
Tehat pl. ha kepfeltolteseket kezelsz a forumban, kezelsz a hirek hozzaszolasaiban, kezelsz a hirekben, etc. akkor ahelyett, hogy mindenutt csinalsz valami kicsit/nagyon eltero megoldast ra, kiszervezed egy kulon applikacioba, amihez csinalsz valami jol atgondolt interface-t, amivel kivulrol a tovabbiakban mind a hirkezelo, mind a forum motor hasznalni tudja.
ezaltal, hogy szetszedted oket kulon rendszerbe, teljesen fuggetlenul tudod oket skalazni, mint a rendszer tobbi reszet, teljesen mas platformot (oprendszer, programozasi nyelv, etc.) hasznalhatsz ehhez a komponenshez, es akar hetente at is irhatod az egeszed, egeszen addig, amig a jo elore definialt interface-t meg nem valtoztatod.
MySQL Clusterrel nem vagy kisegitve azert, egyreszt nem biztos, hogy neked pont a Mysql az idealis valasztas, masreszt a sima mysql es a mysql cluster kozott is joval tobb kulonbseg van, mint hogy az utobbiba lehet lapatolni a szervereket, es majd jol skalazodik magatol.
ha ezeket nem ismered meg, mielott elkotelezned magad mellette, akkor garantaltan meg fogsz lepodni.
de altalanossagban elmondhato, hogy a fajlrendszer/rdbms szokott a szuk keresztmetszet lenni, illetve ez az, amit nehezebb utolag skalazni, ha eleve nem lett minimalis figyelem ennek az elokeszitesere forditva.
elosztott fajlrendszer kapcsan erdemes a Shared disk file systems illetve a Distributed file systems kulcsszavakkal olvasgatni, soksokgepes kornyezetben altalaban az utobbi a "jobb", persze ez is fugghet a feladattol.
nem minden oldalnal fontosabb a durability, mint a performance. ha facebook-on elveszne vagy atmenetileg elerhetetlenne valna nehany kepem, az kevesbe zavarna a felhasznalokat, mint ha mondjuk minden kepfeltoltes 3szor lassabb lenne, mert 3 helyre fel kellene toltenie a site-nak, mielott kiirhatja nekem, hogy na most aztan tenyleg jol elraktak.
A CentOS nem OS, hanem linux disztribucio, google nem azt hasznalja AFAIK:
http://en.wikipedia.org/wiki/Goobuntu
http://lwn.net/Articles/357658/
ha a kernelt ilyen szinten maguknak fejlesztik, akkor igazabol szinte lenyegtelen, hogy milyen disztribuciot hasznalnak (ha hasznalnak egyaltalan)
szoval szerintem a barmelyik mainstream linux disztribucio megfelelo lehet, lenyeg az, hogy kezrealljon, altalaban amit erdemes figyelni, hogy vannak a hosszu supporttal rendelkezo disztrok (CentOS, Debian, Ubuntu LTS), amikbe lassabban kerulnek be az ujabb verziok, illetve a porgossebb disztrok (Ubuntu, Fedora), ahol frissebbek a csomagok, viszont gyakrabban kell frissiteni a rendszert.
persze nagyon nagy rendszernel mar praktikusabb lehet sajat verziokat csomagolni.
nginx szerintem hasznos, akar content szervernek, akar reverse proxy-nak hasznalod.
Tyrael
Shared filesystem
Hogyan kell és érdemes a
Tyrael
Válaszok
Az operációs rendszer választás egy érdekes téma - ezt akár föl is teheted utána a kérdezz-felelekben - de szerintem, ez egy olyan kérdés, amit esetileg kell eldönteni. Az Ubuntu pl. nagyon friss szoftverekkel jön, ha ez nálad szempont (pl webtárhely esetén), akkor ezt lehet választani. A Centos legjobb tudomásom szerint gyakorlatilag a Redhat unbrandelt, binárisan kompatibilis változata, ami azt jelenti, hogy milliószor agyontesztelt, viszont ósdi szoftverek vannak benne.
Az nginx-nek és a LigHTTPd-nek van egy hatalmas előnye az Apache-al szemben: nem szeretnének annyi mindent csinálni. Erről két mondat erejéig lesz szó, ezért itt részletesebben: Mivel nem akarnak annyi féle-fajta funkciót megvalósítani, tudnak nagyon gyorsak lenni. Ha nem probléma az a relatív featurehiány, ami őket jellemzi, akkor nagyon jók. Mi pl most már új PHP-s szoftvert is csak FastCGI-re írunk és LigHTTPd-vel üzemeltetünk. Ha viszont mod_php-tól függő funkcióid vannak, akkor esélytelen vagy.
szoftverfejlesztes nagyobb
Tyrael
Természetesen
Ami a programkódokat illeti, pontosan erről lesz szó, hogy hogyan lehet egy egy gépes környezetből elindulni egy többgépes rendszer felé. Erre egyébként egy gyakorlati példát is fogok mutatni, össze fogunk rakni egy blogszolgáltatást.
Ami a facebook.com-ot illeti, érintőlegesen bele fogok menni azokba a megoldásokba, amiket kintről láthatóan használnak, viszont részletekbe nem nagyon bocsájtkoznék, egyrészt mert nem ismerem a rendszerüket olyan mélységben, másrészt mivel az általuk használt szoftverek ismertetése kitenne egy teljes évadot az akadémián.
János még nem írta ugyan itt,
http://www.slideshare.net/janoszen/nagy-terhels-webes-rendszerek-fejlesztse
Tyrael
Elkészült