Sempre più aziende avviano oggi aggiornamenti applicativi con il nuovo software cloud-ready a microservizi con lo scopo di velocizzare i deploy attraverso l’impiego dei container software e dell’orchestratore Kubernetes. Progetti portati avanti senza lo studio degli aspetti che riguardano la gestione e la salvaguardia dei dati. Parliamo, in particolare, delle operazioni di backup-restore, del disaster recovery, degli spostamenti di applicazioni tra sistemi on-premise e servizi di cloud, oppure da un cloud all’altro, per esempio, per incrementare le prestazioni o testare gli aggiornamenti applicativi per essere certi che funzionino in produzione. In tutti questi casi, il livello d’astrazione dal livello fisico introdotto con l’uso dei container e di Kubernetes rendono complicati e inefficienti gli approcci di salvaguardia di tipo tradizionale.
Come cambia il backup delle applicazioni a microservizi
Le applicazioni a microservizi cambiano in profondità il software e gli ambienti d’esecuzione, facendo nascere nuove esigenze in tema di salvaguardia di dati e applicazioni. “Un aspetto che viene spesso trascurato – spiega Salvatore – è la necessità di aggiornare la salvaguardia con soluzioni che siano nativamente integrate con Kubernetes”. Se, con le applicazioni monolitiche, le operazioni di backup/restore possono avere come riferimento la macchina fisica o virtuale che le ospita, con quelle a microservizi viene meno la corrispondenza, dal momento che i componenti (decine o anche centinaia per ogni singola applicazione) sono indipendenti e possono essere spostati dall’orchestratore su sistemi diversi, sia on premise sia in cloud. Con i microservizi diventa inoltre importante avere un controllo più granulare delle operazioni, per poter limitare backup e ripristino ai soli componenti che ne hanno necessità e non più all’intera applicazione. Cambia inoltre il modo di gestire la salvaguardia dello stato dinamico dell’applicazione. Se nel mondo tradizionale questa funzione può essere realizzata con agenti o funzioni API specifiche dell’applicazione che chiudono i buffer e salvano su disco lo stato, con applicazioni cloud-ready fatte da decine o centinaia di microservizi stateful e stateless (a seconda che gestiscano oppure no la persistenza dei dati) la salvaguardia delle informazioni di stato si fa molto più complessa.
Come funziona la salvaguardia di dati e applicazioni nel mondo cloud-ready
Per la salvaguardia di una moderna applicazione a microservizi non basta salvare dati sui volumi di storage, serve avere accesso alle definizioni di come è costituita l’applicazione e alle modalità con cui è stato fatto il deploy. “Con Kubernetes il deploy delle applicazioni è dinamico – spiega Salvatore –, anche mappando il nodo che esegue i container su una virtual machine non potremmo mai sapere dove verrà distribuito dall’orchestratore. È necessario quindi il discovering dei componenti dell’applicazione attraverso le API di Kubernetes, accedere all’immagine Docker, alla configurazione dell’ambiente, ai ConfigMaps e alle altre informazioni che nell’ambiente accompagnano l’applicazione, dichiarando le modalità di deploy”, precisa Salvatore. Tra queste informazioni ci sono anche i Secrets che proteggono le credenziali d’accesso a database e ad altri servizi: “Informazioni che non è opportuno salvare in chiaro, ma solo attraverso la crittografia nativa dell’orchestratore”. Nella gestione di un’infrastruttura che evolve verso i concetti dell’IT software-defined, è importante salvaguardare anche lo stato delle pipeline di continuous integration e deploy (CI/CD) relative alla release dell’applicazione, sfruttare i metadati messi a disposizione da strumenti come Helm. “In mancanza, verrebbe meno la capacità di fare il discovery delle applicazioni complesse e si avrebbero forti limitazioni nelle capacità di ripristino”, precisa Salvatore.
Come affidare a Kubernetes le operazioni di salvaguardia e ripristino
Kubernetes gestisce i volumi di storage in modo molto efficace attraverso API che separano la visione, ad alto livello, dello sviluppatore da quella di chi gestisce i sistemi. “Con le API di Kubernetes lo sviluppatore dichiara, come oggetto, uno storage con determinate caratteristiche senza preoccuparsi di come è realizzato – spiega Salvatore –. Un’altra API permette all’amministratore IT di predisporre le risorse”. Il livello di astrazione di Kubernetes offre il vantaggio di non doversi preoccupare d’interfacciare nativamente i provider di storage”.
Se un cluster smette di funzionare si può effettuare il ripristino, recuperando da un backup snapshot il database ETCD dove Kubernetes mantiene in tempo reale lo stato completo del cluster e delle risorse impiegate e quindi riavviare i deploy. Una soluzione adatta per gli scopi di disaster recovery dell’ambiente, ma non delle applicazioni. Per fortuna Kubernetes sa gestire sia le componenti stateless sia stateful come, per esempio, ambienti database e di event streaming, permettendo di fare salvaguardia in diversi modi. Il primo, passa attraverso l’uso dell’interfaccia CSI (container storage interface) per effettuare snapshot di container con applicazioni che richiedono storage persistente. Un altro è richiamare i tool del software ospitato, per esempio un database, per congelare lo stato prima del dump o dello snapshot, in modo da avere dati consistenti sul disco. L’ulteriore opzione è quella di usare un framework specifico per coordinare le operazioni sull’intero stack di servizi che supporta l’applicazione. “Non serve inventare l’acqua calda – continua Salvatore –, esistono framework open source, come Kanister e altri, adatti a gestire i componenti di un’applicazione complessa e distribuita”. Questi strumenti consentono di definire i meccanismi di backup e di dichiararli assieme all’applicazione: “In questo modo avremo affidato a Kubernetes il compito di occuparsi delle operazioni”, conclude Salvatore.
