Pianificazione e failover del ripristino di emergenza di Archiviazione di Azure
Microsoft si impegna per fare in modo che i servizi di Azure siano sempre disponibili. Potrebbero tuttavia verificarsi interruzioni dei servizi occasionali non pianificate. I componenti chiave di un piano di ripristino di emergenza valido includono strategie per:
- Protezione dei dati
- Backup e ripristino
- Ridondanza dei dati
- Failover
- Progettazione di applicazioni per la disponibilità elevata
Questo articolo descrive le opzioni disponibili per gli account di archiviazione con ridondanza geografica e fornisce consigli per lo sviluppo di applicazioni a disponibilità elevata e il test del piano di ripristino di emergenza.
Scegliere l'opzione di ridondanza appropriata
Archiviazione di Azure gestisce più copie dell'account di archiviazione per garantire che le destinazioni di disponibilità e durabilità vengano soddisfatte, anche in caso di errori. Il modo in cui i dati vengono replicati offre livelli di protezione diversi. Ogni opzione offre i propri vantaggi, quindi l'opzione scelta dipende dal grado di resilienza richiesta dalle applicazioni.
Archiviazione con ridondanza locale (LRS), l'opzione di ridondanza più economica, archivia e replica automaticamente tre copie dell'account di archiviazione all'interno di un singolo data center. Anche se l'archiviazione con ridondanza locale protegge i dati da errori di rack e unità del server, non tiene conto di emergenze come incendi o inondazioni all'interno di un data center. In caso di situazioni di emergenza di questo tipo, tutte le repliche di un account di archiviazione configurato per l'uso dell'archiviazione con ridondanza locale potrebbero essere perse o irreversibili.
Per confronto, l'archiviazione con ridondanza della zona mantiene una copia di un account di archiviazione e la replica 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.
Archiviazione e failover con ridondanza geografica
L'archiviazione con ridondanza geografica, l'archiviazione con ridondanza geografica della zona e l'archiviazione con ridondanza geografica della zona (RA-GZRS) sono esempi di opzioni di archiviazione geograficamente ridondanti. Se configurata per l'uso dell'archiviazione con ridondanza geografica (GRS, GZRS e RA-GZRS), Azure copia i dati in modo asincrono in un'area geografica secondaria. Queste regioni si trovano a centinaia o anche migliaia di chilometri di distanza. Questo livello di ridondanza consente di ripristinare i dati in caso di interruzione nell'intera area primaria.
Diversamente dall'archiviazione con ridondanza locale e con ridondanza geografica, l'archiviazione con ridondanza geografica offre anche il supporto per un failover non pianificato in un'area secondaria in caso di interruzione nell'area primaria. Durante il processo di failover, le voci DNS (Domain Name System) per gli endpoint del servizio dell'account di archiviazione vengono aggiornate automaticamente in modo che gli endpoint dell'area secondaria diventino i nuovi endpoint primari. Una volta completato il failover non pianificato, i clienti possono iniziare a scrivere nel nuovo endpoint primario.
L'archiviazione con ridondanza geografica e accesso in lettura e l'archiviazione con ridondanza geografica della zona e accesso in lettura offrono entrambe la ridondanza geografica, ma forniscono anche il vantaggio aggiunto dell'accesso in lettura all'endpoint secondario. Queste opzioni sono ideali per le applicazioni progettate per applicazioni business critical a disponibilità elevata. Se nell'endpoint primario si verifica un'interruzione, le applicazioni configurate per l'accesso in lettura all'area secondaria possono continuare a funzionare. 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
Gli account di Archiviazione di Azure supportano tre tipi di failover:
- Failover pianificato gestito dal cliente (anteprima): i clienti possono gestire il failover dell'account di archiviazione per testare il piano di ripristino di emergenza.
- Failover gestito dal cliente (non pianificato): 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 in caso di emergenza grave nell'area primaria. 1,2
1 Il 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 Usare le opzioni di failover gestite dal cliente per sviluppare, testare e implementare i piani di ripristino di emergenza. 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). Questa tabella riepiloga gli aspetti di ogni tipo di failover:
| Type | Ambito di failover | Caso d'uso | Perdita di dati stimata | Lo spazio dei nomi gerarchico è supportato |
|---|---|---|---|---|
| Failover pianificato gestito dal cliente (anteprima) | Account di archiviazione | Gli endpoint del servizio di archiviazione per le aree primarie e secondarie sono disponibili e si vuole eseguire test di ripristino di emergenza. Sono disponibili gli endpoint del servizio di archiviazione per l'area primaria, ma un altro servizio impedisce il corretto funzionamento dei carichi di lavoro. Per prepararsi in modo proattivo per emergenze su larga scala, ad esempio un uragano, che potrebbero influire su un'area. |
No | Sì (in anteprima) |
| Failover gestito dal cliente (non pianificato) | 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 | L'area primaria diventa non disponibile a causa di un'emergenza significativa, ma l'area secondaria è disponibile. | Sì | Sì |
La tabella seguente confronta lo stato di ridondanza di un account di archiviazione dopo ogni tipo di failover:
| Risultato del failover in... | Failover pianificato gestito dal cliente (anteprima) | Failover gestito dal cliente (non pianificato) |
|---|---|---|
| ...l'area secondaria | L'area secondaria diventa la nuova primaria | L'area secondaria diventa la nuova primaria |
| ...l'area primaria originale | L'area primaria originale diventa la nuova area secondaria | La copia dei dati nell'area primaria originale viene eliminata |
| ...la configurazione della ridondanza dell'account | L'account di archiviazione viene convertito in archiviazione con ridondanza geografica | L'account di archiviazione viene convertito in archiviazione con ridondanza locale |
| ...la configurazione della ridondanza geografica | La ridondanza geografica viene mantenuta | La ridondanza geografica viene persa |
La tabella seguente riepiloga la configurazione di ridondanza risultante in ogni fase del failover e del processo di failback per ogni tipo di failover:
| Originale configurazione |
After failover |
Dopo la riabilitazione ridondanza geografica |
After failback |
Dopo la riabilitazione ridondanza geografica |
|---|---|---|---|---|
| Failover pianificato gestito dal cliente | ||||
| GRS | GRS | N/D 1 | GRS | N/D 1 |
| GZRS | GRS | N/D 1 | GZRS | N/D 1 |
| Failover gestito dal cliente (non pianificato) | ||||
| GRS | LRS | GRS | LRS | ARCHIVIAZIONE CON RIDONDANZA GEOGRAFICA |
| GZRS | LRS | GRS | ZRS | GZRS |
1 La ridondanza geografica viene mantenuta durante un failover pianificato e non deve essere riconfigurata manualmente.
Failover pianificato gestito dal cliente (anteprima)
Il failover pianificato può essere usato in più scenari, tra cui i test di ripristino di emergenza pianificati, un approccio proattivo alle emergenze su larga scala o per il ripristino da interruzioni non di archiviazione correlate.
Durante il processo di failover pianificato, le aree primarie e secondarie vengono scambiate. L'area primaria originale viene abbassata di livello e diventa la nuova area secondaria. Allo stesso tempo, l'area secondaria originale viene promossa e diventa la nuova area primaria. Al termine del failover, gli utenti possono continuare ad accedere ai dati nella nuova area primaria e gli amministratori possono convalidare il piano di ripristino di emergenza. L'account di archiviazione deve essere disponibile sia nelle aree primarie che secondarie prima di poter avviare un failover pianificato.
La perdita di dati non è prevista durante il failover pianificato e il processo di failback, purché le aree primarie e secondarie siano disponibili nell'intero processo. Per altri dettagli, vedere la sezione Prevedere la perdita di dati e le incoerenze.
Per comprendere l'effetto di questo tipo di failover sugli utenti e sulle applicazioni, è utile sapere cosa accade durante ogni passaggio del failover pianificato e dei processi di failback. Per informazioni dettagliate sul funzionamento di questo processo, vedere Funzionamento del failover gestito dal cliente (pianificato).
Importante
Il failover pianificato gestito dal cliente è attualmente in ANTEPRIMA e limitato alle aree seguenti:
- Francia centrale
- Francia meridionale
- India centrale
- India occidentale
- Asia orientale
- Asia sud-orientale
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.
Per acconsentire esplicitamente all'anteprima, vedere Configurare le funzionalità di anteprima nella sottoscrizione di Azure e specificare AllowSoftFailover come nome della funzionalità. Il nome del provider per questa funzionalità di anteprima è Microsoft.Storage.
Importante
Dopo un failover pianificato, il valore LST (Last Sync Time) di un account di archiviazione potrebbe apparire non aggiornato o essere segnalato come NULL quando sono presenti i dati di File di Azure.
Gli snapshot di sistema vengono creati periodicamente nell'area secondaria di un account di archiviazione per mantenere punti di ripristino coerenti usati durante il failover e il failback. L'avvio del failover pianificato gestito dal cliente fa sì che l'area primaria originale diventi la nuova replica secondaria. In alcuni casi, non sono disponibili snapshot di sistema nel nuovo database secondario dopo il completamento del failover pianificato, cosa che causa la visualizzazione del valore LST complessivo dell'account come Null.
Poiché le attività utente, ad esempio la creazione, la modifica o l'eliminazione di oggetti, possono attivare la creazione di snapshot, qualsiasi account su cui si verificano queste attività dopo il failover pianificato non richiederà ulteriore attenzione. Tuttavia, gli account senza snapshot o attività utente possono continuare a visualizzare un valore LST Null finché non viene attivata la creazione dello snapshot di sistema.
Se necessario, eseguire una delle attività seguenti per ogni condivisione all'interno di un account di archiviazione per attivare la creazione di snapshot. Al termine, l'account dovrebbe visualizzare un valore LST valido entro 30 minuti.
- Montare la condivisione, quindi aprire qualsiasi file per la lettura.
- Caricare un file di test o di esempio nella condivisione.
Failover gestito dal cliente (non pianificato)
Se gli endpoint dati per i servizi di archiviazione nell'account di archiviazione non sono più disponibili nell'area primaria, è possibile avviare un failover non pianificato nell'area secondaria. Al termine del failover, l'area secondaria diventa il nuovo database primario e gli utenti possono continuare ad accedere ai dati lì.
Per comprendere l'effetto di questo tipo di failover sugli utenti e sulle applicazioni, è utile sapere cosa accade durante ogni passaggio del failover non pianificato e dei processi di failback. Per informazioni dettagliate sul funzionamento di questo processo, vedere Funzionamento del failover gestito dal cliente (non pianificato).
Failover gestito da Microsoft
Microsoft potrebbe avviare un failover a livello di area in circostanze estreme, ad esempio un'emergenza irreversibile che influisce su un'intera area geografica. Durante questi eventi, non è necessaria alcuna azione da parte dell'utente. Se l'account di archiviazione è configurato per l'archiviazione con ridondanza geografica e accesso in lettura e per l'archiviazione con ridondanza geografica della zona e accesso in lettura, le applicazioni possono leggere dall'area secondaria durante un failover gestito da Microsoft. Tuttavia, non si avrà accesso in scrittura all'account di archiviazione fino al completamento del processo di failover.
Importante
Usare le opzioni di failover gestite dal cliente per sviluppare, testare e implementare i piani di ripristino di emergenza. 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 data center. Non può essere avviato per singoli account di archiviazione, sottoscrizioni o tenant. Se è necessaria la possibilità di eseguire il failover selettivo dei singoli account di archiviazione, usare il failover pianificato gestito dal cliente.
Prevedere la perdita e le incoerenze dei dati
Attenzione
Il failover non pianificato gestito dal cliente comporta in genere una certa perdita di dati e può anche introdurre 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, è possibile che le scritture più recenti non siano ancora state copiate nel database secondario.
Quando si verifica un failover non pianificato, 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 esistono ancora all'interno dell'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:
- Spazio dei nomi gerarchico (Azure Data Lake Storage)
- Feed di modifiche
- Ripristino temporizzato per i BLOB in blocchi
Ora ultima sincronizzazione
La proprietà Ora ultima sincronizzazione indica l'ora in cui è stata eseguita 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 nel database secondario. Al contrario, i dati e i metadati scritti dopo l'ora dell'ultima sincronizzazione potrebbero non essere ancora copiati nel database secondario e potrebbero andare persi. Durante un'interruzione, usare questa proprietà per stimare la quantità di perdita di dati che può verificarsi durante l'avvio di 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, la registrazione di tutte le operazioni di scrittura consente di confrontare gli orari dell'ultima operazione di scrittura con l'ora dell'ultima sincronizzazione. Questo metodo consente di determinare quali scritture non sono ancora sincronizzate con il database secondario e rischiano di andare perse.
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 Storage
La replica per gli account di archiviazione con uno spazio dei nomi gerarchico abilitato (Azure Data Lake Storage) viene eseguita a livello di file. Poiché la replica si verifica a questo livello, un'interruzione nell'area primaria potrebbe impedire la corretta replica di alcuni file all'interno di un contenitore o di una directory 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 gestito dal cliente (non pianificato) degli account di archiviazione con feed di modifiche abilitato potrebbe causare incoerenze tra i log del feed di modifiche e i dati del BLOB e/o i metadati. Tali incoerenze possono derivare dalla natura asincrona degli aggiornamenti del log delle modifiche e dalla replica dei dati tra le aree primarie e secondarie. È possibile evitare incoerenze adottando le precauzioni seguenti:
- Assicurarsi che tutti i record di log vengano scaricati nei file di log.
- Assicurarsi che tutti i dati di archiviazione vengano replicati dall'area primaria all'area secondaria.
Per altre informazioni sul feed di modifiche, vedere Funzionamento del feed di modifiche.
Tenere presente che anche altre funzionalità dell'account di archiviazione richiedono l'abilitazione del feed di modifiche. Queste funzionalità includono backup operativo di Archiviazione BLOB di Azure, replica di oggettie 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.
Tempo e costo del failover
Il tempo necessario per il completamento del failover gestito dal cliente dopo l'avvio può variare, anche se in genere richiede meno di un'ora.
Un failover pianificato gestito dal cliente non perde la ridondanza geografica dopo un failover e un failback successivo, ma un failover non pianificato gestito dal cliente sì.
L'avvio di un failover non pianificato gestito dal cliente converte automaticamente l'account di archiviazione nell'archiviazione con ridondanza locale all'interno di una nuova area primaria ed elimina l'account di archiviazione nell'area primaria originale.
È possibile abilitare nuovamente l'archiviazione con ridondanza geografica o l'archiviazione con ridondanza geografica e accesso in lettura per l'account, ma una nuova replica dei dati nella nuova area secondaria comporterà dei costi. Inoltre, tutti i BLOB archiviati devono essere riattivati in un livello online prima che l'account possa essere riconfigurato per la ridondanza geografica. Questa riattivazione comporta anche un addebito aggiuntivo. 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 necessario per il completamento della replica dipende da diversi fattori. Questi fattori includono:
- 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.
- Numero di snapshot per BLOB, se applicabile.
- La strategia di partizionamento dei dati, se l'account di archiviazione contiene tabelle. 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 pianificato gestito dal cliente (anteprima) | Account per utilizzo generico v2 Account per utilizzo generico v1 Account di archiviazione BLOB legacy |
Account per utilizzo generico v2 |
| Failover gestito dal cliente (non pianificato) | 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 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 modello 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.
Spazio dei nomi gerarchico (HNS)
Importante
Il failover gestito dal cliente (non pianificato) per gli account con Azure Data Lake Storage Gen2 abilitato è attualmente in ANTEPRIMA e supportato in tutte le aree con ridondanza geografica e archiviazione con ridondanza geografica e accesso in lettura pubblica.
Per acconsentire esplicitamente all'anteprima, vedere Configurare le funzionalità di anteprima nella sottoscrizione di Azure e specificare AllowHNSAccountFailover come nome della funzionalità.
Importante
Il failover gestito dal cliente (non pianificato) per gli account con SSH File Transfer Protocol (SFTP) è attualmente abilitato 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 gestito dal cliente:
- Sincronizzazione file di Azure non supporta il failover dell'account gestito dal cliente. Non è consigliabile eseguire il failover degli account di archiviazione usati come endpoint cloud per Sincronizzazione file di Azure. Il failover interrompe la sincronizzazione dei file e potrebbe causare la perdita imprevista di dati dei nuovi file a 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.
- 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 geografica con NFSv3 abilitato.
La tabella seguente può essere usata per fare riferimento al supporto delle funzionalità.
| Failover pianificato | Failover non pianificato | |
|---|---|---|
| Archiviazione di Azure Data Lake | Supportata (anteprima) | Supportata (anteprima) |
| Feed di modifiche | Non supportato | Supportata |
| Replica di oggetti | Non supportato | Non supportato |
| SFTP | Supportata (anteprima) | Supportata (anteprima) |
| NFSv3 | Archiviazione con ridondanza geografica non supportata | Archiviazione con ridondanza geografica non supportata |
| Azioni di archiviazione | Supportato1 | Supportato1 |
| Ripristino temporizzato | Non supportato | Supportata |
1 Se si avvia un failover pianificato o non pianificato gestito dal cliente, le attività di archiviazione non possono operare sull'account finché non viene eseguito il failback nell'area primaria originale. Altre informazioni.
Il failover non è pensato per la migrazione dell'account
I failover degli account di archiviazione sono una soluzione temporanea usata per sviluppare e testare i piani di ripristino di emergenza o per il ripristino da un'interruzione del servizio. Il failover non deve essere usato come parte della strategia di migrazione dei dati. 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 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 è 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 effettuano il failover durante un failover dell'account di archiviazione. Tutte le macchine virtuali di cui è stato eseguito il failover in un'area secondaria in risposta a un'interruzione del servizio devono essere ricreate al termine del failover. Il failover dell'account può causare la perdita di dati archiviati in un disco temporaneo quando la macchina virtuale viene arrestata. Microsoft consiglia di seguire le indicazioni specifiche legate a disponibilità elevata e ripristino di emergenza per le macchine virtuali in Azure.
Dischi non gestiti di Azure
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. Prima di poter avviare un failover in un account contenente dischi non gestiti collegati alle macchine virtuali di Azure, è necessario arrestare i dischi. Per questo motivo, le procedure consigliate da Microsoft includono la conversione di dischi non gestiti in dischi gestiti.
Per eseguire un failover in un account contenente dischi non gestiti, seguire questa procedura:
- 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.
- Arrestare la VM.
- 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.
- Attendere che l'ora dell'ultima sincronizzazione si aggiorni e assicurarsi che sia successiva al momento in cui è stata eliminata la macchina virtuale. Questo passaggio garantisce che l'endpoint secondario venga completamente aggiornato con i file VHD quando si verifica il failover e che la macchina virtuale funzioni correttamente nella nuova area primaria.
- Avviare il failover dell'account.
- Attendere che il failover dell'account venga completato e che l'area secondaria diventi la nuova area primaria.
- Creare una macchina virtuale nella nuova area primaria e ricollegare i dischi rigidi virtuali.
- 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
Come illustrato in precedenza, è possibile mantenere la disponibilità elevata configurando le applicazioni per l'uso di un account di archiviazione configurato per l'accesso in lettura a un'area secondaria. Tuttavia, se si preferisce non eseguire il failover durante un'interruzione all'interno dell'area primaria, è possibile copiare manualmente i dati come alternativa. Strumenti come AzCopy e Azure PowerShell consentono di copiare dati dall'account di archiviazione nell'area interessata a un altro account di archiviazione in un'area non interessata. Al termine dell'operazione di copia, è possibile riconfigurare le applicazioni in modo da usare l'account di archiviazione nell'area non interessata per la disponibilità di lettura e 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:
- Progettazione di applicazioni resilienti per Azure: panoramica dei concetti chiave relativi all'architettura delle applicazioni a disponibilità elevata in Azure.
- Elenco di controllo della resilienza: elenco di controllo per verificare che l'applicazione implementi le procedure di progettazione consigliate per la disponibilità elevata.
- Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata: linee guida per la creazione di applicazioni per sfruttare i vantaggi dell'archiviazione con ridondanza geografica.
- Esercitazione: Creare un'applicazione a disponibilità elevata con archiviazione BLOB: esercitazione che illustra come compilare un'applicazione a disponibilità elevata che passa automaticamente da un endpoint all'altro mentre vengono simulati errori e ripristini.
Fare riferimento a 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 da un'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
- Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata
- Esercitazione: Creare un'applicazione a disponibilità elevata con l'archivio BLOB
- Azure Storage redundancy (Ridondanza di Archiviazione di Azure)
- Funzionamento del failover pianificato gestito dal cliente (anteprima)
- Funzionamento del failover gestito dal cliente (non pianificato)