Principale > Blog sul backup e sul ripristino > Come fare il backup di Kubernetes?

Come fare il backup di Kubernetes?

1 Star2 Stars3 Stars4 Stars5 Stars
(15 voti, media: 4,67 fuori da 5)
Loading...
Aggiornato 9th Febbraio 2023, Rob Morrison

Sebbene l’ipotesi che in precedenza Kubernetes fosse utilizzato principalmente dai team DevOps fosse in qualche modo corretta, molte aziende stanno ora implementando attivamente i container negli ambienti operativi. Inoltre, scelgono sempre più spesso approcci container-centrici rispetto alle tradizionali macchine virtuali. Ciò è dovuto ai vari vantaggi di flessibilità, prestazioni e costi che i container possono spesso offrire. Tuttavia, man mano che i container si spostano nel lato operativo dell’ambiente IT, cresce la preoccupazione per gli aspetti di sicurezza dei container in un ambiente mission-critical, compresi i dati persistenti nel contesto dei processi di backup e ripristino.

In origine, la stragrande maggioranza delle applicazioni containerizzate erano stateless, il che permetteva loro di avere un processo di distribuzione molto più semplice su un cloud pubblico. Ma col tempo la situazione è cambiata, con un numero molto maggiore di applicazioni statiche distribuite nei container rispetto al passato. Questo cambiamento è il motivo per cui il backup e il ripristino in Kubernetes sono oggi un argomento importante per molte organizzazioni.

Caratteristiche importanti di una soluzione di backup Kubernetes competente

La natura dinamica degli ambienti Kubernetes rende più difficile per i sistemi e le tecniche di backup più tradizionali funzionare bene nel contesto dei nodi e delle applicazioni Kubernetes. Sia l’RPO che l’RTO possono dover essere molto più rigorosi, poiché le applicazioni devono essere costantemente attive e funzionanti, o particolarmente critiche, e così via.

Questo ci porta a distinguere tre diverse caratteristiche che sono altamente raccomandate per ogni azienda in generale, e una chiara necessità quando si tratta di backup Kubernetes secondo le migliori prassi:

  • Ripristino di emergenza;
  • Backup e ripristino;
  • Alta disponibilità locale.

In un ambiente Kubernetes, il contesto di questi tre aspetti del backup può cambiare leggermente rispetto alla loro normale definizione:

L’alta disponibilità locale come caratteristica riguarda più che altro la prevenzione/protezione dei guasti all’interno di un centro dati specifico o attraverso le zone di disponibilità (se parliamo di cloud, per esempio). Un guasto “locale” è quello che si verifica nell’infrastruttura/nodo/app utilizzata per eseguire l’applicazione. In uno scenario perfetto, la sua soluzione di backup Kubernetes dovrebbe essere in grado di reagire a questo guasto mantenendo l’applicazione funzionante, il che significa essenzialmente nessun tempo di inattività per l’utente finale. Uno degli esempi più comuni di guasto locale è un volume cloud bloccato che si verifica dopo il guasto di un nodo.

In questa prospettiva, l’alta disponibilità locale come funzionalità può essere considerata un fondamento del sistema complessivo di protezione dei dati. Per svolgere questo compito, la soluzione deve offrire una sorta di sistema di replica dei dati a livello locale e deve anche essere presente nel percorso dei dati. È importante ricordare che la fornitura di disponibilità locale tramite il ripristino del backup è ancora considerata backup e ripristino e non alta disponibilità locale, a causa del tempo di ripristino complessivo.

Backup e ripristino è un’altra parte importante di un sistema di backup Kubernetes. Nella maggior parte dei casi d’uso, esegue il backup dell’intera applicazione fuori sede da un cluster Kubernetes locale. Il contesto di Kubernetes porta anche a un’altra considerazione importante: se il software di backup ‘capisce’ ciò che è incluso in un’applicazione Kubernetes, come ad esempio:

  • Configurazione dell’app;
  • Risorse Kubernetes;
  • Dati

Un backup Kubernetes corretto deve salvare tutte le parti di cui sopra come un’unica unità, affinché sia utile nel sistema Kubernetes dopo il ripristino. Puntare su macchine virtuali, server o dischi specifici non significa che un software ‘capisca’ le applicazioni Kubernetes. Idealmente, un software Kubernetes dovrebbe essere in grado di eseguire il backup di applicazioni specifiche, gruppi specifici di applicazioni, nonché dell’intero spazio dei nomi Kubernetes. Questo non vuol dire che sia completamente diverso dal normale processo di backup: i backup di Kubernetes possono anche trarre grandi vantaggi da alcune delle caratteristiche regolari di un backup abituale, tra cui la conservazione, la pianificazione, la crittografia, il tiering e così via.

La capacità di Disaster Recovery (DR) è probabilmente essenziale per qualsiasi organizzazione che utilizza Kubernetes in una situazione mission-critical, proprio come nell’impiego di qualsiasi altra tecnologia. Innanzitutto, il DR deve “capire” il contesto dei backup di Kubernetes, proprio come il backup e il ripristino. Può anche avere diversi livelli di RTO e RPO e diversi livelli di protezione in base a questi livelli. Ad esempio, potrebbe esserci un requisito RPO zero rigoroso che implica tempi di inattività rigorosamente zero, oppure un RPO di 15 minuti, con requisiti un po’ meno rigorosi. Inoltre, non è raro che applicazioni diverse abbiano RTO e RPO completamente diversi all’interno dello stesso database.

Un’altra importante distinzione di un sistema di disaster recovery specifico per Kubernetes è che deve essere in grado di lavorare con i metadati in una certa misura (etichette, repliche di app, ecc.). L’incapacità di fornire questa funzione potrebbe facilmente portare a un recupero disarticolato in generale, nonché a una perdita generale di dati o a un ulteriore tempo di inattività.

Tipi di dati che devono essere sottoposti a backup in Kubernetes

Come qualsiasi sistema complesso, Kubernetes e Docker hanno una serie di tipi di dati specifici di cui avranno bisogno per ricostruire correttamente l’intero database in caso di disastro. Per semplificare le cose, è possibile suddividere tutti i tipi di dati e file di configurazione in due categorie diverse: configurazione e dati persistenti.

La configurazione (e le informazioni sullo stato desiderato) comprende:

  • Base dati Kubernetes etcd
  • File Docker
  • Immagini da file Docker

I dati persistenti (modificati o creati dai contenitori stessi) sono:

  • Database
  • Volumi persistenti

Database di Kubernetes etcd

È una parte integrante del sistema che contiene le informazioni sugli stati del cluster. Il backup può essere eseguito manualmente o automaticamente, a seconda della sua soluzione di backup. Il metodo manuale è il comando etcdctl snapshot save db, che crea un singolo file con il nome snapshot.db.

Un altro metodo per fare la stessa cosa è quello di attivare lo stesso comando subito prima di creare un backup della directory in cui apparirà questo file. Questo è uno dei modi per integrare questo specifico backup nell’intero ambiente.

File Docker

Poiché i contenitori Docker vengono eseguiti da immagini, queste immagini devono essere basate su qualcosa – e queste sono, a loro volta, create da file Docker. Per una corretta configurazione di Docker, si raccomanda di utilizzare una sorta di repository come sistema di controllo delle versioni per la totalità dei suoi file Docker (GitHub, ad esempio). Per facilitare l’estrazione di versioni precedenti, tutti i file Docker dovrebbero essere archiviati in un repository specifico che consenta agli utenti di estrarre versioni precedenti di tali file, se necessario.

Un repository aggiuntivo è consigliato anche per i file YAML che sono associati a tutte le distribuzioni Kubernetes, che esistono sotto forma di file di testo. Anche il backup di questi repository è un must, utilizzando strumenti di terze parti o le funzionalità integrate di qualcosa come GitHub.

È importante ricordare che è possibile eseguire il backup dei file Docker, anche se i container vengono eseguiti da immagini senza i loro file Docker. Esiste un comando specifico che è docker image history, che le consente di creare un file Docker dall’immagine corrente. Esistono anche diversi strumenti di terze parti che possono fare lo stesso.

Immagini da file Docker

Anche le immagini Docker stesse dovrebbero essere salvate in un repository. Sia il repository privato che quello pubblico possono essere utilizzati a questo scopo. Diversi fornitori di cloud tendono a fornire repository privati anche ai loro clienti. Se le manca l’immagine da cui viene eseguito il suo contenitore, un comando specifico che è docker commit dovrebbe essere in grado di creare quell’immagine.

Basi di dati

L’integrità è fondamentale anche quando si tratta di database che i container utilizzano per archiviare i loro dati. In alcuni casi, è possibile spegnere il container in questione prima di creare un backup dei dati, ma il tempo di inattività richiesto potrebbe causare molti problemi all’azienda in questione.

Un altro metodo per eseguire i backup del database all’interno dei container è la connessione al motore del database stesso. È necessario utilizzare prima un bind mount per collegare un volume di cui si possa eseguire il backup, e poi si può utilizzare il comando mysqldump (o simile) per creare un backup. Il file di backup in questione dovrebbe anche essere sottoposto a backup utilizzando il suo sistema di backup in seguito.

Volumi persistenti

È giusto dire che esistono diversi metodi per i container per accedere a una sorta di archiviazione persistente. Se si tratta di volumi docker tradizionali, questi risiedono in una directory che si trova sotto la configurazione Docker. I montaggi Bind, invece, possono essere qualsiasi directory montata all’interno di un container. Nonostante il fatto che i volumi tradizionali siano più preferiti dalla comunità Docker, entrambi sono relativamente uguali quando si tratta di eseguire il backup dei dati. Un terzo modo di eseguire la stessa operazione è montare una directory NFS o un singolo oggetto come volume all’interno di un contenitore.

Tutti e tre questi metodi presentano lo stesso problema quando si tratta di eseguire il backup dei dati: la coerenza di un backup non è completa se i dati all’interno di un contenitore cambiano a metà del backup. Naturalmente, è sempre possibile ottenere la coerenza spegnendo il volume prima di eseguire il backup, ma nella maggior parte dei casi i tempi di inattività per questi sistemi sono praticamente fuori questione per la continuità aziendale.

Esistono alcuni modi per eseguire il backup dei dati all’interno dei container che sono specifici del metodo. Ad esempio, i volumi docker tradizionali potrebbero essere montati su un altro contenitore che non modificherà i dati fino al completamento del processo di backup. Oppure, se utilizza un volume montato su bind, è possibile creare un’immagine tar di un intero volume e poi eseguire il backup dell’immagine.

Purtroppo, tutte queste opzioni sono molto difficili da realizzare quando si tratta di Kubernetes. Proprio per questo motivo, si raccomanda sempre di archiviare le informazioni di stato nel database e al di fuori del filesystem del container.

Detto questo, se utilizza una directory montata su bind o un file system montato su NFS come archivio persistente, è anche possibile eseguire il backup dei dati utilizzando i metodi normali, come un’istantanea. In questo modo dovrebbe ottenere una maggiore coerenza rispetto al tradizionale backup a livello di file dello stesso volume.

Mercato delle soluzioni di backup Kubernetes

Nel contesto di questi tre importanti fattori/caratteristiche, esaminiamo alcuni altri esempi di soluzioni di backup e ripristino Kubernetes.  Gli esempi che utilizziamo qui sono Kasten, Portworx, Cohesity, OpenEBS e Rancher Longhorn.

Kasten K10

Kasten K10 (recentemente acquisito da Veeam) è una soluzione di backup e ripristino che è anche orgogliosa dei suoi sistemi di mobilità e disaster recovery. Il processo di backup con Kasten è semplificato grazie alla sua capacità di scoprire automaticamente le applicazioni, oltre a molte altre caratteristiche, come la crittografia dei dati, il controllo degli accessi basato sui ruoli e un’interfaccia facile da usare. Allo stesso tempo, può lavorare con molti servizi di dati diversi, come MySQL, PostgreSQL, MongoDB, Cassandra, AWS e così via.

L’alta disponibilità locale non è disponibile, poiché Kasten non supporta direttamente la replica all’interno di un singolo cluster e si affida invece ai sistemi di archiviazione dati sottostanti.  Anche il disaster recovery è solo parzialmente “presente”, poiché Kasten non può raggiungere casi di RPO zero a causa della mancanza di un componente di percorso dei dati. Degno di nota è anche il fatto che i backup di Kasten sono solo asincroni, il che comporta in genere un tempo di inattività aggiuntivo tra le operazioni.

kasten landing page

Portworx

Portworx PX-Backup è un’azienda di gestione dei dati che sviluppa una piattaforma di archiviazione basata sul cloud per gestire e accedere al database dei progetti Kubernetes. È un altro esempio di soluzione di gestione dei dati e, nonostante i suoi limiti in quanto tale, uno dei vantaggi principali dell’utilizzo di Portworx è l’alta disponibilità dei dati.

Le operazioni di backup e ripristino, la comprensione delle app Kubernetes, l’alta disponibilità locale, il ripristino di emergenza, tra le altre funzioni – tutto ciò rende Portworx una buona soluzione per il backup di Kubernetes – se sta cercando una soluzione specializzata in compiti legati a Kubernetes.

Un’altra parte significativa di PX-Backup è la sua scalabilità, che consente di eseguire backup on-demand / backup programmati di centinaia di applicazioni contemporaneamente. La soluzione supporta anche le configurazioni multi-database e può ripristinare le applicazioni direttamente sui servizi cloud, come Amazon, Google, Microsoft, ecc.

portworx landing page

Cohesity

Cohesity è un concorrente relativamente popolare nel campo del backup e del ripristino generale, ma le sue capacità legate a Kubernetes hanno ancora spazio per crescere. Prima di tutto, Kubernetes è un’aggiunta relativamente nuova per loro, e hanno aggiunto la “comprensione” per le app Kubernetes fin dall’inizio, ma allo stesso tempo funziona solo per tutte le applicazioni all’interno dello stesso spazio dei nomi, e non è possibile proteggere app specifiche all’interno di quello stesso spazio dei nomi.

D’altra parte, ci sono anche funzionalità di recupero rapido, backup incrementali app-tier basati su criteri, consolidamento dello stato dei dati e molte altre funzionalità.

cohesity landing page

OpenEBS

OpenEBS è un altro esempio di soluzione che è riuscita a raggiungere alcuni risultati con una sola delle tre caratteristiche del nostro elenco, e in questo caso si tratta di Alta disponibilità locale.

Allo stesso tempo, OpenEBS può anche integrarsi con Velero, creando una soluzione Kubernetes combinata che eccelle nella migrazione dei dati Kubernetes. OpenEBS, da solo, può eseguire il backup solo di singole applicazioni (l’esatto contrario di ciò che fa Cohesity). Ci sono anche caratteristiche come lo storage multi-cloud, la sua natura open-source e un elenco gigantesco di piattaforme Kubernetes supportate, da AWS e Digital Ocean a Minikube, Packet, Vagrant, GCP e altro ancora.

Tuttavia, questo potrebbe non coprire le esigenze di un utente, poiché alcuni utenti potrebbero aver bisogno di questi backup dello spazio dei nomi in casi d’uso specifici.

openebs landing page

Rancher Longhorn

Rancher Longhorn è l’ultimo dei nostri esempi e probabilmente è il meno conosciuto di tutti. La sua comunità è relativamente piccola per una soluzione open-source e non consente di eseguire backup Kubernetes completi con metadati e risorse per realizzare il ripristino consapevole delle app. Tuttavia, c’è una caratteristica unica che spicca, e si chiama DR Volume. DR Volume può essere impostato sia come sorgente che come destinazione, rendendo il volume attivo in un nuovo cluster che si basa sui dati più recenti del backup.

Le capacità di Rancher di lavorare con diversi tipi di piattaforme container e di consentire diversi metodi di backup sono ciò che lo differenzia dagli altri, e c’è già la possibilità di supportare Kubernetes Engine, le distribuzioni Docker e le distribuzioni K3. I contenitori Docker, ad esempio, devono creare un tarball che potrebbe fungere da backup per Rancher.

rancher landing page

Rubrik

Molti altri attori più importanti nel campo del backup e del ripristino hanno iniziato a offrire i propri servizi in termini di backup e ripristino di Kubernetes – Rubrik ne è un buon esempio: consente agli utenti di implementare il vasto set di funzionalità di gestione di Rubrik nel campo delle implementazioni Kubernetes.

Consente la flessibilità in termini di destinazione del ripristino, nonché la protezione degli oggetti Kubernetes e una piattaforma unificata che fornisce approfondimenti e una panoramica dell’intero sistema. Ci sono anche funzioni come l’automatizzazione del backup, il ripristino granulare, la replica delle istantanee e altro ancora. Rubrik può anche lavorare con i Volumi Persistenti ed è in grado di replicare gli spazi dei nomi – offrendole la possibilità di variare quando si tratta di sviluppo e/o test prima della distribuzione.

rubrik kubernetes landing page

Druva

Un’altra variante di tale soluzione è presentata da Druva, che offre una soluzione di backup e ripristino Kubernetes piuttosto semplice ma efficace, con tutte le caratteristiche di base attese – istantanee, backup e ripristino, automatizzazione e alcune funzionalità aggiuntive. Druva può anche ripristinare intere applicazioni all’interno di Kubernetes, con molta mobilità per quanto riguarda la destinazione del ripristino.

Inoltre, Druva supporta più ruoli di amministrazione, può creare copie dei carichi di lavoro per la risoluzione dei problemi ed eseguire il backup di aree specifiche come i namespace o i gruppi di app. Vi è anche una varietà di opzioni di conservazione, una protezione completa dei dati Kubernetes, il supporto per Amazon EC2 e EKS (carichi di lavoro container personalizzati).

druva kubernetes landing page

Zerto

Zerto è anche una buona scelta se sta cercando una piattaforma di gestione del backup multifunzionale con supporto nativo di Kubernetes. Offre tutto ciò che si può desiderare da una moderna soluzione di backup e ripristino Kubernetes – CDP (protezione continua dei dati), replica dei dati tramite snapshot e un vendor lock-in minimo, grazie al fatto che Zerto supporta tutte le piattaforme Kubernetes in ambito aziendale.

Zerto offre anche la protezione dei dati come una delle strategie principali fin dal primo giorno, offrendo alle applicazioni la possibilità di essere generate con protezione fin dall’inizio. Zerto dispone anche di molte funzionalità di automazione, è in grado di fornire approfondimenti estesi e può lavorare con diversi archivi cloud contemporaneamente.

zerto kubernetes landing page

Come è chiaro in questo blog, il tema di Kubernetes è ancora relativamente nuovo e il mercato sta ancora cercando di recuperare l’elenco completo di funzionalità che qualsiasi sistema basato su Kubernetes richiede fin dall’inizio. L’intera natura di Kubernetes rende le app un animale molto diverso da quello che erano prima, e questo ci porta all’attuale elenco di soluzioni che eccellono in una cosa e faticano a recuperare nell’altra.

Chiaramente, Kubernetes è un’area tecnologica in rapida crescita, quindi è sicuro che presto arriveranno altre soluzioni, e quelle attuali probabilmente diventeranno ancora migliori di quelle attuali. Un esempio di una nuova e potente soluzione Kubernetes è rappresentato da Bacula Enterprise.

La soluzione di backup Kubernetes di Bacula Enterprise

La natura stessa degli ambienti Kubernetes li rende allo stesso tempo molto dinamici e potenzialmente complessi. Il backup di un cluster Kubernetes non deve aggiungere inutilmente complessità. E naturalmente è solitamente importante – se non critico – che gli Amministratori di Sistema e altro personale IT abbiano un controllo centralizzato sul sistema completo di backup e ripristino dell’intera organizzazione, compresi gli ambienti Kubernetes. In questo modo, fattori come conformità, gestibilità, velocità, efficienza e continuità aziendale diventano molto più realistici. Allo stesso tempo, l’approccio agile dei team di sviluppo non deve essere compromesso in alcun modo.

Bacula Enterprise è unico in questo spazio, perché è una soluzione aziendale completa per ambienti IT completi (non solo Kubernetes) che offre anche un backup e un ripristino di Kubernetes integrato in modo nativo, compresi cluster multipli, sia che le applicazioni o i dati risiedano all’esterno o all’interno di un cluster specifico. Il reparto operativo di ogni azienda riconosce la necessità di avere una strategia di ripristino adeguata quando si tratta di ripristino di cluster, aggiornamenti e altre situazioni. Un cluster che si trova in uno stato irrecuperabile può essere riportato allo stato stabile con Bacula se sia i file di configurazione che i volumi persistenti del cluster sono stati sottoposti a un backup corretto in precedenza.

Un altro modo per mostrare i metodi di lavoro di Bacula è l’immagine qui sotto:

bacula enterprise kubernetes module schematic

Uno dei principali vantaggi del modulo Kubernetes di Bacula è la possibilità di eseguire il backup di varie risorse Kubernetes, tra cui:

  • Baccelli;
  • Servizi;
  • Distribuzioni;
  • Volumi persistenti.

Caratteristiche del modulo Kubernetes di Bacula Enterprise

Il modo in cui funziona questo modulo è che la soluzione stessa non fa parte dell’ambiente Kubernetes, ma accede invece ai dati rilevanti all’interno del cluster tramite pod Bacula che sono collegati a singoli nodi Kubernetes in un cluster. La distribuzione di questi pod è automatica e funziona in base alle esigenze.

Il modulo di backup di Kubernetes include anche altre funzioni:

  • Backup e ripristino di Kubernetes per i volumi persistenti;
  • Ripristino di una singola risorsa di configurazione Kubernetes;
  • La capacità di ripristinare i file di configurazione e/o i dati dai volumi persistenti alla directory locale;
  • La possibilità di eseguire il backup della configurazione delle risorse dei cluster Kubernetes.

Vale anche la pena di notare che Bacula supporta facilmente più piattaforme di cloud storage contemporaneamente, tra cui AWS, Google, Glacier, Oracle Cloud e Azure, a livello di integrazione nativa. Le funzionalità di cloud ibrido sono quindi integrate, tra cui la gestione avanzata del cloud e le funzionalità di caching automatizzato del cloud, consentendo una facile integrazione dei servizi di cloud pubblico o privato per supportare varie attività.

La flessibilità della soluzione è particolarmente importante al giorno d’oggi, con molte aziende e imprese che stanno diventando sempre più complesse in termini di famiglie di hypervisor e container diversi. Allo stesso tempo, questo aumenta in modo significativo la richiesta di flessibilità del fornitore per tutti i fornitori di database. Le capacità di Bacula in questo senso sono sostanzialmente elevate, in quanto combina il suo ampio elenco di compatibilità con varie tecnologie per raggiungere standard di flessibilità particolarmente elevati senza vincolarsi a un unico fornitore.

La complessità sempre crescente di diversi aspetti del lavoro di qualsiasi organizzazione è in continuo aumento, e il più delle volte è più facile ed economico utilizzare un’unica soluzione per l’intero ambiente IT, e non diverse soluzioni contemporaneamente. Bacula è progettato per fare esattamente questo, ed è anche in grado di fornire sia un’interfaccia tradizionale basata sul web per le sue esigenze di configurazione, sia il classico controllo da linea di comando. Queste due interfacce possono anche essere utilizzate contemporaneamente.

Il plugin di backup Kubernetes di Bacula consente due tipi di destinazione principali per le operazioni di ripristino:

  • Ripristinare in una directory locale;
  • Ripristino nel cluster.

I backup regolari e/o automatizzati sono altamente raccomandati per garantire il miglior ambiente di backup e ripristino possibile per i container. Testare i backup di tanto in tanto dovrebbe essere obbligatorio anche per il suo Amministratore di Sistema. Nella prossima immagine, vedrà una parte del processo di ripristino, vale a dire la parte Selezione ripristino, in cui può scegliere quali file e/o directory desidera ripristinare:

restore selection area

Un’altra parte del processo di ripristino che incontrerà è la pagina delle opzioni di ripristino avanzate, che si presenta così:

advanced restore options

Qui può specificare diverse opzioni, come il formato di uscita, il percorso del file di configurazione KBS, la porta dell’endpoint e altro ancora.

È anche facile controllare l’intero processo di ripristino al termine della personalizzazione, grazie alla pagina di registro del lavoro di ripristino che scrive ogni azione una per una:

restore log

Un’altra capacità importante del modulo Kubernetes è la funzione Plugin Listing, che offre molte informazioni utili sulle risorse Kubernetes disponibili, compresi gli spazi dei nomi, i volumi persistenti e così via. Per farlo, il modulo utilizza un comando speciale .ls con un parametro specifico plugin=<plugin>.

Il modulo Kubernetes di Bacula offre una serie di funzionalità, alcune delle quali sono:

  • Ridistribuzione rapida ed efficiente delle risorse del cluster;
  • Salvaguardia dello stato del clusterubernetes;
  • Salvataggio delle configurazioni da utilizzare in altre operazioni;
  • Mantenere le configurazioni modificate il più possibile sicure e ripristinare lo stesso identico stato di prima.

Sebbene questo accada spesso, si raccomanda vivamente di evitare di pagare il suo fornitore in base al volume dei dati. Non ha senso essere tenuti in ostaggio, ora o in futuro, da un fornitore pronto ad approfittare della sua organizzazione in questo modo. Invece, osservi attentamente i modelli di licenza di Bacula Systems, che evita ai suoi clienti di esporsi ai costi di crescita dei dati, rendendo al contempo molto più facile per i dipartimenti di approvvigionamento dei clienti prevedere i costi futuri. Questo approccio più ragionevole di Bacula deriva dalle sue radici open source e risuona bene in un ambiente DevOps.

Velero & Bacula Enterprise: Qual è la differenza?

Questo non significa che non esistano altre soluzioni sul mercato, sia premium che gratuite. Ad esempio, Velero.

Velero (precedentemente chiamato Heptio Ark) è una soluzione gratuita open-source di backup e ripristino che si concentra principalmente sul lavoro con cluster Kubernetes / volumi persistenti. Ha la capacità di lavorare con diverse piattaforme cloud tramite plugin specifici, e può scegliere se eseguirlo in sede o all’interno della piattaforma cloud pubblica di sua scelta.

I tre principali campi di destinazione delle capacità di Velero sono:

  • Ripetizione del cluster di produzione a scopo di test o sviluppo;
  • Capacità generali di backup e ripristino per i cluster Kubernetes;
  • Funzione di migrazione del cluster.

L’idea di come funziona Velero si basa su due parti principali: un server che lavora all’interno del suo cluster e un client locale rappresentato da una linea di comando per le sue esigenze operative. È anche piuttosto unico nel modo in cui funziona con i cluster Kubernetes.

Il modo in cui funziona è che l’API di Kubernetes viene utilizzata per acquisire lo stato specifico dei cluster ed eseguire il processo di ripristino quando necessario. Questo è diverso da quello che fa la maggior parte delle altre soluzioni, che accedono direttamente ai database etcd di Kubernetes e interagiscono con i dati in questione attraverso di essi (Bacula Pods ne è un esempio). I vantaggi di fare tutto tramite API sono i seguenti:

  • Anche se le risorse esposte tramite API sono archiviate in un database separato, è comunque possibile eseguire il backup e/o il ripristino in modo rapido ed efficiente;
  • Il backup può essere in qualche modo selettivo, catturando sottoinsiemi specifici delle risorse di un cluster, filtrati per tipo di risorsa, spazio dei nomi, ecc.
  • Non è raro che gli utenti di offerte Kubernetes gestite non abbiano accesso al database etcd sottostante, il che rende i backup e i ripristini diretti praticamente impossibili e costringe a ricorrere a vari workaround.

Possiamo anche confrontare Velero con uno degli esempi premium di soluzioni di backup Kubernetes dell’elenco precedente, come Kasten K10. Il primo punto di confronto tra Velero e Kasten è il fatto che uno dei due è una soluzione open source gratuita, mentre l’altro è una soluzione premium a pagamento.

Entrambi i sistemi presentano un pacchetto regolare di vantaggi e benefici: Velero è inizialmente più accessibile grazie alla gratuità, ma presenta anche un livello di ingresso molto più elevato in termini di conoscenze necessarie, unito a un’assistenza meno rapida e precisa per i clienti rispetto alle soluzioni a pagamento.

Kasten, d’altra parte, costerebbe probabilmente più di Velero da configurare (tutto ciò che è superiore a zero dollari è “di più”!), ma avrebbe il vantaggio di un supporto live 24/7 e quindi una soglia di conoscenza inferiore per configurare tutto correttamente. In quanto soluzione cosiddetta “premium”, Kasten ha anche più funzioni rispetto a Velero, come il già citato disaster recovery (anche se non è una soluzione perfetta, è comunque presente se ne ha bisogno).

Il tema della scelta tra Velero e Kasten si riduce per lo più al caso specifico dell’azienda in questione, con due degli ostacoli più grandi che sono il prezzo della soluzione e la scala su cui deve lavorare, includendo tutti i tipi di funzionalità popolari e/o non comuni.

Quando si tratta di fare un confronto diretto tra Velero e Bacula, si può dire che ognuno ha i suoi vantaggi e benefici.

Bacula è molto più completo in termini di soluzione di backup e ripristino a livello aziendale, e offre una gamma particolarmente ampia di funzioni e tecnologie che ci si aspetta da una soluzione di livello aziendale e pesante. Pertanto, Bacula offre una soluzione completa di backup su una sola piattaforma per le aziende medio-grandi e grandi. Bacula dispone anche di ‘BWeb’, un’interfaccia web completa per le numerose funzioni che offre. Bacula è probabilmente la soluzione che un Direttore IT sceglierebbe quando ha bisogno di eseguire il backup di ambienti IT complessi e mutevoli, utilizzando un’unica piattaforma moderna.

Velero, invece, è specifico nel senso che non cerca di coprire ogni aspetto del backup di tutte le applicazioni, i dati e i tipi di storage, ma si concentra solo sul lavoro con Kubernetes. Alcuni utenti potrebbero trovarlo più interessante rispetto a una soluzione all-in-one. Poi c’è anche l’approccio unico che Velero adotta per lavorare con i dati e i backup – tramite API. E l’ultimo, ma sicuramente non il meno importante: è gratuito e open source. Nonostante tutti i vantaggi di Bacula, è stato progettato per essere una soluzione di fascia alta per le medie e grandi imprese e questo, ovviamente, non è rappresentativo di tutti gli utenti di Kubernetes.

Informazioni sull'autore
Rob Morrison
Rob Morrison è il direttore marketing di Bacula Systems. Ha iniziato la sua carriera nel marketing IT con Silicon Graphics in Svizzera, ottenendo ottimi risultati in vari ruoli di gestione del marketing per quasi 10 anni. Nei 10 anni successivi, Rob ha ricoperto anche diverse posizioni di gestione del marketing in JBoss, Red Hat e Pentaho, assicurando la crescita della quota di mercato di queste note aziende. Si è laureato all'Università di Plymouth e ha conseguito una laurea ad honorem in Digital Media and Communications e ha completato un programma di studi all'estero.
Lascia un commento

Il suo indirizzo e-mail non sarà pubblicato. I campi obbligatori sono contrassegnati da *