Condividi tramite

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 della zona e archiviazione con ridondanza geografica della zona e accesso in lettura) e su come progettare le applicazioni in modo che garantiscano 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. La scelta dell'opzione di ridondanza per l'account dipende dal grado di resilienza necessario per l'applicazione.

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 che si trova ad 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. Una volta completato il failover, i clienti possono iniziare a scrivere nel nuovo endpoint primario.

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 la lettura dall'endpoint secondario. Microsoft consiglia l'archiviazione con ridondanza geografica della zona 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 di Archiviazione di Azure.

Pianificare il failover dell'account di archiviazione

Gli account di Archiviazione di Azure supportano due tipi di failover:

1Il failover gestito da Microsoft non può essere avviato per singoli account di archiviazione, sottoscrizioni o tenant. Per altre informazioni, 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 Storage Gen2). Questa tabella riepiloga gli aspetti di ogni tipo di failover:

Type Ambito di failover Caso d'uso Perdita di dati stimata 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 del servizio.		 Sì Sì (in anteprima)
Gestione di 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 potrebbe 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 eseguire operazioni di lettura dall'area secondaria se l'account di archiviazione è configurato per l'archiviazione con ridondanza geografica e accesso in lettura o l'archiviazione con ridondanza geografica della zona e accesso in lettura.

Importante

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. 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 vengono scritti in modo asincrono dall'area primaria all'area secondaria, si verifica sempre un ritardo prima che un'operazione di scrittura nell'area primaria venga copiata nell'area secondaria. Se l'area primaria non è più disponibile, le operazioni di scrittura più recenti potrebbero non essere ancora state copiate nell'area secondaria.

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 nell'area secondaria 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 disporre dell'archiviazione 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, elenchi di controllo di accesso inclusi. Tutti i dati e i metadati scritti prima dell'ora dell'ultima sincronizzazione sono disponibili nell'area secondaria, mentre i dati e i metadati scritti dopo l'ora dell'ultima sincronizzazione potrebbero non essere stati scritti nell'area secondaria e andare persi. Usare questa proprietà in caso di interruzione per stimare la quantità di dati che potrebbero andare persi 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. Se ad esempio si registrano tutte le operazioni di scrittura, è possibile confrontare l'ora delle ultime operazioni di scrittura con quella dell'ultima sincronizzazione per determinare quali operazioni di scrittura non sono state sincronizzate con l'area secondaria.

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

Coerenza file per Azure Data Lake Storage Gen2

La replica per gli account di archiviazione con uno spazio dei nomi gerarchico abilitato (Azure Data Lake Storage Gen2) 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 del feed di modifiche

Il failover dell'account di archiviazione degli account di archiviazione con ridondanza geografica con il feed di modifiche abilitato può comportare incoerenze tra i log del feed di modifiche e i dati e/o i metadati dei BLOB. 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 sono previste è quando tutti i record di log correnti vengono scaricati correttamente nei file di log e tutti i dati di archiviazione vengono 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 di oggetti e il ripristino temporizzato per i BLOB in blocchi.

Incoerenze nel 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 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 precedente al 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 dal failover, non è possibile eseguire il ripristino a un punto precedente al 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 ad 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, il 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 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 di archiviazione BLOB legacy		 Account per utilizzo generico v2
Failover gestito da Microsoft Tutti i tipi di account Account per utilizzo generico v2

Account di archiviazione della versione classica

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 classico, non è supportato. Per rendere idonei gli account di archiviazione classici per il failover dell'account gestito dal cliente, questi devono prima essere sottoposti a migrazione al modello ARM. L'account di archiviazione deve essere accessibile per eseguire l'aggiornamento, quindi l'area primaria non può trovarsi 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.

In caso di un'emergenza significativa che influisce sull'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. È consigliabile non effettuare il failover degli account di archiviazione contenenti condivisioni file di Azure che vengono usate come endpoint cloud in Sincronizzazione file di Azure. 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.
  • Non è possibile effettuare il failover di un account di archiviazione contenente BLOB in blocchi Premium. Gli account di archiviazione che supportano i BLOB in blocchi Premium non supportano attualmente 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 dopo il completamento del failover, è sufficiente riabilitarlo.
  • Network File System (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 è pensato per la migrazione dell'account

Il failover dell'account di archiviazione 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 Panoramica della migrazione di Archiviazione di Azure.

Account di archiviazione contenenti BLOB di archivio

Gli account di archiviazione contenenti BLOB di archivi supportano il failover dell'account. Tuttavia, al termine 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 di Archiviazione di Azure. Queste API costituiscono la base di tutte le azioni che è possibile eseguire con Archiviazione di Azure. L'API REST di 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 di Archiviazione di Azure consente di gestire l'account di archiviazione e le risorse correlate.

Al termine di un failover, i client possono leggere e scrivere nuovamente i dati di Archiviazione di Azure nella nuova area primaria. Tuttavia, il provider di risorse di 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 di Archiviazione di Azure non esegue il failover, la proprietà Percorso restituirà il percorso primario originale al termine del failover.

Macchine virtuali di Azure

Le macchine virtuali di Azure non effettuano il failover durante 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 indicazioni specifiche legate a disponibilità elevata e ripristino di emergenza 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 se è presente un lease su 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 effettuare il failover in caso di interruzione nell'area primaria, è possibile usare strumenti come AzCopy o Azure PowerShell per copiare i 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 di Archiviazione di Azure:

  • Dischi: usare Backup di Azure per eseguire il backup dei dischi delle macchine virtuali usati dalle macchine virtuali di Azure. Valutare anche l'opportunità di usare Azure Site Recovery per proteggere le macchine virtuali in caso di emergenza a livello di area.
  • BLOB in blocchi: attivare l'eliminazione temporanea per proteggere da eliminazioni e sovrascritture a livello di oggetto o copiare i BLOB in blocchi in un altro account di archiviazione in un'area diversa usando AzCopy, Azure PowerShell o la libreria di spostamento dei dati di Azure.
  • File: Usare Backup di Azure per eseguire il backup delle condivisioni file. Abilitare anche l'eliminazione temporanea per evitare eliminazioni accidentali di condivisioni file. Per la ridondanza geografica quando non è disponibile l'archiviazione con ridondanza geografica, 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