Come migrare da SLES 15 SP5 a SP6 senza tempi di inattività del sistema

È possibile mantenere un'applicazione disponibile durante la migrazione di un cluster SLES 15 SP5 a SP6, ma non è possibile aggiornare e riavviare una singola istanza del sistema operativo senza alcuna interruzione. SUSE supporta la migrazione dei service pack da SP5 a SP6 e il processo di migrazione online richiede comunque il riavvio del sistema. Per evitare tempi di inattività del servizio, è necessario aggiornare un nodo alla volta in un cluster SUSE Linux Enterprise High Availability (SLE HA) supportato oppure creare un ambiente SP6 sostitutivo e reindirizzarvi il traffico. Il servizio deve disporre di un ambiente funzionante in cui essere eseguito mentre ciascun host non è disponibile.

Questa guida per principianti si concentra sul percorso di aggiornamento progressivo per un cluster SLE HA. Spiega inoltre cosa fare se si dispone di un solo server, cosa verificare prima della modifica e come capire se il servizio è rimasto integro. I comandi e l'ordine esatti per lo spostamento dei carichi di lavoro dipendono dalle risorse del cluster, dallo storage e dall'applicazione.

Cosa significa “senza tempi di inattività del sistema”

La migrazione di un service pack sostituisce i pacchetti di sistema mentre il sistema sorgente è in esecuzione. SUSE la definisce migrazione online. Riduce la necessità di avviare il sistema da un supporto di installazione, ma la procedura ufficiale prevede il riavvio del sistema dopo una migrazione riuscita. La migrazione online non è la stessa cosa di un aggiornamento live, che lascia lo stesso host in esecuzione continuando a gestire le richieste.

Per un servizio in cluster, un aggiornamento progressivo significa mettere fuori servizio un nodo, migrarlo e riavviarlo, reinserirlo nel cluster e quindi ripetere la procedura sul nodo successivo. L'applicazione può rimanere disponibile da un altro nodo se il failover funziona e la capacità rimanente è sufficiente. Un failover potrebbe comunque causare una breve interruzione per le sessioni attive, quindi è consigliabile monitorare il servizio rivolto all'utente anziché presumere che l'"alta disponibilità" garantisca che ogni connessione rimanga inalterata.

SUSE elenca SLES 15 SP5 come sorgente supportata per SP6, sia online che offline. Il percorso supportato è documentato nella guida all'aggiornamento di SLES 15 SP6 . La documentazione di SUSE HA supporta un aggiornamento progressivo del cluster tra service pack all'interno della stessa versione principale. Consultare la guida all'aggiornamento del cluster SLE HA .

Scegli l'approccio giusto prima di cambiare qualsiasi cosa

• Un server autonomo: pianificare una finestra di manutenzione per la migrazione dell'host e il riavvio. Un bilanciatore di carico non può eliminare i tempi di inattività se non esiste una seconda istanza dell'applicazione funzionante.
• Due o più nodi SLE HA: valutare la procedura di aggiornamento progressivo documentata, dopo aver verificato il quorum, il fencing, l'allocazione delle risorse, l'accesso allo storage e la capacità di riserva.
• Applicazione con repliche al di fuori di SLE HA: aggiornare un host o un pool SP6 sostitutivo, convalidarlo e spostare gradualmente il traffico. Si tratta di un'implementazione blue-green o rolling a livello applicativo, separata da una migrazione SLES in loco.
• Host gestito da SUSE Manager: seguire il flusso di lavoro di migrazione client di SUSE Manager. SUSE sconsiglia di utilizzare la migrazione online YaST o di migrare zypper migrationdirettamente su un client SUSE Manager.

Se il servizio in uso è un database o un'altra applicazione con stato, è necessario considerare la compatibilità dell'applicazione e la replica dei dati come un flusso di lavoro separato. Un percorso di migrazione del sistema operativo non aggiorna automaticamente il database né garantisce la sicurezza della sua progettazione in termini di replica e failover.

Preparare il cluster e il piano di cambiamento

1. Conferma le versioni, la registrazione e l'idoneità all'aggiornamento

Verificate che ogni nodo utilizzi SLES 15 SP5, con l'estensione SLE HA e gli altri moduli o prodotti registrati come previsto. L'elenco delle destinazioni di migrazione dipende dai prodotti e dalle estensioni installati. La mancanza di una destinazione SP6 può indicare un problema di registrazione, di repository o di disponibilità dell'estensione; non tentate di forzare un percorso di repository diverso solo per far apparire la destinazione.

Per un sistema registrato, i seguenti controlli di sola lettura possono aiutare a stabilirne lo stato:

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

Confronta i prodotti SLES e SLE HA installati, i repository e l'architettura su tutti i nodi. Se l'host è gestito da SUSE Manager, utilizza la procedura di migrazione client corrispondente anziché seguire direttamente i passaggi descritti di seguito.

2. Applicare la patch, eseguire il backup e testare.

SUSE richiede che il sistema sorgente sia aggiornato all'ultima versione disponibile prima di procedere all'aggiornamento. Applicare gli aggiornamenti di manutenzione SP5 correnti e consultare le note di rilascio di SP6 per informazioni su modifiche a pacchetti, moduli e applicazioni. Le istruzioni di preparazione all'aggiornamento di SUSE raccomandano inoltre di disporre di un backup aggiornato e di consultare le note di rilascio.

Eseguire il backup della configurazione di sistema e dei dati delle applicazioni e verificare che il backup possa essere ripristinato. Testare l'intera procedura su un cluster di staging identico a quello di produzione, incluse le interfacce di rete, lo storage, le risorse del cluster, i repository di terze parti e i controlli di integrità delle applicazioni. Registrare la durata della migrazione e del riavvio su ciascun nodo per poter stimare la finestra temporale necessaria per la modifica.

3. Dimostrare che i nodi rimanenti possono gestire il carico di lavoro

Prima di rimuovere un nodo, verificare che il cluster sia integro e che non presenti guasti alle risorse irrisolti. Controllare che un altro nodo sia in grado di eseguire i servizi, montare o accedere allo storage necessario e gestire il traffico previsto. Se la rimozione di un nodo sovraccaricherebbe CPU, memoria, rete o storage, aumentare la capacità, ridurre il carico o pianificare una finestra di manutenzione anziché dichiarare che non vi sono tempi di inattività.

Assicurati che il fencing del cluster sia configurato e funzioni correttamente in base alla tua architettura HA (High Availability). Il fencing protegge le risorse condivise isolando i nodi non affidabili; disabilitarlo per semplificare un aggiornamento può creare un rischio di split-brain. Mantieni disponibile l'accesso tramite console o out-of-band nel caso in cui un nodo non si riavvii dopo il riavvio.

Eseguire un aggiornamento progressivo, un nodo alla volta.

Utilizzate i passaggi seguenti come schema di pianificazione. Seguite la procedura specifica per la vostra versione di SLE HA e la configurazione delle risorse; non copiate ciecamente una sequenza di gestione delle risorse nell'ambiente di produzione.

1. Verificare l'integrità del cluster. Acquisire lo stato attuale e confermare che tutti i nodi e le risorse siano integri. In SLE HA, crm statusquesto è un metodo documentato per ispezionare lo stato del cluster.
2. Spostare o svuotare i servizi dal nodo. Utilizzare la procedura approvata dal cluster per spostare le risorse dell'applicazione su un altro nodo funzionante. Verificare l'endpoint dell'applicazione e lo storage dipendente prima di procedere.
3. Arrestare lo stack del cluster sul nodo in fase di aggiornamento. Le istruzioni di SUSE per gli aggiornamenti progressivi avvertono che lasciare attivo il gestore delle risorse del cluster durante un aggiornamento software può causare problemi come la delimitazione dei nodi attivi. Il comando documentato a livello di nodo è crm cluster stop.
4. Eseguire la migrazione del service pack di SLES. Su un host registrato e non gestito da SUSE Manager, utilizzare sudo zypper migration. Esaminare le modifiche al target SP6 e al repository proposti. Leggere le azioni proposte per i pacchetti, in particolare i pacchetti da rimuovere o di cui effettuare il downgrade, prima di confermare. Le istruzioni ufficiali di migrazione online di SLES descrivono questo percorso della riga di comando.
5. Riavviare e verificare il nodo. Al termine della migrazione, riavviare l'host come indicato da SUSE. Verificare che si avvii SLES 15 SP6, che i prodotti richiesti siano registrati, che i repository corrispondano al service pack di destinazione e che il nodo non presenti errori di sistema critici.
6. Riportare il nodo nel cluster. Avviare il relativo stack del cluster utilizzando la procedura approvata; la guida SLE HA mostra come fare crm cluster start. Controllare crm statuso Hawk2 e verificare che il nodo si riconnetta senza errori di risorse.
7. Ripetere l'operazione solo dopo che il cluster si è stabilizzato. Spostare il carico di lavoro del nodo successivo, rimuovere tale nodo dal cluster, eseguire la migrazione, riavviare, convalidare e quindi riaggiungerlo. Non avviare il nodo successivo se il cluster rimanente è degradato o sta gestendo un carico di lavoro superiore a quello che può gestire in sicurezza.

SUSE dichiara che i nodi cluster con versioni miste sono supportati solo temporaneamente durante l'aggiornamento progressivo e che l'aggiornamento dovrebbe essere completato entro una settimana. Pianifica una sequenza breve e controllata anziché lasciare un cluster con versioni miste attivo a tempo indeterminato. Al termine, verifica che tutti i nodi eseguano SP6, controlla l'integrità del cluster e delle applicazioni e rivedi i log e la registrazione del repository.

Problemi comuni e come risolverli

• Non viene visualizzato alcun target di migrazione SP6: verificare la registrazione, i repository attivi e se ogni modulo o estensione installato dispone di un target SP6 supportato. Risolvere eventuali problemi relativi ai repository o alle autorizzazioni prima di iniziare.
• Il risolutore propone rimozioni inaspettate: interrompi e analizza l'origine dei pacchetti, i repository di terze parti e le dipendenze. SUSE avverte che i repository locali o su DVD obsoleti dovrebbero essere disabilitati per la migrazione. Non accettare un piano di pacchetti che non riesci a spiegare.
• Il nodo aggiornato non si riconnetterà: mantieni l'applicazione sui nodi funzionanti, esamina i log del cluster e di sistema e verifica la rete del nodo, la registrazione del prodotto, la configurazione del repository e i pacchetti SLE HA prima di riprovare.
• Il servizio è raggiungibile, ma gli utenti segnalano errori: testare le transazioni dell'applicazione, non solo la disponibilità dell'host. Convalidare le connessioni al database, lo storage condiviso, l'autenticazione, i processi pianificati e qualsiasi controllo di integrità del bilanciatore di carico.
• Un sistema a server singolo deve rimanere online: non esiste una procedura di migrazione del service pack SLES predefinita che eviti il ​​riavvio sullo stesso host. Aggiungere una seconda istanza dell'applicazione o pianificare un periodo di manutenzione.

Come valutare se è stato evitato il tempo di inattività

Definisci una condizione di successo misurabile prima della modifica. Ad esempio: il controllo di integrità esterno del servizio continua a superare la verifica durante la manutenzione di ciascun nodo, i tassi di errore rimangono entro la soglia concordata e una transazione utente rappresentativa ha successo anche quando un nodo non è disponibile. Registra eventuali interruzioni di failover, sessioni perse, attività in coda o prestazioni degradate. Se l'endpoint è rimasto attivo ma un flusso di lavoro chiave non è andato a buon fine, la migrazione non ha raggiunto l'obiettivo di livello di servizio.

Un aggiornamento progressivo può mantenere disponibile un servizio progettato in modo appropriato mentre i singoli server vengono riavviati. Non può garantire sessioni ininterrotte, compensare un cluster con capacità insufficiente o eliminare il riavvio da ogni host migrato. Per implementazioni a nodo singolo, applicazioni stateful senza replica testata o cluster con estensioni non supportate, utilizzare una finestra di manutenzione pianificata oppure creare e convalidare un ambiente sostitutivo prima di spostare il traffico di produzione.

Riferimenti ufficiali

• SUSE: Percorsi di aggiornamento e migrazione supportati a SLES 15 SP6
• SUSE: Preparazione dell'aggiornamento
• SUSE: Aggiornamento online con YaST o Zypper
• SUSE: Aggiornamento progressivo del cluster SLE HA
• Note di rilascio di SUSE: SLES 15 SP6