DR per i servizi PaaS

Il disaster recovery per i servizi IaaS (VM) prevede in genere Azure Site Recovery per replicare l'intero sistema operativo e i dischi dati in una regione secondaria. I servizi PaaS utilizzano modelli DR diversi, perché l'infrastruttura sottostante è gestita da Microsoft. Per PaaS, la DR viene solitamente configurata a livello di dati: i dati vengono replicati in una regione secondaria, mentre la piattaforma viene avviata automaticamente.

Azure SQL Database offre disponibilità elevata integrata a livello di zona all'interno di una singola regione. Per la DR tra regioni, mette a disposizione due funzionalità principali: replica geografica attiva (database secondari leggibili in un massimo di altre quattro regioni) e gruppi di failover automatico (failover automatizzato con un singolo endpoint listener). Queste funzionalità vengono configurate a livello di database o server senza dover usare Azure Site Recovery.

I gruppi di failover automatico aggiungono l'automazione e un singolo endpoint di connessione alla replica geografica. Configuri un gruppo nel server primario, aggiunga il server secondario e definisca un periodo di tolleranza: il tempo che Azure attende per consentire il ripristino del primario prima di attivare il failover automatico. Le applicazioni si connettono all'endpoint listener (ad esempio mygroup.database.windows.net) e vengono reindirizzate automaticamente dopo il failover, senza modificare le stringhe di connessione.

La replica geografica di Azure SQL Database è asincrona: le transazioni vengono sottoposte a commit nel database primario e quindi replicate in quello secondario. Ciò comporta un piccolo ritardo di replica, in genere inferiore a 5 secondi in condizioni normali. Nella maggior parte degli scenari, l'RPO per la replica geografica SQL è quindi di circa 5 secondi, il che la rende adatta ai carichi di lavoro Tier 1 e Tier 2 che richiedono una perdita di dati molto ridotta.

Tutti i livelli di Azure SQL Database includono backup automatizzati: backup completi settimanali, backup differenziali ogni 12 ore e backup del log delle transazioni ogni 5-12 minuti. Ciò abilita il ripristino temporizzato (PITR), ovvero il ripristino del database a qualsiasi secondo compreso nel periodo di conservazione (7-35 giorni per Standard/General Purpose, fino a 35 giorni per Business Critical). Il PITR è utile per ripristinare i dati dopo un'eliminazione o una corruzione accidentale.

Azure Cosmos DB con scritture multiregione offre un RPO quasi nullo per le applicazioni globali. Tutte le regioni configurate possono accettare simultaneamente operazioni di scrittura e Cosmos DB sincronizza automaticamente i dati utilizzando il proprio protocollo di replica proprietario. Se una regione si guasta, il traffico viene indirizzato automaticamente verso le regioni rimanenti e integre, senza necessità di un failover manuale, ottenendo un RTO e un RPO prossimi allo zero.

Azure App Service è di per sé stateless (il codice dell'applicazione viene distribuito dal controllo del codice sorgente o da un file ZIP). Per la DR, l'attenzione si concentra sul livello dei dati (database e archiviazione BLOB). App Service può essere ridistribuito rapidamente in una regione secondaria tramite una pipeline CI/CD. Tuttavia, deve assicurarsi che il dominio personalizzato, i certificati TLS e le impostazioni dell'app siano replicati o gestiti tramite script, in modo da poterli ricreare rapidamente nella regione secondaria.

Azure Blob Storage con Geo-Redundant Storage (GRS) replica automaticamente i dati in una regione secondaria distante centinaia di chilometri. I dati vengono replicati in modo asincrono (RPO generalmente inferiore a 15 minuti). Read-Access GRS (RA-GRS) consente di leggere dall'endpoint secondario anche prima dell'attivazione del failover, una funzione utile per i carichi di lavoro di analisi e reporting durante un'interruzione nella regione primaria.

Le Azure Functions sono stateless per progettazione, quindi è facile ridistribuirle. Per la DR, distribuisca la stessa app per funzioni in una regione secondaria e utilizzi Traffic Manager per instradare i trigger HTTP tra le regioni. Per i trigger non HTTP (Service Bus, Event Grid), configuri l'origine dei messaggi affinché distribuisca i messaggi a entrambe le regioni oppure faccia eseguire il polling della stessa origine alla regione secondaria. Lo stato delle funzioni in Durable Functions viene archiviato in Azure Storage: si assicuri che l'account di archiviazione utilizzi GRS.

Utilizzi la geo-replica attiva quando ha bisogno di un controllo granulare, ad esempio per indirizzare il traffico di lettura a una replica secondaria per migliorare le prestazioni o per gestire in modo indipendente più repliche secondarie in aree diverse. Utilizzi i gruppi di failover automatico quando desidera semplicità: un singolo endpoint listener, il failover automatico secondo una pianificazione e l'orchestrazione integrata del processo di failover senza interventi manuali.

Il ripristino di emergenza PaaS è spesso più economico rispetto a quello basato su VM per diversi motivi. La geo-replica di SQL Database addebita solo lo spazio di archiviazione e le risorse di calcolo della replica secondaria; non è necessario pagare la licenza completa del sistema operativo di una VM. Azure Cosmos DB addebita le RU con provisioning in ogni area. Azure Storage GRS aggiunge circa il doppio del costo dello spazio di archiviazione. Al contrario, le VM replicate tramite ASR richiedono costi completi di calcolo, archiviazione e licenze nell'area secondaria.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha appreso che: il ripristino di emergenza PaaS si concentra sul livello dati anziché sulla replica delle VM; i gruppi di failover automatico di Azure SQL forniscono un singolo endpoint listener con failover automatizzato; e le scritture in più aree di Cosmos DB offrono RTO e RPO prossimi allo zero per le applicazioni globali. Nella prossima lezione esamineremo i framework di conformità di Azure e il modello di responsabilità condivisa.