Servizi di backup
Niente fa più paura al personale IT di una perdita di dati. La strategia più efficace per evitare la perdita di dati consiste nell'eseguire il backup di volumi di archiviazione, macchine virtuali, database e altri sistemi che archiviano dati in modo che i dati possano essere ripristinati. I provider di servizi cloud offrono servizi di backup a questo scopo specifico. In generale, questi servizi possono essere usati per eseguire il backup non solo dei dati archiviati in locale, ma anche dei dati archiviati nel cloud e i backup possono essere replicati e distribuiti a livello geografico per evitare gli eventi che causano la perdita di dati in un intero data center o in un'area del mondo.
Il cloud pubblico distribuisce risorse fluide in volumi elevati, costituiti non solo da grandi blocchi di risorse di archiviazione, ma da pool di archiviazione a scalabilità elevata. Sono altrettanto e, in alcuni casi, anche più versatili dei sistemi di archiviazione di backup e delle unità nastro di cui stanno prendendo il posto. Offrono inoltre alle organizzazioni nuove opportunità per implementare ridondanze, failover e reti di sicurezza che molte non avrebbero mai potuto permettersi all'epoca in cui tutti gli asset venivano acquistati senza ricorrere al capitale operativo. Le opzioni di archiviazione nel cloud pubblico svolgono un ruolo di cui i data center hanno sempre avuto estrema necessità, ma che fino a poco tempo fa era stato difficile ottenere.
Servizi di backup basati sul cloud
Ciò che caratterizza i moderni servizi di backup offerti dai provider di servizi cloud pubblico è il modo in cui estendono l'infrastruttura dei clienti. Prima dell'avvento di questi servizi, la tipica strategia di backup di un'organizzazione includeva due livelli: backup di volumi di dati che ospitavano database e backup di immagini di macchine virtuali che ospitavano carichi di lavoro critici. La teoria alla base del backup era che, quando un errore di sistema causa un guasto, tale evento disattiva un server. La linea di condotta immediata diventa quindi quella di ripristinare lo stato del server da un'immagine di backup.
L'infrastruttura basata sul cloud rende obsoleta la vecchia teoria del backup. Nei sistemi moderni i server sono costituiti da software, non da hardware. I server virtuali sono ospitati da un'infrastruttura virtuale basata su hypervisor, ad esempio NSX di VMware, o assemblati da contenitori e ospitati da sistemi operativi virtualizzati. In entrambi i casi, le immagini software dei carichi di lavoro per le applicazioni e i servizi vengono continuamente gestite, aggiornate e protette. I componenti software attivi infatti sono di per sé repliche di questi master sicuri o, per la containerizzazione, i prodotti dei master originali archiviati in repository di contenitori e assemblati automaticamente in base alle esigenze. Un errore hardware che disattiva un nodo server rende semplicemente non disponibili per un certo periodo di tempo i server ospitati da tale nodo. L'infrastruttura reindirizza semplicemente il traffico del nodo e nel frattempo effettua tutti i tentativi possibili per sostituirlo. Il gestore dell'infrastruttura non fa nulla che non sia già stato fatto nel corso della normale amministrazione del sistema.
Come tuttavia rivelerà un'osservazione anche superficiale dei data center moderni, non tutte le infrastrutture moderne sono infrastrutture basate sul cloud. I servizi sono ancora ospitati in computer bare metal in data center locali. Le reti client/server, complete di middleware, sono ancora molte. E in un sistema ibrido, in cui una parte progettata alcuni anni fa è connessa a un'altra parte progettata nel secolo precedente, è necessario archiviare informazioni sufficienti sulla composizione di un sistema in modo che, in caso di emergenza, il sistema possa essere ricostruito, con qualsiasi mezzo pratico, ma rapido, in una nuova località con un impatto minimo sui livelli di servizio. Con le strategie di backup moderne, il cloud pubblico può trovarsi in tale località, anche se i sistemi sottoposti a snapshot si trovavano al di fuori del cloud.
AWS Backup
All'inizio del 2019, Amazon Web Services ha riprogettato il servizio di backup basato sul cloud per gli ambienti di tipo cloud ibrido dei clienti. Alla base del nuovo AWS Backup, la cui console basata sul browser è illustrata nella figura 2, c'è un motore di criteri, non diverso dall'arbitro delle regole per un firewall. Con questo motore, l'amministratore del backup scrive regole che specificano quanto segue:
Per quali risorse di un sistema è necessario il backup
Come eseguire ogni backup e con quale frequenza
Dove archiviare le immagini dei backup
Come monitorare l'integrità delle immagini dei backup e con quale frequenza
Per quanto tempo devono essere conservate le immagini dei backup
In quali circostanze è necessario effettuare il recupero e il ripristino
La procedura completa che comprende tutti i criteri attivi è il piano di backup. In questo caso ogni regola fa riferimento alle risorse all'interno del cloud AWS, per cui è necessario il backup, tramite il valore del tag, ovvero un nome arbitrario assegnato dall'amministratore. Per includere una risorsa, ad esempio un volume EBS (Elastic Block Storage) in un piano di backup, è sufficiente che l'amministratore assegni a tale risorsa un nome di tag che verrà riconosciuto da AWS Backup. In questo modo, non è necessario che l'amministratore o il responsabile di una risorsa AWS usi la console di AWS Backup solo per porre una risorsa sotto la supervisione del responsabile nell'ambito di un piano di backup esistente.
![Figura 2: Console di AWS Backup. [Per gentile concessione di Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Figura 2: Console di AWS Backup. [Per gentile concessione di Amazon]
Le risorse locali possono essere incorporate in un piano di backup tramite AWS Storage Gateway. Ai fini di AWS Backup, Storage Gateway funge da wrapper API per i volumi e i dispositivi di archiviazione fisica, rendendoli accessibili ai servizi AWS.
In origine, Storage Gateway consentiva le sostituzioni degli asset di archiviazione fisica esistenti con le controparti basate sul cloud che usavano la stessa interfaccia. Era ad esempio possibile eseguire il wrapping di un volume iSCSI locale in quello che in AWS si chiama volume memorizzato nella cache. Questo wrapper rende l'archiviazione nel cloud accessibile alle applicazioni locali esistenti senza che i clienti debbano riprogettare tali applicazioni. I dati a cui si accede di frequente possono continuare a essere archiviati nel volume iSCSI come cache, riducendo la quantità di latenza generata. In alternativa, le modifiche recenti al contenuto del volume del gateway possono essere archiviate in locale come snapshot. Storage Gateway supporta anche i volumi archiviati, in cui il dispositivo locale continua a mantenere una copia locale completa del volume, di cui Storage Gateway esegue il mirroring nel cloud. Il nuovo AWS Backup sfrutta lo scambio di ruolo di Storage Gateway con i volumi fisici, trasformando la copia locale nel backup per il volume basato sul cloud, durante l'aggiunta di una console di gestione dei criteri centralizzata, con regole che determinano come devono essere gestite entrambe le repliche.
Ai fini del ripristino di emergenza, uno dei principali vantaggi offerti da un provider di servizi cloud è la possibilità di archiviare rapidamente i dati critici di un'organizzazione in posizioni distanti per ottenere la ridondanza geografica. AWS gestisce i data center cloud nel maggior numero di zone di disponibilità per qualsiasi provider di servizi cloud. Rende nota la capacità nativa per le applicazioni ospitate di effettuare il failover automatico in zone alternative ed estende questa funzionalità alla ridondanza per il backup dei dati. È tuttavia noto che le zone di failover risiedono all'interno della stessa area AWS. In una situazione di emergenza estrema (di cui le compagnie di assicurazione e quindi i responsabili della gestione dei rischi tengono conto), ad esempio un guasto della rete elettrica, è plausibile che si verifichino interruzioni nelle zone di disponibilità adiacenti l'una all'altra.
Uno sviluppatore di software o un operatore IT con esperienza di sviluppo può scrivere criteri personalizzati per il routing con ridondanza geografica specifico di un'organizzazione usando il servizio di routing di base di AWS, Route 53. Questa tecnica richiede tuttavia molto lavoro. Più di recente AWS ha offerto un servizio più accessibile, chiamato AWS Global Accelerator, un altro motore di criteri che gestisce il traffico e indirizza Route 53 dove devono essere ospitati i servizi e lo spazio di archiviazione.1 Global Accelerator può anche essere usato come una sorta di "servizio di bilanciamento su richiesta", che consente la distribuzione di più siti per le applicazioni ospitate (e con esse, i dati critici) tra zone di disponibilità lontane tra loro.
Un altro modo per assicurarsi che i dati di cui è stato eseguito il backup vengano archiviati in un'area sufficientemente distante, come hanno suggerito i tecnici di Amazon, è definire un bucket (contenitore di backup per utilizzo generico di AWS) come destinazione di backup iniziale e quindi replicare tale bucket in una località ridondante in qualsiasi zona di disponibilità designata. AWS offre la replica tra aree come servizio separato.2 Il prezzo del servizio di backup AWS viene calcolato in base al volume, sia per ogni gigabyte archiviato che per ogni gigabyte ripristinato.
Dal punto di vista dell'architettura, AWS Backup è progettato per fungere da mirror per le risorse AWS. Il modo per rendere gli asset locali parte di tale piano è attraverso una sorta di doppia backdoor, prima convertendo tali asset locali in volumi AWS remoti (remoti dal punto di vista di Amazon), quindi creando un'interfaccia di backup con il wrapper per tali asset locali.
Backup di Azure
Backup di Azure consente di eseguire il backup sia delle risorse locali (server e macchine virtuali) che delle risorse ospitate in Azure. Non è progettato per modificare i criteri di backup esistenti nel data center, ma solo per sostituire i dischi locali e le unità nastro con l'archiviazione nel cloud. La posizione basata sul cloud per i file e i volumi in Azure di cui viene eseguito il backup è denominata insieme di credenziali di Servizi di ripristino, la cui console basata sul browser è illustrata nella figura 3. Durante il processo di installazione per questo insieme di credenziali tramite il portale di Azure, l'amministratore scarica e installa l'agente lato client noto come agente di servizi di ripristino Microsoft Azure o "MARS". In Windows Server, MARS viene eseguito come applicazione, in modo molto simile a un componente aggiuntivo System Center. In alternativa, un amministratore può scegliere di usare System Center Data Protection Manager, in cui Servizi di ripristino di Microsoft Azure è già incluso. L'amministratore individua i volumi e i servizi nella rete i cui dati richiedono il backup e Servizi di ripristino di Microsoft Azure distribuisce gli agenti agli indirizzi del server responsabili di tali componenti.
![Figura 3: Console di Insieme di credenziali di Servizi di ripristino di Azure. [Per gentile concessione di Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Figura 3: Console dell'insieme di credenziali di Servizi di ripristino di Azure. [Per gentile concessione di Microsoft]
Il modello di distribuzione di Backup di Azure si basa sugli obiettivi a livello di servizio per il ripristino di emergenza, che forniscono metriche adeguate per determinare quanto tempo può resistere un'organizzazione senza avere accesso al motore del business e quanti dati è accettabile perdere in un evento di emergenza. Questi obiettivi specifici (RPO, RTO e conservazione dei dati) sono illustrati nella prossima lezione sul ripristino di emergenza.
Il tipo di ripristino consentito da Backup di Azure (contrariamente ad Azure Site Recovery, il servizio di ripristino di emergenza di Microsoft) si basa interamente sulla replica dei dati invece che sul ripristino del servizio. Un cliente, ad esempio, può usare Backup di Azure per generare le repliche dei file di immagine delle macchine virtuali (VHD). Il ripristino di un disco rigido virtuale si limita tuttavia a riprodurre ancora una volta il file di immagine archiviato nella risorsa di archiviazione locale e non riavvia il server virtuale basato su tale disco rigido virtuale.
Con Backup di Azure viene addebitato solo il costo per lo spazio di archiviazione utilizzato al mese, senza costi aggiuntivi per i ripristini. Il modello di determinazione dei prezzi per l'archiviazione è associato alle opzioni di ridondanza. Attualmente, Azure offre due opzioni di questo tipo: archiviazione con ridondanza locale, che è meno costosa e replica i dati tre volte all'interno di un data center di Azure, e archiviazione con ridondanza geografica, che replica i dati in un'area secondaria geograficamente distante dall'area primaria.
Backup di Google Cloud Storage
Google offre un'ampia gamma di livelli di archiviazione nel cloud in base alla classe di dati da archiviare, ad esempio file disponibili in modo persistente, archiviazione a blocchi per le immagini di macchine virtuali, archiviazione di oggetti per i video. Non commercializza in modo esplicito un servizio di backup con marchio per nessuno di questi livelli, anche se i servizi di archiviazione possono certamente essere usati, e lo sono, per il backup e il ripristino. Google presume che i backup siano tra i motivi principali per cui un'azienda sceglie di effettuare investimenti considerevoli nell'archiviazione nel cloud.
![Figura 4: Contenuti di un bucket di Google Cloud Storage. [Per gentile concessione di Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Figura 4: Contenuto di un bucket di Google Cloud Storage. [Per gentile concessione di Google]
Come in AWS, in Google il contenitore di archiviazione per utilizzo generico viene chiamato bucket. La figura 4 mostra un passaggio del processo di importazione dei dati da una risorsa di archiviazione locale a un bucket di Google Cloud Storage (GCS). Come il modello di distribuzione di Azure è basato su tre parametri chiave, i parametri chiave di GCS sono:
Prestazioni, che in questo contesto sono sinonimo di disponibilità (rapidità con cui i server risponderanno alla richiesta di lettura dei dati da parte dei clienti)
Conservazione, che ancora una volta indica per quanto tempo il cliente prevede di tenere i dati nel cloud
Modelli di accesso, che sono relativi all'accessibilità (frequenza con cui il cliente prevede di leggere o richiamare i dati archiviati)
Quando inizializza un bucket, il cliente GCS sceglie la classe di archiviazione, che specifica i criteri di replica. Questa scelta determina, quando il bucket inizia a essere usato per i backup, la dispersione dei dati archiviati. GCS offre attualmente tre opzioni di georilevazione:
A livello di area: i dati vengono archiviati in una sola area selezionata del territorio di servizio di Google
In due aree: i dati vengono replicati tra due aree di servizio selezionate
In più aree: i dati vengono distribuiti in modo ridondante tra più aree di servizio
Successivamente, GCS suddivide le classi di archiviazione del bucket in base alla frequenza con cui vi viene eseguito l'accesso:
Standard/A disponibilità elevata: dati che devono essere facilmente accessibili per le applicazioni e gli utenti
Coldline: consente al cliente di utilizzare parte della tariffa di archiviazione mensile per pagare le operazioni di accesso e trasferimento, per i dati a cui si prevede di accedere solo poche volte all'anno
Nearline: soluzione di fascia medio-alta, per i dati a cui si prevede di accedere circa una volta al mese
L'approccio di Google per la vendita dell'infrastruttura cloud alle aziende consiste nel presentare i servizi come un tipo di appliance che non si vede. In questo senso, offrire come servizi separati l'appliance in sé e la possibilità di usarla può essere una doppia fatica per Google, come lo sarebbe vendere un forno e anche un abbonamento per poter cucinare, come valore aggiunto.
In questo modo, l'organizzazione del cliente GCS seleziona l'infrastruttura necessaria per i processi che intende eseguire e personalizza le impostazioni di tale infrastruttura, come le funzionalità di un'appliance. Come AWS e Azure, Google offre un'appliance montata su rack per i data center allo scopo preciso di velocizzare il passaggio dall'archiviazione locale all'archiviazione nel cloud. Tali funzionalità possono quindi essere perfezionate nel tempo in base a come cambia l'uso della risorsa di archiviazione. Si supponga, ad esempio, che una società di produzione video abbia bisogno di quantità elevate di spazio di archiviazione di backup per le versioni di un film in lavorazione. Durante il processo di modifica, è possibile che le copie vengano recuperate abbastanza spesso, quindi il cliente potrebbe impostare il bucket sull'archiviazione standard a livello di area. Una volta che il video è stato completato e distribuito al pubblico, potrebbe essere necessario avere le copie a portata di mano per un altro anno, anche se non si prevede di accedervi spesso. In tal caso, il bucket standard può essere trasferito a un bucket Coldline con due aree per ragioni di archiviazione e di sicurezza.
Riferimenti
Amazon Web Services, Inc. Traffic management with AWS Global Accelerator (Gestione del traffico con AWS Global Accelerator)https://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/.
Amazon Web Services, Inc. Panoramica della configurazione della replicahttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html.