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?
mysql cluster active/passive + rsync dla dokumentow?
Co proponujecie? Pozdrawiam.
postgres - pięknie się robi kilka redundantnych serwerów. a zalety z przejścia na postgresa to już sama w sobie zachęta i powód :) pływający IP to spore wyzwanie aby wszystko chodziło pięknie. dokumenty położone na sieciowym systemie plików (oczywiście redundantnym). no i oczywiście - np kilka radiusdów jeśli autoryzacja / parametry usług - odpytujesz po radiusie. hm z pozytywnym zdziwieniem czytam że DRBD - pieśń sprzed lat 15 tu, działa do dziś. ps. ilu masz tych klientów że musisz mieć pełną redudnancję lmsa. bo w praktyce, jeśli nawet panel klienta nie działa 24h a usługi działają to khem, wielu tego nie zauważy.
W dniu 14 lipca 2013 17:31 użytkownik Łukasz Matys lukasz@e-matys.com napisał:
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?
mysql cluster active/passive + rsync dla dokumentow?
Co proponujecie? Pozdrawiam.
-- Matys Łukasz mobile: (+ 48) 504257944 gg: 6808288 _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Wiadomość napisana przez Krzysztof Drewicz w dniu 14 lip 2013, o godz. 17:54:
postgres - pięknie się robi kilka redundantnych serwerów. a zalety z przejścia na postgresa to już sama w sobie zachęta i powód :) pływający IP to spore wyzwanie aby wszystko chodziło pięknie. dokumenty położone na sieciowym systemie plików (oczywiście redundantnym). no i oczywiście - np kilka radiusdów jeśli autoryzacja / parametry usług - odpytujesz po radiusie. hm z pozytywnym zdziwieniem czytam że DRBD - pieśń sprzed lat 15 tu, działa do dziś. ps. ilu masz tych klientów że musisz mieć pełną redudnancję lmsa. bo w praktyce, jeśli nawet panel klienta nie działa 24h a usługi działają to khem, wielu tego nie zauważy.
Uzywam drbd+heartbeat(teraz pacemaker) dla mysqld, httpd, IP, inne od wielu lat. Bylem ciekaw czy da sie to jakos inaczej zrealizowac.
Radiusy, dnsy, dhcp centralne to wszystko jest redudantnie, bo natywnie to wszystko jest tak pomyslane - ale poza pacemakerem, nie mialem innego pomyslu na lmsa. Pozdrawiam.
Dla dokumentow mozna zrobic jeden zasob na jakiejs macierzy (RAID 1/10) zamontowany nfsem na dwoch node'ach. Co do bazy do psql oferuje wiecej mozliwosci odnosnie LB. Jednak jest cos takiego jak mysql proxy, tam mozna wyroznic gdzie maja leciec zapytania zmieniajace baze, a gdzie same odczyty. A co do vhosta to chociazby dwa wpisy w DNS pod jednym adresem. Teraz przegladarki po pierwszym rozwiazaniu nazwy DNS cache'uja sobie IP. Ewentualnie haproxy z round-roubin.
W dniu 2013-07-14 17:31, Łukasz Matys pisze:
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?
mysql cluster active/passive + rsync dla dokumentow?
Co proponujecie? Pozdrawiam.
Wiadomość napisana przez Łukasz Czerepuk w dniu 14 lip 2013, o godz. 18:23:
Dla dokumentow mozna zrobic jeden zasob na jakiejs macierzy (RAID 1/10) zamontowany nfsem na dwoch node'ach.
Ale tutaj nadal mamy pojedynczy punkt awarii - sama macierz.
Dla dokumentow mozna zrobic jeden zasob na jakiejs macierzy (RAID 1/10) zamontowany nfsem na dwoch node'ach. Co do bazy do psql oferuje wiecej mozliwosci odnosnie LB. Jednak jest cos takiego jak mysql proxy, tam mozna wyroznic gdzie maja leciec zapytania zmieniajace baze, a gdzie same odczyty. A co do vhosta to chociazby dwa wpisy w DNS pod jednym adresem. Teraz przegladarki po pierwszym rozwiazaniu nazwy DNS cache'uja sobie IP. Ewentualnie haproxy z round-roubin.
W dniu 2013-07-14 17:31, Łukasz Matys pisze:
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?
mysql cluster active/passive + rsync dla dokumentow?
Co proponujecie? Pozdrawiam.
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.
uczestnicy (4)
-
Krzysztof Drewicz -
Rafał Ramocki -
Łukasz Czerepuk -
Łukasz Matys