Strona główna
» Jak
»
Zbuduj obsługiwany klaster SLES 15 HA z Fencing First
Zbuduj obsługiwany klaster SLES 15 HA z Fencing First
W przypadku SLES 15 zarejestruj rozszerzenie SUSE Linux Enterprise High Availability, a następnie użyj crm cluster initi crm cluster joindo uruchomienia węzłów. Przed umieszczeniem usług w klastrze sprawdź redundantną sieć, odgrodzenie węzłów (STONITH) i kworum.
Ta procedura jest zgodna z dokumentacją SLE HA 15 SP7 aktualną na październik 2026 r. Sprawdź zainstalowany dodatek Service Pack i architekturę procesora; identyfikatory rejestracji i szczegóły pomocy technicznej mogą się różnić.
1. Przygotuj węzły i sieć
Przed utworzeniem klastra sprawdź nazewnictwo hostów, rozpoznawanie nazw, synchronizację czasu i stan interfejsu na każdym węźle.
Użyj co najmniej dwóch węzłów na tej samej obsługiwanej architekturze procesora, statycznych głównych adresów IP, unikalnych nazw rozpoznawalnych na każdym węźle oraz zsynchronizowanych zegarów z wykorzystaniem zewnętrznego źródła czasu. SUSE wymaga dwóch redundantnych ścieżek komunikacyjnych TCP/IP na węzeł; nazwy interfejsów muszą być takie same we wszystkich węzłach.
Przed rozpoczęciem bootstrappingu należy przeprowadzić sprawdzanie obu węzłów i potwierdzić, czy wybrane interfejsy i nazwy są poprawne.
2. Zarejestruj i zainstaluj rozszerzenie High Availability
Na każdym węźle zarejestruj rozszerzenie SLE HA i zainstaluj jego wzorzec zarządzania klastrem.
SLE HA to oddzielnie zarejestrowane rozszerzenie; sam SLES nie zawiera wzorca klastra. W przypadku zarejestrowanych węzłów SLES 15 SP7 x86_64 należy włączyć rozszerzenie i zainstalować wzorzec na każdym węźle:
Wpisz ADDITIONAL_REGCODEkod subskrypcji. Identyfikator produktu dotyczy architektury x86_64; w przypadku innych architektur należy użyć identyfikatora zgodnego z systemem SUSE. Wszystkie węzły powinny mieć ten sam poziom SLES SP i SLE HA. Zapoznaj się z podręcznikiem instalacji SUSE SLE HA 15 SP7 .
3. Przed inicjalizacją ustal ogrodzenie i kworum
Ogrodzenie jest wymogiem pomocniczym; klaster dwuwęzłowy powinien być również zaprojektowany z uwzględnieniem kwestii kworum.
Wymagane dla obsługiwanych klastrów: ogrodzenie węzła (STONITH) z parametrem stonith-enabledi startup-fencingpozostawione jako prawdziwe. Ogrodzenie izoluje niepewny węzeł, aby uniemożliwić obu stronom partycji uruchomienie tej samej usługi. Wybierz obsługiwane urządzenie do kontroli zasilania lub SBD z przetestowanym systemem nadzorującym dla swojego sprzętu lub hiperwizora.
Dla dwóch węzłów: SUSE zaleca QDevice/QNetd dla klastrów o parzystej liczbie węzłów. Dodaje ono niezależne głosowanie kworum, a nie odgradzanie; najpierw skonfiguruj oddzielny serwer QNetd, jeśli QDevice jest uwzględniany podczas bootstrapu. Zobacz przewodnik QDevice i QNetd .
Nieporozumienie dotyczące pamięci masowej: współdzielona pamięć masowa nie jest obowiązkowa dla każdego klastra, ale dane aplikacji wymagają własnej, współdzielonej, replikowanej lub odzyskiwalnej struktury. Pacemaker przenosi zasoby; nie kopiuje danych aplikacji.
4. Zainicjuj pierwszy węzeł
Skrypt rozruchowy uruchamia się na węźle node1 i pyta o adres sieciowy, którego Corosync powinien używać.
Na węźle 1 uruchom bootstrap powłoki CRM jako root lub za pomocą zatwierdzonej konfiguracji użytkownika sudo:
crm cluster init --name prod-ha
Postępuj zgodnie z instrukcjami i wybierz żądany adres Corosync. Skrypt konfiguruje Corosync, SSH, Csync2, porty zapory klastra i Hawk2; sprawdza synchronizację czasu i oferuje opcjonalne SBD oraz adres IP administratora Hawk2. Sprawdź /var/log/crmsh/crmsh.logustawienia bootstrapu.
Skonfiguruj mechanizm nadzorujący na każdym węźle przed wybraniem SBD. Jeśli korzystasz z zewnętrznego ogrodzenia, skonfiguruj obsługiwany zasób STONITH przed obciążeniami. Nigdy nie wyłączaj STONITH, aby ominąć brakujące urządzenie. Bootstrap tworzy podstawowy klaster, a nie aplikację HA.
5. Dołącz do drugiego węzła
Uruchom polecenie join na węźle node2, używając tych samych opcji interfejsu sieciowego, które zostały wybrane podczas inicjalizacji.
Zainstaluj i zarejestruj SLE HA na węźle 2. Jeśli używasz SBD, przygotuj tam jego watchdoga przed dołączeniem. Następnie, jako root:
crm cluster join -c root@node1
W przypadku konfiguracji sudo-user należy skorzystać z procedury SUSE USER@NODE1. Należy określić te same dwa interfejsy, jeśli zostały skonfigurowane podczas inicjalizacji. Skrypt kopiuje ustawienia Corosync, konfiguruje SSH i Csync2 oraz uruchamia węzeł node2. Powtórz tę czynność dla kolejnych węzłów; nie należy mieszać metod konfiguracji Bootstrap i YaST.
6. Potwierdź członkostwo i zabezpiecz administrację
Przed użyciem Hawk2 sprawdź status członkostwa w systemie CRM i zmień hasło Bootstrap Hacluster.
Sprawdź członkostwo w węźle klastra:
crm status
Sprawdź, czy oba węzły są online i czy kworum jest obecne. Bootstrap tworzy się haclusterz hasłem początkowym linux; zmień je na każdym zainicjowanym węźle:
passwd hacluster
Hawk2 używa protokołu HTTPS na porcie 7630. Przed zaufaniem należy zweryfikować certyfikat podpisany przez siebie u administratora. Adres IP zarządzania Hawk2 nie jest adresem klienta aplikacji.
7. Dodaj zasoby dla usługi, którą faktycznie musisz chronić
W przykładzie zdefiniowano jedynie zasób zmiennego IP; należy zastąpić jego adres dokumentacyjny nieużywanym adresem ze swojej podsieci.
Pacemaker zarządza usługami za pośrednictwem agentów zasobów. Zainstaluj i skonfiguruj obciążenie odpowiednio na kwalifikujących się węzłach. W tym przykładzie tworzony jest tylko zmienny prymityw IP:
192.0.2.50jest zarezerwowany dla dokumentacji. Zastąp go wolnym adresem i poprawnym prefiksem z podsieci. Prymityw IP nie uruchamia aplikacji ani nie replikuje danych. Dodaj obsługiwanego agenta aplikacji oraz specyficzne dla obciążenia funkcje porządkowania, kolokacji i przechowywania; postępuj zgodnie ze wskazówkami dotyczącymi odzyskiwania i odgradzania dla danego produktu.
8. Przetestuj tryb failover przed wywołaniem gotowości klastra
Zaplanowany test gotowości sprawdza, czy zasób jest ruchomy, a następnie przywraca działanie węzła.
Po skonfigurowaniu zasobów rzeczywistych i ogrodzenia zaplanuj kontrolowany test przełączania awaryjnego. Przestaw węzeł 1 w tryb gotowości i sprawdź usługę z węzła 2:
Zastąp SERVICE_VIPprawdziwym adresem klienta. Sprawdź, czy aplikacja odpowiada, zasoby są przenoszone zgodnie z oczekiwaniami, a węzeł 1 ponownie dołącza. Polecenie ping sprawdza tylko dostępność sieci. System SUSE crm cluster crash_testcelowo przerywa działanie komponentów, dlatego należy go używać w zaplanowanym środowisku testowym. Przeczytaj przewodnik szybkiego startu i ochrony instalacji SLE HA .
Sprawdź dostępność usługi
Po przetestowaniu należy sprawdzić, czy oba węzły mają oczekiwany status, ogrodzenie pozostaje włączone, a obciążenie odpowiada za pośrednictwem punktu końcowego klienta po powrocie węzła 1 do trybu online. Sam zielony widok członkostwa lub pomyślne wykonanie polecenia ping nie dowodzi odzyskania aplikacji.