Klaster HA, planowanie infrastruktury

[havq]

Witam.Jestem wieloletnim użytkownikiem Linuksa i właśnie stanęło przede mną małe wyzwanie. Mianowicie, planuję uruchomić klaster HA typu aktywnie pasywny, składający się z dwóch węzłów, wykorzystując do jego budowy wykorzystują infrastrukturę typu heartbeat wraz z drbd (najprawdopodobniej dojdzie tu jeszcze pacemaker). Zakładam, że w razie awarii jednego z serwerów, drugi serwer uruchomi wszystkie nieaktywne usługi zapewniając pełną redundancję (będę się tu wspomagał wirtualnymi interfejsami, na których klienci będą oczekiwać usług). Oto lista usług, które chciałbym na nim uruchomić:

• Firewall oparty na iptables (dostęp do internetu będzie miała jedynie poczta, proxy, dns oraz serwer czasu).
• LDAP (dostęp tylko z LAN).
• Postfix (autoryzacja w LDAP).
• Dovecot.
• Squid (jako HTTP proxy z autoryzacją w LDAP).
• Bind.
• Ntpd.
• NFS (udostępnianie katalogów domowych użytkowników autoryzujących się w bazie LDAP, dostęp tylko z LAN).
• Samba (autoryzacja w LDAP).
• Serwer Apache (dostęp tylko z LAN).
• Postgresql (dostęp tylko lokalny).
• Svn (dostęp tylko z LAN).

Wymyśliłem następujący podział usług:
Serwer nr1 (usługi aktywne):

• Firewall
• Postfix
• Dovecot
• Squid
• Bind
• Ntpd

Serwer nr2 (usługi aktywne):

• LDAP
• NFS
• Samba
• Apache
• Postgresql
• Svn

Do synchronizacji zasobów zamierzam korzystać głównie z drbd, obejmując w nim:

• Skrzynki pocztowe
• Pamięć podręczna squida
• Zasoby binda
• Bazę LDAP
• Zasoby NFS
• Zasoby samby
• Zasoby apache
• Zasoby postgresqla
• Zasoby svn

Jeżeli chodzi o obciążenie tych usług to mogę to konfiguracja na chwilę obecną dotyczy:

• Około 50 użytkowników poczty.
• Około 20 użytkowników korzystających z internetu przez proxy.
• Około 30 użytkowników używających katalogów domowych NFS.
• Około 20 użytkowników używających samby jako zasobów sieciowych.
• Około 50 użytkowników systemu CRM uruchomionym na apache i postgresql

Pomijam svn, bind oraz LDAP, bo dodawanie tutaj danych jest stosunkowo rzadkie(w porównaniu do w/w usług).
Wytrwałych, którzy dotrwali do końca posta chciałbym poprosić o radę. Mianowicie zastanawiam się czy drbd poradzi sobie z synchronizacją wszystkich tych usług poprzez pojedynczą skrętkę między dwoma serwerami?
Czy uważacie, że warto dodać na serwerach moduł PAM zapewniający autoryzację z LDAP (wydaje mi się, że ułatwiłoby to zarządzanie kontami powłoki użytkowników IT, tym bardziej że to nie są moje jedyne dwa serwery)?
Poza tym ciekawy jestem co myślicie o takim rozwiązaniu?
Może macie jakieś sugestie, bądź uwagi dotyczące czegoś czego nie przemyślałem?
Z góry dziękuję za wszystkie opinie i sugestie, a także pozdrawiam użytkowników forum.

[Unit]

Nie podałeś jeszcze na jakim sprzęcie to będzie działać.

Usługi rozdzieliłeś między 2 serwery. Domyślam się, że będziesz miał 2 partycje drbd z rozdzielonymi tymi usługami tak by jeden serwer miał jedną partycję drbd master, a drugą slave - krzyżowo, czy jakiś inny masz pomysł (np.: master-master drbd z gfs2 lub clusterfs)?

Wytrwałych, którzy dotrwali do końca posta chciałbym poprosić o radę. Mianowicie zastanawiam się czy drbd poradzi sobie z synchronizacją wszystkich tych usług poprzez pojedynczą skrętkę między dwoma serwerami?

Na pewno synchronizacja musi być na interfejsach 1Gb, fajnie by było gdybyś miał jakieś zabezpiecznie typu bonding interfejsów.

Czy uważacie, że warto dodać na serwerach moduł PAM zapewniający autoryzację z LDAP (wydaje mi się, że ułatwiłoby to zarządzanie kontami powłoki użytkowników IT, tym bardziej że to nie są moje jedyne dwa serwery)?

Tak.

[havq]

Dzięki za odzew.

Nie podałeś jeszcze na jakim sprzęcie to będzie działać.

Planuje uruchomić te usługi na dwóch maszynach o parametrach:

• Intel Xeon E3-1220
• 8GB RAM DDR3 ECC
• RAID1 500GB SATA
• 1Gb ethernet dla drbd (zintegrowana)
• 1Gb ethernet do sieci wewnętrznej (zintegrowana)
• dodatkowa karta sieciowa dedykowana do połączenia internetowego

Oczywiście dochodzi do tego UPS, automatyczne wyłączanie się maszyn przy niskim poziomie akumulatora i konfiguracja umożliwiająca automatyczne wstanie serwerów po dłuższej awarii prądu. Przy tym ostatnim obawiam się trochę czy heartbeat nie zgłupieje, gdy maszyny będą wstawać jednocześnie.

Usługi rozdzieliłeś między 2 serwery. Domyślam się, że będziesz miał 2 partycje drbd z rozdzielonymi tymi usługami tak by jeden serwer miał jedną partycję drbd master, a drugą slave - krzyżowo, czy jakiś inny masz pomysł (np.: master-master drbd z gfs2 lub clusterfs)?

Dokładnie tak jak napisałeś, w najprostszej wersji zakładałem konfigurację dwóch partycji drbd powiązanych krzyżowo. Koncepcja bardziej złożona dotyczyłaby oddzielnych partycji na:

• Skrzynki pocztowe (Serwer 1 - master)
• Pamięć podręczna squida (Serwer 1 - master)
• Zasoby binda (Serwer 1 - master)
• Zasoby NFS (Serwer 2 - master)
• Zasoby samby (Serwer 2 - master)
• Zasoby postgresql (Serwer 2 - master)
• Bazę LDAP (Serwer 2 - master, przewiduję stosunkowo niewielką ilość zapisów)
• Zasoby apache (Serwer 2 - master, przewiduję stosunkowo niewielką ilość zapisów)
• Zasoby svn (Serwer 2 - master, przewiduję stosunkowo niewielką ilość zapisów)

Na pewno synchronizacja musi być na interfejsach 1Gb, fajnie by było gdybyś miał jakieś zabezpiecznie typu bonding interfejsów.

Dzięki za sugestię, nie dość że zwiększy to poziom dostępności, to jeszcze podniesie wydajność synchronizacji

[Unit]

Sprzęt wygląda ok. Raid programowy czy sprzętowy?

Przy tym ostatnim obawiam się trochę czy heartbeat nie zgłupieje, gdy maszyny będą wstawać jednocześnie

Nie powinno być problemów o ile w konfiguracji heartbeata będziesz miał wpis: auto_failback on - z tego co pamiętam bez tego wpisu, który serwer pierwszy wstanie ten lepszy i zabierze wszystkie zasoby.

1Gb ethernet dla drbd (zintegrowana)
1Gb ethernet do sieci wewnętrznej (zintegrowana)

W sumie mógłbyś wykorzystać obie sieciówki do sieci wewnętrznej - drbd też tędy by się synchronizowało i przy okazji wrzucił byś bonding tylko trzeba było by przetestować jak sobie przełącznik z taką konfiguracją radzi, bo możliwe że będzie odcinał jeden z kabelków (spanning tree protocol).

[fnmirk]

havq, masz do odbioru prywatną wiadomość.

[havq]

Sprzęt wygląda ok. Raid programowy czy sprzętowy?

Raid programowy zbudowany przy pomocy mdadm.

Nie powinno być problemów o ile w konfiguracji heartbeata będziesz miał wpis: auto_failback on - z tego co pamiętam bez tego wpisu, który serwer pierwszy wstanie ten lepszy i zabierze wszystkie zasoby.

Dziękuję, bardzo cenna informacja, będę wiedział pod jakim kątem przeglądać dokumentację.

W sumie mógłbyś wykorzystać obie sieciówki do sieci wewnętrznej - drbd też tędy by się synchronizowało i przy okazji wrzucił byś bonding tylko trzeba było by przetestować jak sobie przełącznik z taką konfiguracją radzi, bo możliwe że będzie odcinał jeden z kabelków (spanning tree protocol).

Chciałem uniknąć mieszania ruchu dotyczącego żądań do serwerów, żeby nie przeciążać dodatkowo interfejsów odpowiedzialnych za synchronizację (ma ona dla mnie priorytet nad żądaniami klientów).

Rozumiem, że sama koncepcja ma na celu jednoczesne podniesienie dostępności zarówno interfejsu do synchronizacji, jak i tego do komunikacji z siecią wewnętrzną? Jeżeli chodzi o przełącznik, to tak czy siak nie mam żadnego odpowiedniego na stanie, więc postaram się kupić od razu odpowiedni.

[fenix79]

Sam od jakiegoś czasu stosuję podobne rozwiązanie, klaster HA aktywno pasywny active passive z drbd i pacemaker i corosync. W klastrze jest uruchomione kilka wirtualnych maszyn na xenie (Windows serwer, oracle, samba...). Każda z wirtualnych maszyn ma oddzielne urządzenie blokowe drbd w trybie master - slave. Do synchronizacji oraz zarządzaniem całością używam pacemaker i corosync z odpowiednimi wtyczkami typu heartbeat, stonith, drbd itp.

Zapytałeś się co się stanie jak maszyny uruchomią się jednocześnie, czy heartbeat nie zgłupieje. Nad całością pieczę sprawuje pacemaker oraz corosync, w którym będziesz miał zdefiniowane zasoby typu master-slave. Pacemaker będzie dbał o to aby tylko jeden zasób typu master był w danej chwili dostępny. W ostateczności może zdarzyć się tak że oba zasoby będą typu slave (poważniejsza awaria), ale nigdy dwa urządzenia typu master. Nawet podczas fizycznego uszkodzenia odnośnika służącego do synchronizacji (mam tu na myśli corosync nie drbd) przy założeniu, że wdrożysz mechanizm stonith wszystko będzie dobrze. Przy zabawach z drbd bardzo ważna jest poprawna konfiguracja stonith, najlepiej na zarządzanej karcie serwera, niezależnej od pracy maszyny (imm czy też bmc), lub w przypadku braku takowej inne rozwiązanie zapewniające wspomnianą funkcjonalność. Np. dodatkowa karta typu stonith, ups z kartą zarządzaną bądź cokolwiek innego zdolne restartować maszynę (niezależnie od jej os) w przypadku jej awarii.

Co się tyczy ilości interfejsów potrzebnych do bezpiecznego używania takiego klastra HA to ja myślę że optymalna była by następująca konfiguracja:

1. 2x1Gbit ograniczająca (ang. bounding) dla drbd (ostatecznie 1x1Gbit), im więcej tym lepiej można zrobić oddzielny lan dla każdego urządzenia blokowego drbd.
2. 2x1Gbit ograniczająca (ang. bounding) dla corosync (ostatecznie 1x1Gbit).

[mariaczi]

Przy konfiguracji zerknij też na smp_affinity http://lserinol.blogspot.com/2009/02/ir ... linux.html dla optymalizacji wydajności kart.

[Bastian]

W klastrze jest uruchomione kilka wirtualnych maszyn na xenie

Przepraszam za pytanie ale jak się ma klaster HA na xenie do idei klastra HA w przypadku gdy padnie dom0?

[fenix79]

Bastian, chyba się nie zrozumieliśmy, dom0 jest uruchomiony na dwóch niezależnych maszynach, a o dostępności konkretnych maszyn wirtualnych (zasobów klastra) dba pacemaker.
Dodatkowo istnieje możliwość pogrupowania usług oraz ich kolejności, co jest zasadne przy architekturze opartej na drbd np. drbd w roli głównego urządzenia (ang. primary) ma być dostępne na maszynie, na której zostanie uruchomiona instancja maszyn wirtualnych. Dokonać tego można za pomocą dyrektyw colocation oraz order.

Kod: Zaznacz cały

colocation col_xen inf: xen1 drbd1:Master xen2 drbd2:Master
order order_xen1 inf: drbd1: promote xen1:start
order order_xen2 inf: drbd2: promote xen2:start