Cum se migrează SLES 15 SP5 la SP6 fără întreruperi ale sistemului

Puteți păstra o aplicație disponibilă în timp ce mutați un cluster SLES 15 SP5 la SP6, dar nu puteți actualiza și reporni o singură instanță a sistemului de operare fără întreruperi. SUSE acceptă migrarea pachetului service pack de la SP5 la SP6, iar procesul de migrare online necesită în continuare o repornire a sistemului. Pentru a evita întreruperea serviciului, actualizați câte un nod pe rând într-un cluster SUSE Linux Enterprise High Availability (SLE HA) acceptat sau construiți un mediu SP6 de înlocuire și mutați traficul către acesta. Serviciul trebuie să aibă un loc sănătos pentru a rula în timp ce fiecare gazdă nu este disponibilă.

Acest ghid pentru începători se concentrează pe calea de actualizare continuă pentru un cluster SLE HA. De asemenea, explică ce trebuie să faceți dacă aveți un singur server, ce trebuie verificat înainte de modificare și cum să aflați dacă serviciul a rămas sănătos. Comenzile și ordinea exactă pentru mutarea sarcinilor de lucru depind de resursele, spațiul de stocare și aplicația clusterului.

Ce înseamnă „fără întreruperi ale sistemului”

O migrare a pachetelor service pack înlocuiește pachetele de sistem în timp ce sistemul sursă rulează. SUSE numește aceasta migrare online. Reduce necesitatea de a porni de pe mediul de instalare, dar procedura oficială prevede repornirea sistemului după o migrare reușită. Migrarea online nu este același lucru cu o actualizare live care lasă aceeași gazdă să deservească continuu cererile.

Pentru un serviciu în cluster, o actualizare continuă înseamnă scoaterea din serviciu a unui nod, migrarea și repornirea acestuia, readucerea acestuia în cluster și apoi repetarea pe următorul nod. Aplicația poate rămâne disponibilă de pe un alt nod dacă failover-ul funcționează și capacitatea rămasă este suficientă. Un failover poate provoca în continuare o scurtă întrerupere a sesiunilor active, așadar măsurați serviciul orientat către utilizator, în loc să presupuneți că „disponibilitatea ridicată” garantează că fiecare conexiune rămâne neatinsă.

SUSE listează SLES 15 SP5 ca sursă acceptată pentru SP6, atât online, cât și offline. Calea acceptată este documentată în ghidul căii de actualizare SLES 15 SP6 . Documentația SUSE HA acceptă o actualizare continuă a clusterului între pachete service din aceeași versiune majoră. Consultați ghidul de actualizare a clusterului SLE HA .

Alege abordarea corectă înainte de a schimba ceva

• Un server independent: programați o fereastră de mentenanță pentru migrarea gazdei și repornirea sistemului. Un echilibrator de încărcare nu poate elimina timpul de nefuncționare dacă nu există o a doua instanță sănătoasă a aplicației.
• Două sau mai multe noduri SLE HA: luați în considerare procedura documentată de actualizare continuă, după verificarea cvorumului, a barierelor, a plasării resurselor, a accesului la spațiul de stocare și a capacității de rezervă.
• Aplicație cu replici în afara SLE HA: actualizați o gazdă sau un pool SP6 de înlocuire, validați-l și transferați traficul treptat. Aceasta este o implementare progresivă sau continuă la nivelul aplicației; este separată de o migrare SLES in situ.
• Gazdă gestionată de SUSE Manager: urmați fluxul de lucru pentru migrarea clientului din SUSE Manager. SUSE recomandă să nu utilizați migrarea online YaST sau zypper migrationdirect pe un client SUSE Manager.

Dacă serviciul dumneavoastră este o bază de date sau o altă aplicație cu stare, tratați compatibilitatea aplicațiilor și replicarea datelor ca un flux de lucru separat. O cale de migrare a sistemului de operare nu actualizează automat baza de date și nu dovedește că designul său de replicare și failover este sigur.

Pregătiți clusterul și planul de schimbare

1. Confirmați versiunile, înregistrarea și eligibilitatea pentru upgrade

Verificați dacă fiecare nod este pe SLES 15 SP5, cu extensia SLE HA și alte module sau produse înregistrate conform așteptărilor. Lista de ținte de migrare depinde de produsele și extensiile instalate. O țintă SP6 lipsă poate indica o problemă de înregistrare, depozit sau disponibilitate a extensiei; nu încercați să forțați o cale diferită către depozit doar pentru a face ținta să apară.

Pentru un sistem înregistrat, următoarele verificări doar în citire pot ajuta la stabilirea stării sale:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper lr -u

Comparați produsele, depozitele și arhitectura SLES și SLE HA instalate pe toate nodurile. Dacă gazda este gestionată de SUSE Manager, utilizați procedura de migrare a clientului corespunzătoare în loc de pașii direcți de mai jos.

2. Aplicați patch-uri, faceți o copie de rezervă și testați

SUSE necesită ca sistemul sursă să fie la cel mai recent nivel de patch înainte de actualizare. Aplicați actualizările de întreținere SP5 și consultați notele de lansare SP6 pentru modificările aduse pachetelor, modulelor și aplicațiilor. Instrucțiunile de pregătire pentru actualizare de la SUSE necesită, de asemenea, o copie de rezervă actualizată și o consultare a notelor de lansare.

Faceți o copie de rezervă a configurației sistemului și a datelor aplicației și verificați dacă copia de rezervă poate fi restaurată. Testați întreaga procedură pe un cluster de testare care corespunde producției, inclusiv interfețele de rețea, stocarea, resursele clusterului, depozitele terțe și verificările de sănătate ale aplicațiilor. Înregistrați cât durează migrarea și repornirea pentru fiecare nod, astfel încât să puteți estima fereastra de modificare.

3. Demonstrați că nodurile rămase pot prelua sarcina de lucru

Înainte de a elimina un nod, confirmați că clusterul este sănătos și nu are erori de resurse nerezolvate. Verificați dacă un alt nod poate rula serviciile, poate monta sau accesa spațiul de stocare necesar și poate gestiona traficul așteptat. Dacă pierderea unui nod ar supraîncărca CPU-ul, memoria, rețeaua sau spațiul de stocare, adăugați capacitate, reduceți sarcina sau programați o fereastră de întreținere în loc să nu solicitați nicio perioadă de nefuncționare.

Asigurați-vă că fencing-ul clusterului este configurat și funcționează conform designului HA stabilit. Fencing-ul protejează resursele partajate prin izolarea unui nod care nu este de încredere; dezactivarea acestuia pentru a face ca o actualizare să pară mai ușoară poate crea un risc de split-brain. Mențineți accesul la consolă sau în afara benzii disponibil în cazul în care un nod nu revine după repornire.

Executați o actualizare continuă, câte un nod pe rând

Folosește pașii de mai jos ca schiță de planificare. Urmează procedura pentru versiunea exactă SLE HA și configurarea resurselor; nu copiază orbește o secvență de gestionare a resurselor în producție.

1. Confirmați starea clusterului. Capturați starea curentă și confirmați că toate nodurile și resursele sunt sănătoase. În SLE HA, crm statusexistă o modalitate documentată de a inspecta starea clusterului.
2. Mutați sau goliți serviciile din nod. Utilizați procedura aprobată de cluster pentru a plasa resursele aplicației sale pe un alt nod sănătos. Verificați endpoint-ul aplicației și spațiul de stocare dependent înainte de a continua.
3. Opriți stiva clusterului pe nodul care este actualizat. Instrucțiunile SUSE pentru actualizarea continuă avertizează că lăsarea managerului de resurse al clusterului activ în timpul unei actualizări de software poate duce la probleme precum blocarea nodurilor active. Comanda documentată la nivel de nod este crm cluster stop.
4. Executați migrarea pachetului service pack SLES. Pe o gazdă înregistrată, care nu este gestionată de SUSE-Manager, utilizați [comment] sudo zypper migration. Examinați modificările oferite pentru ținta SP6 și depozit. Citiți acțiunile propuse pentru pachet, în special pachetele de eliminat sau de retrogradat, înainte de a confirma. Instrucțiunile oficiale de migrare online SLES descriu această cale din linia de comandă.
5. Reporniți și verificați nodul. După finalizarea migrării, reporniți gazda conform instrucțiunilor SUSE. Confirmați că pornește SLES 15 SP6, că produsele necesare sunt înregistrate, că depozitele corespund pachetului service pack țintă și că nodul nu are erori critice de sistem.
6. Returnați nodul în cluster. Porniți stiva clusterului utilizând procedura aprobată; ghidul SLE HA arată crm cluster start. Verificați crm statusHawk2 și verificați dacă nodul se reconecta fără erori de resurse.
7. Repetați numai după ce clusterul este stabil. Mutați sarcina de lucru a următorului nod, scoateți acel nod din cluster, migrați, reporniți, validați și reconectați-l. Nu porniți următorul nod în timp ce clusterul rămas este degradat sau transportă mai multă muncă decât poate gestiona în siguranță.

SUSE afirmă că nodurile clusterului cu versiuni mixte sunt acceptate doar temporar în timpul actualizării continue și că actualizarea ar trebui finalizată în decurs de o săptămână. Planificați o secvență scurtă și controlată, în loc să lăsați un cluster cu versiuni mixte la locul său pe termen nelimitat. Finalizați prin a confirma că toate nodurile rulează SP6, verificând starea de funcționare a clusterului și a aplicațiilor și revizuind jurnalele și înregistrarea depozitului.

Probleme frecvente și ce trebuie făcut

• Nu apare nicio țintă de migrare SP6: verificați înregistrarea, depozitele active și dacă fiecare modul sau extensie instalată are o țintă SP6 acceptată. Rezolvați problemele legate de depozit sau drepturi înainte de a începe.
• Rezolvitorul propune eliminări neașteptate: opriți și investigați originile pachetelor, depozitele terțe și dependențele. SUSE notează că depozitele locale sau DVD învechite ar trebui dezactivate pentru migrare. Nu acceptați un plan de pachet pe care nu îl puteți explica.
• Nodul actualizat nu se va reconecta: păstrați aplicația pe noduri sănătoase, inspectați jurnalele clusterului și ale sistemului și verificați rețeaua nodului, înregistrarea produsului, configurația depozitului și pachetele SLE HA înainte de a reîncerca.
• Serviciul este accesibil, dar utilizatorii raportează erori: testați tranzacțiile aplicației, nu doar disponibilitatea gazdei. Validați conexiunile la baza de date, stocarea partajată, autentificarea, joburile programate și orice verificări ale stării de funcționare a echilibratorului de încărcare.
• Un sistem cu un singur server trebuie să rămână online: nu există o procedură de migrare a pachetului service pack SLES care să evite repornirea pe aceeași gazdă. Adăugați o a doua instanță a aplicației sau planificați o perioadă de mentenanță.

Cum se poate evalua dacă s-a evitat timpul de nefuncționare

Definiți o condiție de succes măsurabilă înainte de modificare. De exemplu: verificarea externă a stării de funcționare a serviciului continuă să fie efectuată pe parcursul întreținerii fiecărui nod, ratele de eroare rămân în limitele convenite și o tranzacție reprezentativă a utilizatorului are succes în timp ce un nod nu este disponibil. Înregistrați orice interval de failover, sesiuni abandonate, lucrări în coadă sau performanță degradată. Dacă endpoint-ul a rămas activ, dar un flux de lucru cheie a eșuat, migrarea nu a îndeplinit obiectivul la nivel de serviciu.

O actualizare continuă poate menține disponibil un serviciu proiectat corespunzător în timp ce serverele individuale repornesc. Nu poate garanta sesiuni neîntrerupte, nu poate compensa un cluster cu capacitate insuficientă sau nu poate elimina repornirea de la fiecare gazdă migrată. Pentru implementări cu un singur nod, aplicații cu stare fără replicare testată sau clustere cu extensii neacceptate, utilizați o fereastră de întreținere planificată sau construiți și validați un mediu de înlocuire înainte de a muta traficul de producție.

Referințe oficiale

• SUSE: Căi de actualizare și migrare acceptate către SLES 15 SP6
• SUSE: Pregătirea actualizării
• SUSE: Actualizare online cu YaST sau Zypper
• SUSE: Actualizare continuă a clusterului SLE HA
• SUSE: Note de lansare SLES 15 SP6