Dotaz: Vhodný FS pro web-cluster

[LuRy]

Zdravim, poradil by nekdo jaky zvolit FS pro sdílený souborový systém mezi servery? Co napr. drbd nebo glusterfs? Pro a proti? Servery jsou mezi sebou spojeny 2x 1gbit linkou v bondingu.

Diky LuRy

Odpovědi

[1john2]

Jaky cluster/na cem postaveny?

Kolik nodu?

Jakou komunikaci cekate?

Nebylo by lepsi se ptat spis na komunikaci na backend servery(databaze) ap?

[LuRy]

3 uzle 1. (RAID 10 8x 146GB SAS) 2. 1x 160GB SATA 3. (RAID 5 3x 1TB SATA)

Linux debian 7.5

Momentalne je NFS na 1. a mysql cluster (percona-cluster) z 3 uzlu na kazdem z nich Loadbalancer pomoci proxy na kazdem servru nginx+fpm Nicmene mysql cluster se mi nestiha vcas replikovat mezi vsechny 3 uzle takze se stava ze se zaznamy predbihaji oproti realnym casum protoze casto nastava situace kdy se provede klidne 10 insertu v jeden moment.

[Aleš Kapica]

DRBD není FS. Je to v podstatě síťový RAID 1 a clusterový souborový systém (OCFS2 nebo GFS2) nad ním musí být tehdy, pokud je do něj chcete zapisovat současně na obou nodech (musí být v režimu primary/primary).

FS jako glusterfs, apod. mají význam pouze tehdy, pokud je těch nodů větší počet.

[LuRy]

Funkci drbd chapu, slo mi spis o sirsi pojeti moji otazky (tj aspon 2 redundantni uloziste a co nejvetsi rychlost respektive lepsi parametry nez ma momentalni nasazene ext4 pro tyto ucely)

[Aleš Kapica]

Doukd jsem používal DRBD v režimu primary/primary, míval jsem OCFS2, teď pro primary/secondary používám Btrfs - tam kde se pracuje přímo se soubory a ext3 tam kde jsou velké soubory s virtuálními disky.

[LuRy]

Jake je realne vyuziti drbd v pri/sec krom redundance?

[Aleš Kapica]

Poněkud nechápu dotaz. Jaké využití? Objem obsazených dat? Nebo jak často se na ně zapisuje? Nebo jak rychle?

[LuRy]

Velikost dat mě netrápí spíše zvýšení iops a rychlosti čtení a zápisu

[dustin]

Asi žádné, redundance sama o sobě je dost klíčová.

Používáme drbd již roky, ale podezřívám je, že drbd modul občas (párkrát do roka) způsobuje zásek jádra (ping jede, ale nic jiného). Vždy se současně zasekly oba servery na drbd napojené. Podezříval jsem server hosting z mžikových výpadků energie, napojili jsme to na jinou větev a dělalo to pořád.

Po odstranění drbd z druhého serveru (tj. na prvním je drbd jen z historických důvodů, nenavázané na sekundár), k občasným zásekům dochází jen na prvním s drbd. Nevím, jádra jsou tam starší 2.6.32, možná že tam opravdu byly nějaké bugy.

[LuRy]

Jak nad tim cim dal vice premyslim tak zjistuju ze je to vice problemu do sebe a jsem z toho trochu nestastny..
Zkoumal jsem zpusoby replikace mysql protoze zjevne na jednom serveru dostavala sodu, tak jsem rozchodil percona-xtradb-cluster multi-master replikaci mezi 3 uzly kdy kazdy z uzlu ma vlastni php do kteryho zapisuje ale pri doreplikaci mezi vsechny uzly se to trochu zamichava respektive neni to vlozeny (AI+primary) ve stejnym poradi jako to bylo inicializovany php skriptem.
Proto me napadla myslenka mit napr 2 uzle na jednech datech skrz drbd+ocfs2 ale narazil jsem tady na abclinuxu na vlakno kde to bylo oznaceny jako hloupost, ono ve svy podstate asi je to hloupost nicmene ocfs2 se kasá moznosti paralelniho pristupovani k stejnym datum z vice uzlu .. Pripadne jeste jestli to ocfs2 nebude chodit pro tenhle ucel lepe nez ext4.

Kdyz na to koukam zpetne tak uvazuji k navratu na jeden single uzel pripadne zkusit pokus mysql-proxy 1 master (insert/update) + 2 slave (select/show)..

Ted mi chybi nejaky kamarad ktery by mi rekl "Jo tohle uz jsem zkousel chodilo to takhle a takhle, zkus tohle" bohuzel vsichni "spoluzaci" nakonec delaji uplne neco jineho nez mel obor skoly nabizet a kdyz uz delaji v oboru tak delaji neco jako "IT technika" na financnim urade..

[PanZvedavy]

zatizeni a velikost te DB?

[LuRy]

Zatizeni ~200-400 qps podle spicky na 1 uzel

Udaje za 17h behu
Reads / Writes: 76% / 24% (na nejvytizenejsim uzlu)
Velikost db je momentalne 3-4GB v buffer poolu je 2,7GB nicmene velikost db se neustale navysuje (neni konstantni), hodne tabulek  nektere maji 1M a vice zaznamu
Query cache efficiency: 42.0% (2M cached / 6M selects)
Table cache hit rate: 97% (604 open / 621 opened)

[PanZvedavy]

db je mala, zaznamu hodne. Pri teto velikosti by to ale melo bejt vsechno v pameti a tudiz nelimitovano šméčkovým iops na sata discich, coz se puvodne jevilo jako slabe misto. Co takhle audit aplikace nebo navrhu db? Pres milion zaznamu na tabulku je pomerne dost nicmene nejsem profik pres sql...

[LuRy]

Zaznamy v db musi byt minimalne po 6 mesicu, podle me se jako problem jevi velke mnozstvi paralelnich updatu / insertu. Cela aplikace je pomerne dost vytizena, ve spicce podle google analytics je 1000-1700 hitu na stranky za minutu. Signle mysql chodila obecne lepe nez tenhle cluster koncept proto mi to prijde zvlastni (Sedela na raid 10 z 8mi SAS 146gb 10krpm)

[LuRy]

jinak abych tu nemlzil, neni problem s vykonosti, ta je dobra, query cache jede vcelku dobre a overload nebyva ani na jednom z uzlu, 6-7 sql dotazu z query cache zvladnu za 0,6-1ms problem je s tou doreplikaci do ostatnich uzlu

[Aleš Kapica]

Sice nejsem tvůj kamarád, ale můžu ti napsat, že jsem to takhle míval, ale nakonec se to ukázalo zbytečně choulostivé řešení. Lepší je oddělit databázový server z virtualu a databáze replikovat na úrovni dumpu. V podstatě úplně nejlepší je ho mít na jiném clusteru, tak abys nemusel řešit datové i databázové soubory, když je něco blbě.

[LuRy]

Co se tyka replikace tak to resi percona pres xtrabackup-v2 tvrdi se ze to je spolehlivejsi nez mysqldump protoze to nejak resi i zamky respektive je mozny delat skrz to backup i na bezicim uzlu bez nejakych problemu.. ale cim dal vic mi pripada ze bych mel zalozit 5 vlaken najednou :D