Le migliori 9 soluzioni di backup di OpenShift ETCD

RedHat OpenShift consente agli utenti di fornire, istanziare, eseguire e gestire un bundle modulare che comprende una piattaforma informatica e una serie di applicazioni, riducendo in modo significativo la complessità della costruzione e della manutenzione dell’infrastruttura che sarebbe probabilmente associata allo sviluppo e al lancio delle applicazioni e dei servizi necessari.

OpenShift rappresenta un approccio specifico al modo in cui le macchine virtuali, i container e gli ambienti di piattaforma come servizio possono lavorare insieme; la piattaforma nel suo complesso è spesso utile sia per le aziende che per i privati che sono in grado di sfruttarla.

Poiché OpenShift consiste in una famiglia di software, è importante menzionare il suo fiore all’occhiello: OpenShift Container Platform.

OpenShift Container Platform, o OSCP, è una piattaforma cloud ibrida come servizio che funziona con container Linux gestiti da Kubernetes. Il più delle volte ci si riferisce ad essa come a “OpenShift”, anche se ci sono molti altri prodotti disponibili all’interno della stessa famiglia, tra cui OpenShift Online, OpenShift Dedicated e altri. Per motivi di continuità, ci riferiremo alla OpenShift Container Platform semplicemente come “OpenShift” per il resto di questo articolo, perché la maggior parte dei servizi e delle soluzioni seguenti funzionano con OSCP.

OpenShift è stato progettato per essere modulare e flessibile, il che comporta una serie di vantaggi per le varie distribuzioni che utilizzano OpenShift. Tuttavia, questo approccio flessibile e versatile ha i suoi limiti. Il primo problema è che questo approccio, sebbene possa essere molto efficace, può anche essere soggetto a errori e guasti. Per questo motivo, un buon sistema di backup è un requisito per la maggior parte, se non per tutte, le implementazioni OpenShift, soprattutto quando vengono creati e/o elaborati dati preziosi e persistenti.

La necessità di un sistema di backup crea un altro problema significativo per le distribuzioni OpenShift: non tutte le soluzioni di backup sono in grado di proteggere adeguatamente gli ambienti OpenShift, e alcune non sono in grado di farlo affatto.

Per questo motivo, una soluzione di backup e ripristino deve essere pienamente compatibile con OpenShift. In genere, le funzioni di backup come l’automazione del backup, il supporto di diverse posizioni e supporti di backup e le funzionalità di migrazione dei dati sono un’aggiunta importante alla capacità di backup e ripristino esistente di OpenShift.

Capacità di backup OpenShift integrate

Non ci sono molte soluzioni di backup complete sul mercato che siano anche in grado di eseguire operazioni di backup e ripristino di OpenShift – ma prima dobbiamo esaminare quanto RedHat stessa è in grado di fare. Questa funzionalità di backup incorporata è quella che approfondiremo per prima.

Backup e ripristino del cluster OpenShift

Esistono due possibili percorsi: le operazioni di backup e ripristino per i cluster e le stesse operazioni per le applicazioni. Le operazioni di backup dei cluster si basano interamente sui dati etcd, un archivio di valori-chiave di OSCP (OpenShift Container Platform) che contiene informazioni su tutti gli oggetti risorsa all’interno di un cluster.

Un amministratore di cluster può dover spegnere o riavviare i cluster in situazioni specifiche, sia per scopi di manutenzione che per risparmiare risorse eseguendo meno cluster contemporaneamente. Il processo di spegnimento di un cluster OpenShift è talvolta chiamato “spegnimento aggraziato” e comprende lo spegnimento dei nodi del cluster con un comando di spegnimento dedicato, nonché lo spegnimento di tutte le dipendenze non più utilizzate con lo spegnimento del cluster.

Esiste anche un altro processo chiamato “riavvio aggraziato”, che naturalmente è l’opposto diretto di un arresto aggraziato, in quanto avvia il cluster invece di arrestarlo. Questo particolare processo, tuttavia, può essere un po’ più complicato del suo opposto, con passaggi quali:

• Accendere qualsiasi dipendenza del cluster precedentemente disabilitata;
• Avvio della macchina cluster stessa;
• Verificare se i nodi del piano di controllo sono pronti;
• Verificare se i nodi worker sono pronti;
• Verificare se il cluster nel suo complesso si è avviato correttamente o meno.

Se il cluster non si è avviato correttamente, l’unica soluzione sarebbe quella di utilizzare un backup etcd per ripristinare lo stato precedente del cluster.

Sebbene sia vero che l’arresto aggraziato dovrebbe consentire il riavvio del cluster con uno sforzo minimo, un backup etcd dovrebbe essere eseguito prima di ogni evento di arresto del cluster. I backup etcd svolgono un ruolo importante negli scenari di ripristino di emergenza e non sarebbe possibile ripristinare un OSCP difettoso senza un backup etcd coinvolto nel processo.

Il processo di backup di etcd è abbastanza semplice e comprende tre fasi principali: l’avvio di una sessione di debug, la modifica della directory principale in /host, e l’avvio di uno script chiamato “cluster-backup.sh“, inserendo anche la posizione del backup.

Il processo di ripristino del cluster, invece, è un po’ più complicato, soprattutto perché i ripristini del cluster tramite il backup di etcd sono considerati una “opzione di ultima istanza” che normalmente dovrebbe essere utilizzata solo quando non funziona nient’altro per recuperare lo stato di funzionamento del cluster. Comporta diverse fasi, come ad esempio:

• Selezione di un host del piano di controllo che eseguirà le operazioni di ripristino;
• Impostare la connettività SSH con tutti i nodi del piano di controllo, compreso quello che verrà utilizzato per il ripristino;
• Copiare manualmente il backup di etcd sull’host scelto come host di ripristino;
• Accedere all’host in questione;
• Esecuzione dello script di ripristino “cluster-restore.sh“;
• Controllare se i nodi sono nello stato “pronto”;
• Riavvio del servizio kubelet per tutti gli host del piano di controllo, compreso quello di recupero;
• Approvare le CSR in sospeso, verificando se il piano di controllo a membro singolo è attivo e funzionante;
• Cancellazione e ricreazione di tutte le macchine del piano di controllo, con l’esclusione di quella scelta per il recupero.

Questo ci porta alla seconda parte di questo lungo processo: inizia con lo stesso utente che accede a una finestra di terminale separata con il ruolo “cluster-admin“. Le operazioni seguenti sono:

• Forzare la ridislocazione di etcd;
• Verificare se i nodi sono aggiornati;
• Forzare nuovi rollout al piano di controllo (questo dovrebbe reinstallare Kubernetes API su tutti i nodi, dal momento che viene utilizzato un bilanciatore di carico interno per collegare il kubelet al server API);
• E per ultimo, ma non meno importante, si verifica che tutti gli host del piano di controllo appena installati funzionino e si uniscano al cluster.

È facile vedere come il processo di ripristino per il backup di etcd sia piuttosto lungo e difficile, e questo è uno dei motivi per cui viene trattato come un’opzione di ultima istanza.

Ora che abbiamo visto come funzionano il backup e il ripristino dei container, analizziamo il processo di backup e ripristino delle applicazioni.

Backup e ripristino delle applicazioni OpenShift

Anche il processo di creazione di backup delle applicazioni in OpenShift può essere piuttosto complicato, ma non lo approfondiremo particolarmente, perché i punti focali di questo articolo sono etcd e i cluster. Tuttavia, ne esamineremo la logica.

Le operazioni di backup e ripristino per le applicazioni all’interno di OpenShift possono essere eseguite con l’aiuto di OADP, o OpenShift API for Data Protection. Utilizza Velero per eseguire operazioni di backup e ripristino sia per le risorse che per le immagini interne, oltre ad essere in grado di lavorare con volumi persistenti tramite Restic o con snapshot.

Esiste un elenco molto specifico di varianti di storage di cui è possibile eseguire il backup con OADP – questo elenco include MS Azure, AWS, GCP, Multicloud Object Gateway, oltre a diverse varianti di object storage compatibili con S3 (Minio, Noobaa, ecc.). Allo stesso tempo, i backup snapshot possono essere eseguiti solo per i cloud storage AWS, Azure, GCP e CSI abilitati agli snapshot (Ceph FS, Ceph RBD, ecc.), poiché solo questi supportano la necessaria API snapshot a livello nativo.

Il processo di backup vero e proprio prevede la creazione di una CR, o risorsa personalizzata, a scopo di Backup o di Ripristino. Questa opzione può essere utilizzata per eseguire backup Restic, backup programmati e per impostare ganci di backup/ripristino da eseguire prima o dopo il completamento del processo di backup/ripristino.

Opzioni di backup OpenShift di terze parti

Sebbene il metodo di backup/ripristino precedentemente menzionato sia effettivamente possibile, presenta dei potenziali problemi associati, soprattutto perché manca di funzioni aggiuntive e potrebbe essere un po’ complicato per molti utenti. Ecco perché esamineremo anche le soluzioni di backup di OpenShift ETCD di terze parti, a partire da IBM Spectrum.

IBM Spectrum Protect Plus

IBM Spectrum Protect Plus è una soluzione completa di protezione dei dati che offre una serie di funzioni nel campo della sicurezza dei dati – tra cui il backup, il ripristino, la conservazione e la replica per ogni tipo di destinazione, che si tratti di database, applicazioni, macchine virtuali, carichi di lavoro SaaS o persino container.

IBM Spectrum Protect è una soluzione abbastanza versatile, ed è per questo che può funzionare anche con i sistemi OpenShift. La soluzione di IBM è in grado di proteggere non solo i volumi persistenti, ma anche altre risorse dipendenti dal cluster OpenShift. Pur avendo una serie di requisiti per il funzionamento dei backup di OpenShift, i requisiti stessi non sono particolarmente rigidi e includono per lo più un unico requisito di aggiornamento delle diverse parti del sistema di virtualizzazione.

IBM Spectrum Protect consente ai suoi utenti di registrare manualmente i cluster OpenShift, di creare backup dei dati dei container OpenShift e di ripristinarli da un’istantanea o da una copia di backup regolare, e può anche ripristinare risorse specifiche di spazio dei nomi e di cluster o persino sovrascrivere le impostazioni di conservazione per backup o snapshot specifici facendo scadere le sessioni di lavoro di backup OpenShift.

CronJob

A differenza del resto di questo elenco, CronJob non è esattamente una soluzione di backup a sé stante. Un CronJob è un’attività che può eseguire azioni specifiche seguendo un programma specifico nei sistemi basati su Unix. In questo particolare contesto, un utente di GitHub utilizza CronJob per eseguire una serie di operazioni che portano alla creazione di un backup di OpenShift con lo stesso metodo che abbiamo menzionato in precedenza (esecuzione di cluster-backup.sh).

Questo CronJob specifico crea un pod che esegue il suddetto script per creare il backup stesso. Inoltre, copia l’intero backup in un PV preconfigurato e poi fa scadere il lavoro di backup stesso per evitare conflitti futuri. Crea due file separati: uno è la raccolta dei pod statici nel loro insieme, con le loro chiavi private e i loro certificati, e l’altro è lo snapshot di etcd. Per questo motivo, questo particolare “metodo” può essere definito una soluzione di backup ETCD di OpenShift.

Kasten K10

Kasten K10 è una piattaforma di gestione dei dati che è nativa per il cloud come tipo di archiviazione, offrendo una serie di opzioni diverse come il backup, il recupero, la mobilità delle applicazioni e il disaster recovery per le applicazioni Kubernetes, oltre ad essere in grado di integrarsi con una varietà di tipi di database diversi, di supportare più fornitori di archiviazione cloud e di funzionare con la maggior parte delle distribuzioni Kubernetes.

K10 può anche eseguire operazioni di backup e ripristino di OpenShift con relativa semplicità. La differenza principale è la creazione di un Segreto – la versione di Kasten di un elenco di backup che include informazioni sulle etichette dei pod etcd, sull’endpoint del cluster etcd e su tutto ciò di cui è necessario eseguire il backup. A parte questo, il loro processo è in qualche modo simile a come K10 esegue solitamente i backup: creazione di un Blueprint e utilizzo di un Segreto con un Blueprint per eseguire l’attività di backup. Il processo di ripristino, invece, è simile a quello che abbiamo discusso nella sezione “metodi integrati” di questo articolo.

Storware Backup and Recovery/a>

Storware Backup and Recovery è un software di protezione dei dati cloud-native che funziona molto bene quando si tratta di creare backup di volumi persistenti o metadati collegati a pod OpenShift. Ha lo status di Red Hat OpenShift Operator certificato, che offre coerenza nei suoi sforzi di protezione dei dati, in combinazione con funzioni come la pianificazione, la modifica dei criteri di backup, l’automazione del backup e così via. Si tratta di un’ottima soluzione di backup e ripristino di OpenShift ETCD che copre diversi piani di dati di OpenShift – il già citato etcd, i metadati, i volumi persistenti e altro ancora.

Portworx Backup

Portworx è una piattaforma di servizi dati che si concentra sullo sviluppo di soluzioni per gli utenti di Kubernetes, per aiutare l’esecuzione di applicazioni in contenitori senza interruzioni ed eventi di perdita di dati. Offre un accesso più facile ai backup delle applicazioni con coerenza e molteplici funzionalità, come la pianificazione dei backup, RBAC, la gestione degli utenti e altro ancora. Portworx può anche offrire funzionalità di disaster recovery, implementazione CSI, crittografia a livello di cluster, snapshot e molte altre funzioni per cluster e applicazioni OpenShift.

Cloudcasa

Cloudcasa è un servizio di backup resiliente e potente, con una grande scalabilità e un’interfaccia facile da usare. Può offrire una protezione dei dati multi-cloud, molteplici opzioni di cyber-resilienza e diversi tipi di backup all’interno dei suoi ambienti OpenShift (risorse Kubernetes, backup etcd e snapshot CSI). Cloudcasa può anche eseguire diversi livelli di operazioni di ripristino, sia a livello granulare che a livello di cluster, il che la rende una soluzione di backup e ripristino di OpenShift ETCD piuttosto conveniente e utile.

Dell EMC PowerProtect Data Manager

Dell EMC è una potenza tecnologica che offre una varietà di prodotti e servizi per diversi mercati. PowerProtect Data Manager di Dell EMC è una soluzione versatile di protezione dei dati che supporta diversi tipi di ambiente e può lavorare con una moltitudine di posizioni di archiviazione diverse. Supporta anche gli ambienti OpenShift, offrendo protezione per i suoi carichi di lavoro, oltre ad essere una soluzione di backup e ripristino affidabile e utile. Integra gli ambienti di OpenShift nella propria interfaccia centralizzata, offrendo la possibilità di assegnare politiche di protezione ai namespace, ai cluster e a tutto il resto di OpenShift.

Bacula Enterprise

Bacula Enterprise è una soluzione di backup aziendale unica e altamente sicura, che supporta una gamma particolarmente ampia di ambienti e funzionalità grazie al suo sistema di ‘moduli’. Uno di questi moduli è stato creato appositamente per le operazioni complete di backup e ripristino di OpenShift, fornendo una serie di funzioni di protezione dei dati agli ambienti OpenShift. Questo particolare modulo offre funzionalità come la salvaguardia dello stato del cluster, la ridistribuzione efficace delle risorse del cluster, le funzionalità di ripristino delle applicazioni, il ripristino mirato dei dati PV, il trasferimento della configurazione per altre operazioni e così via. Non solo Bacula Enterprise può essere utile per salvaguardare i suoi dati OpenShift nel loro complesso, ma può anche facilitare i piani di disaster recovery, offrire ulteriore sicurezza ai suoi dati, aiutare con le attività di migrazione del cluster, offrire funzionalità di replica dell’ambiente e molto altro ancora. Vale la pena notare che il suo modello di licenza basato su abbonamento e l’elevata scalabilità lo rendono vantaggioso per le distribuzioni medio-grandi e grandi.

Conclusione

Gli ambienti OpenShift sono estremamente utili in aree e settori applicativi specifici, ma è anche relativamente nuovo, il che significa che la salvaguardia dei dati al suo interno può essere un po’ problematica. Dato che gli ambienti Kubernetes di qualsiasi tipo sono sempre più diffusi, il backup dei loro dati – soprattutto quelli persistenti – è sempre più importante. Questo articolo illustra diverse soluzioni di backup di OpenShift, comprese le opzioni integrate e di terze parti disponibili, e può essere utile per trovare una soluzione per un caso d’uso specifico dell’utente.