Ostatnio miałem problemy z cieszeniem się pracą. Właściwie kombinowałem
tylko co by robić, żeby nic nie robić i jak dotrwać do weekendu. W końcu jednak
klient (czyli szef) sprowadził cztery serwery (dwa Sun Fire i dwa jakieś
Supermicro) dla swoich klientów i miałem na tym postawić nasz system. Właściwie
to miały być dwie instalacje – dla każdego klienta dwa serwery z których
jeden miał zastępować drugi w razie awarii. Czyli miałem zrobić dwa klastry HA
(High Availability).
Prawdę mówiąc nie miałem większego pojęcia na ten temat, więc się trochę
bałem, czy w ogóle się uda. Na początku więc po prostu postawiłem cztery
identyczne serwery. Potem szef zepsuł jedną maszynę Sun Fire i mogłem spokojnie
się skoncentrować na budowie jednego klastra
:-). Warto zaznaczyć,
że wszystkie te maszyny stoją w Amsterdamie, a ja mam do nich dostęp tylko
przez sieć: SSH (także do konsoli szeregowych) oraz interfejs WWW do zdalnego
wyłącznika zasilania.
Nasz system oparty jest na Xenie, na listach Xena przeczytałem, że do zapewnienia
redundancji dobrze mieć DRBD (dla dla
replikacji dysków), albo iSCSI lub inne rozwiązanie SAN (jeśli przestrzeń
dyskowa miałaby być współdzielona). Wyszło mi na to, że dla nas lepsze będzie
DRBD. Zacząłem czytać o DRBD. Dowiedziałem się, że DRBD dobrze byłoby używać
wraz z Heartbeatem. To się zabrałem za
szykowanie pakiecików…
Po kilku przeróbkach PLDowych pakietów, po kilku kompilacjach kernela,
Heartbeata i DRBD, w końcu udało mi się coś uruchomić. Najpierw niespecjalnie
to działało, a ja kompletnie nie wiedziałem co sie na moich serwerach dzieje.
Ale po trochu to rozpracowywałem. W końcu usługi się uruchamiały tam gdzie
trzeba, a jak maszynę wyłączyłem, to
przeskakiwały na drugą. Super.
:-)
… ale to wszystko w konfiguracji Heartbeat w wersji pierwszej, która
już podobno nie jest zalecana. No to włączyłem wersję drugą (
crm w
yes
/etc/ha.d/ha.cf) i zabawa zaczęła się od początku:
wszystko przestało działać, przestałem rozumieć co się dzieje i dalej trzeba
było pakiet heartbeat poprawiać. Ale i to opanowałem i muszę przyznać, że
sprawiło mi to niezłą frajdę.
:-)
Ciekawe co jeszcze mogę w tym klastrze poprawić… bo inne rzeczy co
czekają w kolejce, niestety, nie są już takie fascynujące… No cóż, kiedyś
nuda musi wrócić.
No i ciekawe jak te klastry będą się zachowywać w warunkach produkcyjnych…
4 uwagi do wpisu “Fajnie jest, gdy praca bawi :-)”
Witam
Mam pytanie: co sie dzieje z DRBD, gdy druga maszyna (ta slave) dziala zauwazalnie wolniej niz master?
AFAIR calosc dziala synchronicznie, wiec zapisy na masterze tez beda opoznione?
PolubieniePolubienie
@sn1p3r: z tego co widziałem, to można ustawić poziom tej „synchroniczności”. Spowolnienie przy rzadkich zapisach można zapewne bardzo ograniczyć. ale jeśli master będzie przez dłuższy zapisywał szybciej niż może slave przyjmować, to wszelkie kolejki się zapełnią (nie ważne, czy w stosie TCP mastera, czy w cache dysku slave’a) i master będzie musiał zwolnić.
Ale czy to w praktyce będzie problem? Jakoś nie wyobrażam sobie zastosowania dla DRBD w którym główną operacją byłby zapis na dysk.
Dla mnie wyzwaniem będzie odpalenie tego DRBD pomiędzy maszynami w różnych „data center”.
PolubieniePolubienie
Zapisywanie na dysk zdarza sie 🙂
Myslalem nad czyms takim
10 maszyn Master DRBD oraz jedna maszyna jako slave DRBD zbierajaca dane z kazdej z 10 maszyn.
Gdy slave zostanie ‘zajechany’ to 10 maszyn takze dostanie w kosc.
Myslalem tez nad DRBD jako alternatywie dla replikacji baz MySQL – tu zapisy tez sie zdarzaja 🙂
PolubieniePolubienie
Przyznasz, że dziesięć maszyn replikujących na jedną to dość ekstremalne zastosowanie. Jeśli chodzi o bazę danych — to nie powinno być źle, jeśli zdalny dysk nie będzie wolniejszy od lokalnego.
PolubieniePolubienie