Funzionamento del failover dell'account di archiviazione gestito dal cliente
Il failover gestito dal cliente degli account di archiviazione di Azure consente di eseguire il failover dell'intero account di archiviazione con ridondanza geografica nell'area secondaria se gli endpoint del servizio di archiviazione per l'area primaria non sono più disponibili. Durante il failover, l'area secondaria originale diventa il nuovo database primario e tutti gli endpoint di servizio di archiviazione per BLOB, tabelle, code e file vengono reindirizzati alla nuova area primaria. Dopo aver risolto l'interruzione dell'endpoint del servizio di archiviazione, è possibile eseguire un'altra operazione di failover per eseguire il failback nell'area primaria originale.
Questo articolo descrive cosa accade durante il failover e il failback di un account di archiviazione gestito dal cliente in ogni fase del processo.
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.
Gestione della ridondanza durante il failover e il failback
Suggerimento
Per comprendere in dettaglio i vari stati di ridondanza durante il failover e il processo di failback dell'account di archiviazione, vedere ridondanza di Archiviazione di Azure per le definizioni di ognuno di essi.
Quando un account di archiviazione è configurato per la ridondanza con ridondanza geografica o con ridondanza geografica e accesso in lettura, i dati vengono replicati tre volte in locale all'interno delle aree primarie e secondarie (archiviazione con ridondanza locale). Quando un account di archiviazione è configurato per la replica con ridondanza geografica della zona o con ridondanza geografica della zona e accesso in lettura, i dati sono ridondanti all'interno dell'area primaria (ZRS) e replicati tre volte localmente all'interno dell'area secondaria (archiviazione con ridondanza locale). Se l'account è configurato per l'accesso in lettura (RA), sarà possibile leggere i dati dall'area secondaria purché siano disponibili gli endpoint del servizio di archiviazione in tale area.
Durante il processo di failover gestito dal cliente, le voci DNS per gli endpoint del servizio di archiviazione vengono modificate in modo che quelle per l'area secondaria diventino i nuovi endpoint primari per l'account di archiviazione. Dopo il failover, la copia dell'account di archiviazione nell'area primaria originale viene eliminata e l'account di archiviazione continua a essere replicato tre volte in locale all'interno dell'area secondaria originale (il nuovo database primario). A questo punto, l'account di archiviazione diventa con ridondanza locale.
Le configurazioni di ridondanza originali e correnti vengono archiviate nelle proprietà dell'account di archiviazione per consentire di tornare alla configurazione originale quando si esegue il failback.
Per ripristinare la ridondanza geografica dopo un failover, sarà necessario riconfigurare l'account come archiviazione con ridondanza geografica. L'archiviazione con ridondanza geografica della zona non è un'opzione dopo il failover perché la nuova replica primaria sarà LRS dopo il failover. Dopo la riconfigurazione dell'account per la ridondanza geografica, Azure inizia immediatamente a copiare i dati dalla nuova area primaria al nuovo database secondario. Se si configura l'account di archiviazione per l'accesso in lettura (RA) all'area secondaria, tale accesso sarà disponibile, ma la replica dal database primario potrebbe richiedere del tempo per rendere corrente la replica secondaria.
Avviso
Dopo aver riconfigurato l'account per la ridondanza geografica, potrebbe essere necessario molto tempo prima che i dati esistenti nella nuova area primaria vengano copiati completamente nel nuovo database secondario.
Per evitare la perdita di una grande quantità di dati, controllare il valore della proprietà Ora ultima sincronizzazione prima di effettuare il failback. Confrontare l'ora dell'ultima sincronizzazione con l'ultima volta in cui i dati sono stati scritti nel nuovo database primario per valutare la potenziale perdita di dati.
Il processo di failback è essenzialmente lo stesso del processo di failover, ad eccezione di Azure, ripristina la configurazione della replica allo stato originale prima del failover (la configurazione della replica, non i dati). Pertanto, se l'account di archiviazione è stato originariamente configurato come archiviazione con ridondanza geografica della zona, l'area primaria dopo il faillback diventa ZRS.
Dopo il failback, è possibile configurare di nuovo l'account di archiviazione in modo che sia con ridondanza geografica. Se l'area primaria originale è stata configurata per l'archiviazione con ridondanza locale, è possibile configurarla come archiviazione con ridondanza geografica o archiviazione con ridondanza geografica e accesso in lettura. Se la replica primaria originale è stata configurata come archiviazione con ridondanza della zona, è possibile configurarla come archiviazione con ridondanza geografica o archiviazione con ridondanza geografica della zona e accesso in lettura. Per altre opzioni, vedere Modificare la modalità di replica di un account di archiviazione.
Come avviare un failover
Per informazioni su come avviare un failover, vedere Avviare un failover dell'account di archiviazione.
Attenzione
Il failover dell'account di archiviazione comporta in genere una perdita di dati e potenzialmente incoerenze di file e dati. È importante comprendere l'impatto che un failover dell'account avrebbe sui dati prima di avviarne uno.
Per informazioni dettagliate sulle potenziali perdite e incoerenze dei dati, vedere Prevedere la perdita e le incoerenze dei dati.
Processo di failover e failback
Questa sezione riepiloga il processo di failover per un failover gestito dal cliente.
Riepilogo delle transizioni di failover
Dopo un failover gestito dal cliente:
- L'area secondaria diventa la nuova primaria
- La copia dei dati nell'area primaria originale viene eliminata
- L'account di archiviazione viene convertito in archiviazione con ridondanza locale
- La ridondanza geografica viene persa
Questa tabella riepiloga la configurazione della ridondanza risultante in ogni fase di un failover gestito dal cliente e del failback:
| Originale configurazione |
After failover |
Dopo la riabilitazione ridondanza geografica |
After failback |
Dopo la riabilitazione ridondanza geografica |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | Archiviazione con ridondanza geografica della zona 1 |
1 la ridondanza geografica viene persa durante un failover gestito dal cliente e deve essere riconfigurata manualmente.
Dettagli sulla transizione di failover
I diagrammi seguenti illustrano cosa accade durante il failover gestito dal cliente e il failback di un account di archiviazione configurato per la ridondanza geografica. I dettagli della transizione per l'archiviazione con ridondanza geografica della zona e archiviazione con ridondanza geografica della zona e accesso in lettura sono leggermente diversi rispetto all'archiviazione con ridondanza geografica e all'archiviazione con ridondanza geografica e accesso in lettura.
- Archiviazione con ridondanza geografica/archiviazione con ridondanza geografica e accesso in lettura
- Archiviazione con ridondanza geografica della zona/archiviazione con ridondanza geografica della zona e accesso in lettura
Operazione Normal (GRS/RA-GRS)
In circostanze normali, un client scrive i dati in un account di archiviazione nell'area primaria tramite gli endpoint del servizio di archiviazione (1). I dati vengono quindi copiati in modo asincrono dall'area primaria all'area secondaria (2). L'immagine seguente mostra lo stato normale di un account di archiviazione configurato come archiviazione con ridondanza geografica quando sono disponibili gli endpoint primari:
Gli endpoint del servizio di archiviazione non sono più disponibili nell'area primaria (GRS/RA-GRS)
Se per qualsiasi motivo gli endpoint del servizio di archiviazione primario non sono più disponibili (1), il client non è più in grado di scrivere nell'account di archiviazione. A seconda della causa sottostante dell'interruzione, la replica nell'area secondaria potrebbe non funzionare più (2), quindi dovrebbe essere prevista una perdita di dati. L'immagine seguente mostra lo scenario in cui gli endpoint primari non sono più disponibili, ma non è ancora stato eseguito alcun ripristino:
Processo di failover (GRS/RA-GRS)
Per ripristinare l'accesso in scrittura ai dati, è possibile avviare un failover. Gli URI dell'endpoint del servizio di archiviazione per BLOB, tabelle, code e file rimangono invariati, ma le relative voci DNS vengono modificate in modo che puntino all'area secondaria (1) come illustrato in questa immagine:
Il failover gestito dal cliente richiede in genere circa un'ora.
Al termine del failover, il database secondario originale diventa il nuovo database primario (1) e la copia dell'account di archiviazione nel database primario originale viene eliminata (2). L'account di archiviazione è configurato come archiviazione con ridondanza locale nella nuova area primaria e non è più con ridondanza geografica. Gli utenti possono riprendere la scrittura dei dati nell'account di archiviazione (3), come illustrato in questa immagine:
Per riprendere la replica in una nuova area secondaria, riconfigurare l'account per la ridondanza geografica.
Importante
Tenere presente che la conversione di un account di archiviazione con ridondanza locale per l'uso della ridondanza geografica comporta costi e tempi. Per altre informazioni, vedere Temi e costi del failover.
Dopo aver riconfigurato l'account come archiviazione con ridondanza geografica, Azure inizia a copiare i dati in modo asincrono nella nuova area secondaria (1), come illustrato in questa immagine:
L'accesso in lettura alla nuova area secondaria non sarà nuovamente disponibile fino a quando il problema che causa l'interruzione originale non sarà stato risolto.
Processo di failback (GRS/RA-GRS)
Avviso
Dopo aver riconfigurato l'account per la ridondanza geografica, potrebbe essere necessario molto tempo prima che i dati nella nuova area primaria vengano copiati completamente nel nuovo database secondario.
Per evitare la perdita di una grande quantità di dati, controllare il valore della proprietà Ora ultima sincronizzazione prima di effettuare il failback. Confrontare l'ora dell'ultima sincronizzazione con l'ultima volta in cui i dati sono stati scritti nel nuovo database primario per valutare la potenziale perdita di dati.
Dopo aver risolto il problema che causa l'interruzione originale, è possibile avviare un altro failover per eseguire il failback nell'area primaria originale, che genera quanto segue:
- L'area primaria corrente diventa di sola lettura.
- Con il failover e il failback avviati dal cliente, i dati non possono completare la replica nell'area secondaria durante il processo di failback. È quindi importante controllare il valore della proprietà Ora dell'ultima sincronizzazione prima del failback.
- Le voci DNS per gli endpoint del servizio di archiviazione vengono modificate in modo che quelle per l'area secondaria diventino i nuovi endpoint primari per l'account di archiviazione.
Al termine del failback, l'area primaria originale diventa nuovamente quella corrente (1) e la copia dell'account di archiviazione nel database secondario originale viene eliminata (2). L'account di archiviazione è configurato come con ridondanza locale nell'area primaria e non è più con ridondanza geografica. Gli utenti possono riprendere la scrittura dei dati nell'account di archiviazione (3), come illustrato in questa immagine:
Per riprendere la replica nell'area secondaria originale, configurare nuovamente l'account per la ridondanza geografica.
Importante
Tenere presente che la conversione di un account di archiviazione con ridondanza locale per l'uso della ridondanza geografica comporta costi e tempi. Per altre informazioni, vedere Temi e costi del failover.
Dopo aver riconfigurato l'account come archiviazione con ridondanza geografica, la replica nell'area secondaria originale riprende come illustrato in questa immagine:
Vedi anche
- Pianificazione del ripristino di emergenza e del failover
- Azure Storage redundancy (Ridondanza di Archiviazione di Azure)
- Avviare un failover dell'account