shared hosting vs. virual gep

Linux-haladó

Sziasztok,

a velemenyetek erdekelne:

Van nekem 20-30 weboldalam, de a terhelesuk eleg hektikus, ezert elofordult mar, hogy egyik site terhelese megolte az egeszet. Az ilyesmi nem lathato elore ebben az esetben.

Most egy tipikus LAMP szerveren vannak, ami egy ESXi VM. Tehat apache virtual hostok.

Ahogy meg lehetne:
- 20-30 kicsi VM-et csinalni nekik
- egy nagy VM, benne OpenVZ (vagy hasonlo) kontenerek minden sitenak
- OpenVZ "bare metal", nem ragaszkodom az ESXi-hez

Melyik lehet a jobb megoldas?

  • 2936 megtekintés

( andrej_ v | 2012. 12. 18., k – 12:40 )

Mekkora fizikai gép áll rendelkezésre és mekkora a mostani virtuális gép, amin futnak?

Én a nulladik körben az Apache+PHP körül néznék szét mit lehet optimálni (APC, XCache, SQL beállítások stb.). Első körben pedig az appok körül néznék szét, hogy mit lehet tenni, akár javasolni a kedves elszállásra hajlamosnak.

A hektikus terheléssel az a fő probléma, hogy a (várható) csúcsra kell felkészülni, illetve érdemes +20%-ot ráhagyni, hogy legalább valami kis tartalék legyen.

Ez most mindegy, a kerdes csak elmeleti.

Tehat a kerdes az, hogy a fent vazolt izolacios modszerek kozul melyiket erdemes hasznalni (sok kis VM, vagy kontenerek egy nagy VM-ben, vagy kontenerek fizikai gepen illetve termeszetesen barmilyen mas otlet a mostani vhostok izolaciojara) hogy akarmi is van, ne tudjak egymas elol megenni az eroforrasokat.

Nade ezaz, mindegyik ugyanugy terheli, es mindegyik ugyanugy tulterhelheti, csak az idopont nem azonos - teljesen veletlenszeru. Pl. a Cunard (akiknek az egyik hajoja volt az, amelyik kenyelembe helyezte magat az olasz partoknal) hajoi osszevissza vannak minden idozonaban, es egyszercsak kitalaljak itt a parton, hogy az uj safety szabalyokat oktato kurzust mindenki csinalja meg tegnapra. Ez 5000 ember. Mas cegeknel hasonlo, csak maskor es ok is mas idozonakban vannak szerencsere.
Na jo azert eleg ritkan hal le az egesz, de nyilvan nagyon belassul ilyen terhelesnel minden oldal. Es ugye jo lenne, ha akkor csak a cunard oldala lenne lassu, a tobbieke meg menne szepen.

Az ESXi-t nem ismerem, de az OpenVZ esetén ez nem annyira jelentős probléma, mert szépen osztozkodnak a memórián. Éppígy a CPU-n is. Plusz általában:

- bőven van mit optimalizálni az apache-on
- halál felesleges apache-ot használni, elég helyette egy lighttpd + fastcgi (jobbára a rewrit rule-ok miatt van apache :D)

Azt még fel tudom ajánlani, hogy hozzám felteszek egy minta appot OpenVZ-re és megtámasztjátok műterheléssel, hogy mit bír el az OpenVZ.

hat ha az a lenyeg, hogy ne fogja meg az egyik terhelese a tobbit, akkor en csinalnek sok kis vm-et, ami viszont a fizikai vasra nezve mar igen jelentos overhead osszesegeben.
ha egy nagy vm-et csinalsz, es bele kontenereket, akkor tovabbra is fennall szvsz, hogy ha egy-ket oldalnak nagy a terhelese, akkor az megfogja a pricit, I/O-t, stb., hiaba vannak kulon kontenerekben. bar hozzateszem, az openvz-t annyira nem ismerem, inkabb fbsd jail-okat ismerem jobban.

( janoszen v | 2012. 12. 18., k – 15:42 )

Alapvetoen arra fel kell keszulni, hogy a virtualizacio csak bizonyos fokig oldja meg a problemaidat, nem egy varazspirula, amitol minden gondod megoldodik.

Ha pl. PHP-rol beszelunk, futtathatsz mindenkinek kulon FPM-et sajat user alatt, amit berakhatsz sajat cgroupba. A cgroupokra pedig tudsz szepen eroforras-limiteket allitani. Ezzel meg tudod kerulni a virtualizacioval jaro tobblet munkat, viszont kelloen stabil lehet a rendszered.

Azt is latni kell, hogy a hosting egy olyan uzlet, ahol a rossz berloktol erdemes idejekoran megszabadulni vagy segiteni neki rendbeszedni a szarkupacukat (ha eleg sokat fizetnek), mert sajnos a userek kreativitasa/hulyesege (a megfelelo alahuzando) hatartalan es valtozatos, altalad elore meg nem almodott modokon tudjak beboritani a szerveredet, spamelni a vilagba, amitol feketelistara kerulsz, stb.

Ennek utanaolvastam gyorsban, ez nem rossz. Talaltam valami homalyos utalast, hogy az LXC is ezt hasznalja. De akkor minden cgrouphoz kell kulon mysql instance, gondolom?

/most nincs jelentosege, de ezek nem berlok, mi nyujtunk egy szolgaltatast, ami vegeredmenyben egy-egy moodle hostolasa. de mindegyik kulonbozo, szarra van "kusztomizalva". A DB akad ki neha azon, hogy a kedves userek egy nagy ronda formmal generalnak riportokat vagyis kitoltik, es az general egy jo nagy queryt. Ezeket sajnos nem nagyon lehet mar optimalizalni. Van query ami 50 masodpercig fut. Termeszetesen csucsidoben, mikor maskor. Elso lepeskent azt akartam, hogy a programozo iranyitsa legalabb ezeket a nagy lekerdezeseket egy mysql slave-ra, de hisztizik. Pedig ez tuti megoldana a belassulasok nagy reszet. Ha kontenereket hasznalnek (vagy valami) akkor neki nem kene modositania semmit. Igaz hogy az adott query meg tovabb futna, de legalabb nem tartana fel a tobbit./

Ha MySQL-szinten akarsz eroforrast limitalni, akkor kotelezoen muszaj kulon instanceokat futtatni, tok mindegy, hogy milyen megoldast hasznalsz. A belso eroforras limitjei kb. hasznalhatatlanok ilyesmire. A tobb instancenak viszont az a kovetkezmenye, hogy rendesen meg kell tomni memoriaval a gepet es kulon kell tekerni oket, magyaran szolva egy jo nagy adag sz*past veszel a nyakadba.

En a helyedben a programozot rugdosnam, hogy legyen kedves a slavet hasznalni ilyesmire, mert mas kulturalt es aranyos munkaval jaro megoldas nem nagyon van.

Amúgy nem biztos, hogy ahány konténer, annyi mysql. Én a mysql socketet osztom meg, kb. így: http://wiki.openvz.org/Shared_webhosting#MySQL_socket_sharing csak annyi a különbség, hogy a socket egy fs-en van, amit minden érintett konténer magához édesget (bind mount) induláskor. Talán megoldás lehet ha megúszod 2-3 mysql szerverből az egészet, pláne ha nem kell nekik fejenként sok memória. De ez nem nagyon szokott megvalósulni :D

Jham, és elvileg akár LXC alatt is működhet.

A Moodlet ismerve kell oda a sok memoria, plusz ha random instanceokon futtatjak a killer queryket, a 2-3 MySQL kozul valamelyik mindig ki fog dolni es akkor azzal ki vagy segitve. Itt a megoldas az, hogy a tisztelt programozo a random testreszek vakargatasa helyett osszeszoritja a fogat es implementalja azt, hogy a killer queryket slaven futtassa.

( azbest | 2012. 12. 18., k – 20:04 )

Amit írok valószínűleg off a témát tekintve, mivel gondolom a jelenlegi gépből szeretnétek kihozni a megoldást.
Az ilyen időszakos nagy terhelésre jó például egy felhős szolgáltató. Amazon ec2-t használtam már hasonló célra. Megnövekedett terhelésnél lehet újabb példányokat indítani a rendszerből és azok közt elosztani a feladatokat, persze automatizálva. A terheléselosztás módja nagyban függ a rajtuk futó rendszerektől is.

Neten kicsit keresgélve úgy tűnik limitálható felhasználónként a rendelkezésre álló erőforrás:
http://stackoverflow.com/questions/437433/limit-in-the-memory-and-cpu-a…

Ha cpu time, memory limitált, akkor gondolom a többi felhasználót nem gyilkolhatja le egy hiperaktív.

Az igazi gond nem is ez, hanem amit korábban is írtak, hogy a mysql egy közös pont, amit elég problémás jól limitálni, különösen, hogy a felhasználói oldalról nincs nagy támogatás. És ebbe belegondolva, már lehet hogy nem is informatikai, hanem üzleti kérdésről van szó, érdemes-e megtartani a problémás felhasználót.

( traz | 2012. 12. 19., sze – 11:43 )

Koszonom mindenkinek, akkor ugy nez ki egyelore nem varialunk, hanem a killer queryk mennek a slave-re. Azert megis kaptam jo tippeket, amik jok lesznek majd mashova.

A progamozo leforditotta a hozzaszolasokat google translate-tel, es el kellett ismernie, hogy szetiszfekson igazam van :D