HA MySQL cluster - tároló gondok

Linux-haladó

Sziasztok kedves mindenki!

A tanácsotokat szeretném kérni... Vannak ötleteim, de mivel még nem csináltam ilyet, nagyon szeretnék egy kis perspektivat szerezni...

Kérlek, nézzétek el nekem a tapasztalatlanságomat ezzel kapcsolatban. Remélem nem mondok nagy butaságokat...

Szóval. Egy loadbalanced mysql clustert akarok létrehozni egy apache clusterhez. A hálózatba eddig az alábbi szervereket terveztem be:

- Két loadbalancer (az egyiken mysql management cucc)
- Négy MySQL node

Amin dilemmázok, az a fileok tárolása... Tudjátok, ez a mysql cluster része volna, illetve kiszolgálna egy ugyancsak loadbalanced apache clustert. Azt már eldöntöttem, hogy a webes node-oknak nem lesz sok diszkjük, hanem NFS-el vagy más módszerrel (ez az amit még nem döntöttem el) fel fognak mountolni - valahogyan - egy redundáns, nagykapacitású központi file storage-et.

Gondolkodom azon, hogy a mysql node-ok is ezen a központi helyen mountoljanak filerendszert, csak azt nem tudom, hogy miféle olyan hálózati tárolórendszer (hardver) megoldás létezik, ami képes elegendően kicsi válaszidőt (seek-, random-access, stb) biztositani a web és mysql szervereknek egyaránt... Gondolkodom NAS, SAN rendszerekben, de konkrétumok kellenének mert ilyet még nem csináltam...

Tehát a fő gond a fájlelérés és tárolás. Azért szeretném mindenképpen egy helyen tárolni az adatokat és általában a hasznos információkat, mert az szvsz csökkenti a node-ok költségeit és egyszerűbb backup/recovery-t tesz lehetővé... Igazából azért tétovázok ennyit, mert tényleg nagyon nagy mennyiségű query-t kell majd kiszolgálni ezzel a rendszerrel. Ti milyen tároló megoldást tartotok erre a célra jónak? Miféle hardver jöhet szóba? Egy-két példa, jótanács, helyreigazitás nagyon jól jönne... Nagyon szépen köszönöm, ha tudtok nekem ötleteket adni.

  • 1199 megtekintés

( gabrielakos v | 2007. 04. 05., cs – 15:36 )

az álmoskönyv szerint adatbázis cuccait nfs-en tárolni nagyon nem egészséges.
Se nem gyors, se nem biztonságos.
Apache dolgait esetleg.

Én még nem nagyon láttam olyan storage-et, ami "megérte" volna, márhogy olcsóbb lett volna, mint ugyanazt a kapacitást kiépíteni a gépekben. Esetleg olyan méretnél opció ez, ahol tényleg irdatlan méretekről van szó, amit már gépbe nem tudsz pakolni.

--
Gabriel Akos

( miloska | 2007. 04. 05., cs – 15:45 )

mysql-nel replication ajanlott.

ha-hoz pl egy ket node-os master-master replication, aztan ha ez teljesitmenyre nem eleg akkor meg lehet read-only slave-eket pakolaszni korejuk (nyilvan az alkalmazasnak tamogatnia kell h nehany sql szerver ro, masikak meg rw).

( bazso | 2007. 04. 05., cs – 16:44 )

Szia,

Ha van elég pénz, és kell a teljesítmény (ami a szerverszám alapján valószínűnek tűnik), akkor SAN, valami normális doboz sok cache, stb.
Ha meg hálózat, akkor iscsi. Pénztárcától függően hardveres vagy szoftveres.
MySQL-hez nem értek, de hogyan oldják meg a közös adatbázisfájlok piszkálását? Ez még a rac-nak is néha fej(fájl)törést okoz. A replikáció egészségesebbnek hangzik.
NFS-re semmiképpen ne tegyél adatbázist.
Ja, és a nagy kérdés: Milyen fájlrendszert raksz fel, ami megoldja neked a konkurrens hozzáférés problémáját? (Az NFS ezen segít, minden másban ront). Az ocfs megoldás lehet, de állítólag nem komázza a nagy terhelést. Azaz vissza az alapokhoz: nagy i/o terhelés lesz? :-)

Üdv,
BaZso

( sheridan | 2007. 04. 05., cs – 17:03 )

Hm. Köszi szépen mindenkinek a hozzászólást. Ezek után én is kezdem azt hinni, hogy a nem "központi" fájlrendszer jobb megoldás lesz. Csak a skálázhatóság miatt aggódok (lemezterület)...

Abból amit elmondtak, elég magas I/O és lekérdezésszám várható.

Utánaolvastam közben: A MySQL oldalán sem irnak semmiféle SAN vagy egyéb ötletet, pláne nem közös fájlok használatát. Az a gyanúm, hogy a MySQL ezt nem támogatja.

Az meg szerintem baromság, hogy a SAN-on külön könyvtárakban ugyanaz a taralom annyiszor, ahány MySQL node...

ha szetvalasztjak az olvasas es iras muveleteket akkor replication-nel remekul tudsz skalazni, nem kell semmi hokuszpok (clusterfs, stb).

ha nem valasztjak szet akkor mar kevesbe rozsas a helyzet, a replication minel tobb master van a rendszerben annal kevesbe mukodik jol.

jelenlegi stable mysql-lel lehet clustert csinalni de _minden_ a memoriaban lesz (vagyis igen sok ram kell nagy db-hez) es van meg par 'aprosag' amint az ndb nem tud.

5.1-es mysql fog tudni olyat, h mar csak a keyek lesznek memoriaban, az adatok disken. ez jelenleg nem stable. az ndb hatranyai ettol szinten nem mulnak el.

szerk: FOREIGN KEY pl nincs ndb-ben