Cum se configurează clusterizarea de înaltă disponibilitate (HAE) pe SUSE Linux 15

Această ghid pentru începători construiește un cluster de bază cu două noduri, activ/pasiv, cu SUSE Linux Enterprise High Availability (SLE HA) 15. Folosește scripturile de bootstrap CRM Shell acceptate: inițializează primul nod cu crm cluster init, adaugă al doilea cu crm cluster join, verifică apartenența și testează o reluare planificată a adresei IP virtuale de administrare. Exemplele respectă documentația SUSE SLE HA 15 SP7, publicată pe 24 septembrie 2026; solicitările pot varia în funcție de service pack, hardware și platformă.

„HAE” este adesea folosit informal pentru extensia High Availability. Documentația actuală a produsului SUSE o numește SUSE Linux Enterprise High Availability sau SLE HA. Această procedură oferă o bază funcțională de cluster și acces de administrare Hawk2. Nu face automat o aplicație, o bază de date sau datele acesteia extrem de disponibile; acestea necesită propriile resurse Pacemaker, design de stocare și testare specifică sarcinii de lucru.

Ilustrațiile de mai jos ale terminalului și ecranului Hawk2 prezintă vizualizări reprezentative ale interfeței, nu capturi de ecran dintr-un sistem live. Numele și adresele sunt exemple. Înlocuiți-le cu valori din rețeaua dvs.

Ce va face acest cluster?

Un cluster este un grup de servere, numite noduri , care se coordonează pentru a menține serviciile selectate în funcțiune. Corosync gestionează apartenența nodurilor și mesageria clusterului. Pacemaker, managerul de resurse al clusterului, decide unde ar trebui să ruleze resursele gestionate și răspunde la erori. O resursă este un serviciu sau o adresă pe care Pacemaker o poate porni, opri, monitoriza și muta.

În această demonstrație, nodul aliceși nodul bobformează un cluster cu două noduri. O adresă IP de administrare flotantă oferă administratorilor o adresă stabilă pentru Hawk2, interfața web a SUSE. Dacă un nod este plasat în standby, Pacemaker poate muta acea adresă IP la celălalt nod. Pentru un cluster cu două noduri de producție, SUSE recomandă adăugarea QDevice/QNetd pentru deciziile de cvorum și necesită izolarea nodurilor.

Ce ar trebui să pregătești înainte de instalare?

• Două sisteme SUSE Linux Enterprise Server 15 acceptate care rulează același service pack și aceeași arhitectură de procesor, cu utilizatorul root sau un cont sudo cu privilegii corespunzătoare.
• Înregistrare SUSE validă și drept de acces SLE HA pe fiecare nod. Extensia și modelul de pachet trebuie să corespundă cu pachetul de service și arhitectura SLES.
• Adrese statice de noduri, rezoluție funcțională a numelor, ceasuri sincronizate și conectivitate fiabilă la rețeaua de cluster. Alegeți interfața Corosync dorită în mod deliberat; căi separate sau redundante sunt utile în proiectele de producție.
• Un plan de închidere. Închiderea (STONITH, „Împușcă celălalt nod în cap”) izolează sau repornește forțat un nod care ar putea fi nesănătos, împiedicând ambele părți ale unei rețele divizate să scrie în date partajate. Un cluster acceptat trebuie să aibă închiderea activată.
• Dacă se utilizează SBD (STONITH Block Device), este necesar un watchdog adecvat pe fiecare nod și un spațiu de stocare partajat în blocuri proiectat corespunzător, cu o cale stabilă pentru dispozitiv. Un watchdog hardware este preferat pentru producție. Dacă se utilizează în schimb o barieră de alimentare fizică, configurați și testați un dispozitiv STONITH compatibil.
• Pentru două noduri, planificați un martor QDevice/QNetd înainte de inițializare dacă intenționați să îl configurați prin fluxul bootstrap. Un martor ajută clusterul să decidă care parte are cvorum atunci când se pierde conectivitatea.

Nu tratați o configurație de laborator ca fiind pregătită pentru producție. Cerințele de sistem SUSE SLE HA 15 SP7 impun izolarea prin fencing, iar prezentarea generală a instalării recomandă testarea configurației cu două sau trei noduri înainte de extinderea acesteia.

Pasul 1: Instalați extensia și pachetele SLE HA

Dacă nu a fost selectată extensia SLE HA în timpul instalării SLES, activați extensia pe fiecare nod. Pentru o gazdă SLES 15 SP7 x86_64 înregistrată, modelul documentat este:

SUSEConnect -p sle-ha/15.7/x86_64 -r ADDITIONAL_REGCODE
zypper install -t pattern ha_sles

Înlocuiți ADDITIONAL_REGCODEcu codul de înregistrare SLE HA. Folosiți identificatorul de produs de activare care corespunde propriului pachet service pack și arhitecturii; nu copiați exemplul SP7 într-un alt pachet service pack SLES 15. Rulați comanda package-pattern pe ambele noduri. SUSE documentează modelul ha_slesca set de pachete utilizate pentru configurarea și gestionarea clusterului.

Pasul 2: Pregătiți numele, ora și accesul la rețea

Dați ambelor noduri nume de gazdă stabile și adrese IP principale statice. Confirmați că fiecare nod îl poate rezolva pe celălalt atât prin nume scurt, cât și prin nume complet calificat. Ghidul de configurare SUSE recomandă listarea membrilor clusterului atunci /etc/hostscând este necesar, deoarece erorile de rezoluție a numelui pot întrerupe comunicarea internă. De exemplu, adaptați intrări precum acestea la DNS-ul și planul de adrese:

10.20.0.11 alice.example.net alice
10.20.0.12 bob.example.net bob

Sincronizați ambele ceasuri cu o sursă NTP din afara clusterului și mențineți consecvența fusurilor orare. Chrony este implementarea NTP implicită pe SLES 15. Verificați conectivitatea în rețeaua pe care intenționați să o utilizați pentru Corosync. Scripturile Bootstrap pot deschide porturile firewall necesare pentru comunicarea în cluster, dar confirmați că firewall-urile gazdă și de rețea permit traficul necesar topologiei selectate. Unicast este implicit în fluxul bootstrap; portul Corosync implicit documentat este 5405.

Pasul 3: Inițializarea primului nod

Pe alice, rulați comanda bootstrap ca root:

crm cluster init --name demo-ha

Examinați solicitările înainte de a le accepta. Selectați interfața și adresa de rețea destinate pentru Corosync, apoi confirmați portul. Scriptul verifică sincronizarea timpului și disponibilitatea watchdog-ului și poate pregăti cheile SSH și configurația clusterului aferentă. Acesta întreabă dacă va configura SBD, un IP virtual de administrare Hawk2 și QDevice/QNetd. SBD necesită ca watchdog-ul și dispozitivul partajat să fie deja gata. Dacă configurați QDevice în acest bootstrap, pregătiți mai întâi serverul QNetd. Scriptul creează un cluster cu un singur nod care rulează; nu adaugă bobîn această etapă.

Nu alegeți o cale aleatorie partajată pe disc sau dispozitiv pentru SBD. Calea trebuie să identifice aceeași unitate de stocare corespunzătoare pe fiecare nod, iar comportamentul său în caz de eroare și timeout-urile trebuie să corespundă designului unității de stocare. SUSE notează că softdognu se poate reporni o mașină dacă toate procesoarele sunt blocate, așadar utilizați sistemul de supraveghere hardware corect pentru producție ori de câte ori este disponibil.

Pasul 4: Alăturați-vă celui de-al doilea nod

După inițializarea primului nod, conectați-vă bobși executați:

crm cluster join

Urmați instrucțiunile pentru a identifica nodul existent din cluster alice. Dacă ați utilizat un cont sudo în loc de root pentru primul nod, SUSE documentează specificarea acelui cont cu -c, de exemplu:

sudo crm cluster join -c USER@alice

Scriptul de alăturare copiază configurația Corosync, configurează SSH și Csync2, aduce mașina curentă online ca nod de cluster și pornește serviciul necesar pentru Hawk2. Nu inițializați ambele mașini independent; al doilea nod trebuie să se alăture clusterului creat de primul.

Pasul 5: Confirmați că ambele noduri sunt online

Din oricare nod, verificați rezumatul clusterului:

crm status

Căutați ambele nume de noduri sub Onlineși o partiție de cluster cu cvorum. Verificați dacă există acțiuni eșuate sau un nod offline înainte de a continua. De asemenea, vă puteți conecta la Hawk2 utilizând adresa VIP de administrare selectată în timpul inițializării, de obicei la https://ADMIN-VIP:7630/. Un avertisment privind certificatul la prima vizită poate apărea atunci când este utilizat un certificat autosemnat; verificați detaliile certificatului cu administratorul clusterului în loc să ignorați un certificat necunoscut într-un mediu de producție.

Pasul 6: Securizarea contului de administrare

Procedura bootstrap creează un haclustercont pentru Hawk2. Ghidul de configurare SUSE documentează o parolă implicită în timpul configurării de bază, așa că schimbați-o imediat înainte de a lăsa sistemul accesibil:

passwd hacluster

Folosește o parolă puternică și unică și respectă politica de acreditare a organizației tale. Restricționează accesul la rețeaua de administrare Hawk2, instalează certificate de încredere, după caz, și nu expune interfața de administrare direct la internetul public.

Pasul 7: Testați în siguranță o reluare planificată

Un test de standby planificat verifică dacă adresa IP virtuală de administrare se poate muta atunci când un nod este eliminat intenționat din plasarea resurselor. Înainte de testare, confirmați că ambele noduri sunt sănătoase, că clusterul are cvorum și că aveți acces la consolă sau în afara benzii în cazul în care ceva se comportă neașteptat. De la un client din aceeași rețea, trimiteți ping continuu adresei VIP de administrare, de exemplu:

ping 10.20.0.20

În Hawk2, deschideți nodul care găzduiește în prezent adresa IP de administrare și selectați Standby . Apoi, bifați Status > Resources . Ghidul de pornire rapidă SUSE descrie cum resursa plutitoare se mută la celălalt nod în timp ce ping-ul continuă. Când testul este finalizat, repuneți nodul în funcțiune folosind acțiunea corespunzătoare a Hawk2, confirmați că ambele noduri sunt online și verificați dacă resursa se află în locația așteptată.

Ce dovedește acest test — și ce nu dovedește?

Dacă ambele noduri rămân vizibile și adresa IP de administrare se mută la peer, aveți dovezi că apartenența de bază la cluster și resursa IP flotantă funcționează în acest scenariu planificat. Un ping în sine nu dovedește că o aplicație este disponibilă, că sesiunile client supraviețuiesc, că datele partajate sunt protejate sau că clusterul se poate recupera după fiecare defecțiune a rețelei, stocării, alimentării sau software-ului.

Pentru o aplicație, adăugați agentul de resurse corect și configurați ordonarea, colocarea, monitorizarea, accesul la stocare și izolarea datelor în funcție de designul aplicației. Nu permiteți niciodată ca două noduri să scrie simultan în spațiul de stocare partajat obișnuit. Testați recuperarea și integritatea datelor sarcinii de lucru într-un mediu de testare, inclusiv erori reale ale nodurilor și rețelei, înainte de producție.

Greșeli frecvente de evitat

• Omiterea fencing-ului: un cluster fără STONITH funcțional nu poate rezolva în siguranță split-brain și nu îndeplinește cerințele de asistență SUSE.
• Presupunând că două noduri pot decide singure: planificați QDevice/QNetd pentru un cluster cu număr par, în special un cluster cu două noduri.
• Utilizarea unei identități de nod instabile sau nepotrivite: utilizați adrese statice, nume de gazdă consistente, rezoluție de nume înainte și înapoi și timp sincronizat.
• Reutilizarea rețelei greșite: selectați interfața Corosync dorită și verificați politica firewall pe fiecare cale de rețea.
• Presupunând că clusterul protejează automat o aplicație: un cluster poate gestiona doar resurse care au fost configurate și testate.
• Numirea inițială a bootstrap-ului „gata de producție”: pornirea rapidă este o configurare de bază. Pregătirea pentru producție necesită teste de recuperare specifice sarcinii de lucru, validare a fencing-urilor, monitorizare, proceduri de backup și restaurare și operațiuni documentate.

Referințe oficiale SUSE

• Instalare și configurare rapidă SLE HA 15 SP7
• Cerințe de sistem și recomandări pentru SLE HA 15 SP7
• Prezentare generală a instalării SLE HA 15 SP7
• Protecție stocare SLE HA 15 SP7 și SBD