EDB Postgres Failover Manager, w skrócie EFM to narzędzie do automatycznego zarządzania klastrem baz danych Postgres. EFM zapewnia infrastrukturę wysokiej dostępności dla EDB Advanced Server oraz dla wersji społecznościowej PostgreSQL. Umożliwia monitorowanie stanu baz danych oraz replikacji, generowanie alertów, promocję do roli Master zapasowego węzła zarówno w razie awarii, jak i ręcznie – w razie konieczności przeprowadzenia prac serwisowych na głównym serwerze klastra.
Artykuł omawia narzędzie EDB Postgres Failover Manager w wersji 3.1.
Architektura
Minimalna konfiguracja klastra, niezbędna do poprawnego działania, zakłada wykorzystanie dwóch serwerów działających w trybie replikacji strumieniowej (streaming replication): jednego Master i jednego Slave. Tych ostatnich może być oczywiście więcej. Opcjonalnym składnikiem instalacji jest serwer świadka (ang. Witness) nadzorujący pracę klastra. W uproszonych instalacjach może on zostać pominięty, jednak należy pamiętać, że znacząco podnosi on szansę na niezakłóconą pracę klastra w wypadku problemów z komunikacją sieciową.
Możliwe jest użycie wirtualnego adresu IP przypisanego do serwera Master, który oczywiście zostanie przypisany do nowo wypromowanego serwera Master. Na każdym z serwerów klastra, również na serwerze Witness, musi być zainstalowana i skonfigurowana usługa Agenta, która odpowiada zarówno za monitorowanie działalności klastra, jak i za wykonanie określonych czynności w wypadku zaistnienia określonych zdarzeń. Akcje, poza z góry zaimplementowanymi, można rozszerzać o skrypty wprowadzone przez administratora.
Usługi Agentów na wszystkich węzłach klastra komunikują się ze sobą za pomocą oprogramowania JGroups, które jest instalowane razem z usługą Agenta. Numery portów, na których odbywa się komunikacja pomiędzy agentami, są konfigurowalne w pliku konfiguracyjnym agenta, w związku z tym należy pamiętać, aby na firewallu odblokować komunikację na wybranych portach.
Zasada Działania
W momencie awarii serwera Master usługi Agenta zainstalowane na wszystkich węzłach komunikują się ze sobą celem ustalenia źródła problemu. Jeżeli usługa Agenta na serwerze Master wykryje niedostępność bazy danych Master, ustala z usługami Agenta zainstalowanymi na pozostałych węzłach czy one również nie widzą bazy Master.
W wypadku gdy żadna usługa Agenta nie widzi tej bazy, usługa Agenta zainstalowana na węźle Master uwalnia wirtualny adres IP, tworzy plik recovery.conf, a następnie informuje pozostałe instancje usługi Agenta o awarii bazy master. Usługi Agenta na pozostałych węzłach próbują ponownie nawiązać połączenie z bazą Master, w przypadku sukcesu wysyłana jest notyfikacja o tym fakcie.
W wypadku braku możliwości połączenia usługi Agenta potwierdzają czy wirtualny adres został zwolniony, jeżeli nie to jest wysyłana notyfikacja.
W wypadku zwolnienia wirtualnego adresu IP usługa Agenta na najbardziej aktualnym węźle wykonuje skrypt zdefiniowany jako “script.fence” (jeżeli jest zdefiniowany).
Następnie, w zależności od wyniku działania skryptu promuje bazę Slave do Master i przydziela wirtualny IP nowemu serwerowi Master. W wypadku wyniku skryptu innego niż sukces (“0”) kończy działanie bez promowania bazy i wysyła notyfikacje zawierającą komunikat zwrócony przez skrypt.
Po wykonaniu promocji bazy danych do Master, w przypadku gdy wartość “auto.reconfigure” w konfiguracji ustawiona jest na “true”, reszta węzłów slave zostaje skonfigurowana do pracy z nowym serwerem master. Następnie uruchamiany jest (cały czas na tej samej maszynie) skrypt “script.post.promotion” wynik działania tego skryptu nie ma znaczenia dla dalszego działania klastra, jednak jest dołączony do notyfikacji wysyłanej przez klaster EFM.
EDB Failover Manager obsługuje następujących 6 scenariuszy działania. Dokładny opis działania każdego z nich wraz z diagramem znajduje się w dokumentacji udostępnionej na stronach producenta pod podanymi linkami:
- Niedostępność bazy danych Master
- Niedostępność bazy danych Slave
- Awaria agenta lub noda Master
- Awaria agenta lub noda Slave
- Awaria agenta lub noda Świadka
- Izolacja noda od klastra
Przygotowanie
Warunkiem koniecznym uruchomienia klastra EFM jest posiadanie już działającego klasta Postgres Master-Slave w oparciu o replikacje strumieniową (inne typy replikacji nie są obsługiwane). Uruchomienie / wyłączenie klastra EFM nie ma bezpośredniego przełożenia na działanie replikacji. Replikacja nadal działa, jednak nie jest monitorowana ani nie jest zabezpieczona przed awarią serwera Master.
Drugim warunkiem jest instalacja maszyny wirtualnej Java w wersji 1.8. Aby móc skorzystać z wbudowanego mechanizmu wysyłania powiadomień – drogą mailową – należy skonfigurować mechanizm wysyłki SMTP na każdym z węzłów.
Obsługa Klastra
Do sprawdzania stanu klastra służy komenda:
efm cluster-status efm
Jak widać na powyższym zrzucie ekranu:
Serwer 192.168.121.30 pełni rolę Master, serwery 192.168.121.31, 192.168.121.32 pełnią rolę slave, serwer 192.168.121.33 pełni rolę świadka i nie ma uruchomionej bazy danych biorącej udział w replikacji.
Koordynatorem klastra jest usługa Agenta uruchomiona na serwerze 192.168.121.31.
“Standby priority host list” – wyświetla serwery, które mogą zostać promowane do roli Master w kolejności według priorytetu. Najważniejszym kryterium jest aktualność kopii bazy danych, jednak za pomocą komendy
efm set-priority efm 192.168.121.31 1
można dokonać zmiany priorytetu.
Wartość 1 oznacza najwyższy priorytet, ustawienie priorytetu na 0 powoduje wyłączenie danego serwera z tej kolejki i w efekcie brak możliwości promowania go do roli Master.
efm set-priority efm 192.168.121.31 0
Sprawdzanie stanu klastra można również zautomatyzować – generując wynik w postaci JSON, który jest łatwy do automatycznego przetworzenia.
efm cluster-status-json efm
Przykład wyniku działania komendy w formacie .json
{"nodes":{"192.168.121.30":{"type":"Master","agent":"UP","db":"UP","vip":"192.168.121.39","vip_active":true,"xlog":"0\/28000440","xloginfo":""},"192.168.121.31":{"type":"Standby","agent":"UP","db":"UP","vip":"192.168.121.39","vip_active":false,"xlog":"0\/28000440","xloginfo":""},"192.168.121.32":{"type":"Standby","agent":"UP","db":"UP","vip":"192.168.121.39","vip_active":false,"xlog":"0\/28000440","xloginfo":""},"192.168.121.33":{"type":"Witness","efm allow-node efm 192.168.121.30agent":"UP","db":"N\/A","vip":"192.168.121.39","vip_active":false}},"allowednodes":["192.168.121.33","192.168.121.30","192.168.121.31","192.168.121.32"],"membershipcoordinator":"192.168.121.31","failoverpriority":["192.168.121.32"],"minimumstandbys":0,"missingnodes":[],"messages":[]}Przyłączenie i odłączenie maszyn do klastra realizowane jest za pomocą komend:
efm allow-node efm 192.168.121.30
włącza daną maszynę do klastra EFM, a przez to umożliwia zarządzanie węzłem z poziomu EFM. Komenda
efm disallow-node efm 192.168.121.30
wyłącza daną maszynę z klastra EFM. Uwaga, samo wykonanie komendy na działającym węźle nie wyłącza go z klastra EFM – nadal jest on monitorowany i kontrolowany przez klaster EFM i może być promowany do roli Master. Dopiero restart agenta EFM na tym węźle spowoduje jego usunięcie z klastra EFM. Jeżeli jednak była tam ustawiona replikacja, to ona nadal działa, dopóki jej nie wyłączymy, aczkolwiek nie jest możliwe monitorowanie węzła z poziomu EFM i promowanie go do roli Master.
Po zatrzymaniu bazy i ponownym jej uruchomieniu (np. w celu przeprowadzenia prac konserwacyjnych), aby uzyskać kontrolę, jaką daje EFM oraz możliwość promowania do roli Master należy wykonać komendę
efm resume efm
Komenda musi być wykonana na węźle, którego dotyczy. Bez wykonania tej komendy EFM nadaje bazie status bezczynny (‘IDLE’), monitoruje co prawda noda, ale nie umożliwia jego promocji do roli Master.
Zatrzymanie całego klastra – czyli zatrzymanie usług agentów na wszystkich węzłach, łącznie ze świadkiem, realizuje komenda:
efm stop-cluster efm
Bardzo przydatną opcją jest komenda służąca do automatycznej konwersji konfiguracji starej wersji do nowej wersji przy podnoszeniu wersji oprogramowania klastra. Musi być wykonana na każdym z węzłów klastra.
/usr/edb/efm-3.1/bin/efm upgrade-conf efm -source /etc/edb/efm-3.0/
Na koniec instrukcja ‘promote’ służy do promowania noda do roli mastera.
efm promote efm
Wykonuje promocję pierwszego w kolejce węzła slave do roli mastera i rekonfiguruje pozostałe węzły klastra (o ile inaczej nie mówi konfiguracja danego węzła) do korzystania z nowego mastera. Jeżeli instrukcja zostanie wykonana na klastrze z działającym masterem, zostanie wypromowany nowy master. Węzły slave zostaną skonfigurowane tak aby z niego korzystały, jednak dotychczasowy master nie zostanie wyłączony, aczkolwiek przestanie uczestniczyć w replikacji.
Aby automatycznie wypromować nowego masera, a dotychczasowego przestawić w tryb slave należy użyć przełącznika:
efm promote efm -switchover
Serwer 192.168.121.31 ma ustawiony priorytet 0, więc nie może być promowany do mastera, aczkolwiek podczas promocji jest przełączany na nowego mastera.
W wersji EFM 3.1 zostały dodane nowe przełączniki:
Wykonanie komendy:
efm promote efm -switchover -quiet
powoduje taki sam efekt jak poprzedniej komendy z tą różnicą, że wysyłane są tylko powiadomienia o statusie “INFO”
Natomiast wykonanie komendy
efm promote efm -switchover -sourcenode 192.168.121.31
powoduje wypromowanie do roli master sewera zgodnie z priorytetem, ale plik recovery.conf, który zostanie zapisany na dotychczasowym serwerze master, zostanie pobrany z serwera wyszczególnionego za pomocą przełącznika “-sourcenode”
Konfiguracja
Konfigurację agentów przeprowadza się za pomocą plików konfiguracyjnych dla każdego z agentów osobno. W systemie RedHat / CentOS konfiguracja znajduje się w pliku:
/etc/edb/efm-X.X/efm.properties
gdzie X.X jest numerem wersji EFM
Część parametrów musi być taka sama dla całego klastra. Przykładem jest parametr auto.failover – włączający/wyłączający funkcję automatycznego promowania nowego Mastera po awarii dotychczasowego. Pozostała część jest ustawiana indywidualnie dla każdego węzła. Tutaj przykładem może być parametr auto.reconfigure – odpowiedzialny za możliwość ponownej konfiguracji danego węzła do korzystania z nowego mastera.
Konfiguracja Alertów
Standardowo alerty o zdarzeniach w klastrze wysyłane są na zdefiniowany adres mailowy za pomocą zmiennej
user.email=user@server
w tym celu na węźle klastra musi być zainstalowane i skonfigurowane oprogramowanie SMTP
Aby zmodyfikować alerty, należy napisać skrypt, który może na przykład poddać modyfikacji treść czy temat maila lub przekazać dane do zewnętrznego programu monitorującego. Po napisaniu skryptu jego ścieżkę podajemy poprzez opcję konfiguracyjną:
script.notification=/var/efm/efm_notification.sh
przy wywołaniu skrypt otrzymuje 2 parametry:
$1 – temat maila
$2 – treść maila
treść i temat maila są sformatowane w sposób ułatwiający automatyczną obróbkę:
temat:
[INFO] EFM Standby agent running on 192.168.121.31 for cluster efm
treść:
EFM node: 192.168.121.31
Cluster name: efm
Database name: edb
VIP: 192.168.121.39 (Inactive)
Standby agent is running and database health is being monitored.Konfiguracja Skryptów
Skrypty uruchamiane są z uprawnieniami użytkownika efm
%p – nowy master
%f – failed
[script.fence=/somepath/myscript %p %f]
- script.fence
ścieżka do skryptu uruchamianego zanim zostanie wypromowany nowy master, uruchamiany na węźle, który ma zostać wypromowany, w wypadku zakończenia skryptu wynikiem innym niż sukces (“0”) węzeł nie zostanie wypromowany do roli Mastera. - script.post.promotion
ścieżka do skryptu uruchomionego po wypromowaniu nowego mastera, na nim samym, kod wyjścia skryptu zostanie wysłany w powiadomieniu - script.resumed
uruchamiany zanim zostanie przywrócone monitorowanie działającej bazy danych przez usługę Agenta - script.db.failure
uruchamiany po wykryciu awarii lokalnej bazy danych - script.master.isolated
uruchamiany na serwerze master po wykryciu jego izolacji od reszty klastra - script.remote.pre.promotion
uruchamiany na pozostałych serwerach przed promocją serwera slave - script.remote.post.promotion
uruchamiany na pozostałych serwerach po promocji serwera slave - script.custom.monitor
skrypt uruchamiający dodatkowy, własny monitoring, dodatkowa konfiguracja skryptu:- custom.monitor.interval – inerwał uruchamiania skryptu w sekundach
- custom.monitor.timeout – po tym czasie działania skryptu zostanie on zatrzymany i zostanie wysłane powiadomienie
- custom.monitor.safe.mode – jeżeli ustawione na “true” inny niż “0” wynik skryptu zostanie zaraportowany, ale nie spowoduje promocji lub uznania stanu awarii
Powiązane wpisy:
