Cosa sono gli upgrade in place di RHEL?

10 novembre 2023Marek Filip

Quando i clienti Red Hat Enterprise Linux (RHEL) desiderano aggiornare il proprio stack di applicazioni o ricevere gli ultimi aggiornamenti sulla sicurezza, e quando si avvicinano alla fine del ciclo di vita di RHEL (come RHEL 7, che raggiungerà la fine del periodo di manutenzione il 30 giugno 2024), in genere vogliono passare alla versione più recente. Questo post è il primo di una serie di articoli sugli upgrade di RHEL che speriamo possano esserti utili per pianificare l'attività futura. Per iniziare, esaminiamo gli upgrade in place di RHEL.

Quali problemi risolvono gli upgrade in place?

Gli upgrade hanno sempre richiesto una nuova installazione del sistema operativo e la ridistribuzione di tutti gli stack di applicazioni, dei database e delle configurazioni. Gli upgrade in place risolvono questo inconveniente preservando i flussi di lavoro esistenti dei clienti. Innanzitutto, diamo un'occhiata ai casi in cui gli upgrade in place sono la scelta più appropriata per le aziende rispetto a una nuova installazione.

Upgrade in place e nuove installazioni a confronto

In molti casi, gli upgrade in place possono essere eseguiti da amministratori di sistema meno esperti. Se i sistemi non presentano configurazioni complesse o insolite, è sufficiente eseguire pochi comandi su tutti i sistemi da aggiornare, consultare il report di analisi preliminare ed eventualmente applicare le correzioni suggerite.

Conservazione delle configurazioni

Una delle funzioni più importanti degli upgrade in place è mantenere il controllo delle applicazioni installate. È possibile estendere il processo di upgrade specificando quali repository personalizzati utilizzare durante la procedura. La creazione di utenti Leapp personalizzati può anche contribuire alla migrazione delle applicazioni di terze parti con configurazioni specifiche. Le organizzazioni che desiderano innovare il proprio ambiente trarranno vantaggio da questo controllo, che permette di soddisfare i requisiti delle applicazioni personalizzate. Infine, è possibile automatizzare eventuali passaggi di correzione indicati durante il processo preliminare utilizzando i playbook di Ansible.

Minore esigenza di competenze avanzate

Gli upgrade in place non richiedono la conoscenza delle configurazioni del sistema esistenti o delle applicazioni installate, quindi possono effettuarli anche gli amministratori di base. Eseguendo l'analisi preliminare e applicando le correzioni suggerite, si riduce il rischio di eliminazione accidentale di applicazioni o configurazioni. L'amministratore deve essere in grado di comprendere soltanto le informazioni nel report.

Continuità delle sottoscrizioni

Poiché gli upgrade in place non eliminano alcuna informazione sulle sottoscrizioni RHEL esistenti, queste restano attive.

Risparmio di tempo e risorse

Gli upgrade in place consentono di risparmiare tempo e risorse preziose. Rappresentano un metodo pratico per prolungare la vita dell'hardware attuale modernizzando l'intero ambiente.

Come affrontare le incertezze

L'analisi preliminare è uno strumento utile già di per sé. Se un cliente ha dei dubbi, può eseguire questa analisi per generare un inventario dei pacchetti installati sul sistema con possibili percorsi di upgrade e suggerimenti di correzione. Questo può essere utile per stabilire la strategia di upgrade più appropriata.

Nuove installazioni

Quando si esegue una nuova installazione di RHEL, tutti i dati di sistema vengono cancellati, incluse le applicazioni e le configurazioni. Questo comporta costi operativi estremamente elevati e richiede competenze aggiuntive durante il deployment.

Eliminazione della configurazione esistente

Le configurazioni vengono eliminate durante l'installazione e riapplicarle tutte può richiedere molto tempo, soprattutto se non si utilizzano le funzionalità di automazione presenti in prodotti come Red Hat Ansible Automation Platform.

Tempo e costi aggiuntivi

È necessario reinstallare il sistema operativo (SO) su centinaia, o addirittura migliaia di macchine, eseguendo nuovamente il deployment dell'intero stack di applicazioni. Questo comporta un maggiore dispendio di tempo e risorse.

Necessità di nuove sottoscrizioni per le macchine

Le macchine i cui dati sono stati cancellati non possono conservare le sottoscrizioni RHEL esistenti durante l'installazione. Per poter funzionare correttamente, occorrono nuove sottoscrizioni per ogni macchina.

Quindi le nuove installazioni sono sempre la scelta migliore?

Quando si esegue la transizione a un nuovo hardware, si dispone di un nuovo stack di applicazioni o si desiderano nuove capacità di gestione e automazione, le nuove installazioni sono molto utili. Ad esempio, i progetti Greenfield (che non dipendono dalle attività precedenti) sono ottimi scenari di utilizzo per nuove installazioni.

Disponibilità e versioni supportate

Quando si esegue l'upgrade dall'interfaccia a riga di comando, si possono installare tutti i pacchetti necessari tramite dnf o Yum grazie a leapp-upgrade, un pacchetto virtuale fornito a tutti i sistemi RHEL in cui è disponibile Leapp. Il comando leapp utilizza i suoi sottocomandi per creare il report preliminare e, successivamente, diventa disponibile l'upgrade stesso.

I clienti possono inoltre eseguire l'analisi preliminare in Red Hat Satellite, dove gestiscono le proprie macchine. Dopo aver eseguito la valutazione preliminare e aver corretto i rischi analizzati, è possibile effettuare l'upgrade di tutte le macchine contemporaneamente anche nell'interfaccia utente. Per ulteriori informazioni, consulta Leapp in Satellite.

È disponibile l'upgrade di diverse versioni di RHEL. Per un elenco completo e aggiornato di tutti i percorsi di upgrade supportati, consulta l'articolo Supported in-place upgrade paths for Red Hat Enterprise Linux. L'elenco viene aggiornato a ogni nuova versione di RHEL.

Per quanto riguarda il supporto sui cloud pubblici, offriamo upgrade in place per le istanze di pagamento a consumo (PAYG) on demand sulle piattaforme Amazon Web Services (AWS), Microsoft Azure e Google Cloud con Red Hat Update Infrastructure (RHUI ). Supportiamo inoltre gli upgrade per chi usa sottoscrizioni già esistenti (modello Bring Your Own Subscription, BYOS) su tutti i cloud pubblici che utilizzano Red Hat Subscription Manager per una sottoscrizione RHEL.

È importante ricordare che non è possibile eseguire upgrade diretti su più versioni principali (ad es. da RHEL 6 a RHEL 8). La procedura per eseguire l'upgrade dalla versione 6 alla 8 prevede prima l'upgrade a RHEL 7 e quindi a RHEL 8.

Per i dettagli sulle architetture e sui prodotti supportati e per avere informazioni più dettagliate su come eseguire l'upgrade, consulta la documentazione riportata di seguito:

Riepilogo

Gli upgrade in place possono risolvere diversi problemi di ridistribuzione facendo risparmiare tempo e denaro. Sebbene si possano comunque utilizzare le nuove installazioni per i progetti greenfield, gli upgrade in place sono chiaramente preferibili quando si rinnovano gli ambienti esistenti. Gli upgrade in place sono anche una componente chiave dell'ecosistema RHEL, quindi è prevedibile un supporto continuo insieme alle innovazioni pianificate.