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.