Klastry IBM PowerHA są wykorzystywane tam, gdzie liczy się wysoka dostępność aplikacji i baz danych krytycznych dla biznesu. Utrzymanie i konfiguracja klastrów wymaga specjalistycznej wiedzy, dlatego praca z nim może budzić pewne obawy u wielu pracowników IT. Nie każdy musi być ekspertem od klastrów i w przypadku gdy za ich utrzymanie odpowiadają dedykowane osoby, zespoły lub kolejne linie wsparcia, podstawowa wiedza z zakresu obsługi klastra może być wystarczająca dla administratorów aplikacji zabezpieczanej przez klaster PowerHA.
Dokumentacja produktu IBM PowerHA może przytłoczyć ilością informacji, dlatego w niniejszym artykule chciałbym możliwie prosto pokazać najbardziej podstawowe czynności związane z obsługą klastra PowerHA. Tekst jest dedykowany specjalistom, którzy nie potrzebują wiedzy z zakresu instalacji, konfiguracji, troubleshootingu a jedynie wykonać najbardziej praktyczne czynności, czyli:
- Sprawdzenie aktualnego stanu klastra i Resource Group
- Wyłączenie lub włączenie usług klastrowych
- Przełączenie Resource Group między węzłami klastra lub pomiędzy Data Center
Jak sprawdzić czy dany system AIX w ogóle działa w klastrze PowerHA?
Najprościej jest wykonać polecenie przeznaczone do listowania bieżącego stanu klastra, takie jak np. cltopinfo, clRGinfo, cldump (clRGinfo i cldump może nie zadziałać przy zatrzymanym klastrze). System AIX bez klastra PowerHA nie powinien uruchomić poprawnie żadnego z tych poleceń, a jeśli zostanie wyświetlony stan klastra, to mamy już szybkie potwierdzenie. W przypadku gdy serwisy klastrowe są zatrzymane na wszystkich węzłach, polecenia cltopinfo lub cldisp powinny zwrócić informacje o konfiguracji PowerHA. Przy skonfigurowanym klastrze powinniśmy też móc sprawdzić status Cluster Managera poleceniem:
lssrc -ls clstrmgrESJeśli klaster jest wyłączony, lub nieskonfigurowany, możemy sprawdzić czy system AIX ma zainstalowane filesety PowerHA
lslpp -l cluster*Komenda ta nie potwierdzi nam czy klaster został skonfigurowany, a jedynie że AIX ma zainstalowane oprogramowanie PowerHA. W przypadku gdy AIX nie ma konfiguracji klastrowej, ale są zainstalowane filesety klastrowe, warto rozważyć ich usunięcie by nie płacić na nieużywane licencje.
Wersję zainstalowanego klastra można sprawdzić poleceniem:
halevel -sJak sprawdzić na jakim węźle działa aplikacja, ile jest tych węzłów i w jakim są stanie?
clRGinfo
Najbardziej podstawowy widok da nam wcześniej wspomniane polecenie clRGinfo. Mamy tu informację o tym jakie są nazwy węzłów klastra, oraz na których węzłach klastra znajdują się Resource Groupy w którym Site (jeśli są skonfigurowane).
cldump
Polecenie które osobiście wykonuję w pierwszej kolejności, jednak często różne osoby nie do końca wiedzą na co patrzeć i są nieco przytłoczone rozkładem informacji w outpucie. Oczywiście można by się tu przyczepić że przecież wszystko widać i nie ma tu czego tłumaczyć, jednak w stresie, np. tuż po awarii ludzie mogą mieć skłonności raczej do nieuważnego przeglądania informacji, a nie wnikliwego czytania wszystkiego co widzą na ekranie.
Pierwsza sekcja (żółta ramka) mówi o statusie klastra: nazwa klastra, stan (np. UP) i substate (np. STABLE, UNSTABLE)
Sekcja niżej (niebieska ramka) dotyczy węzłów klastra, oraz stanu ich zasobów sieciowych z powiązanymi adresami IP oraz Service IP Label
Sekcja dalej (zielona ramka) opisuje polityki oraz status Resource Group. Tutaj można zobaczyć informację gdzie dana RG się aktualnie znajduje. Na tym przykładzie jest przedstawiona tylko jedna Resource Groupa, ale w przypadku gdy jest ich wiele, output polecenia cldump będzie znacząco dłuższy, powielając podobne informacje. Informacje w zielonej ramce są wyświetlane po kolei, dla każdej Resource Group osobno.
W przypadku klastra typu Standard, status RG jest raczej oczywisty, ale w przypadku gdy klaster ma węzły w różnych DC i jest skonfigurowany jako Stretched lub Linked, wtedy możemy zobaczyć RG w stanie „Online Secondary”, co czasami spotyka się ze małym zaskoczeniem. Różnica między tymi stanami jest następująca:
- Online – Resource Groupa jest aktywna na danym węźle
- Online Secondary – Resource Groupa nie jest aktywna, ale węzeł na którym jest widoczna RG Online Secondary jest wyznaczony jako węzeł zapasowy dla danej RG i na nim zostanie aktywowana RG w przypadku awarii węzła podstawowego
cltopinfo
Sekcje oznaczyłem kolorami analogicznie jak w przypadku cldump. Możemy tu zauważyć dodatkowe informacje, takie jak typ klastra (Standard/Stretched/Linked), Heartbeat Type oraz dysk repository.
Jak przełączyć klaster?
Potocznie często mówi się, że „przełączamy klaster”, jednak mówiąc precyzyjnie przenosimy tak na prawdę Resource Groupę pomiędzy węzłami klastra. Jeden klaster może mieć wiele Resource Group i niekoniecznie musimy przełączać wszystkie na raz.
Przeniesienie Resource Groupy na inny węzeł
Najprościej taką czynność wykonać za pomocą narzędzia SMIT, uruchamiając je z poziomu wiersza poleceń z użyciem skróconej formy, czyli smitty sysmirror lub smitty hacmp
smitty sysmirror --> System Management (C-SPOC) --> Resource Group and Applications --> Move Resource Groups to Another NodeDlaczego pokazuję te ekrany? Dlatego że często zdarza się, że ktoś chce wiedzieć co pojawi się po wybraniu danej pozycji w SMIT, ale nie jest pewien czy zatwierdzając enterem przejdzie do kolejnego ekranu wyboru, czy wykona już właściwą akcję, a nieumyślne przełączenie RG może nas kosztować nieco stresu 🙂
W pierwszym kroku wybieramy właściwą Resource Groupę (czyli w statusie Online, jeżeli chcemy przenieść RG która jest aktywna):
W kolejnym kroku wybieramy docelowy węzeł na którym chcemy uruchomić daną RG.
Jeżeli RG jest w trybie OFFLINE, to jej nie przenosimy (bo nie ma skąd ;)). Po prostu ją uruchamiamy na docelowym węźle.
smitty sysmirror --> System Management (C-SPOC) --> Resource Group and Applications --> Bring a Resource Group OnlinePrzeniesienie Resource Groupy do innego Data Center/Site
Procedura bardzo podobna jak w przypadku przełączenia na inny węzeł. Różnica polega jedynie na tym że zamiast docelowego węzła, wybieramy docelowy Site. Oczywiście opcja jest dostępna jedynie w przypadku, gdy wcześniej zostały zdefiniowane „site policies”.
Zatrzymywanie usług klastrowych
Warto pamiętać że w potocznym języku „Zatrzymanie klastra” nie musi być jednoznaczne z zatrzymaniem systemu operacyjnego. Zawsze warto precyzyjnie określać czy dana sytuacja dotyczy zatrzymania węzłów klastra łącznie z systemami AIX/LPAR-ami, czy zatrzymania serwisów klastrowych, bez zatrzymywania systemu operacyjnego.
W standardowym przypadku (czyli zatrzymania serwisów klastrowych), wystarczy że użyjemy polecenia smitty clstop lub wybierzemy odpowiednią opcję z poziomu menu C-SPOC.
smitty sysmirror --> System Management (C-SPOC) --> PowerHA SystemMirror ServicesNależy zwrócić uwagę na to, jaką akcję podejmiemy z aktualnie działającymi RG na węźle, który zamierzamy wyłączyć. Do wyboru są 3 akcje:
- Bring Resource Groups Offline
- Move Resource Groups
- Unmanage Resource Groups
O ile dwie pierwsze pozycje są raczej oczywiste, tak opcja „Unmanage Resource Groups” może budzić wątpliwości. Należy wiedzieć, że w takim trybie serwisy PowerHA zostaną zatrzymane, ale RG pozostanie aktywna. Jest to bardzo przydatna opcja do wykonania wykonania podniesienia wersji PowerHA lub wgrania FIXa, przy zachowaniu działającej RG (a więc bazy lub aplikacji), ale na pewno nie jest odpowiednia przed restartem AIX, ponieważ w takim przypadku nie zostanie wykonane uruchomienie skryptu zatrzymującego aplikację (Application Server Controller Scripts).
Należy pamiętać że zatrzymanie Resource Groupy spowoduje również uruchomienie skryptu służącego do zatrzymania bazy/aplikacji. Aby sprawdzić lokalizację skryptów można użyć polecenia cllsserv, które wyświetli wszystkie serwery aplikacyjne (czyli upraszczając, przypisane skrypty zatrzymujące/uruchamiające przypisane do Resource Groupy).
cllsservUWAGA: Przed zatrzymaniem Resource Groupy należy pamiętać że jeżeli baza/aplikacja zostanie zatrzymana w sposób ręczny, przed administratora, to skrypt zatrzymujący może próbować zatrzymać procesy które już zostały wcześniej zatrzymane (w teorii każdy taki skrypt powinien być napisany w taki sposób, by rozpoznawał bieżący stan aplikacji, ale w praktyce nie wszystkie skrypty będą napisane idealnie). Może to spowodować bardzo długie działanie skryptu, lub zatrzymanie usług klastrowych z błędem. Jeśli RG już przeszła w status ERROR i udało się już ustalić przyczynę, można przywrócić prawidłowy stan postępując wg. dokumentacji: https://www.ibm.com/docs/en/powerha-aix/7.2.x?topic=tools-recovering-from-powerha-systemmirror-script-failure
Jeżeli baza lub aplikacja z uzasadnionego powodu ma być zatrzymywana w sposób ręczny (a skrypt nie został napisany w taki sposób by to rozpoznawał), to koniecznie przed zamknięciem Resource Groupy należy zakomentować zawartość skryptów zatrzymujących. Najprostszy sposób aby to zrobić, to dopisanie wiersza exit 0, na początku skryptu. Klaster PowerHA oczekuje że skrypty zwrócą status 0 – jeśli tak się nie stanie, klaster czeka a po pewnym czasie podejmuje akcję recovery, dlatego tak ważne jest aby skrypty zakończyły się z poprawnym statusem. W poniższym przykładzie został dopisany wiersz exit 0, dlatego zatrzymanie bazy Oracle, które jest w dalszej części skryptu, nie odbędzie się:
#!/usr/bin/ksh
exit 0
/u01/oracle/stop_oracle.sh Jeżeli jest planowany restart systemu operacyjnego, to powinien się on odbyć dopiero po zatrzymaniu Resource Groupy i serwisów klastrowych. Jeżeli RG jest w statusie RELEASING lub ONLINE, system AIX zdecydowanie nie powinien być jeszcze restartowany.
W przypadku gdy serwisy klastrowe PowerHA są zatrzymywane przed wykonaniem aktualizacji oprogramowania AIX, należy w pierwszej kolejności zapoznać się z poniższą pozycją z dokumentacji IBM: https://www.ibm.com/docs/en/powerha-aix/7.2.x?topic=maintenance-updating-software-cluster
Uwaga! W przypadku gdy aktualizacja ma dotyczyć podniesienia wersji filesetów RSCT, może wystąpić impact na klaster PowerHA i działanie mechanizmu DMS (Dead Man Switch), dlatego należy zablokować cthags lub rozważyć opcję STOP_CAA/START_CAA.
Uruchomienie serwisów klastrowych
W standardowym przypadku wystarczy że użyjemy polecenia smitty clstart lub wybierzemy odpowiednią opcję z poziomu menu C-SPOC.
smitty sysmirror --> System Management (C-SPOC) --> PowerHA SystemMirror ServicesWarto zwrócić uwagę na pozycję Manage Resource Groups, która określa czy wraz z uruchomieniem serwisów klastrowych uruchomimy również Resource Group (Automatically), czy jedynie same serwisy klastrowe, bez RG (Manually).
Podsumowanie
Niniejszy tekst starałem się przygotować by był możliwie prosty i zrozumiały. Jeżeli jesteś zainteresowany tematyką klastrów PowerHA SystemMirror dla systemu AIX zapraszam Cię do zapoznania się z innymi moimi publikacjami: