Eseguire il ripristino dopo un'interruzione di servizio a livello di area

Articolo
03/21/2023

Dal punto di vista fisico e logico, Azure è suddiviso in unità chiamate aree. Un'area è costituita da uno o più data center che si trovano in posizioni molto vicine. Molti servizi e aree supportano anche le zone di disponibilità, che possono essere usate per offrire maggiore resilienza contro le interruzioni in un singolo data center. Prendere in considerazione l'uso di aree con zone di disponibilità per migliorare la disponibilità della soluzione.

In rari casi, è possibile che le strutture in un'intera zona o area di disponibilità diventino inaccessibili, ad esempio a causa di errori di rete. Oppure, le strutture possono essere perse completamente, ad esempio a causa di una calamità naturale. Azure include funzionalità per la creazione di applicazioni distribuite tra zone e aree. Questa distribuzione riduce al minimo la possibilità che un errore che si verifica in una zona o area possa interessarne altre.

Servizi cloud

Gestione delle risorse

È possibile distribuire le istanze di calcolo tra aree creando un servizio cloud separato in ogni area di destinazione e quindi pubblicando il pacchetto di distribuzione in ogni servizio cloud. Tuttavia, la distribuzione del traffico tra servizi cloud in aree diverse deve essere implementata dallo sviluppatore dell'applicazione o con un servizio di gestione del traffico.

Determinare il numero di istanze del ruolo di riserva da distribuire in anticipo per il ripristino di emergenza è un aspetto importante della pianificazione della capacità. La presenza di una distribuzione secondaria completa assicura che la capacità sia già disponibile quando necessario; i costi tuttavia raddoppiano. Un modello comune consiste nell'avere una piccola distribuzione secondaria sufficiente a eseguire i servizi critici. Questa piccola distribuzione secondaria è un'opzione consigliabile, sia per la capacità di riserva, sia per verificare la configurazione dell'ambiente secondario.

Nota

La quota di sottoscrizione non è una garanzia di capacità. La quota è semplicemente un limite di credito. Per garantire la capacità è necessario definire il numero di ruoli nel modello del servizio e distribuire i ruoli.

Bilanciamento del carico

Per bilanciare il carico del traffico tra le aree è necessario usare una soluzione di gestione del traffico. Azure offre Gestione traffico di Azure. È anche possibile usufruire di servizi di terze parti che offrono funzionalità di gestione del traffico simili.

Strategie

Sono disponibili molte strategie alternative per implementare il calcolo distribuito in aree diverse. Queste strategie devono essere adattate agli specifici requisiti aziendali e ai casi di ciascuna applicazione. Gli approcci possono essere in generale suddivisi nelle categorie seguenti:

Ridistribuire in caso di emergenza: in questo approccio, l'applicazione viene ridistribuita da zero al momento dell'emergenza. Questa opzione è appropriata per le applicazioni non critiche che non richiedono un tempo di ripristino garantito.
Riserva ad accesso frequente (Attivo/Passivo): viene creato un servizio ospitato secondario in un'area alternativa e i ruoli vengono distribuiti per garantire una capacità minima. Tuttavia, i ruoli non ricevono il traffico di produzione. Questo approccio è utile per le applicazioni che non sono state progettate per distribuire il traffico tra le aree.
Riserva a caldo (attiva/attiva): l'applicazione è progettata per ricevere il carico di produzione in più aree. I servizi cloud di ogni area possono essere configurati per una capacità superiore a quella richiesta per scopi di ripristino di emergenza. In alternativa è possibile aumentare il numero di istanze dei servizi cloud in base alle esigenze al momento di un'emergenza e di un failover. Questo approccio richiede un investimento sostanziale nella progettazione dell'applicazione, ma presenta vantaggi significativi. I vantaggi includono tempo di ripristino garantito e ridotto, test continuo di tutti i percorsi di ripristino e utilizzo efficiente della capacità.

La descrizione completa della progettazione distribuita non rientra nell'ambito di questo documento. Per altre informazioni, vedere Ripristino di emergenza e disponibilità elevata per le app Azure licazioni.

Macchine virtuali

Il ripristino delle macchine virtuali dell'infrastruttura distribuita come servizio (IaaS) è simile al ripristino del calcolo delle piattaforme distribuite come servizio (PaaS) sotto molti aspetti. Esistono tuttavia differenze importanti perché una macchina virtuale IaaS è costituita sia dalla macchina virtuale che dal disco della macchina virtuale.

Usare Backup di Azure per creare backup tra le aree coerenti con l'applicazione. Backup di Azure consente ai clienti di creare backup coerenti con l'applicazione di più dischi di macchine virtuali e di supportare la replica del backup tra le aree. Questa operazione viene eseguita optando per la replica geografica dell'insieme di credenziali di backup al momento della creazione. La replica dell'insieme di credenziali di backup deve essere configurata al momento della creazione. Non può essere impostata in un secondo momento. In caso di perdita di un'area, Microsoft rende disponibili i backup ai clienti. I clienti possono eseguire il ripristino da uno dei punti di ripristino configurati.
Separare i dischi dati dal disco del sistema operativo. Una considerazione importante per le macchine virtuali IaaS è l'impossibilità di modificare il disco del sistema operativo senza creare di nuovo la macchina virtuale. Ciò non costituisce un problema se la strategia di ripristino prevede la ridistribuzione dopo l'emergenza. Può tuttavia rappresentare un problema se si usa l'approccio Warm Spare per la capacità di riserva. Per implementare correttamente questo approccio è necessario che il disco del sistema operativo sia distribuito sulle località primarie e secondarie e che i dati dell'applicazione siano archiviati in un'unità separata. Usare se possibile una configurazione del sistema operativo standard che possa essere messa a disposizione in entrambe le località. Dopo un failover sarà quindi necessario collegare l'unità di dati alle macchine virtuali IaaS esistenti nel controller di dominio secondario. Usare AzCopy per copiare gli snapshot dei dischi di dati in un sito remoto.
Possono verificarsi problemi di coerenza dopo un failover geografico di più dischi delle macchine virtuali. I dischi delle macchine virtuali vengono implementati come BLOB di archiviazione di Azure e hanno la stessa caratteristica di replica geografica. A meno che non venga usato Backup di Azure , non ci sono garanzie di coerenza tra dischi perché la replica geografica è asincrona e viene eseguita in modo indipendente. I singoli dischi delle macchine virtuali sono garantiti come coerenti per arresto anomalo dopo un failover geografico, ma non come coerenti tra loro. Ciò può causare problemi in alcuni casi, ad esempio in caso di striping del disco.
Usare Azure Site Recovery per replicare le applicazioni tra aree. Con Azure Site Recovery, i clienti non devono preoccuparsi di separare i dischi dati dai dischi del sistema operativo o sui potenziali problemi di coerenza. Azure Site Recovery replica i carichi di lavoro in esecuzione in macchine virtuali e fisiche da un sito primario (locale o in Azure) in una posizione secondaria (in Azure). Quando si verifica un'interruzione nel sito primario del cliente, è possibile attivare un failover per restituire rapidamente il cliente a uno stato operativo. Dopo il ripristino della posizione primaria, i clienti possono quindi eseguire il failback. Possono replicare facilmente usando punti di ripristino con snapshot coerenti con l'applicazione. Questi snapshot acquisiscono i dati del disco, tutti i dati in memoria e tutte le transazioni in-process. Azure Site Recovery consente ai clienti di mantenere gli obiettivi del tempo di ripristino (RTO) e gli obiettivi del punto di ripristino (RPO) entro i limiti dell'organizzazione. I clienti possono anche eseguire facilmente esercitazioni sul ripristino di emergenza senza influire sulle applicazioni nell'ambiente di produzione. Usando i piani di ripristino, i clienti possono sequenziare il failover e il ripristino di applicazioni multilicenza in esecuzione in più macchine virtuali. Possono raggruppare i computer in un piano di ripristino e, facoltativamente, aggiungere script e azioni manuali. I piani di ripristino possono essere integrati con i runbook di Automazione di Azure.

Storage

Ripristino tramite archiviazione con ridondanza geografica di BLOB, tabelle, code e dischi di macchine virtuali

In Azure, BLOB, tabelle, code e dischi delle macchine virtuali sono tutti con replica geografica per impostazione predefinita. Questa operazione viene definita archiviazione con ridondanza geografica.This is referred to as geo-redundant storage (GRS). L'archiviazione con ridondanza geografica replica i dati di archiviazione in un data center associato situato a centinaia di chilometri di distanza all'interno di un'area geografica specifica. L'archiviazione con ridondanza geografica è progettata per offrire un livello di durabilità aggiuntivo in caso di grave emergenza in un data center. Microsoft determina quando si verifica il failover, che è limitato alle emergenze gravi nelle quali la località primaria originale è ritenuta irrecuperabile in un intervallo di tempo ragionevole. In alcuni scenari può trattarsi di più giorni. I dati vengono in genere replicati entro pochi minuti, anche se l'intervallo di sincronizzazione non è ancora coperto da un contratto di servizio.

Se si verifica un failover geografico, non verrà apportata alcuna modifica alla modalità di accesso dell'account (l'URL e la chiave dell'account non cambieranno). L'account di archiviazione si troverà tuttavia in un'area diversa dopo il failover. Ciò potrebbe influire sulle applicazioni che richiedono affinità di area con l'account di archiviazione. Anche per i servizi e le applicazioni che non richiedono un account di archiviazione nello stesso data center, la latenza tra data center potrebbe essere utile per spostare temporaneamente il traffico nell'area di failover. Ciò potrebbe essere un elemento da prendere in considerazione in una strategia globale di ripristino di emergenza.

Oltre al failover automatico offerto dall'archiviazione con ridondanza geografica, Azure ha introdotto un servizio che fornisce l'accesso in lettura alla copia dei dati nella località di archiviazione secondaria. Questa operazione è denominata archiviazione con ridondanza geografica e accesso in lettura.This is called read-access geo-redundant storage (RA-GRS).

Per altre informazioni sull'archiviazione con ridondanza geografica e l'archiviazione con ridondanza geografica e accesso in lettura, vedere Replica di Archiviazione di Azure.

Mapping delle aree di replica geografica

È importante comprendere dove viene eseguita la replica geografica dei dati, per sapere dove distribuire le altre istanze dei dati che richiedono affinità di area con l'archiviazione. Per altre informazioni, vedere Aree abbinate di Azure.

Prezzi della replica geografica

La replica geografica è inclusa nel prezzo corrente di Archiviazione di Azure. Questa operazione è denominata archiviazione con ridondanza geografica.This is called geo-redundant storage (GRS). Se non si intende usufruire della replica geografica dei dati è possibile disabilitare questa funzionalità per l'account. Questa operazione è denominata archiviazione con ridondanza locale e viene addebitata a un prezzo scontato rispetto all'archiviazione con ridondanza geografica.

Determinare se si è verificato un failover geografico

Un eventuale failover geografico verrà indicato nel dashboard per l'integrità dei servizi di Azure. Le applicazioni possono tuttavia implementare una modalità automatica per rilevare questo evento monitorando l'area geografica dell'account di archiviazione. Questa funzionalità può essere usata per attivare altre operazioni di ripristino, ad esempio l'attivazione di risorse di calcolo nell'area geografica in cui è stata trasferita l'archiviazione.

Database

Database SQL

Il database SQL di Azure offre due tipi di ripristino: il ripristino geografico e la replica geografica attiva.

Ripristino geografico

Ripristino geografico è disponibile anche con i database di livello Basic, Standard e Premium. È l'opzione di ripristino predefinita quando il database non è disponibile a causa di un evento imprevisto nell'area in cui è ospitato. Analogamente al ripristino temporizzato, il ripristino geografico si basa sui backup di database nell'archiviazione di Azure con ridondanza geografica. Esegue il ripristino della copia di backup con replica geografica ed è quindi resiliente alle interruzioni dell'archiviazione nell'area primaria. Per altre informazioni, vedere Ripristinare un database SQL di Azure o eseguire il failover in un database secondario.

Replica geografica attiva

Replica geografica attiva è disponibile per i database a tutti i livelli. È stata progettata per le applicazioni che hanno requisiti di ripristino più elevati di quelli supportati dal ripristino geografico. Usando la replica geografica attiva, è possibile creare fino a quattro repliche secondarie leggibili nei server in aree diverse. È possibile avviare il failover su qualsiasi database secondario. Inoltre, la replica geografica attiva può essere usata per supportare gli scenari di aggiornamento o riposizionamento dell'applicazione e anche di bilanciamento dei carichi di lavoro di sola lettura. Per maggiori dettagli, consultare Configurare la replica geografica attiva per il database SQL di Azure e avviare il failover. Per informazioni dettagliate su come progettare e implementare applicazioni e relativi aggiornamenti senza tempi di inattività, vedere Progettare servizi disponibili a livello globale usando il database SQL di Azure e Gestione degli aggiornamenti in sequenza delle applicazioni cloud con la replica geografica attiva del database SQL.

SQL Server in Macchine virtuali di Azure

Sono disponibili numerose opzioni per il ripristino e la disponibilità elevata per SQL Server 2012 e versioni successive in esecuzione in macchine virtuali di Azure. Per altre informazioni, vedere Disponibilità elevata e ripristino di emergenza per SQL Server nelle macchine virtuali di Azure.

Altri servizi della piattaforma Azure

Quando si prova a eseguire il servizio cloud in più aree di Azure è necessario considerare le implicazioni per ognuna delle dipendenze. Nelle sezioni seguenti, il materiale sussidiario specifico del servizio presuppone che sia necessario usare lo stesso servizio Azure in un data center di Azure alternativo. Ciò comporta attività di configurazione e di replica dei dati.

Nota

In alcuni casi, questi passaggi consentono di attenuare un'interruzione specifica del servizio anziché un evento dell'intero data center. Dalla prospettiva dell'applicazione, un'interruzione specifica del servizio potrebbe essere altrettanto limitante e richiedere la migrazione temporanea del servizio in un'altra area di Azure.

Bus di servizio

bus di servizio di Azure usa uno spazio dei nomi univoco che non si estende sulle aree di Azure. Il primo requisito consiste quindi nel configurare gli spazi dei nomi del bus di servizio necessari nell'area alternativa. Esistono tuttavia anche considerazioni per la durata dei messaggi in coda. Sono disponibili diverse strategie per la replica dei messaggi tra aree di Azure. Per informazioni dettagliate su queste strategie di replica e altre strategie di ripristino di emergenza, vedere Procedure consigliate per isolare le applicazioni del bus di servizio da interruzioni ed emergenze del servizio.

Servizio app

Per eseguire la migrazione di un'applicazione del servizio app di Azure, ad esempio le app Web o le app per dispositivi mobili, in un'area di Azure secondaria, è necessario avere un backup del sito Web disponibile per la pubblicazione. Se l'interruzione non riguarda l'intero data center di Azure, potrebbe essere possibile usare FTP per scaricare un backup recente del contenuto del sito. Creare quindi una nuova app nell'area alternativa, se non è già stato fatto per riservare la capacità. Pubblicare il sito nella nuova area e apportare le modifiche di configurazione necessarie. Queste modifiche possono riguardare le stringhe di connessione del database o altre impostazioni specifiche dell'area. Se necessario, aggiungere il certificato SSL del sito e modificare il record CNAME DNS in modo che il nome di dominio personalizzato punti all'URL dell'app Web di Azure ridistribuito.

HDInsight

I dati associati a HDInsight vengono archiviati per impostazione predefinita nell'archivio BLOB di Azure. HDInsight richiede che un cluster Hadoop che elabora processi MapReduce debba essere inserito nella stessa area dell'account di archiviazione che contiene i dati analizzati. Se si usa la funzionalità di replica geografica disponibile in Archiviazione di Azure è possibile accedere ai dati nell'area secondaria in cui i dati sono stati replicati, se per qualche motivo l'area primaria non è più disponibile. È possibile creare un nuovo cluster Hadoop nell'area in cui i dati sono stati replicati e continuare l'elaborazione.

Report SQL

Il ripristino dopo la perdita di un'area di Azure richiede al momento più istanze di report SQL in diverse aree di Azure. Queste istanze di report SQL devono accedere agli stessi dati e questi dati devono disporre di un proprio piano di ripristino in caso di emergenza. È anche possibile mantenere copie di backup esterne del file RDL per ogni report.

Servizi multimediali

Servizi multimediali di Azure ha un approccio di ripristino diverso per la codifica e lo streaming. Lo streaming è in genere più critico durante un'interruzione di area. A tale scopo è necessario disporre di un account di Servizi multimediali in due diverse aree di Azure. Il contenuto codificato deve trovarsi in entrambe le aree. In caso di errore è possibile reindirizzare il traffico di streaming nell'area alternativa. La codifica può essere eseguita in qualsiasi area di Azure. Se i tempi di codifica sono importanti, ad esempio durante l'elaborazione di eventi in tempo reale, è necessario predisporre l'invio di processi a un data center alternativo durante gli errori.

Rete virtuale

I file di configurazione offrono il modo più rapido per configurare una rete virtuale in un'area alternativa di Azure. Dopo aver configurato la rete virtuale nell'area primaria di Azure, esportare le impostazioni di rete virtuale della rete corrente in un file di configurazione di rete. Se si verifica un'interruzione nell'area primaria, ripristinare la rete virtuale dal file di configurazione archiviato. Configurare quindi altri servizi cloud, macchine virtuali o impostazioni cross-premise per l'uso con la nuova rete virtuale.
Sono disponibili risorse correlate alla rete virtuale da tenere in considerazione (ad esempio NSG, DNS, tabelle di route). Il metodo descritto in Infrastruttura come codice è un modo per generare lo stesso ambiente ogni volta ed è possibile eseguire la distribuzione in una nuova area.

Elenchi di controllo per il ripristino di emergenza

Elenco di controllo per i servizi cloud

Vedere la sezione Servizi cloud di questo documento.
Creare una strategia di ripristino di emergenza tra le aree.
Identificare i compromessi quando si riserva capacità in aree alternative.
Usare strumenti di routing del traffico, ad esempio Gestione traffico di Azure.

Elenco di controllo per le macchine virtuali

Vedere la sezione Macchine virtuali di questo documento.
Usare Backup di Azure per creare backup coerenti con l'applicazione tra le aree.

Elenco di controllo per l'archiviazione

Vedere la sezione Archiviazione di questo documento.
Non disabilitare la replica geografica delle risorse di archiviazione.
Informazioni sull'area alternativa per la replica geografica in caso di failover.
Creare strategie di backup personalizzate per approcci di failover gestiti dall'utente.

Elenco di controllo per il database SQL

Vedere la sezione Database SQL di questo documento.
Usare il ripristino geografico o la replica geografica in base alle esigenze.

Elenco di controllo per SQL Server nelle macchine virtuali

Vedere la sezione SQL Server nelle macchine virtuali di questo documento.
Usare i gruppi di disponibilità AlwaysOn tra aree o il mirroring del database.
In alternativa usare backup e ripristino con l'archivio BLOB.

Elenco di controllo per il bus di servizio

Vedere la sezione Bus di servizio di questo documento.
Configurare uno spazio dei nomi del bus di servizio in un'area alternativa.
Prendere in considerazione strategie di replica personalizzate per i messaggi tra le aree.

Elenco di controllo del servizio app

Vedere la sezione del servizio app di questo documento.
Mantenere backup dei siti all'esterno dell'area primaria.
Se l'interruzione è parziale, provare a recuperare il sito corrente con l'FTP.
Pianificare la distribuzione del sito su un sito nuovo o esistente in un'area alternativa.
Pianificare le modifiche di configurazione per i record di applicazione e DNS CNAME.

Elenco di controllo per HDInsight

Vedere la sezione HDInsight di questo documento.
Creare un nuovo cluster Hadoop nell'area con i dati replicati.

Elenco di controllo per report SQL

Vedere la sezione Report SQL di questo documento.
Mantenere un'istanza di report SQL alternativa in un'area diversa.
Mantenere un piano separato per replicare la destinazione in quell'area.

Elenco di controllo per Servizi multimediali

Vedere la sezione Servizi multimediali di questo documento.
Creare un account di Servizi multimediali in un'area alternativa.
Codificare lo stesso contenuto in entrambe le aree per supportare il failover dello streaming.
In caso di interruzione del servizio, inviare i processi di codifica a un'area alternativa.

Elenco di controllo per rete virtuale

Vedere la sezione Rete virtuale di questo documento.
Usare le impostazioni di rete virtuale esportate per creare di nuovo la rete in un'altra area.

Condividi tramite