Mantenere i servizi disponibili durante l'aggiornamento da SLES 15 SP5 a SP6

È difficile programmare una breve finestra di manutenzione quando un server SLES esegue un servizio rivolto ai clienti. SUSE supporta la migrazione online dei service pack da SLES 15 SP5 a SP6, ma la macchina aggiornata necessita comunque di un riavvio; "online" non significa senza riavvio. Per mantenere un'applicazione raggiungibile, è necessario aggiornare i nodi ridondanti uno alla volta oppure creare un server sostitutivo con SP6 e reindirizzare il traffico verso di esso. Un singolo server non può mantenere il proprio sistema operativo disponibile durante il riavvio.

Scenario illustrativo: un team fittizio gestisce un'applicazione web su tre nodi SLES 15 SP5 dietro un bilanciatore di carico. L'applicazione può gestire le richieste provenienti dagli altri due nodi mentre un nodo è in manutenzione. La sequenza seguente mostra come il team potrebbe migrare il cluster; si tratta di un esempio, non di un'affermazione che sia stato eseguito un test o che ogni cluster possa tollerare un'interruzione di servizio di un nodo.

1. Scegli un percorso che corrisponda al servizio

Per la migrazione da SLES 15 SP5 a SP6, SUSE documenta sia il metodo di aggiornamento online che quello offline. Il metodo online utilizza YaST Migration oppure, zypper migrationse eseguito a sistema operativo in esecuzione, richiede il riavvio del sistema al termine della migrazione. Anche le modifiche ai pacchetti potrebbero riavviare i servizi, pertanto la sola migrazione online non garantisce la continuità delle applicazioni.

Utilizzare la procedura di aggiornamento progressivo di SLE High Availability solo se il carico di lavoro è già protetto da un cluster supportato e funzionante. Il cluster deve mantenere il quorum e una capacità sufficiente per eseguire il servizio anche con un nodo offline. Un normale bilanciatore di carico senza ridondanza delle applicazioni, o un cluster a due nodi che perde il quorum quando un nodo si arresta, non è sufficiente. Se il server è autonomo, utilizzare un host SP6 parallelo ed eseguire un cutover del carico di lavoro/dati testato per mantenere la raggiungibilità; in caso contrario, pianificare un periodo di inattività per il suo riavvio.

2. Verificare l'obiettivo e preparare un piano di recupero

Prima di intervenire sul cluster, verificare la versione di partenza, la registrazione, i repository e le estensioni supportate. SUSE elenca SLES 15 SP5 a SP6 come percorso supportato. La migrazione online richiede che la macchina sia registrata presso SUSE Customer Center o un server RMT locale; i client di SUSE Manager devono utilizzare la procedura di migrazione client di Manager anziché eseguirla zypper migrationdirettamente. La destinazione disponibile può dipendere dai prodotti e dalle estensioni registrati.

Secondo le informazioni di rilascio di SUSE, a partire dal 1° gennaio 2026 SLES 15 SP6 è passato alla versione LTSS. Prima di pianificare questa migrazione specifica, verifica che la tua sottoscrizione e la fonte di registrazione supportino attualmente il target SP6. Se non è disponibile, non forzare una modifica del repository per simulare una migrazione supportata.

Eseguire il backup dei dati e della configurazione dell'applicazione utilizzando il metodo supportato dall'applicazione stessa e verificare di poterli ripristinare. Consultare la guida all'aggiornamento di SLE HA e le note di rilascio di SP6 per le estensioni, i database, lo storage e l'hardware. Nel cluster fittizio, l'operatore verifica anche il quorum, il fencing, lo stato di replica, la capacità di riserva, lo stato di salute del bilanciatore di carico e un metodo collaudato per instradare il traffico da ciascun nodo. Uno snapshot può facilitare il rollback su configurazioni root Btrfs supportate, ma non sostituisce i backup di applicazioni o database.

3. Aggiorna un nodo esaurito alla volta

Per ogni nodo, seguire la procedura di aggiornamento progressivo di SLE HA e il runbook del cluster. Non aggiornare mai più nodi contemporaneamente a meno che la procedura specifica del prodotto non lo consenta esplicitamente.

1. Verificare che i nodi rimanenti siano in grado di gestire il carico di lavoro. Controllare l'integrità dell'applicazione e lo stato del cluster. Spostare o dirottare il traffico dal nodo utilizzando i controlli documentati per il bilanciatore di carico e le risorse del cluster. Non procedere se i nodi rimanenti non sono in grado di mantenere il quorum o di soddisfare la capacità minima del servizio.
2. Arresta lo stack del cluster su quel nodo. SUSE avverte che lasciare attivo il gestore delle risorse del cluster durante l'aggiornamento del software può causare la delimitazione dei nodi attivi. Sul nodo selezionato per la manutenzione, esegui:

sudo crm cluster stop

3. Avvia la migrazione del service pack e controlla la proposta. Esegui il comando di migrazione Zypper documentato:

sudo zypper migration

Seleziona SLES 15 SP6 solo se risulta disponibile come destinazione. Leggi attentamente il repository e il piano di installazione, in particolare i pacchetti proposti per la rimozione o il downgrade, e interrompi l'operazione se le modifiche sono impreviste. Non accettare un piano che non hai prima esaminato. L'elenco esatto dei pacchetti varia in base al software installato e alle estensioni registrate.

4. Riavvia il nodo aggiornato. Dopo che Zypper segnala una migrazione riuscita, riavvia la macchina in modo che avvii il kernel e i servizi di SP6:

sudo reboot

5. Riconnettiti e verifica prima di passare al nodo successivo. Dopo che il nodo ha restituito il controllo, avvia il suo stack del cluster:

sudo crm cluster start
sudo crm status

Attendi che il cluster segnali l'avvenuta aggiunta del nodo e che le risorse siano integre, quindi ripristinalo in servizio secondo le istruzioni del tuo runbook. Verifica l'applicazione dall'esterno del cluster. Solo a questo punto ripeti il ​​processo per il nodo successivo. SUSE consente l'utilizzo di versioni miste solo per un breve periodo durante un aggiornamento progressivo e raccomanda agli amministratori di completare l'aggiornamento del cluster entro una settimana.

4. Verifica il servizio, non solo l'etichetta del sistema operativo

Dopo l'aggiornamento di tutti i nodi, conferma il rilascio con cat /etc/os-release, verifica lo stato di salute del cluster con crm statuse controlla le unità systemd non funzionanti con systemctl --failed. Quindi testa l'applicazione effettiva tramite il suo normale indirizzo rivolto al client, inclusi i controlli di integrità, l'accesso al database o allo storage e qualsiasi attività pianificata rilevante per gli utenti. Esamina i log di migrazione e conferma che i repository e le estensioni previsti siano attivi su ogni nodo.

Una migrazione del sistema operativo riuscita non garantisce la compatibilità di tutte le dipendenze dell'applicazione né che nessuna richiesta sia stata interrotta. Se l'applicazione non tollera un failover del nodo, utilizzare una distribuzione blue-green con replica dei dati convalidata e commutazione controllata dell'endpoint, oppure pianificare una finestra di manutenzione. Per le opzioni di comando esatte e le condizioni di supporto, consultare la guida all'aggiornamento online di SLES 15 SP6 di SUSE , i percorsi di aggiornamento supportati , la procedura di aggiornamento progressivo di SLE HA e le note di rilascio di SUSE Multi-Linux Manager 5.1 relative alla transizione al ciclo di vita SP6.