Pentru SLES 15, înregistrați extensia SUSE Linux Enterprise High Availability, apoi utilizați crm cluster initși crm cluster joinpentru a boota nodurile. Înainte de a plasa serviciile în cluster, verificați rețeaua redundantă, fencing-ul nodurilor (STONITH) și cvorumul.
Această procedură respectă documentația SLE HA 15 SP7 actualizată în octombrie 2026. Confirmați pachetul service pack instalat și arhitectura procesorului; identificatorii de înregistrare și detaliile de asistență pot varia.
Folosiți cel puțin două noduri pe aceeași arhitectură de procesor acceptată, adrese IP primare statice, nume unice rezolvabile pe fiecare nod și ceasuri sincronizate folosind o sursă de timp externă. SUSE necesită două căi de comunicație TCP/IP redundante per nod; numele interfețelor trebuie să se potrivească între noduri.
hostname -f
getent hosts node1 node2
chronyc tracking
ip -br addrRulați verificările pe ambele noduri și confirmați că interfețele și numele selectate sunt corecte înainte de bootare.
SLE HA este o extensie înregistrată separat; SLES singur nu include modelul de cluster. Pentru nodurile SLES 15 SP7 x86_64 înregistrate, activați extensia și instalați modelul pe fiecare nod:
SUSEConnect -p sle-ha/15.7/x86_64 -r ADDITIONAL_REGCODE
zypper install -t pattern ha_slesÎnlocuiți ADDITIONAL_REGCODEcu codul dvs. de abonament. Identificatorul de produs este pentru x86_64; utilizați identificatorul corespunzător SUSE pentru alte arhitecturi. Păstrați toate nodurile la același nivel SLES SP și SLE HA. Consultați ghidul de instalare SLE HA 15 SP7 de la SUSE .
Obligatoriu pentru clusterele acceptate: fencing-ul de noduri (STONITH), cu stonith-enabledși startup-fencinglăsat la valoarea true. Fencing-ul izolează un nod incert pentru a împiedica ambele părți ale unei partiții să ruleze același serviciu. Alegeți un dispozitiv de control al alimentării acceptat sau un SBD cu un watchdog testat pentru hardware-ul sau hypervisor-ul dvs.
Pentru două noduri: SUSE recomandă QDevice/QNetd pentru clustere de noduri pare. Adaugă un vot independent pentru cvorum, nu o fencing; configurați mai întâi serverul QNetd separat dacă includeți QDevice în timpul bootstrap-ului. Consultați ghidul QDevice și QNetd .
Concepție greșită despre stocare: stocarea partajată nu este obligatorie pentru fiecare cluster, dar datele aplicației au nevoie de propriul design partajat, replicat sau recuperabil. Pacemaker mută resurse; nu copiază datele aplicației.
Pe nodul 1, porniți bootstrapul CRM Shell ca root sau prin configurarea sudo-user aprobată:
crm cluster init --name prod-haUrmați instrucțiunile și selectați adresa Corosync dorită. Scriptul configurează Corosync, SSH, Csync2, porturile firewall ale clusterului și Hawk2; verifică sincronizarea temporală și oferă SBD opțional și o adresă IP de administrare Hawk2. Verificați /var/log/crmsh/crmsh.logsetările de bootstrap.
Configurați sistemul de supraveghere pe fiecare nod înainte de a selecta SBD. Dacă utilizați o fencing externă, configurați resursa STONITH acceptată înainte de sarcinile de lucru. Nu dezactivați niciodată STONITH pentru a ocoli un dispozitiv lipsă. Bootstrap creează un cluster de bază, nu o aplicație HA.
Instalați și înregistrați SLE HA pe nodul 2. Dacă utilizați SBD, pregătiți sistemul de supraveghere acolo înainte de a vă conecta. Apoi, ca root:
crm cluster join -c root@node1Pentru o configurare cu ajutorul utilizatorului sudo, utilizați procedura SUSE USER@NODE1. Specificați aceleași două interfețe dacă au fost configurate la inițializare. Scriptul copiază setările Corosync, configurează SSH și Csync2 și aduce nodul 2 online. Repetați pentru mai multe noduri; nu combinați metodele de configurare bootstrap și YaST.
Dintr-un nod de cluster, verificați apartenența:
crm statusVerificați dacă ambele noduri sunt online și dacă există cvorum. Bootstrapul creează haclusterparola inițială linux; schimbați-o pe fiecare nod inițializat:
passwd haclusterHawk2 folosește HTTPS pe port 7630. Verificați un certificat autosemnat cu administratorul înainte de a-l considera de încredere. O adresă IP de administrare Hawk2 nu este adresa client a aplicației.
Pacemaker gestionează serviciile prin intermediul agenților de resurse. Instalați și configurați sarcina de lucru în mod corespunzător pe nodurile eligibile. Acest exemplu creează doar o primitivă IP flotantă:
crm configure primitive service-vip IPaddr2 params ip=192.0.2.50 cidr_netmask=24 op monitor interval=10s timeout=20s192.0.2.50este rezervat pentru documentație. Înlocuiți o adresă liberă și un prefix corect din subrețeaua dvs. O primitivă IP nu pornește o aplicație și nu replică date. Adăugați agentul acceptat de aplicație plus comportamentul specific sarcinii de lucru privind ordinea, colocația și stocarea; urmați instrucțiunile de recuperare și izolare ale produsului respectiv.
După configurarea resurselor reale și a fencing-ului, programați un test controlat de failover. Puneți nodul 1 în standby și verificați serviciul de la nodul 2:
crm node standby node1
crm status
ping -c 4 SERVICE_VIP
crm node online node1Înlocuiți SERVICE_VIPcu adresa reală a clientului. Confirmați că aplicația răspunde, resursele se mișcă conform așteptărilor și nodul 1 se reunește. Ping verifică doar accesibilitatea rețelei. SUSE crm cluster crash_testperturbă intenționat componentele, așa că utilizați-l într-un mediu de testare planificat. Citiți ghidul de pornire rapidă și de fencing pentru instalarea SLE HA .
După testare, confirmați că ambele noduri au starea așteptată, că fencing-ul rămâne activat și că sarcina de lucru răspunde prin endpoint-ul clientului după ce nodul 1 revine online. O vizualizare verde a membrilor sau un ping reușit nu dovedesc singure recuperarea aplicației.
Urmăriți un modul kernel defect la pornirea SLES, corectați o intrare de boot învechită sau reparați driverul necesar și verificați următoarea bootare.
Pregătiți căile SAN SCSI, activați multipathd, inspectați setările implicite hardware ale SUSE și verificați hărțile stabile ale dispozitivelor fără a ghici setările matricei.
Găsește procesul care deține blocarea pachetului Zypper, distinge conflictele de proces de blocările pachetului și reîncearcă actualizările fără a șterge orbește fișierele de blocare.
Înregistrați SLE HA, bootați SLES 15 noduri, apoi adăugați fencing, cvorum și resurse de servicii testate înainte de a vă baza pe failover.
Urmăriți o eroare de reîmprospătare Zypper către SUSE, RMT sau un endpoint terț, apoi aplicați remedierea corectă la nivelul serverului sau al memoriei cache fără a dezactiva actualizările esențiale.
Rezolvați erorile de spațiu din pool-ul subțire SUSE LVM prin verificarea utilizării datelor și metadatelor, extinderea pool-ului în siguranță și prevenirea întreruperilor repetate.
Identificați dacă Btrfs este intenționat doar pentru citire, are puțin spațiu sau protejează datele după erori, apoi alegeți o cale de recuperare care corespunde cauzei.
Pregătiți canalele oglindite, creați o cheie de activare și porniți un client SLES 15 fără acces direct la internet, păstrând în același timp conexiunea necesară pentru înregistrările Manager.
Corectează eroarea de lansare XIO a YaST prin SSH, verifică redirecționarea X11 și xauth și comută la interfața ncurses atunci când o fereastră la distanță nu este necesară.
Găsește snapshot-ul Btrfs de dinainte de actualizare, testează-l în modul doar pentru citire și fă recuperarea permanentă cu Snapper, înțelegând în același timp ce date rămân în afara rollback-ului rădăcină.
