Pianificazione e failover del ripristino di emergenza di Archiviazione di Azure

  • Articolo

Microsoft si impegna per fare in modo che i servizi di Azure siano sempre disponibili. Possono tuttavia verificarsi interruzioni dei servizi non pianificate. I componenti chiave di un piano di ripristino di emergenza valido includono strategie per:

Questo articolo è incentrato sul failover per gli account di archiviazione con ridondanza globale (archiviazione con ridondanza geografica, archiviazione con ridondanza geografica e accesso in lettura) e su come progettare le applicazioni in modo che siano a disponibilità elevata in caso di interruzione e failover successivo.

Scegliere l'opzione di ridondanza appropriata

Archiviazione di Azure gestisce più copie dell'account di archiviazione per garantire la durabilità e la disponibilità elevata. L'opzione di ridondanza scelta per l'account dipende dal grado di resilienza necessaria per le applicazioni.

Con l'archiviazione con ridondanza locale, tre copie dell'account di archiviazione vengono archiviate e replicate automaticamente all'interno di un singolo data center. Con l'archiviazione con ridondanza della zona, una copia viene archiviata e replicata in ognuna di tre zone di disponibilità separate all'interno della stessa area. Per altre informazioni sulle zone di disponibilità, vedere Zone di disponibilità di Azure.

Il ripristino di una singola copia di un account di archiviazione viene eseguito automaticamente con archiviazione con ridondanza locale e archiviazione con ridondanza della zona.

Archiviazione e failover con ridondanza globale

Con l'archiviazione con ridondanza globale (GRS, GZRS e RA-GZRS), Azure copia i dati in modo asincrono in un'area geografica secondaria a almeno centinaia di chilometri di distanza. In questo modo è possibile ripristinare i dati in caso di interruzione nell'area primaria. Una funzionalità che distingue l'archiviazione con ridondanza globale dall'archiviazione con ridondanza locale e dall'archiviazione con ridondanza della zona è la possibilità di eseguire il failover nell'area secondaria in caso di interruzione nell'area primaria. Il processo di failover aggiorna le voci DNS per gli endpoint di servizio dell'account di archiviazione in modo che gli endpoint per l'area secondaria diventino i nuovi endpoint primari per l'account di archiviazione. Al termine del failover, i client possono iniziare a scrivere nei nuovi endpoint primari.

Le configurazioni di ridondanza RA-GRS e RA-GZRS offrono l'archiviazione con ridondanza geografica con il vantaggio aggiunto dell'accesso in lettura all'endpoint secondario in caso di interruzione nell'area primaria. Se si verifica un'interruzione nell'endpoint primario, le applicazioni configurate per l'accesso in lettura all'area secondaria e progettate per la disponibilità elevata possono continuare a leggere dall'endpoint secondario. Microsoft consiglia l'archiviazione con ridondanza geografica e accesso in lettura per la massima disponibilità e durabilità degli account di archiviazione.

Per altre informazioni sulla ridondanza in Archiviazione di Azure, vedere ridondanza Archiviazione di Azure.

Pianificare il failover dell'account di archiviazione

Archiviazione di Azure account supportano due tipi di failover:

  • Failover gestito dal cliente: i clienti possono gestire il failover dell'account di archiviazione in caso di interruzione imprevista del servizio.
  • Failover gestito da Microsoft: potenzialmente avviato da Microsoft solo in caso di grave emergenza nell'area primaria. 1,2

1Il failover gestito da Microsoft non può essere avviato per singoli account di archiviazione, sottoscrizioni o tenant. Per altri dettagli, vedere Failover gestito da Microsoft.
2 Il piano di ripristino di emergenza deve essere basato sul failover gestito dal cliente. Non basarsi sul failover gestito da Microsoft, che verrebbe usato solo in circostanze estreme.

Ogni tipo di failover ha un set univoco di casi d'uso, aspettative corrispondenti per la perdita di dati e supporto per gli account con uno spazio dei nomi gerarchico abilitato (Azure Data Lake Archiviazione Gen2). Questa tabella riepiloga gli aspetti di ogni tipo di failover:

Type Ambito failover Caso d'uso Perdita di dati prevista HNS supportato
Rete virtuale dell'area di lavoro di Account di archiviazione Gli endpoint del servizio di archiviazione per l'area primaria diventano non disponibili, ma l'area secondaria è disponibile.

È stato ricevuto un avviso di Azure in cui Microsoft consiglia di eseguire un'operazione di failover degli account di archiviazione potenzialmente interessati da un'interruzione.		 Sì Sì (in anteprima)
Gestito da Microsoft Intera area o unità di scala L'area primaria diventa completamente non disponibile a causa di un'emergenza significativa, ma l'area secondaria è disponibile. Sì Sì

Failover gestito dal cliente

Se gli endpoint dati per i servizi di archiviazione nell'account di archiviazione non sono più disponibili nell'area primaria, è possibile eseguire il failover nell'area secondaria. Al termine del failover, l'area secondaria diventa il nuovo database primario e gli utenti possono continuare ad accedere ai dati nella nuova area primaria.

Per comprendere appieno l'impatto che il failover dell'account gestito dal cliente avrebbe sugli utenti e sulle applicazioni, è utile sapere cosa accade durante ogni passaggio del processo di failover e failback. Per informazioni dettagliate sul funzionamento del processo, vedere Funzionamento del failover dell'account di archiviazione gestito dal cliente.

Failover gestito da Microsoft

In circostanze estreme in cui l'area primaria originale viene considerata irreversibile entro un periodo di tempo ragionevole a causa di un'emergenza grave, Microsoft può avviare un failover a livello di area. In tal caso, non è necessaria alcuna azione da parte dell'utente. Si avrà di nuovo accesso in scrittura all'account di archiviazione solo dopo il completamento del failover gestito da Microsoft. Le applicazioni possono leggere dall'area secondaria se l'account di archiviazione è configurato per RA-GRS o RA-GZRS.

Importante

Il piano di ripristino di emergenza deve essere basato sul failover gestito dal cliente. Non fare affidamento sul failover gestito da Microsoft, che potrebbe essere usato solo in circostanze estreme. Un failover gestito da Microsoft viene avviato per un'intera unità fisica, ad esempio un'area o un'unità di scala. Non può essere avviato per singoli account di archiviazione, sottoscrizioni o tenant. Per consentire il failover selettivo dei singoli account di archiviazione, usare il failover dell'account gestito dal cliente.

Prevedere la perdita e le incoerenze dei dati

Attenzione

Il failover dell'account di archiviazione comporta in genere una perdita di dati e potenzialmente incoerenze di file e dati. Nel piano di ripristino di emergenza è importante considerare l'impatto che un failover dell'account avrebbe sui dati prima di avviarne uno.

Poiché i dati sono scritti in modo asincrono dall'area primaria all'area secondaria, si verifica sempre un ritardo prima che venga copiata una scrittura nell'area primaria nel database secondario. Se l'area primaria non è più disponibile, le scritture più recenti potrebbero non essere ancora state copiate nel database secondario.

Quando si verifica un failover, tutti i dati nell'area primaria vengono persi man mano che l'area secondaria diventa il nuovo database primario. Tutti i dati già copiati nel database secondario vengono mantenuti quando si verifica il failover. Tuttavia, tutti i dati scritti nel database primario che non sono stati copiati nell'area secondaria vengono persi in modo permanente.

La nuova area primaria è configurata per essere con ridondanza locale (LRS) dopo il failover.

È anche possibile che si verifichino incoerenze di file o dati se gli account di archiviazione hanno uno o più degli elementi seguenti abilitati:

Ora ultima sincronizzazione

La proprietà Ora ultima sincronizzazione indica l'ora in cui è stata eseguita con certezza l'ultima operazione di scrittura dei dati dall'area primaria all'area secondaria. Per gli account con uno spazio dei nomi gerarchico, la stessa proprietà Ora ultima sincronizzazione si applica anche ai metadati gestiti dallo spazio dei nomi gerarchico, inclusi gli ACL. Tutti i dati e i metadati scritti prima dell'ora dell'ultima sincronizzazione sono disponibili nel database secondario, mentre i dati e i metadati scritti dopo l'ora dell'ultima sincronizzazione potrebbero non essere stati scritti nel database secondario e potrebbero andare persi. Usare questa proprietà se si verifica un'interruzione per stimare la quantità di perdita di dati che può verificarsi avviando un failover dell'account.

Come procedura consigliata, progettare l'applicazione per poter usare l'ora dell'ultima sincronizzazione per valutare la perdita di dati prevista. Ad esempio, se si registrano tutte le operazioni di scrittura, è possibile confrontare l'ora dell'ultima operazione di scrittura con l'ora dell'ultima sincronizzazione per determinare quali scritture non sono state sincronizzate con il database secondario.

Per altre informazioni sul controllo della proprietà Ora ultima sincronizzazione, vedere Controlla la proprietà Last Sync Time per un account di archiviazione.

Coerenza dei file per Azure Data Lake Archiviazione Gen2

La replica per gli account di archiviazione con uno spazio dei nomi gerarchico abilitato (Azure Data Lake Archiviazione Gen2) viene eseguita a livello di file. Ciò significa che se si verifica un'interruzione nell'area primaria, è possibile che solo alcuni dei file in un contenitore o in una directory siano stati replicati correttamente nell'area secondaria. La coerenza per tutti i file in un contenitore o in una directory dopo il failover di un account di archiviazione non è garantita.

Incoerenze dei dati blob e feed di modifiche

Archiviazione failover degli account di archiviazione con ridondanza geografica con feed di modifiche abilitato può comportare incoerenze tra i log del feed di modifiche e i dati blob e/o i metadati. Tali incoerenze possono derivare dalla natura asincrona di entrambi gli aggiornamenti ai log delle modifiche e dalla replica dei dati BLOB dall'area primaria all'area secondaria. L'unica situazione in cui le incoerenze non sarebbero previste è che tutti i record di log correnti siano stati scaricati correttamente nei file di log e che tutti i dati di archiviazione siano stati replicati correttamente dall'area primaria all'area secondaria.

Per informazioni sul funzionamento del feed di modifiche, vedere Funzionamento del feed di modifiche.

Tenere presente che altre funzionalità dell'account di archiviazione richiedono l'abilitazione del feed di modifiche, ad esempio il backup operativo di Archiviazione BLOB di Azure, la replica degli oggetti e il ripristino temporizzato per i BLOB in blocchi.

Incoerenze di ripristino temporizzato

Il failover gestito dal cliente è supportato per gli account di archiviazione di livello standard per utilizzo generico v2 che includono BLOB in blocchi. Tuttavia, l'esecuzione di un failover gestito dal cliente in un account di archiviazione reimposta il primo punto di ripristino possibile per l'account. I dati per il ripristino temporizzato per i BLOB in blocchi sono coerenti solo fino al tempo di completamento del failover. Di conseguenza, è possibile ripristinare solo i BLOB in blocchi a un punto nel tempo non prima del tempo di completamento del failover. È possibile controllare il tempo di completamento del failover nella scheda ridondanza dell'account di archiviazione nel portale di Azure.

Si supponga, ad esempio, di aver impostato il periodo di conservazione su 30 giorni. Se sono trascorsi più di 30 giorni dal failover, è possibile eseguire il ripristino in qualsiasi punto entro i 30 giorni. Tuttavia, se sono trascorsi meno di 30 giorni dopo il failover, non è possibile eseguire il ripristino a un punto prima del failover, indipendentemente dal periodo di conservazione. Ad esempio, se sono trascorsi 10 giorni dal failover, il punto di ripristino più breve possibile è 10 giorni nel passato, non 30 giorni nel passato.

Tempo e costo del failover

Il tempo necessario per il completamento del failover dopo l'avvio può variare, anche se in genere richiede meno di un'ora.

Un failover gestito dal cliente perde la ridondanza geografica dopo un failover (e failback). L'account di archiviazione viene convertito automaticamente nell'archiviazione con ridondanza locale nella nuova area primaria durante un failover e l'account di archiviazione nell'area primaria originale viene eliminato.

È possibile riabilitare l'archiviazione con ridondanza geografica o l'archiviazione con ridondanza geografica e accesso in lettura (RA-GRS) per l'account, ma si noti che la conversione da archiviazione con ridondanza locale a archiviazione con ridondanza geografica o archiviazione con ridondanza geografica e accesso in lettura comporta un costo aggiuntivo. Il costo è dovuto agli addebiti in uscita di rete per replicare nuovamente i dati nella nuova area secondaria. Inoltre, tutti i BLOB archiviati devono essere riattivati in un livello online prima che l'account possa essere configurato per la ridondanza geografica, che comporta un costo. Per altre informazioni sui prezzi, vedere:

Dopo avere nuovamente abilitato l'archiviazione con ridondanza geografica per l'account di archiviazione, Microsoft inizia la replica dei dati dell'account nella nuova area secondaria. Il tempo di replica dipende da molti fattori, tra cui:

  • Numero e dimensioni degli oggetti nell'account di archiviazione. La replica di molti oggetti di piccole dimensioni può richiedere più tempo rispetto alla replica di meno oggetti e oggetti più grandi.
  • Risorse disponibili per la replica in background, ad esempio CPU, memoria, disco e capacità WAN. Il traffico in tempo reale ha la priorità sulla replica geografica.
  • Se l'account di archiviazione contiene BLOB, il numero di snapshot per BLOB.
  • Se l'account di archiviazione contiene tabelle, la strategia di partizionamento dei dati. Il processo di replica non può essere ridimensionato oltre il numero di chiavi di partizione usate.

Tipi di account di archiviazione supportati

Tutte le offerte con ridondanza geografica supportano il failover gestito da Microsoft. Inoltre, alcuni tipi di account supportano il failover dell'account gestito dal cliente, come illustrato nella tabella seguente:

Tipo di failover GRS/RA-GRS GZRS/RA-GZRS
Failover gestito dal cliente Account per utilizzo generico v2 account
per utilizzo generico v1 account
BLOB legacy Archiviazione		 Account per utilizzo generico v2
Failover gestito da Microsoft Tutti i tipi di account Account per utilizzo generico v2

Account di archiviazione classici

Importante

Il failover dell'account gestito dal cliente è supportato solo per gli account di archiviazione distribuiti usando il modello di distribuzione Azure Resource Manager (ARM). Il modello di distribuzione di Azure Service Manager (ASM), noto anche come versione classica, non è supportato. Per rendere idonei gli account di archiviazione classici per il failover dell'account gestito dal cliente, è prima necessario eseguirne la migrazione al modello di Resource Manager. L'account di archiviazione deve essere accessibile per eseguire l'aggiornamento, quindi l'area primaria non può essere attualmente in uno stato di errore.

se si verifica un'emergenza che interessa l'area primaria, Microsoft gestirà il failover per gli account di archiviazione classici. Per altre informazioni, vedere Failover gestito da Microsoft.

Azure Data Lake Storage Gen2

Importante

Il failover dell'account gestito dal cliente per gli account con uno spazio dei nomi gerarchico (Azure Data Lake Storage Gen2) è attualmente in ANTEPRIMA e supportato solo nelle aree seguenti:

  • (Asia Pacifico) India centrale
  • (Asia Pacifico) Asia sud-orientale
  • (Europa) Europa settentrionale
  • (Europa) Svizzera settentrionale
  • (Europa) Svizzera occidentale
  • (Europa) Europa occidentale
  • (America del Nord) Canada centrale
  • (America del Nord) Stati Uniti orientali 2
  • (America del Nord) Stati Uniti centro-meridionali

Per acconsentire esplicitamente all'anteprima, vedere Configurare le funzionalità di anteprima nella sottoscrizione di Azure e specificare AllowHNSAccountFailover come nome della funzionalità.

Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.

se si verifica un'emergenza significativa che interessa l'area primaria, Microsoft gestirà il failover per gli account con uno spazio dei nomi gerarchico. Per altre informazioni, vedere Failover gestito da Microsoft.

Funzionalità e servizi non supportati

Le funzionalità e i servizi seguenti non sono supportati per il failover dell'account:

  • Sincronizzazione file di Azure non supporta il failover dell'account di archiviazione avviato dal cliente. Archiviazione gli account contenenti condivisioni file di Azure usate come endpoint cloud in Sincronizzazione file di Azure non devono essere sottoposti a failover. Il failover causerebbe l'arresto della sincronizzazione e potrebbe causare inoltre una perdita di dati imprevista nel caso di file appena disposti su livelli. Per altre informazioni, vedere Procedure consigliate per il ripristino di emergenza con Sincronizzazione file di Azure per informazioni dettagliate.
  • Non è possibile eseguire il failover di un account di archiviazione contenente BLOB in blocchi Premium. Archiviazione account che supportano BLOB in blocchi Premium attualmente non supportano la ridondanza geografica.
  • Il failover gestito dal cliente non è supportato per l'origine o l'account di destinazione in un criterio di replica di oggetti.
  • Per eseguire il failover di un account con SSH File Transfer Protocol (SFTP) abilitato, è prima necessario disabilitare SFTP per l'account. Se si vuole riprendere a usare SFTP al termine del failover, è sufficiente riabilitarlo.
  • Il file system di rete (NFS) 3.0 (NFSv3) non è supportato per il failover dell'account di archiviazione. Non è possibile creare un account di archiviazione configurato per la ridondanza globale con NFSv3 abilitato.

Il failover non è per la migrazione dell'account

Archiviazione failover dell'account non deve essere usato come parte della strategia di migrazione dei dati. Il failover è una soluzione temporanea a un'interruzione del servizio. Per informazioni su come eseguire la migrazione degli account di archiviazione, vedere Archiviazione di Azure panoramica della migrazione.

Archiviazione account contenenti BLOB archiviati

Archiviazione account contenenti BLOB archiviati supportano il failover dell'account. Tuttavia, dopo il completamento di un failover gestito dal cliente, tutti i BLOB archiviati devono essere riattivati in un livello online prima che l'account possa essere configurato per la ridondanza geografica.

Provider di risorse di archiviazione

Microsoft offre due API REST per l'uso delle risorse Archiviazione di Azure. Queste API costituiscono la base di tutte le azioni che è possibile eseguire su Archiviazione di Azure. L'API REST Archiviazione di Azure consente di usare i dati nell'account di archiviazione, inclusi BLOB, code, file e dati di tabella. L'API REST del provider di risorse Archiviazione di Azure consente di gestire l'account di archiviazione e le risorse correlate.

Al termine di un failover, i client possono di nuovo leggere e scrivere Archiviazione di Azure dati nella nuova area primaria. Tuttavia, il provider di risorse Archiviazione di Azure non esegue il failover, quindi le operazioni di gestione delle risorse devono comunque essere eseguite nell'area primaria. Se l'area primaria non è disponibile, non sarà possibile eseguire operazioni di gestione nell'account di archiviazione.

Poiché il provider di risorse Archiviazione di Azure non esegue il failover, la proprietà Location restituirà il percorso primario originale al termine del failover.

Macchine virtuali di Azure

Le macchine virtuali di Azure non ese eseguiti il failover come parte di un failover dell'account. Se l'area primaria non è disponibile e si effettua il failover nell'area secondaria, sarà necessario ricreare le macchine virtuali dopo il failover. Si verifica anche una potenziale perdita di dati associata al failover dell'account. Microsoft consiglia di seguire le linee guida per la disponibilità elevata e il ripristino di emergenza specifiche per le macchine virtuali in Azure.

Tenere presente che i dati archiviati in un disco temporaneo vanno persi quando la macchina virtuale viene arrestata.

Dischi non gestiti di Azure

Come procedura consigliata, Microsoft consiglia di convertire i dischi non gestiti in dischi gestiti. Se tuttavia è necessario effettuare il failover di un account che contiene dischi non gestiti collegati a macchine virtuali di Azure, sarà necessario arrestare le macchine virtuali prima di avviare il failover.

I dischi non gestiti vengono archiviati come BLOB di pagine in Archiviazione di Azure. Quando una macchina virtuale è in esecuzione in Azure, eventuali dischi non gestiti collegati alla macchina virtuale vengono concessi in lease. Un failover dell'account non può continuare quando è presente un lease in un BLOB. Per eseguire il failover, seguire questa procedura:

  1. Prima di iniziare, prendere nota dei nomi dei dischi non gestiti, dei numeri di unità logica e della macchina virtuale a cui sono collegati. In questo modo sarà più facile ricollegare i dischi dopo il failover.
  2. Arrestare la VM.
  3. Eliminare la macchina virtuale, ma conservare i file VHD per i dischi non gestiti. Prendere nota dell'ora in cui è stata eliminata la macchina virtuale.
  4. Attendere che l'ora dell'ultima sincronizzazione venga aggiornata e che sia successiva all'ora in cui è stata eliminata la macchina virtuale. Questo passaggio è importante, perché se l'endpoint secondario non è stato completamente aggiornato con i file VHD quando si verifica il failover, la macchina virtuale potrebbe non funzionare correttamente nella nuova area primaria.
  5. Avviare il failover dell'account.
  6. Attendere che il failover dell'account venga completato e che l'area secondaria diventi la nuova area primaria.
  7. Creare una macchina virtuale nella nuova area primaria e ricollegare i dischi rigidi virtuali.
  8. Avviare la nuova macchina virtuale.

Tenere presente che i dati archiviati in un disco temporaneo vanno persi quando la macchina virtuale viene arrestata.

Copia dei dati come alternativa al failover

Se l'account di archiviazione è configurato per l'accesso in lettura all'area secondaria, è possibile progettare l'applicazione per la lettura dall'endpoint secondario. Se si preferisce non eseguire il failover se si verifica un'interruzione nell'area primaria, è possibile usare strumenti come AzCopy o Azure PowerShell per copiare dati dall'account di archiviazione nell'area secondaria a un altro account di archiviazione in un'area non interessata. È quindi possibile indirizzare le applicazioni a tale account di archiviazione per la disponibilità sia in lettura che in scrittura.

Progettare la disponibilità elevata

È importante progettare l'applicazione per la disponibilità elevata fin dall'inizio. Per indicazioni sulla progettazione dell'applicazione e sulla pianificazione del ripristino di emergenza, vedere queste risorse di Azure:

Tenere presenti queste procedure consigliate per mantenere la disponibilità elevata per i dati Archiviazione di Azure:

  • Dischi: usare Backup di Azure per eseguire il backup dei dischi delle macchine virtuali usati dalle macchine virtuali di Azure. Prendere in considerazione anche l'uso di Azure Site Recovery per proteggere le macchine virtuali in caso di emergenza a livello di area.
  • BLOB in blocchi: attivare l'eliminazionetemporanea per proteggersi da eliminazioni e sovrascrizioni a livello di oggetto o copiare BLOB in blocchi in un altro account di archiviazione in un'area diversa usando AzCopy, Azure PowerShell o la libreria di spostamento dati di Azure.
  • File: usare Backup di Azure per eseguire il backup delle condivisioni file. Abilitare anche l'eliminazione temporanea per proteggersi dalle eliminazioni accidentali della condivisione file. Per la ridondanza geografica quando l'archiviazione con ridondanza geografica non è disponibile, usare AzCopy o Azure PowerShell per copiare i file in un altro account di archiviazione in un'area diversa.
  • Tabelle: usare AzCopy per esportare i dati delle tabelle in un altro account di archiviazione in un'area diversa.

Tenere traccia delle interruzioni

I clienti possono sottoscrivere il dashboard per l'integrità dei servizi di Azure per tenere traccia dell'integrità e dello stato di Archiviazione di Azure e di altri servizi di Azure.

Microsoft consiglia anche di progettare l'applicazione per prepararsi alla possibilità di errori di scrittura. L'applicazione deve esporre gli errori di scrittura in modo che l'utente sia avvisato di una possibile interruzione nell'area primaria.

Vedi anche