[update2] tippek appserver cluster összerakására centos 6 alatt?

Red Hat, Fedora, CentOS

UPDATE:

kezd összeállni a kép. tehát, a megoldott részletek:
- cluster tag install: speciális kickstartos usb-s netinstall. már félig előkészítve érkezik meg a szerver a clusterbe.
- distributed locking PHP web alkalmazáshoz: mysql-ben a select .. set_lock és release_lock. tökéletesen működik, nem szól bele a teljesítménybe, nem kell új kapcsolatot nyitni hozzá, atomikus, és kizárólagos (amíg egy sql szervert használunk).
- passzív monitoring gráfolással: munin (marad, mert ismerem, és nem kellenek triggerek).
- config management: ansible (barátságos, megfelelő teljesítményű, mindent tud, ami kell).
- idő szinkronizálás: ntp, a fejgép valamelyik európai ntp szerverről veszi az adatokat, a cluster tagoknak pedig a fejgép az ntp forrás.
- cluster tagok menedzselése, szervízmenedzselés rajtuk: pacemaker+corosync. még nincs kész, de ez is tud mindent, ami szükséges. mondjuk rémálom a kezdeti konfigja.
- nginx konfig menedzsment: saját script, ami a pcs-ből szerzi az adatokat, és ez alapján kapcsolgat nginx konfigokat, aztán soft reload az nginxnek.

kérdéses, de jelenleg nincs jobb:
- website megosztott fájlterület: nfs4, sync, hard, nolocks. a hard ugyan megakasztja a kliens gépeket, ha a gw szerver leáll/rebootol, de amint visszajön, mennek tovább gond nélkül. mivel nem kell HA, ezért DRBD nélkül.

még megoldandó: gateway shutdown esetén a kliens gépek értesítése, hogy lőjék le az NFS-t esetleg használó cuccaikat, és unmountolják az nfs-t. jobb tippem nincs, mint egy külön init.d script, ami shutdown esetén legelőször, startup esetén legvégül fut le, és ami:
- shutdown esetén pcs-en keresztül(?) szól a cluster tagoknak, hogy a php-fpm szolgáltatást állítsák le (ez használja csak az nfs-t), majd direkt ssh-s parancson keresztül unmountolom a gépeken a /home-ot (az van NFS-en megosztva), végül pcs-el standby-ba rakom a clustergépet.
- startup esetén: /home nfs remount ssh-n keresztül, pcs-el pedig kiveszem standbyból a cluster tagokat, és ahol kell, beindítom a php-fpm-et.

==================
eredeti post:

hali mind,

kicsit hosszadalmas dolog jön, de segítség kéne, nagyon.

szóval, adott egy site, aminek eléggé nagy a forgalma, és eddig változatos módon próbáltuk a növekvő forgalmat és az egyre bonyolultabb, egyre több ajaxos megoldást tartalmazó kódbázist normális sebességgel kiszolgálhatóvá tenni. volt már olyan, hogy egy másik szerveren futott az egész adatbázis (most csak bizonyos táblák futnak egy másik szerveren), de a lényeg, hogy a fő kiszolgálást (ami LAMP alapon történik) mindig csak egyetlen szerver végezte. nemrég masszív kódrefaktoringot is csináltam, ami segített a dolgokon, de ez már csak ideig-óráig mehet így. szóval az egyetlen megoldás az, ha egy olyan mini-clustert hozok létre, amiben:
- van egy gateway szerver, a netről csak ez látszik
- e mögött egy privát switchben egy mini-hálózat van, amiben kétféle gép lesz: app server (amin a php scriptek futnak), és db szerver (jelenleg egy, ami pedig értelemszerűen a db backendet adja).

csináltam egy rakat barrage tesztet, hogy megtudjam, egy gépen futva melyik webkiszolgáló kombináció adja a legjobb eredményt, ez alapján arra jutottam, hogy a gateway gépen nginx fog futni (az nginx repoból), az app gépeken pedig php-fpm kiszolgálók fognak menni (remi repoból, mert a php 5.4 mindenképp fontos).

gondolkoztam azon is, hogy pxe boot-tal működjenek a gateway mögötti gépek, de főleg az nfs szerver terhelés-enyhítése miatt arra jutottam, hogy maradnak kis ssd-kel szerelt gépek, a frissítést yum-mal is el tudják végezni, és a /home/ partíciót (mivel itt vannak a scriptek) kötöm be nfs-en. a telepítésre pedig csináltam kickstart fájlokat, így új szervert berakni, vagy meglevőt újrahúzni gyerekjáték. a konfigok központi kezelésére pedig csináltam néhány egyszerű shell scriptet, amik nfs-ről húzzák át az egyes géptípusok konfigjait.

ami készen van:

- gateway szerver: centos, nginx, kimenő sendmail, ntp szerver, nfs szerver, iptables NAT-tal kiszolgálja a belső hálózatban levő gépek net igényét is, dhcpd a belső címkiosztások kezelésére (mac addr alapján)

- app szerverek: centos, php-fpm szerver, /home/ nfs-ről mountolva, rc.localban a konfig fájlok szinkronizációs megoldásával

- db és memcached szerver: centos, mysqld, memcached (egyrészt serverwide változók tárolására, másrészt session backendként az egyes php-fpm-es gépek részére)

- a statikus fájlokat a gateway nginx-e szolgálja ki, mivel erre külön backend gép nem lesz, ráadásul az nfs megosztás miatt úgyis csak a gatewayt terhelné, így legalább be tudja cachelni read pufferbe

amiben kéne tipp, segítség:

- kéne valami watchdog rendszer, ami figyeli, ha kiesik valamelyik app backend, vagy neadjisten a db backend. tudnék csinálni saját scriptet, de ha tudtok valami ilyesmiről, akkor inkább nem találnám fel a spanyolviaszt.

- ezzel kapcsolatos még, hogy keresek olyan tápelosztót, amit soros portról, vagy esetleg etherneten vezérelni tudnék, hogyha egy backend gép elakad, akkor tudjak távolról egy gyors ki-be kapcsolást csinálni. találtam olyan, hogy epowerswitch 4, csakhogy fogalmam sincs, azt honnan lehet rendelni. valaki tud erről valamit?

- valahogy az nginx-nek is a tudtára kéne adni, ha egy backend meghal, hogy oda ne küldjön forgalmat.

- valahogy meg kéne oldani, hogy a backend gépek ne nagyon drifteljenek el az órájukat illetően, mivel van a site-on pár olyan szolgáltatás, ami minimum másodperces egyezést, de optimális esetben millisec egyezést kívánna meg a gépek között. erre lehet megoldás az a fícsör az nginxben, hogy ugyanarról az ip-ről mindig ugyanarra az app szerverre dobja a requestet? (akkor legalább sessionön belül konzisztens lenne a timestamp kezelés.)

- a mail() funkciónál elég, ha a php.ini-ben a localhost helyett a gateway gépet adom meg, hogy tudjon leveleket is kiküldeni a rendszer?

- nagyon rossz ötlet, hogy nem PXE boottal mennek a backend gépek? tényleg nem akarom az NFS-t arra lefoglalni, hogy a rendszerfájlokat onnan vegye, lesz így is elég gondja, hogy a php-fpm scripteket végrehajtsa a gateway gépről.

- php-ban acélbiztos, atomikus locking nfs mounton? erre olvastam egy olyan tippet, ami a hardlinkes megoldást preferálja, miszerint egy meglevő fájlra csinálok egyedi néven egy hardlinket, aztán stat-olom, és megnézem, hogy az 'nlink' (hardlinkek száma) 2-e -- mert akkor csak én lockolom az adott pillanatban az adott fájlt. erről tudtok valamit, esetleg más ötlet? (állítólag az nfslock nem jó, mert nem atomikus a php szempontjából.)

előre is köszönet a tippekért! :)

  • 12122 megtekintés

( pdx | 2014. 05. 13., k – 16:48 )

- a site egy rakat cronos háttérfolyamatot is futtat, szintén php-ben megírva. de az egy CLI alkalmazás, és mivel az központi dolgokat csinál, ezért ez csak magán a gatewayen futna, php-cli módban, mindenfajta webszerver nélkül.

- nem tudom, mi a tapasztalat a php-fpm, mint netes kiszolgáló ügyében. mivel az klasszikus forkolós, és nem multithreades (a php miatt), nem tudom, hogy mi a jobb ötlet: az nginx közvetlen fastcgi módban éri el az appszervereken a php-fpm-et, vagy pedig az nginx csak proxyzik, és az appszervereken nem php-fpm módban futnak a scriptek, hanem esetleg lokális apache szerverrel, mod_php üzemmódban.

- mivel a userek is generálnak egy rakat fájlt, ezért nem megoldható, hogy bármelyik appszerver is privát fájlterülettel működjön (az alap centoson kívül); plusz a php scriptek elég sűrűn változnak (bugfixek, új fícsörök, stb), ezért is lenne nfs-en az egész website.

- a privát hálózat switche természetesen gigabites, hogy minél kisebb legyen a network bottleneck.

- az egész koncepciója az, hogy ha bevezetünk valami php-igényes szolgáltatást, akkor csak bedobunk egy új appszervert, és így a terhelést tetszőlegesen tudjuk eloszlatni. persze tisztában vagyok azzal, hogy egy idő után a db szerver lesz a szűk keresztmetszet, akkor persze be lehetne állítani replikáló szervereket is, de az már egy másik sztori. egyelőre azzal biztos nem lesz gond.

- a jelenlegi rendszerben már minden csontig van optimalizálva (maga az ipv4 stacktől kezdve a php scripteken át egészen a mysql beállításokig), tehát nem az a kérdés, hogy hogy tudnám a jelenlegi szerveren tovább optimalizálni a dolgokat (tényleg, minden trükköt bevetettünk már, ami a nagykönyvben van, meg néhány kisebb füzetben is :) ).

- esetleg valakinek van tapasztalata azzal, hogy a mariadb mennyivel jobb a mainline mysqld-nél? csak myisam, memory és archive táblákat használunk, tehát az innodb és hasonló nyalánkságok terén mutatott előny nekünk nem előny igazán. (nem kell tranzakcionális db-t használnunk, és akkor már a myisam a leggyorsabb, főleg, ha a táblák jó része fix sorhosszúságú.)

( janoszen v | 2014. 05. 13., k – 18:07 )

Ez az appszerveres megoldas ordit arrol, hogy nem csinaltatok meg nagy rendszert PHP-val, sem programozoi, sem pedig rendszergazdai oldalrol. Amivel semmi baj nincs, de adnek nehany tanacsot:

- Az NFS-t surgosen felejtsd el. Egyreszt vannak ennel jobb megoldasok, masreszt az NFS bizonyos korulmenyek kozott ugy ossze tud borulni alattad (foleg nem megfelelo config eseten), hogy hard reset kell a fele gepparknak.

- Ha ne adj isten valamelyik szervereden van FTP daemon, akkor attol erdemes mihamarabb megvalni, az a technologia annyi sebbol verzik, hogy nem igaz.

- Ismerkedj meg a deployment mufajaval. Ha sokat valtozik a kod, arra nem az NFS a megoldas, hanem az, hogy a deployment folyamat szepen kirakja az osszes szerverre a kodot a verziokoveto rendszerbol, amit remelhetoleg hasznaltok. Ha nem, akkor itt az ideje megismerkedni vele. Capistrano, Phing, Jenkins, stb. toolok sokat segitenek.

- A felhasznaloi adatokat erdemes kulon helyen tarolni, nem ott, ahol a kod van. Lehet tobb fele megoldast nezegetni, ezek alatt akar lehet is NFS, de inkabb valami S3-klon filerendszer/webservice, ami gondoskodik a fajlok redundanciajarol. Vagy csinalsz egy darab "usercontent" szervert, ahova az upload-ok mennek, a linkeles meg megy az adatbazisban a feltolteskor felvett rekord alapjan.

- A lockolas nem egyszeru kerdes, de egesz biztosan nem file szinten oldanam meg. Plane nem, ahogy Te irtad, spin lock-kal, mert konyorog erte, hogy berohadjon. Helyette inkabb epitsetek mondjuk MySQL alapon egy tablat amire lehet SELECT...FOR UPDATE muvelettel lockot kerni. Ennek az az elonye, hogy ha lerohad a kapcsolat, atuomatikusan elengedi a lockot.

- A gepeidre ismerkedj meg a konfiguracio menedzsment temakorevel PXE boot helyett. Puppet, Chef, barmi lehet, de legyenek egysegesek a gepeid.

- mail fuggveny helyett SwiftMailer es belso halozaton logo SMTP szerver.

- Az ora problemara hasznalj NTP-t.

- A frontend NGINX tud az upstream modullal tudtommal backend checkeket futtatni.

- A DB engine megvalasztasakor azt tartsd szem elott, hogy melyiket konnyebb karban tartani. Ha a MySQL-t strict modban futtatod, eleg sokat nyersz a hasznalhatosag teren es nem kovetsz el olyan hanyagsagokat, amik problemakhoz vezethetnek. Hogy mainline MySQL vagy MariaDB, esetleg Percona... ezek olyan dolgok, amikkel intenziven kell foglalkozni, es szinte biztos, hogy elso korben nem eri meg a plusz munkat a nem mainline megoldas, lesz dolgod amugy is eleg.

- Monitorozasra Nagios, Icinga, Monit, Munin es a rakas masik szoftver ami keszen van. Guglizz, talalsz eleget. Termeszetesen config management rendszerbol felhuzva.

- Tavoli gyors kikapcsolasra nem az eloszto a megoldas, hanem a tisztesseges gep, illetve az abban levo tavmenedzsment kartya, plane hogy a "meghalt" nem egy binaris allapot, eleg sok csunyasag tud ott keletkezni. Mar egesz olcso konfiguraciokban is kaphato, pl a Supermicronak vannak ilyenjei, de a HP mikroszerver is egesz jo cucc (az mas kerdes, hogy szinte mindegyikre lehet anyazni). Ha nincs penz rendes gepet venni, akkor bereljetek.

- Privat switch helyett a szolgaltatotol kerjetek privat VLAN-t, jobban jartok vele. Ha nem tud adni, akkor gyorsan kezdjetek el szaladni.

- A PHP legjobban tapasztalatom szerint PHP-FPM + nginx + FastCGI uzemmodban erzi magat. Az Apache-ot keruld el messzirol ha performance a cel.

- Legyen napra kesz, tesztelt biztonsagi mentesed.

- Vegezetul: szerintem nagyon tultervezted magad. Ha soha nem csinaltal meg cluster architekturat, ne akarj egybol 10 gepet vasarolni, hanem vegyel mondjuk 2-t. Az egyikre tedd a DB szervert, a masikra az appot es kesz. Igeny szerint kell boviteni, nulla vagy nullahoz kozeli tapasztalattal, meresi eredmenyek nelkul, a netrol osszevadaszva a technologiakat szinte biztos, hogy befurdesz a projekttel. Esetleg bereljetek fel valakit, aki latott mar bonyolultabb (PHPs) architekturat, hogy nezze at az alkalmazasotokat es adjon tippet az optimalizalasra, esetleg tervezze meg nektek az uj architekturat. Sokkal olcsobb lesz, mint ami penzt kidobtok a gepekre feleslegesen. En szoktam ilyen tanacsadast csinalni, ha erdekel, nagyon szivesen beszelgetek veled egy orat privatban Skype-on hogy tisztabban lass a kerdesben.

Remelem sikerult mindenre valaszolni. :)

hujjuj.... köszi a választ, szép lassan elkezdem értelmezni a dolgokat, még az is lehet, hogy hivatalosan is hozzátok fordulunk majd segítségért, de pár dologra már így is tudok reagálni.

- a biztonsági mentés (naprakész) az nálunk is alapvető dolog, természetesen már most így van.

- ftpd (illetve vsftpd) még van ugyan pár szerverünkön, de már átálltunk scp-re, úgyhogy az nincs is tervben az új rendszerrel kapcsolatban.

- akkor marad az nginx frontend, és php-fpm backend, végül is én is erre jutottam a barrage tesztek alapján.

- mintha azt olvastam volna, hogy az nginx-ben az automata failover kezelés csak a fizetős verzióban van benne, de ezt majd még újra ellenőrzöm.

- kód tekintetében a deployment nem horror, tudok is róla, csak eddig nem kellett használnunk. hát akkor fogjuk. :) bár a legjobb lenne összekötni a config managementtel, mert néha bizony együtt kell változniuk. így első blikkre a puppet és az ansible tetszetős, ez utóbbi főleg azért, mert nem ruby. :) (tudom, irracionális, de valahogy a hideg kiráz minden rubys cucctól.) a kód már nagyon régen verziókövetéses módon van tárolva, igaz, nem git, csak svn, de elvagyunk vele.

- nem tudom, hogy meg tudom-e kerülni az NFS-t. a user tartalom nem csak user tartalom (mármint nem csak uploadok halmaza), hanem generált fájlok a userekhez tartozó könyvtárakban, stb. a jogosultság jelen esetben nem problémás dolog, mivel egyetlen userid alatt mennek a webes dolgok, viszont az, hogy több gépről egyszerre ugyanazt a a fájlterületet lássam, az olyannyira alapvető követelmény, hogy nem tudom megkerülni. néztem alternatívákat, de realtime, kernel-szinten támogatott közös fájlrendszert nem nagyon látok az NFS-en kívül. ott van még a CODA, de úgy tudom, az már halott dolog, nincs is a 2.6-ban. smbfs-el meg úriember nem parolázik. én is olvastam az NFS csapdáiról, meg a hibatűrésének a nemlétéről, de ha ez nem, akkor mi?

- viszont ha már nem tudom megkerülni az NFS-t, illetve valamilyen network fájlrendszert, akkor tulképp a deployment is opcionálissá válhat, mert elvégre a php-fpm+zendopcache is csak akkor olvas be egy fájlt, ha még nincs bent a cache-ében, vagy változott, ez meg nem terhelné agyon az NFS-t.

- óra probléma: most is NTP-vel oldom meg, csak az a bajom, hogy nem tudom, mennyire lehet leszorítani a driftet. legalább másodperc-szinten ugyanúgy kéne állni a szerverek órájának, ha ms szinten nem is lehet őket tartósan syncelni.

- a swiftmailer eléggé overkill, de az alapötlet tényleg ez, hogy csak a gatewayen megy egy sendmail, és az felel a levelek kiküldéséért.

- a lockolás mysql-ből megoldása: eléggé atomikus ez? és ha jól értem, hacsak nem akarok minden lockolásnak egy külön táblát szentelni, akkor vagy innodb vagy bdb engine-ű táblát kell használnom, mert csak azok támogatják a soronkénti lockolást. én sem lelkesedem a spinlock-ért, és persze amúgy is úgy írtam meg, hogy be ne rohadhasson (feladja egy idő után a lockolást, ha nem megy), de mivel a db backend amúgy is rendesen izzad, nem akartam ezzel terhelni.

- passzív monitorozásra én is a muninra gondoltam (ezt használjuk is a mostani rendszereinkben), viszont nem tudom, mennyire lehet aktív triggereket rákötni (pl. ha kiesik az egyik szerver, megpróbálni "feléleszteni" egy power cycle-al, vagy átírni konfig fájlokat, hogy további akcióig ne használják a szervert), ebben még nem merültem el.

kód tekintetében a deployment nem horror, tudok is róla, csak eddig nem kellett használnunk. hát akkor fogjuk. :) bár a legjobb lenne összekötni a config managementtel, mert néha bizony együtt kell változniuk. így első blikkre a puppet és az ansible tetszetős, ez utóbbi főleg azért, mert nem ruby. :) (tudom, irracionális, de valahogy a hideg kiráz minden rubys cucctól.) a kód már nagyon régen verziókövetéses módon van tárolva, igaz, nem git, csak svn, de elvagyunk vele.

Valamilyen szinten igen, de nem javaslom, hogy config management eszkozzel deployoljatok. Ami a Rubyt illeti, van racionalis ok is amiert lehet nem szeretni, pl mert szereti a RAM-ot. A Puppet viszont egy igen komoly eszkoz, rengeteg mindent tud es eleg stabil.

nem tudom, hogy meg tudom-e kerülni az NFS-t. a user tartalom nem csak user tartalom (mármint nem csak uploadok halmaza), hanem generált fájlok a userekhez tartozó könyvtárakban, stb. a jogosultság jelen esetben nem problémás dolog, mivel egyetlen userid alatt mennek a webes dolgok, viszont az, hogy több gépről egyszerre ugyanazt a a fájlterületet lássam, az olyannyira alapvető követelmény, hogy nem tudom megkerülni. néztem alternatívákat, de realtime, kernel-szinten támogatott közös fájlrendszert nem nagyon látok az NFS-en kívül. ott van még a CODA, de úgy tudom, az már halott dolog, nincs is a 2.6-ban. smbfs-el meg úriember nem parolázik. én is olvastam az NFS csapdáiról, meg a hibatűrésének a nemlétéről, de ha ez nem, akkor mi?

Oszinten megmondom, az NFS-re ra se neztem az elmult nehany evben, de valoszinuleg nem veletlenul alakult ki ugy, hogy egyetlen olyan rendszert nem is lattam, ami NFS-sel szolgalta volna ki a programkodot. Nekem nagyon rossz tapasztalataim voltak vele ilyen felhasznalasra, plane ha veletlenul megszaladt valami es teletolt egy konyvtarat kismillio file-al, stb. Ami a user adatok tarolasara vonatkozo kerdesedet illeti, eleg nehez generikus megoldast mondani, hiszen nem tudom, milyen jellegu adataid vannak. Rengeteg fele-fajta adatbaziskezelo es filerendszer van, ami alkalmas lehet a feladatra es adott esetben akar gyorsabb is lehet mint az NFS. Ha statikus adatok kiszolgalasarol van szo, letezik egy olyan pattern is, hogy a 404 error handler egy PHP script, ami az adott szerverre letolti valami hattertarbol a filet ha nincs ott. Ha meg ott van, akkor kozvetlenul kiszolgalja.

óra probléma: most is NTP-vel oldom meg, csak az a bajom, hogy nem tudom, mennyire lehet leszorítani a driftet. legalább másodperc-szinten ugyanúgy kéne állni a szerverek órájának, ha ms szinten nem is lehet őket tartósan syncelni.

Ha jol tudom, akkor NTPd-ben peerkent felconfolva a lokalis clusteredet meglehetosen pontosak lesznek az orak, de ezt akar meg is tudom nezni majd az egyik tesztrendszeren.

a swiftmailer eléggé overkill, de az alapötlet tényleg ez, hogy csak a gatewayen megy egy sendmail, és az felel a levelek kiküldéséért.

SwiftMailert azert erdemes hasznalni, hogy kulturaltan osszerakja a levelet. Erre a mail() fuggveny csak rengeteg erolkodessel kepes. Nem tudom, milyen tipusu leveleid vannak, de a spam mappa a nagy ellenseged.

a lockolás mysql-ből megoldása: eléggé atomikus ez?

Ha jol valositod meg, teljesen atomi. Ha erdekel, leirom privatba a menetet, nem akarom a vegtelensegig nyujtani a temat.

passzív monitorozásra én is a muninra gondoltam (ezt használjuk is a mostani rendszereinkben), viszont nem tudom, mennyire lehet aktív triggereket rákötni (pl. ha kiesik az egyik szerver, megpróbálni "feléleszteni" egy power cycle-al, vagy átírni konfig fájlokat, hogy további akcióig ne használják a szervert), ebben még nem merültem el.

Azt hiszem, aktiv monitorozas nelkul nem igazan leszel meg. A "felelesztessel" ovatosan, ezek mar High Availability kerdesek es abban nagyon csunya fejlovesek tudnak szembejonni. A terheles elosztasra vannak normalis technologiak, nem kell a monitoring rendszert raakasztani hozza.

a locking egy érdekes témakör, arra jutottam. :) és végül is igaz, hogy ha meg lehet oldani valahogy a fájlrendszeren kívül, akkor ott lenne érdemes. per pill egygépes működésben flock()-al megy, megbízhatóan, de ugye amint több gépről jöhetne lockolási kérés ugyanarra a fájlra, akkor már gáz van.

az sql-t erre befogni viszont, megvallom őszintén, félek. teljesítményügyileg. az sql sok minden másra már így is rendesen ki van használva, erre rádobni a lockolási feladatot, hááát...

néztem az alternatív megoldásokat -- igazándiból egy szimpla, mindentől független, atomikusan működő lock daemon lenne a legjobb, de úgy látom, az egész egyszerűen *nincs*. találtam egy old nevű projektet (open lock daemon), ami pont erre lett kitalálva, de egyrészt úgy 2006 óta semmi változás, másrészt nincs natív php kliens hozzá, ami megint csak nem jó.

viszont többen arra esküsznek, hogy a redis erre (is) jó. van neki egy setnx (illetve set ... nx) parancsa, ami csak akkor állít be egy értéket, ha az nem létezik. mivel a redisesek szerint ez majdnem-atomikus művelet, ezért lockra is alkalmas, sőt, mivel default expiration értéket is be lehet állítani, így a hirtelen halál esetén beragadt lockokat is el tudja engedni magától. persze ez is spinlock, de per pill nincs jobb ötletem hálózatos lockolásra.

A majdnem atomi az nem atomi. Ha kelloen sok forgalmad van (mar pedig a jelek szerint van), elo fognak fordulni adatkonzisztencia-problemak. Szoval vagy szuksege van az adataidnak lockolasra, vagy nincs. Ha van, akkor hasznalj valamit, ami tenyleg atomi. Telepithetsz meg egy Redist is, csak eppen a) nem teljesiti a lockolas kovetelmenyet b) eggyel noveli a komponensek szamat amikkel foglalkozni kell. c) tok folosleges, mert egy meglevo komponensed sokkal jobban megoldja a feladatot kulonosebb erolkodes nelkul, tekintve hogy egy, a kulcsok szamaval megegyezo elemszamu tablaban kell updateket vegrehajtani (kb 5-10 sor), ami elfer memoriaban es merhetetlenul kicsi terhelest okoz.

Alapvetoen a clusterepitesnel alapszabaly, hogy feltetelezes helyett merni kell, lehetoseg szerint valos forgalommal. Mernek fogadasokat kotni, hogy mennyire keves RAM-mal es CPU-val megaldott virtualis gepen tudnam meg vigan rohogve kiszolgalni a lockolasi kereseket.

Update: azert vannak hasznalhato lock szerverek. Gyors guglizas utan raakadtam erre. A kodja eleg egyszerunek tunik ahhoz, hogy akar mukodjon is.

--
Pásztor János
Üzemeltető Macik

közben jobban belemélyedtem a redises témába, és mint kiderült, a redisnél a SETNX/SET NX EX hívások bizony nem majdnem atomikusak, hanem *teljesen* atomikusak (nem is csoda, főleg ha figyelembe vesszük, hogy a redis single thread/single process alapon megy, tehát minden bejövő kérés várósorba kerül, ha éppen fut valami). tehát biztosított, hogy ha két kérés is befut szorosan egymás után ugyanarra a resource ID lockra, akkor a queueing miatt az egyik meg fogja kapni a lockot, a másik meg nem, és pötty.

ugyan blocking típusú lockot nem tud a redis natívan, de spinlock-kal meg lehet oldani a dolgot kliens oldalon. ráadásul a SET NX EX formátumban expiration is megadható a lockhoz, tehát ha be is halna az eredeti lockot tartó processz, az egy adott idő után felszabadul, és pöröghet tovább a rendszer. így már csak az az egy kérdés marad, hogy mennyi időre kérjem a lockot, amit viszont be tudok lőni úgy, hogy a spinlock expiration (merthogy azt sem engedem a világ végéig pörögni magában) alá essen mondjuk 1-2 ciklussal, így, ha a php script sokáig is blokkolna, előbb-utóbb biztosan végrehajtaná a műveletet.

no meg ott az az előny is, hogy redis kliens nagyjából mindenhez van natívan, és pont a lockolásra kitalált redises megoldásokkal is teli a net.

(arról aztán végképp nem beszélve, hogy bár az elején biztosan memcached-et fogunk használni a serverwide változókra és a megosztott session kezelésre (mert azt már teszteltük, és működik), később lehet, hogy az is átkerülne redisre.)

igen. vannak adatok, amiket már nem éri meg db-ben tárolni a jellegük miatt. emiatt aztán fájl-alapon vannak tárolva. viszont a hozzáférést (főleg az írásost) így is sorba kell rendezni, különben adatkorrupció léphetne fel, azt pedig ugyebár nem akarjuk.

eddig nem volt különösebb gond ebből, mert egy szerveren belül mentek csak a hozzáférések, így a flock()-os lockolás tökéletesen elegendő volt. amint viszont bejön az NFS, a több szerver, valami megbízható lockolás nélkül nem tudnánk tartani az adatintegritást. az NFS lock híresen rossz és omlásokra hajlamos, arról nem is szólva, hogy néha nem is fájlokat kell lockolnunk, hanem virtuális erőforrásokat. tehát emiatt kell valami független lockszerver, és ez az, amire a redis a jelek szerint tökéletesen alkalmas.

szóval NFS lesz, nolock,sync opciókkal (mivel az NFS-es területre a php appjaimon kívül semmi sem próbál majd meg írni, így az NFS lockot teljesen el is felejthetjük; sync meg az integritás miatt kell, még ha okoz is teljesítménycsökkenést), és redis, mint lockserver.

ha van mysql db-d akkor abban is hasznalhatsz lockot, van egy ilyen:
http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#fun… vagy amit janoszen mondott: SELECT...FOR UPDATE

(ennek mintha meglenne az az elonye, hogyha elszall a process -> lezarodik a mysql kapcsolat, akkor automatan felszabadul a lock)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Te figyu, ne essek bantodas meg ilyesmi, felolem / felolunk azt hasznalsz amit akarsz, de ugy megis kivancsi vagyok, hogy milyen meres vagy tapasztalat alapjan mondod hogy a Redis a biztonsagosabb tipp es hogy a MySQL el fog szallni? Mintha lenne egy fix elkepzelesed arrol, hogy a rendszernek hogyan kell kineznie es ettol a threadtol csak azt varnad, hogy megerositsunk ebben, hogy jo az elkepzelesed, nem is akarod igazan megfogadni a tanacsainkat.

--
Pásztor János
Üzemeltető Macik

nem, távol álljon ez tőlem.

de.

az oké, hogy új kapcsolatot nem kell nyitnom, mert már amúgy is csatlakozok a mysql-hez, de a db-nek így is van rohadt sok feladata, miért dobnék rá még egyet? ráadásul csak a lockolás miatt kellene bedobnom egy innodb táblát a csak myisam+memory+archive táblák közé, nem tudom, megéri-e.

mondjuk már eldöntöttem, hogy fogok csinálni real-world tesztet, redis vs mysqld mint lock szerver, aztán majd az alapján már informált döntést tudok hozni.

hmm, viszont itt javasolták a GET_LOCK() használatát distributed lockingra, az viszont egész normálisnak tűnik, nem kell hozzá plusz kapcsolat, és mivel az nem használna semmilyen táblát, ezért jó eséllyel minimális erőforrást használna. na *azt* már van értelme tesztelnem. :)

köszi, janoszen és ElBandi: a lockolási tárgykör megoldódott, a mysqld get_lock()/release_lock()-ja pontosan azt, és pontosan úgy tudja, ahogy kell, és még új kapcsolatot sem kell nyitnom hozzá. holnap csinálok egy live tesztet, hogy mennyire nyomja meg a szervert az egész, de sejtésem szerint lepkefingnyit sem fogja.

akkor most jöhet a config management és a heartbeat management tárgyköre, hello, kilóméteres doksik (pacemaker, corosync, ansible, stb...) :)

realworld tapasztalat flock()-ról mysqld alapú get_lock()/release_lock() alapra való átállásról:

szinte zökkenőmentes. a munin statisztikák szerint a rendszer teljesítményére semmilyen hatással nincs. az egyetlen változás ezen a gráfon van:

http://dorfl.vphone.hu/munchen/vphone.hu/carrot.vphone.hu/mysql_qcache…

szerda du. 1 fele álltam át flock()-ról mysqld alapra a lockolásban. a "not cached" query-k száma (hiszen ezeket tényleg nem lehet cache-elni) megugrott, illetve, mondjuk úgy, megjelent.

amit ma reggel láthattok (kiugrás) az azért van, mert csütörtökönként csinálja a heti backupot, ilyenkor a szerver némileg belassul, és lassabban jönnek be az oldalak, mert lassabban is generálódnak. emiatt előfordulhat, hogy 1-1 lockot tovább tart bent egy processz, és ha ugyanarra akar lockolni egy másik processz is, többet kell várnia. mivel retry-outos (bizonyos mennyiségű próbálkozás után adja fel, nem timeout után) spinlock van, ezért ez többszöri próbálkozást jelent. az eredeti próbálkozások közötti idő túl kevés volt, emiatt aztán volt néhány (kb. 15) lock failure hibajelentés, úgyhogy átírtam az in-between timert, azóta nincs hibajelentés.

úgyhogy marad is a mysql-es lock a mostani rendszerben is. :)

"meresi eredmenyek nelkul"

Tegnap óta ez birizgálja a csőrömet, mert ha jól tippelek az oldalra, akkor a DB van ronggyá tekerve és 90%-ban(*) olvasással, és ezen nem az fog segíteni, hogy M db. appserver és 1 db. DB.

*) de inkább több

hát pedig pont nem.

elég sokrétű caching stratégiát alkalmazunk, és a db már jó ideje beéri egy procival a négy közül, amit hajlamos vagyok személyes büszkeség tárgyának tekinteni. :) arról nem is szólva, hogy a mysqld is konkrétan szénné van már optimalizálva, nem csak adatstruktúra szinten, hanem query cache, memória/disk használat ügyében is.

nem, itt, ami a gond, az az, hogy mivel egyre több szolgáltatást vezetünk be, és ezek közül sok a minimálisan prediktálható, on-the-fly ajaxos service, ezért pakolni kéne a ramot és a processzorkapacitást a szerverbe, viszont a blade szerver kategória nálunk árban sajnos nem játszik, ezért akarok a klasszikus google-féle úton elindulni: könnyen cserélhető, könnyen bővíthető, teljesen standard pc-kből építkezve kihozni egy skálázható rendszert. költséghatékonyan, standard, open-source elemekből.

tévedés ne essék, most per pillanat jól fut a rendszer, és kisebb csuklásokkal már évek óta, ugyanazon a vason, egyre több szolgáltatással teszi ezt, köszönhetően többek között annak, hogy tényleg szénné van optimalizálva az egész rendszer. csakhogy a jövőben ez már nem lesz elég, és nem akarunk minden ugrásnál egy még drágább és még drágább vasra átállni, hanem egy fenntartható, könnyen bővíthető rendszert akarunk összerakni. erről szól az egész.

ezért akarok a klasszikus google-féle úton elindulni: könnyen cserélhető, könnyen bővíthető, teljesen standard pc-kből építkezve kihozni egy skálázható rendszert. költséghatékonyan, standard, open-source elemekből.

Az a baj, hogy ez elmeletben tok jol hangzik, a gyakorlatban viszont nagyon nagyon NAGYON sokaig nem eri meg. Lattam ilyen ceget, akik ezzel kiserleteztek, sajat tapegysegeket is terveztek, stb. aztan rajottek, hogy nehany szaz gepnel meg mindig dominal az ebbe fektetett munkaido ara es sokkal koltseghatekonyabb megvenni az olcsobb fajta elore gyartott szervert mint erolkodni a sajat konstrukcioval.

Tovabbi problema, hogy a PHP-s vilag nem nagyon ezzel a szemlelettel epult, eleve el kell felejtened a fajlba irast es olyan adatbazisokat/adatstrukturakat hasznalnod, amik megengedoek egy-ket-harom node kiesesevel szemben. Ezzel szoges ellentetben van az, hogy pl. lockolni akarsz, mert az barmifele nagyon elosztott rendszerarchitekturat lehetetlenne tesz, hiszen valakinek kell mondania egy lockra autoritativ igent, innentol kezdve master electiont kell tartanod, meg kell varnod amig a lockjaid szinkronizalodnak, stb. vagy bevallalsz egy SPOF-ot a lock szerveren, ami megint ellent mond a nagyon elosztott architekturanak.

Aztan azt se felejtsuk el, hogy 10 gep hosting koltsege sem elhanyagolhato, lehet hogy inkabb megeri 2-3 normalis gepet berelni valahol es akkor a szolgaltato felel az alkatreszcsereert es nem Neked kell berohanni cserelni a disket. (Mennyibe is kerul egy munkaorad a munkaltatodnak jarulekokkal egyutt?)

Szerintem, probald meg a vizioidat kicsit bekorlatozni (tudom, amikor cluster epitesbe fog az ember, jol esik Google meretekben elmerengeni, tenyleg nem bantasbol mondom) es helyette inkabb az uzletileg szigoruan szukseges lepeseket valositsd meg. Tehat ha meg tudod oldani ket szerverbol ugy, hogy atteszed a DB-t, oldd meg ket szerverbol. Aztan ha felmerul az igeny (es csakis akkor), lepj tovabb. Lasd meg: LEAN elv. Igy Te sem fogsz befurdeni vele es a munkaltatod/megbizod sem dob ki feleslegesen sok penzt.

--
Pásztor János
Üzemeltető Macik

neeem, a google-féle hozzáállásban nekem pont az tetszik, hogy igyekszik elkerülni a spéci hardverek használatát, és amit lehet, off-the-shelf alapon old meg.

amúgy nem gigászi méretekben gondolkozok: a közeljövőre (1-2 év) megfelelő lesz a már megvett microcluster:
- 1 db. gateway gép (nfs, nginx, központi cronos scriptek, dhcpd, ntpd): core i7 quad, 16gb ram, sata raid
- 2 db. appserver gép (php-fpm): mini-itx alapon, core i5 duo, 8gb ram, 128gb ssd (a local rendszernek)
- 1 db. dbserver gép (mysqld, memcached): mini-itx, core i7 quad, 16gb ram, 128gb ssd (csak a local rendszer) + egy IRAM-szerű, sata-n csatolt, DDR2 ramokkal működő ramdisk (saját vészhelyzeti elemmel)

ennyi, nem több. ezeket kell összehangolni.

Figy, szerintem mas egy tobb ezer-tizezer gepes clustert uzemeltetni olcso alkatreszekkel mint egy olyan clustert, ahol egy gep kiesese is teljes leallast okozhat. A Google pont leszarja, ha a szerverterem 10%-a all, olyan az adatszerkezete hogy nem erdekli es majd jon a 24/7 rolleres mernok aki kicsereli. Nalad ha meghal a GW gep, leall az egesz hobelebanc es mivel nincs ertelmes tavmenedzsmented sem on-site mernokod, kerheted a szerverteremtol a KVM-et osszesen legalabb 4x mire sikerul odaig eljutni, hogy SSH-n be tudsz menni a gepekre.

_Nekem_ az a tapasztalatom, hogy ezzel a vegyunk olcso gepet mert konnyu alkatreszt szerezni hozzaallassal meg fogod szivatni magad. En anno toltottem egy franko hetveget a Victor Hugo utcaban emiatt. Soha tobbet.

Ha semmikepp nem vagy meggyozheto, legalabb vegyel egy olcso 4 portos KVM switchet a gepeidhez amibe problema eseten be tud dugni az on site manus egy UTP kabelt es akkor nem kell allandoan rohangaltatnod amikor egyik geprol at akarsz maszni a masikra.

--
Pásztor János
Üzemeltető Macik

+1, vagy inkább +nagyon sok. Még brand gépek és aránylag jól tervezett rendszerek is okoztak álmatlan éjszakákat - bár a legtöbb para abból adódott, hogy az üf. a javasolt Intel SSD-k heléyett valami x márkát vett, mert az olcsóbb volt, és időnként kiszórta a raid10-es tömbből őket a vezérlő. Mind a négyet :-P És "valahogy" ezt nem tolerálta a rajta futkorászó mysql...

"Az NFS-t surgosen felejtsd el. Egyreszt vannak ennel jobb megoldasok, masreszt az NFS bizonyos korulmenyek kozott ugy ossze tud borulni alattad (foleg nem megfelelo config eseten), hogy hard reset kell a fele gepparknak."

Ezen a NetApp-os sracok csak mosolyognak :)

Amugy teljesen vallalhato amit irsz, annyit tudnek hozzatenni, hogy en mindenkeppen EMC networkert hasznalnek backupra, Netscaler megint csak jol bevalt load balancernek nalunk.

Itt Centos 6-rol volt szo sajat konfiguralasban, nem NetApp storagerol. Webes kornyezetben vannak specializaltabb technologiak a feladatra, tok folosleges full filerendszert tenni a dolog ala. Nem ketelkedem abban, hogy lehetseges NFS-t ugy konfiguralni hogy jo legyen, de szerintem nem art nemi tapasztalat a teruleten, nomeg rengeteg teszteles. Ha csak siman feltelepited es nem turod at a configjat jo alaposan, jo esely van ra, hogy nagyobb terheles hatasara ossze fog borulni. De majd ugy is akarok nezelodni NetApp storage kerdesben, max megkerdezem oket, mit gondolnak a temarol.

"Itt Centos 6-rol volt szo sajat konfiguralasban"
Arra utaltam, hogy lehet ezt jol is csinalni. Nekem semmi nyugom a NetApp-al, bar sokat nem is dolgozok vele, vannak erre szakosodott kollegak, de ugy tunik, rezzenestelenul mukodik minden.Persze lehet, hogy a hatterben a sracok mar vert pisalnak :D

Anno volt szerencsém olyan farmot üzemeltetni, ahol szinte minden NFS-ről "érkezett" (nfsroot, alkalamzások nfs-ről csatolva, stb.) - két nagyobb borulásról tudok, az egyik esetben sem az NFS volt a "hunyó". Ennek ellenére én sem mondom azt, hogy az NFS egy "életbiztosítás", de az esetleges hibákra kellően felkészülve, lehetőleg minél kevesebb spof-ot a rendszerben hagyva (optimális esetben egy szál utp-kábelen összekötve a gépeket) megbízhatóan el tud ketyegni.

ha jól tudom, az nfs-nél az a ciki, ha a source szerver valamiért kiesik, és ilyenkor káprázatosan befagynak (io blockba jutnak) azok a gépek, amiken be volt mountolva az.

a miniclusterben ez lenne a felállás, nfs-szempontból:
- a gateway szerver az nfs szerver is egyúttal.
- csak a /home lesz megosztva.
- mindegyik appszerver a saját /home-jának a helyére mountolja be a gatewayről megosztott /home-ot.
- a db szerveren szerintem felesleges NFS mountot csinálni, mert ott aktív script nem fog működni.
- a clusteren belüli gépek és a gateway egy switchre lesznek rákötve, úgyhogy ha nem is az "egy szál utp kábel" szintű csatlakozás lesz, de teljesen közel maradnak.

amit már látok potenciális problémának:
- mikor az appszerverek bootolnak, a gateway szerveren már működnie kéne az NFS share-nek, különben megakadhat a boot a mountoláskor; igaz?
- ha a gateway szervert valamiért rebootolni kell, akkor valahogy szólnia kell az appszervereknek, hogy lőjék le magukban a php-fpm-et (mert csak az fogja használni a /home-ot), és hogy unmountolják a /home-ot. aztán reboot végén, amikor már felállt a gateway szerver, akkor kell szólnia az appszervereknek, hogy heló, itt vagyok, és akkor azok remountolhatják a /home-ot, és újraindíthatják a php-fpm-et; igaz?

erre van már létező megoldás?

ha jól tudom, az nfs-nél az a ciki, ha a source szerver valamiért kiesik, és ilyenkor káprázatosan befagynak (io blockba jutnak) azok a gépek, amiken be volt mountolva az.

Igen, jol latod. Csinalhatsz NFS failovert, de az egyreszt csak UDP-vel fog ertelmesen mukodni, masreszt szembe jon az altalam itt leirt problemakor.

- mikor az appszerverek bootolnak, a gateway szerveren már működnie kéne az NFS share-nek, különben megakadhat a boot a mountoláskor; igaz?

Nem, mert tudod manualisan / scriptbol is mountolni.

- ha a gateway szervert valamiért rebootolni kell, akkor valahogy szólnia kell az appszervereknek, hogy lőjék le magukban a php-fpm-et (mert csak az fogja használni a /home-ot), és hogy unmountolják a /home-ot. aztán reboot végén, amikor már felállt a gateway szerver, akkor kell szólnia az appszervereknek, hogy heló, itt vagyok, és akkor azok remountolhatják a /home-ot, és újraindíthatják a php-fpm-et; igaz?

Ez mar eroteljesen a hack megoldas VAGY tenyleg failover clustert epitesz, de az egy onallo feladathalmaz. Rengeteg ponton elverezhet egy ilyen megoldas, ugyhogy HA ezt valasztod, mindenkepp a kezi leallitast javaslom. Ha meg berohad a gateway... good luck, a szerverkozpont szeretni fog, ha a 10 gepedre egyesevel kesz KVM konzolt. Lehetoseg szerint meg az irodaban kiserletezd ki, hogy mi van ha berohad a gep es konfiguralj ertelmes timeoutokat. Arra is ugyelj, hogy az alkalmazas mit csinal, ha kap egy file close muveletre egy IO hibat (mert az NFS eseten tudtommal akkor kapod a hibat a helyi filerendszerrel ellentetben).

--
Pásztor János
Üzemeltető Macik

egyébként úgy látom -- főleg az NFS-es thread-ből -- hogy van egy alapvető tárgyi tévedés a cluster célját illetően.

nem HA a cél, és ki vagyok békülve a SPOF-okkal, egyelőre.

a cél az, egyelőre, hogy az egygépes üzemből (ami valójában kétgépes, mert pár tábla egy másik szerverről megy, de ez részletkérdés) első körben szét tudjam szedni a dolgokat a kívánt konfigra, és az stabilan menjen.

ergo nem kell most DRBD-s NFS, ha a gateway gépen meg leáll a HDD valamiért, az úgyis olyan esemény, ami miatt be kell slattyognom a hosting központba. a reboot és a boot kezelése az, amit meg kell oldanom, hogy az NFS kliensek ne sikoltsanak be.

db redundancia sem kell per pillanat, egy db szerverrel vígan el fog menni még jó darabig a rendszer.

ami az igazán fontos, az valami közös lockolási lehetőség (mert hiába, de nem tudom megkerülni a php-ból a fájlba írást, mi több, átírást), meg az, hogy ha valamelyik app szerver kiesne, akkor a gateway szerveren levő nginx vagy varnish vagy akármi erről értesüljön, és oda már ne küldjön kéréseket.

A gw-en egy haproxy frontendnek, aztán mögötte varnish meg "normál" webszerver(ek) url alapon szortírozva? Faék egyszerű, és elég jól teljesít. Én egyébként elgondolkodnék azon, hogy az alkalmazásszerveren a webes kiszolgálást végző cucc ne a default 80-as porton menjen, hanem mondjuk 8080-on, és oda csak a többi appszerverről fogadjon el kéréseket, a 80-as portra meg ráaggatni egy-egy haproxy-t, backend pool-ként meg felvenni az összes appszerver 8080-as portját mindenütt. Innentől kezdve csak azt kell megoldani, hogy a fürt "közös" ip-címe mindig egy adott gépen figyeljen, az meg megint nem nagy kunszt :-P

hát... a haproxy+varnish+nginx+phpfpm kombó rémálomnak hangzik.

az nginx híresen jó a statikus file kiszolgálási teljesítményében, és a site természete miatt vannak a teljesen statikus elemek... és a teljesen dinamikus elemek, a kettő közt nincs szürke zóna. a statikus elemekben ott vannak a képek, a js és css fájlok, a többi meg mind dinamikus.

igazság szerint nincs mit cache-elni. az nginx a statikus cuccokat amúgy is cacheli önmagában (tudomásom szerint; javítsatok ki, ha nincs így), a dinamikus tartalmakon meg sajnos nincs mit cache-elni, ezért azoknál teljesen felesleges lenne a plusz layer.

ha teszem azt egynél több nginx futna, akkor már persze lenne étterme a haproxynak, de mivel csak egy fog futni még jó ideig, ezért az csak plusz adminisztrációs nyűg lenne, nem?

na, akkor a lockolási probléma megoldva.

jön a cluster management. :)

belemélyedtem rendesen a témába, és úgy tűnik, hogy centoson gyárilag kénytelen vagyok a pacemaker+corosync+crm+ccs+pcs+lcmc kombóval dolgozni, ha a hivatalos utat akarom követni.

mivel a dokumentáció brutális mennyiségű (bár egy részén már átrágtam magam), pár kérdés már most is felütötte a fejét nálam.

1. a configuration management megoldható csak ezekkel a komponensekkel? úgy látom, hogy a ccs csak konkrétan a cluster funkcionalitás konfigurációit hajlandó átdobálni és menedzselni, viszont az lcmc tutorial screenshotjaiban arra utaló jeleket is láttam, hogy ott a konkrét daemonok konfigjaiba is be lehet nyúlni, úgyhogy ez most nem tiszta.

2. failover és HA most nem kell. a STONITH koncepcióját is értem, de nem vagyok benne biztos, mennyire lenne érdemes használnom azt, és a fencinget úgy alapból. igazából egy olyan beállást kéne összehoznom, ami a gateway gépen futó nginx *konfigját* változtatja attól függően, hogy melyik clustertagon hogy fut 1-1 service:
- ha a gateway szerveren leáll vagy még nem indult be az NFS, akkor a cluster tagokon a /home-ot umountolni kell, de előtte az appserver típusú tagokon a php-fpm-et le kell lőni, mivel csak azok használnak bármit a /home-ról.
- ha valamelyik appserver típusú tagon a php-fpm leáll, nem fut, vagy nem reszponzív, akkor a gateway szerveren az nginx konfigot úgy kell beállítani, hogy arra az appserverre ne küldjön fastcgi kérést (nginx bad gateway üzeneteket elkerülendő).
- ha a dbserver típusú tagon a mysqld nem fut vagy nem reszponzív, a gateway szerveren az nginx konfigot úgy kell beállítani, hogy a fastcgi használat helyett egy statikus oldalt (technikai probléma lépett fel, stb) kell mutatni, és az appserver típusú tagokon le kell kapcsolni a php-fpm-et, és a gateway szerveren szólni kell a cronos processzemnek, hogy ne próbáljon meg háttérfolyamatokat futtatni.
- ha a dbserver típusú tagon a memcached nem fut vagy nem reszponzív, akkor ugyanaz, mint előbb.
- ha visszajön a mysqld és/vagy a memcached, akkor először az appservereken a php-fpm-eket elindítani, aztán áttérni a normál konfigurációra az nginxben, és újra engedélyezni a cronos scriptemet.
vajon ilyet tud ez a programcsomag?

3. a pacemaker doksikban azt írják, hogy nehogy dhcp-vel merjem a cluster tagoknak az IPv4 adatokat megadni. pedig a menedzselhetőség szempontjából ez nem lenne utolsó dolog (most is így van beállítva). persze maga a dhcp úgy van beállítva, hogy MAC címekre vannak rálőve konkrét IP-k, tehát a gépek IP-je és hostneve sosem változna. ez így még mindig problémás? (ha pl. lejár a lease, a megújítás pillanatában egy pillanatra elveszhet az IP, és ez a gond?)

4. nincs hivatalos php-fpm és memcached OCF script. találtam néhány hekkeltet, vajon ezzel érdemes így foglalkozni?

na, config managementre megvan a választásom, az ansible. kb. pontosan azt tudja, és úgy, ahogy én szeretném.

most jön a következő nagy téma: a pacemaker. kicsit most overkillnek érzem az egészet, mivel igazán ebből most csak a monitoring részét használnám. fencingre csak olyan szinten lenne szükségem, hogy ha a gateway szerver újraindul, véletlenül se maradjon bemountolva a belső gépeken a /home, és emiatt az appszervereken az unmount előtt le kell lőnöm a php-fpm-eket is.

mivel az ansible nagyon jól megoldja a távoli szervereken a processzek state-be hozását, ezért valahogy a pacemaker/corosync párost kéne összehoznom az ansible-el, mármint úgy, hogy a pacemaker figyeli a cluster általános állapotát, és az triggereli az ansible-t.

valami ötlet, tapasztalat ebben?

egyébként megnéztem a redhat-féle hivatalos megoldást (spacewalk), az is nagyon szimpatikus, attól eltekintve, hogy postgres-t követel meg db backendnek, aminek a fenntartásával nincs tapasztalatom, sajnos. :( így az nekem kiesett... szomorú látni, hogy volt egy kezdeményezés egy mysql-es spacewalkra, itt:
https://fedorahosted.org/spacewalk/wiki/MySQL_support
de végül a srác másik diplomamunkát választott, így ennek annyi.

( igor | 2014. 05. 13., k – 22:40 )

Ha ne túl nagy a site és appservernként rendelkezésre áll a teljes site helyigénye akkor én eliminálnám az nfs-t és a változásokat iwatch-al szinkronizálnám az appserverek között.

Ezen felül a gateway/loadbalancerre egy varnisht mindenképpen tervezz be. Az egyes appservereken az tud health check-et is végezni és szinte minden egyebet amire szükséged van.

MySQL esetén Percona fork használata javasolt még.

( efbijn | 2014. 05. 14., sze – 05:56 )

sub

@@
"You can hide a semi truck in 300 lines of C."

( uid_4656 v | 2014. 05. 19., h – 16:35 )

Én is adnék néhány tippet-tanácsot.

Ha igazán szépen és jól skálázható architektúrát akarsz, akkor a következő "rétegekben" kell tudnod skálázhatóságot nyújtani:

- DNS --> a www.akarmi.com név mögött round-robin módon legyen több IP-cím
- az így használni kívánt IP-címeket oszd el eszközökre dinamikusan úgy, hogy ha eszközök halnak meg, akkor menjenek át az IP-k másik eszközökre (ebben segíthet pl. a hálózati eszközökön a VRRP belövése, linuxon a keepalived (szintén VRRP) vagy a pacemaker - alaposan nézd meg őket, különböznek sokmindenben)
- ezeken az IP-címeken hallgatózzon a kérések route-olásáért felelős szoftver (ez lehet haproxy vagy nginx - az igényeid alapján a haproxy ideális lehet, mivel szépen tudja nézegetni, hogy melyik backend webszerverek vannak életben éppen)
- a kiszolgált tartalmak elé lehet tenni cache-t, itt a varnish-t érdemes nézegetni, mást nagyon nem (de jöhetnek tippek nekem is ebben)
- a statikus tartalmakra az nginx tényleg jó, ami még jobb lehet az az, ha kiviszed valamilyen CDN felhőbe az adatokat (de akkor ne hozd haza őket a varnish-ba)
- a dinamikus tartalmak előállítására a php-fpm tényleg jó lehet (bár nem mindig a legjobb, de azt írtad, hogy kimérted)
- a dinamikus tartalmak mögé is lehet tenni cache-t, itt sok lehetőség van (memcache, redis, mongodb - a megfelelő alkalmazásokkal, a memcache sok node-ra nem skálázódik olyan jól, mint a többi, kevés node-ra viszont cserébe sokkal jobb és egyszerűbb)
- ami nincs a cache-ben, az adatbázisban lesz - ACID adatbázist skálázni viszont nem jó mulatság, ha teheted keress más megoldást (itt is segíthet az, ha nem adatbázisban, hanem csak mögöttes cache-ben gondolkodsz, esetleg a "tényleg fontos, hogy konzisztens legyen" adatok pillanatnyi állapotát időnként kiszinkronizálva egy klasszikus adatbázisba

Ez az alap, ezt már többnyire csak butítani kell. :-)

A konkrét kérdéseidre:

- haproxy
- haproxy
- NTP (illetve a sticky session-re (így hívják azt, hogy ugyanazt a klienst mindig ugyanarra az appserverre küldje a load balancer) - haproxy)
- elég, de én mondjuk szoktam localhost-on futtatni egy mail szervert és a localhost-ot adom meg - nagyobb levélforgalomra jobba skálázódik, képes lesz szétdobálni a leveleket több különböző kimenő SMTP szerverre stb.
- az NFS-t az egészből úgy ahogy van, kihagynám, ha tehetném, de pont az OS az, aminek az esetében nem igazán fog fájni, az OS fájljaihoz való nyúlkálás általában nem függvénye a bejövő HTTP kérések mennyiségének, így nem zavaró a dolog
- fogalmam sincs :-)

Elég nagy szerverpark üzemel (még...) úgy, hogy nfsroot van a kiszolgálók alatt, és a boot során dől el (a kernel kap egy, a gép funkciójára vonatkozó paramétert, ami a /proc/cmdline -ból kinyerve szépen feldolgozható) az adott gép funkciója, ami alapján a szolgáltatást nyújtó komponenseket és a kapcsolódó adatterületeket is felhúzza - nfs-ről illetve lokális diszkről (pl. redis esetében a normál leállításkor mentett tartalmat - ha van ilyen.)
Ha az nfs-kiszolgáló is párban van, akkor azért nagy para nem lesz - és ahogy írtam is, nagy megborulások nem az nfs miatt voltak.
Az adatbázis(ok) terheléselosztása már nehezebb dió - aktív-aktív fürt esetén egy megborulás után sokat lehet szopórollerezni... Ha lehet, az alkalmazást kell felkészíteni, hogy képes legyen külön read-only adatbázisliknet is használni - ekkor egy aktív/passzív db-fürt, előtte haproxy, ami az írásokat az épp aktív node-ra tolja, az olvasásokat meg round-robinban szórja a db-k felé. Ez persze akkor jó, ha a rendszer terhelése döntően olvasás.

Az nfsroot-nak egyébként van mégegy előnye: pici ügyességgel simán lehet verziókezelőben tárolni az egészet (fsvs), amivel a frissítések elég gyorsan lezavarhatóak (checkout egy munkaterületre (/work) , chroot /work, frissít, exit, commit, checkout a tesztgépek nfsroot-ja alá, tesztszervereken az érintett motyó újraindítása, ha sikeres, akkor mehet a checkout az élesek alá is. Kevés gépnél mondjuk nem jelentős a megspórolt idő, néhányszor tíz gép esetén viszont annál inkább.)

( tompos v | 2014. 05. 29., cs – 14:11 )

> idő szinkronizálás: ntp, a fejgép valamelyik európai ntp szerverről veszi az adatokat, a cluster tagoknak pedig a fejgép az ntp forrás.

Az utobbit hagyd ki a kepbol, vegye mindegyik a hu.pool.ntp.org-tol. Nincs okod ra, h mashogy legyen.

Miért esne szét? A cluster tagjainak az órájára az a követelmény, hogy egymással szinkronban járjanak, nem pedig az, hogy egy külső fárrással. Scenario: az egyik gép, aminek a saját órája nem túl pontos önmagában, nem éri el a külső pool-t valamilyen tőled független okból. Ez a gép el fog csúszni a többitől, és ez az elcsúszás megmarad addig, amíg valamelyik belső hosthoz nem szinkronizálod. Ha senki sem éri el a külső ntp forrást, akkor gyakorlatilag megszűnik az időszinkron, míg abban az esetben, ha saját forrásokat használ, akkor lokálisan -akár elérhető a külső forrás, akár nem- megmarad a szinkron.
Ahol pl. Kerberos-t használnak, ott sem egyedileg frissítenek időt a gépek külső pool-ból, hanem a KDC-(k)hez szinkronizálnak, és a KDC(-k) az(ok), ami(k) szinkron izélnek kintről/atomórától/akármitől.

és ez vajon mennyi idő? amíg rásyncel az egyik ntp szerverre a pooljából? az meg reálisan mennyi idő, 10-20 mp? addig kieshetnek egy picit a syncből a benti gépek, az igaz, de vajon mi van sűrűbben, ntpd restart a gatewayen vagy intermittens hálózati hiba? ha rajtam múlik, az utóbbi.

Egy nem ntp szerverrel mit csinaljon? A toket vakarja?

Igen, akkor is mukodnie kell. De mivel ez egy online szolgaltatas, valoszinuleg az offline ido kicsi lesz.
Igy osszevetve a +1 szolgaltatast (= +1 hibalehetoseg egy olyan service-rol, amirol fingja sincs) azzal, hogy mennyi esellyel fog offline-ban gondot okozni, szamomra eleg egyertelmu. Persze mindenki ugy szopatja magat, ahogy jol esik:)

Hogy mivan? Azt hogyan?

Mindenesetre:

- akkor is ntp server kell (legfeljebb a node-okra is)
- meg mindig nem latom, mit nyersz vele egy interneten logo gepen ahhoz kepest, mintha publikus ntp szerverekhez szinkronizalna

Ertem en, h meg lehet csinalni, csak miert fizeti ki neked ezt a fonokod?

Ha külső forrásból, függetlenül szinkronizálnak, akkor addig jó, amíg garantáltan valamennyi géped el tudja érni a pool legalább egy szerverét, és az így lekérdezett szerverek órája pontosan együtt mozog. Ez utóbbi feltétellel nincs gond, a probléma azzal van, hogy valamennyi gépnek folyamatosan el kell érni egy külső, tőled független szolgáltatást.
Ha ezt a szolgáltatást valamelyik géped nem éri el, akkor az bizony elcsúszhat a többihez képest. Mivel a saját hálózatodon kívül n+1 olyan eszközön megy keresztül a forgalom, amire nincs ráhatásod, így nem tudod garantálni azt, hogy minden géped, minden kérése célhoz fog érni. Márpedig a szigorú időszinkronhoz erre van szükség.
Ha egy vagy két belső forrás szinkronizál a külső pool-hoz, és ezekhez szinkronizálod a belső gépeket, akkor tőled független eszköztől nem fog függni az órák együttfutása, ergo ha van külső forrás, ha nincs, az órák egymáshoz képest nem fognak elmászni.
Ha egyáltalán nem éred el az ntp pool-t egyik gépről sem, akkor saját ntp-kiszolgáló(k) esetén maximum az történik, hogy a valós időhöz képest minden gép egységesen fog elcsúszni (ahogy az ntp-szervere(k)nek kinevezett gépe(i)d), viszont ha mindenki külön szinkronizálna egy külső szerverhez, akkor a külső pool elérhetetlensége valamennyi gépen a saját óra szerinti működést, és garantált szétcsúszást eredményez.

Mutatnal egy konkret peldat? Eroltetten se igazan sikerul talalnom olyat, h miert ne tudna elerni az osszes gep a kulso szolgaltatast.

Arra viszont ecceru, hogy mikor kenheted a hajadra a belso szervereidet (teljes rendszer inditas 0-rol).

A te esetedben T. sysadmin definialja a sajatlabonloves tipikus esetet.

Idoben vazold fel legyszives, mikor csinal ez problemat. Meg mindig nem latom realisan.
Azaz most van 12:00, Pistike Hosting Kft.-nal tonkre megy a switch (switch1.pistike.hosting.local:). A gepek magukra maradnak a firewallal (amin amugy meg mindig lehet ntp a legrosszabb esetre, bar lehet, h az okos admin nem akar egy ilyen szolgaltatast az fw-re...).

Innentol tovabbirnad, amig para lesz?

10x
t

Innentől, ha nincs elérhető ntp-szerver, a gépek saját óra szerint működnek, és elkezdhetnek szétcsúszni, mivel nincs honnan szinkronizálni. És ezt a kiesést nem tudod befolyásolni, nem tudod, meddig tart- csak azt, hogy a gépeknél az időszinkron "majd valamikor" helyreáll, addig semmi sem biztos, csak a bizonytalanság.
Ha viszont van legalább egy belső ntp-szervered, akkor no para, ahhoz a géphez tud mindenki szinkron izélni addig is,amíg a külső forrás ismét elérhető nem lesz.

A kerdes az, hogy varhatoan mikor _fog_ szetcsuszni, h bajt okozzon. Az nyilvanvalo, hogy elkezd, mikrosec-ek, vagy epp egesz masodpercek akar.
Azt szeretnem erzekelni, hogy nagysagrendbeli kulonbseg van ekozott meg akozott, hogy helyreall az internet kapcsolat es megy minden normalisan.

Aranytalanul sokba kerul sajat ntp szerver uzemeltetese, egyszeruen nincs realis oka, h vki ilyet csinaljon hasonlo kornyezetben.

tompos

Nagyobb hálózatoknál úgy szokás, hogy:

- van több szervered, ami az internet felől vesz az időt (server pool.ntp.org) és ezek a hostok egymáshoz is szinkronizálnak LAN-on keresztül (peer ntpX.lan)
- mindenki másnak ezek a szerverek adnak időt (server ntpX.lan)

http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101

Kispista Bt.-nek semmi szüksége ilyen megoldásra, de párszáz/párezer gép esetében már simán megéri így csinálni.