httpd clusterhez milyen közös filrendszer jó?

Linux-haladó

Sziasztok!

Van egy apache szerveres VM-ekből álló kis clusterem, load balancerként nginx-et használok. A rendszer fut és probléma nincs, a kérdésem az, hogyha az apache web root folderét szeretném közös filerendszerre tenni, akkor arra mit ajánlotok?

Pl.: ha egy user feltölt egy file-t az egyik szerverre, az a másik szerveren is jelenjen meg.

A cluster feladata, hogy túl tudjon nőni egy gép kapacitásán. Mindenféle HA és egyéb funkciókat a VM-eket futtató virtualizációs cluster ellát, csak a filerendszer lenne kérdéses. Fontos lenne, hogy ne I/O művelet-szegény legyen a rendszer. Gondoltam, hogy NFS megosztáson keresztül sharelem a web root könyvtárat az összes apache számára, de nem tudom helyes irány lesz-e.

Előre is köszönöm a véleményeket, tapasztalatokat.

Üdv

CadilLACi

  • 2192 megtekintés

( sj | 2016. 10. 31., h – 23:36 )

túl tudjon nőni egy gép kapacitásán. vs. NFS megosztáson keresztül sharelem a web root könyvtárat

ez a 2 ellentmond egymasnak. Szerintem ne tedd kozos filerendszerre (bar attol is fugg, hogy mid van), mert akkor az lesz a szuk keresztmetszet. Inkabb arra talalj megoldast, hogy az egyik szerverre feltoltott tartalom atmenjen a masik szerverre. De az is lehet, hogy a problemat egy egeszen mas megoldassal sokkal ertelmesebben meg lehetne oldani. Pl. a userek egy master szerverre toltik a cuccot, ami aztan replikalja az adatokat a clusterben levo slave-ekre. Mondjuk ez nem feltetlen jatszik a 3000 Ft/ev aru shared webhosting kategoriaban...

( Zs | 2016. 11. 01., k – 13:16 )

Sok minden függ attól is, hogy mi a célod? Ha pl. a magas rendelkezésre állásra hajtasz, akkor a load balancert is illenék redundánssá tenni... Az NFS szerver ezen a ponton szintén problémát jelent: ha bármi miatt lefekszik, hiába van 10 apache node-od, nem lesz alatta az adat.
Alkalmazás szinten szintén lehet kezelni a problémát - de ez egyfelől egy extra feladat az alkalmazásban, másfelől nem annyira egyszerű:
- master node, változás csak itt történhet, a változás innen replikálódik szét a cluster többi elemére. De egyfelől ha a master node megáll, akkor a szolgáltatás "statikussá" vált, lekérdezés oké, módosítás nem oké. Másfelől nem csak a folyamatos szinkront kell megoldani, de új node belépése, kiesett node visszalépése esetén egy ismeretlen állapotból kell szinkronba hozni a rendszert
- maga az alkalmazás képes arra, hogy a változást a többi node-on átvezesse - kvázi multi-master node működés. Na itt azután minden jöhet, split-brain és társai. Nem megoldhatatlan, de a korrekt megvalósítás rendesen leizzasztja az embert.

A shared filesystem nem rossz gondolat, de ha már felmerült az NFS, akkor inkább nézzük meg a GlusterFS-t. Előnye, hogy nincs dedikált szerver node, szinkronba tudja hozni a kiesett node-okat. Hátránya, hogy a sok kicsi file kezelése ... nem gyors. Ezen lehet, hogy tuninggal lehet segíteni, de odáig még nem jutottam.

( Elbandi v | 2016. 11. 01., k – 14:27 )

hacsak nem sokszaz megas fajlokat toltenek fel, akkor tedd ezeket db-be. azt amugy is replikalnod kell valamelyik megoldassal

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

( uid_6201 v | 2016. 11. 01., k – 15:20 )

OCFS2 nem jó?
Olvasás tempójával nincs probléma, írásra sokkal lassabb egy egygépes ext4-hez képest.

( baloghlaszlo | 2016. 11. 03., cs – 10:36 )

Végül sok gondolkodás után arra jutottam, hogy mivel a VM-eket futtató cluster egy proxmox cluster Ceph shared storage-gel, a ceph-en beállítok egy file-rendszer partíciót (nem RBD-t amin a az imagek vannak) és azt fogom bemountolni.

Végül is a ceph magas rendelkezésre állása már a hypervisorokban be van építve.

Ha jutok valami sikerre ez ügyben, megírom.

High-availability != Cluster FS

Legalabbis itt ceph aloli kiosztas alatt ha jol ertem csak mint blokk eszkozt erted, nem pedig mint cephfs-t, attol hogy lesz egy blokk eszkozod ami tobb vm-ben is felcsatolsz, rajta olyan filerendszer kell ami cluster kepes.

Ennel az egesznel nagy kerdes hogy milyen webszervereket kell kiszolgalni, mindenfele hosting vagy sajat fejlesztes amit kontrollalni tudsz?
Mert ha mindenfele hosting akkor valoban kell valami cluster fs, hogy barmifele diszkre irast le tudjon kezelni fs szinten, akar ha tobb geprol is ugyanazt a file-t akarna szerkezteni.

Ha viszont tudod kontrollalni hogy hova tortenhessenek iras muveletek vagy csak melyik gepen akkor meg lehet fontolni egyeb megoldasokat is.

( Winter | 2016. 11. 03., cs – 12:36 )

Mi úgy oldottuk meg, hogy a gyakran lekért (kvázi a webes tartalom) fájlok szinkronizálva megvannak az összes node-on localban, a nagyobb letölthető állományok pedig régebben glusteren voltak felcsatolva. Ezt most cseréltük Amazon EFS-re.

DigitalOcean 10$ kredit- Cloudatcost VPS 50%: MEQy2epUny - <3 openSUSE, Ubuntu, KDE <3

( janoszen v | 2016. 11. 03., cs – 13:13 )

Ez elég erősen függ az alkalmazástól. Ha az alkalmazás például sokat berhel a filerendszeren, valamilyen hálózati vagy cluster FS használata elég érdekes és nehezen levadászható problémákat tud okozni.

De lépjünk vissza egy lépést, itt több probléma van:

- Hogy kerül ki a kód a szerverre?
- Hogyan kezeled a user adatokat?

Az elsőre van több bejáratott megoldás is, többek között Capistrano, Deployer, vagy akár egy saját gyártású shell script. Az NFS-t erre nem javaslom, mert fölösleges és nem tudsz belőle scripteket futtatni pl. cache ürítésre.

A másodikra már trükkösebb a megoldás. A triviális és valószínűleg legkevésbé fájdalommentes megoldás az lenne, ha a szoftver fejlesztője hajlandó lenne az alkalmazást kicsit megsimogatni. Használhatnál például Amazon S3-at, vagy az OpenStack megfelelőjét, a Swiftet. Ehhez viszont az kell, hogy elég legyen egy feltöltöm/letöltöm megoldás. Persze ehhez az alkalmazásnak nyilván kell tartania, hogy milyen címen érhető el a kívánt file, mert nem lesz a webrootban.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Hali!

Az idő haladt, a beüzemelés a következő tapasztalatokkal gazdagított: A cephFS eléggé béta szagú még, nem tudom megbízhatóan használni.

Az alaphelyzet az, hogy fut 3 hypervisoron egymás mellett 2-3-5-x darab Centos 7 VM, amin httpd fut. A beérkező kéréseket a load balancer live balanszolt rount robinnal adogatja tovább ezekhez a webszerver VM-ekhez. De mivel ugyanaz a weboldal van benne a web szerver root könyvtárában, ugyanazt a tartalmat szolgálják ki a VM-ek. Itt célszerű lenne a php és json fileokat amiből a weboldal felépül, egy közösen bemountolt filerendszerre tenni.

Így megúsznánk azokat a problémákat, hogy mi van, ha az egyik json file módosul (azt a másik vm-re érkező kérések hogy veszik észre), mi van ha egy felhasználó feltölt egy képet, stb. Így minden web node ugyanazokat a fileokat látná.

Végleges megoldásnak az látszik, hogy minden egyes Hypervisoron telepítettem egy helyi VM-et ami nem live migrálódhat sehova, megadtam neki egy ssd partíciót diskként, és ide feltettem 1-1 glusterFS bricket. Ez tartalmazza a webszerver root könyvtárát. A Webszerver Node-okra ezek vannak felcsatolva fstabban glusterként.

A dolog működik, per pill nincs vele problémám, mondjuk éles terhelés-tesztnek még nem vetettem alá a cuccot. 10gbit a link a VM-ek és a hypervisorok között, sztem ez is elég lesz. Ami a csőrömet piszkálja, hogy a GlusterFS állítólag kis fileokon nem jól teljesít. A php-k és a jsonok 30-40kbyte körül vannak, nem tudom éles terhelésben ez mennyire lesz szűk keresztmetszet. (bár a )

Arra gondoltam még, hogy a webszerver node-okon létrehozok egy tmpfs-t és a kb 500 MB-nyi webkönyvtár rootot oda felteszem minden bootoláskor glusterről, a változó fileokat tartalmazó könyvtárakat pedig hagyom glusteren.

Valakinek van tapasztalata, tudása, hogy ez alapján mi fog nekem először elromlani?

Köszi

CadilLACi

Hááát lehet ilyet játszani, de a tapasztalatom alapján a jól képzett PHP kódert nem tudod rendszer szintű megoldásokkal helyettesíteni.

Az optimális az lenne, ha a PHP kód nem közös fájlrendszeren lakna, hiszen egy deployment tool ezt meg tudja oldani és nem szaladsz bele arccal előre a PHP sajátos működéséből adódó opcache, stb problémákba. A JSON-ra szintén van megoldás, pl. PHP-val kiszolgálod egy JSON-ra vagy BLOB-okra szakosodott DB-ből és cacheled az előtte levő nginxben. Ha változik a file, az alkalmazás felokosíthatö hogy kiüsse a cachet. De ez csak egy példa, van rengeteg lehetséges megoldás, de a közös filerendszer nem szerepel a listámon.

Persze ez nyilván nem járható mindenhol, de arra számíts, hogy a PHP, különösen terhelt / latencyvel boldogított filerendszer fölött mindenféle izgalmas problémákba fog szaladni, ugyanis tudtommal a tesztelés nagyon komoly része kizárólag helyi filerendszerek fölött történik.

--
Pásztor János
Sole Proprietor @ Opsbears | Development Lead @ IXOLIT | Refaktor Magazin | Refactor Zone

OK, ezt nem irtam le ertelmesen.

Tegyuk fel, hogy van egy cache-ed az adott gepen. Mondjuk APC. Ebben laknak valami adatok. Na most, ha tobb geped van, akkor egy deploykor adott esetben le kell futtatni egy cache torlest vagy cache elomelegitest. NFS-el ezt nem tudod megtenni, mert ugye csak feltoltod a kodot (rosszabb esetben FTP-n) es nem fut a szervereken kod a deploy hatasara. Capistranoval, deployerrel ezt meg tudod csinalni.

Bonuszkent fogalmam sincs hogy hogyan mukodik NFS-el a PHP Opcache-e, azt erdekes lenne megnezni.

--
Pásztor János
Sole Proprietor @ Opsbears | Development Lead @ IXOLIT | Refaktor Magazin | Refactor Zone

( sj | 2016. 12. 01., cs – 21:29 )

szerintem irj az akamai-nak, hogy ebbol a temabol irod a diplomamunkadat, es mondjak mar el, ok hogy csinaljak...