Il panorama del cloud-native è in rapida evoluzione: si prevede che entro il 2025 l’85% delle organizzazioni a livello globale utilizzerà i container in produzione¹. Per continuare a raggiungere gli obiettivi aziendali, migliorando al contempo l’agilità aziendale e ottimizzando le operazioni, è necessaria una soluzione di gestione dei dati olistica e completa per l’intero patrimonio di dati.
Commvault è sempre stata all’avanguardia nella protezione delle nuove tecnologie, e i container e Kubernetes non fanno eccezione. Abbiamo sviluppato un ampio supporto per la protezione delle applicazioni in esecuzione su un cluster Kubernetes e dei relativi dati. Sono supportate tutte le distribuzioni Kubernetes certificate dalla CNCF (Cloud Native Computing Foundation) e, tramite il framework CSI (Container Storage Interface), supportiamo anche un’ampia gamma di provider di storage su Kubernetes, garantendo una protezione completa dei dati cloud-native, gestita con la semplicità di un’unica soluzione di gestione dei dati.
In questa nuova versione introduciamo due nuove funzionalità chiave per la protezione dei dati in Kubernetes:
- Protezione completa a livello di cluster e di namespace.
- Protezione di ETCD.
Riepilogo
Commvault consente agli utenti di integrare facilmente un cluster Kubernetes nel Commvault Command Center™, ovvero la piattaforma unica che soddisfa tutte le esigenze relative alla protezione, alla gestione e al ciclo di vita dei dati.
Commvault definisce un’applicazione Kubernetes come qualsiasi entità che sia un pod o un insieme di pod, ovvero: Deployment, ReplicaSet, StatefulSet ecc., nonché i relativi componenti associati, come desumibile dai file YAML delle applicazioni.
Per spiegare meglio il concetto, quando analizziamo un’applicazione come un Deployment, esaminiamo le sue specifiche di configurazione e individuiamo eventuali PVC (Persistent Volume Claims), Secret, ConfigMap e altre entità associate. Tutti questi elementi insieme costituiscono un’applicazione.
Un utente può cercare le applicazioni all’interno di un cluster integrato, selezionarle e raggrupparle in un “Gruppo di applicazioni” in base agli SLA (Accordi sul livello di servizio) relativi al backup, alle esigenze di conservazione o a qualsiasi altro criterio.
Gli utenti possono aggiungere applicazioni ai gruppi di applicazioni in diversi modi:
- Sfoglia e seleziona tutte le applicazioni presenti in uno o più spazi dei nomi.
- Selezionare applicazioni specifiche.
- Utilizzare regole di individuazione dinamica: ad esempio, selezionare le applicazioni che corrispondono a un determinato selettore di etichetta o nome, ecc.
Il rilevamento dinamico è particolarmente utile nei casi in cui un amministratore dei backup possa chiedere ai team DevOps di impostare selettori di etichetta sulle proprie applicazioni, ottenendo così la garanzia di specifici SLA (Accordi sul livello di servizio) in materia di protezione.
I processi di backup vengono eseguiti a livello di gruppo di applicazioni e utilizzano le regole relative ai contenuti per individuare, in fase di esecuzione, le applicazioni esistenti e quelle appena create, insieme alle relative risorse presenti nel cluster, ed eseguire i backup. Il backup dei PVC viene effettuato tramite CSI, se disponibile; in alternativa, se CSI non è disponibile, Commvault può collegarsi direttamente ai PVC utilizzando la semantica ReadMany.
Uno schema che illustra come avviene il tutto.
Con Commvault, il ripristino di un’applicazione o dei relativi dati può essere effettuato a diversi livelli di granularità:
- Ripristino a livello di applicazione: è possibile ripristinare un’intera applicazione, insieme alle risorse e ai dati ad essa associati, in un’unica operazione.
- File dell’applicazione: i dati di un’applicazione (o parti di essi) presenti sui PVC possono essere ripristinati in modo frammentario senza dover ripristinare l’intera applicazione.
- File di configurazione delle applicazioni: i file di configurazione che costituiscono un’applicazione possono essere ripristinati come file, in modo che l’utente possa modificarli prima di applicarli al cluster.
Miglioramenti
È giunto il momento di parlare delle nuove ed entusiasmanti funzionalità, che garantiscono una protezione completa di Kubernetes e sono incluse nella versione 2022E della piattaforma.
1. Protezione completa del cluster
Con questa funzionalità abbiamo aggiunto un pulsante di facile utilizzo per l’amministratore del backup: “Esegui il backup di tutto ciò che si trova sul cluster, per favore”. Grazie mille!
Se configurata in questo modo, vengono rilevati tutti gli elementi presenti nel cluster, comprese le risorse a livello di cluster.
Inoltre, vengono inclusi automaticamente anche gli spazi dei nomi individuati per la prima volta al momento del backup.
Gli amministratori dei backup non devono più selezionare singoli spazi dei nomi o applicazioni all’interno di uno spazio dei nomi affinché siano protetti integralmente.
2. Protezione a livello di namespace
Oltre a un intero cluster, gli utenti possono ora scegliere di eseguire il backup di un intero namespace, ovvero delle applicazioni (e delle relative risorse) e di tutte le risorse non referenziate all’interno del namespace (che chiamiamo “orfane”).
Inoltre, gli utenti possono ora ripristinare gli spazi dei nomi nella loro interezza, pur mantenendo le varie opzioni di ripristino granulare illustrate in precedenza.
3. Protezione di etcd.
etcd è un database distribuito e replicato che Kubernetes utilizza per memorizzare la configurazione del cluster. L’immagine qui sotto illustra l’utilizzo di etcd in un tipico cluster Kubernetes.
Ogni nodo del piano di controllo dispone di una replica/copia di etcd.
La perdita o il danneggiamento di queste copie può mandare all’aria la giornata (o la settimana) di un amministratore di Kubernetes.
Poiché etcd è replicato tra i nodi master di un cluster Kubernetes, le soluzioni tradizionali cercano di proteggere etcd proteggendo i nodi master stessi. Ciò avviene spesso implementando soluzioni su quei nodi del cluster per proteggere etcd a livello locale. Si tratta di un approccio, nel migliore dei casi, poco pratico e macchinoso, poiché separa la protezione delle applicazioni in esecuzione sul cluster dalla protezione dello stato del cluster in due meccanismi molto diversi tra loro. La protezione dello stato delle applicazioni e quella dello stato del cluster vanno di pari passo e separarle può portare a incongruenze, specialmente durante il ripristino a seguito di un disastro.
Commvault integra ora perfettamente la protezione di etcd, insieme alla protezione delle applicazioni e dell’intero cluster, nel Command Center. È sufficiente che l’utente attivi un’opzione sul cluster per proteggere etcd e selezioni uno SLA. Tutto qui! Davvero! (Vedi l’immagine qui sotto)
Grazie a questi miglioramenti abbiamo sviluppato una soluzione completa e olistica per le vostre esigenze di protezione dei dati su Kubernetes e l’abbiamo integrata nel nostro Commvault Command Center, consentendovi di semplificare la gestione dell’intero patrimonio di dati da un’unica interfaccia. Non c’è da stupirsi che Commvault continui a distinguersi in questo settore.
Riferimento
1 – Forbes – Guida al monitoraggio dei container per i dirigenti (CxO)
