On Sun, 14 Jul 2013 17:31:59 +0200, Łukasz Matys lukasz@e-matys.com wrote:
Witam. Obecnie mam zrealizowanego LMS'a za pomoca dwoch vhostow, drbd + pacemaker. Wszytko dziala ok od dawna, ale obecnie calosc bedzie przenoszona na nowa infrastrukture. To co mi sie nie podoba, to zawilosc konfiguracji i samo DRBD - ew. kwestie split horizon etc.
Czy macie jakies inne sprawdzone rozwiazania redudantnego lmsa? Juz
nawet
nie chodzi o plywajacy adres ip, ale chociaz sama baza + dokumenty. Jak
to
rozwiazac?
Co do dokumentów to testowałem kiedyś OCFS2, GFS i GlusterFS. Wszystkie trzy pozwalają na dostęp do plików w trybie Active/Active. OCFS2 jest blokowy i mógłbyś go postawić na szczycie DRBD, ale jego chcesz się pozbyć. Zostaje GFS i GlusterFS. Oba mają wady i zalety, ale są raczej niezawodne. AFAIR GlusterFS jest prostszy w konfiguracji, ale wolniejszy. Nie mniej jednak nie sądzę byś do trzymania dokumentów potrzebował mega wydajności. Tak czy siak ja bym zrobił kluster active/active z serwerów LMS. Tylko o replikacji nie możesz zapomnieć. Użyłbym memcache, (php ma natywne wsparcie dla trzymania sesji wewnątrz), lub również GFS/GlusterFS.
mysql cluster active/passive + rsync dla dokumentow?
MySQL Cluster ma to ograniczenie, że tabele podczas pracy trzymane są w całości w RAM (na dysku też), więc jak bazę masz dużą, a RAMu mniej to odpada. Generalnie przy klastrze wąskim gardłem są bazy danych. MySQL ma jakiś mechanizm ale tak jak wspomniałem jest on ułomny (chociaż może coś się zmieniło w ciągu ostatnich 2-3 lat od kiedy go ostatnio używałem). Postgres nie ma wbudowanych mechanizmów pozwalających na budowę klastra. Obie bazy mają wewnętrzne mechanizmy pozwalające na konfiguracje Active/Passive (lub Master/Slave) - tak w wypadku MySQL jak i Postgresa jest to po prostu replikacja. W Wypadku PG mógłbyś użyć slonego, bo ma więcej możliwości niż natywne rozwiązania (np możesz w dowolnym momencie zamienić serwery bazodanowe funkcjami), ale ma też dużo bardziej złożoną i zależną od struktury replikowanej bazy konfigurację.
PS: Replikację "Master/Master" z zapisem do obydwu odradzam i/lub automatycznym przepinaniem ruchu odradzam jeżeli ten ruch jest znaczny. Replikacja działa asynchronicznie, mysql nie ma wspiera double-commit ani żadnego podobnego mechanizmu (postgres tak samo) więc nie ma gwarancji, że nie utracisz spójności danych.
Co proponujecie? Pozdrawiam.