Funzionamento del failover gestito dal cliente (non pianificato)
Il failover gestito dal cliente (non pianificato) 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 la nuova area primaria. Tutti gli endpoint del servizio di archiviazione vengono quindi 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 non pianificati gestiti dal cliente in ogni fase del processo.
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.
Gestione della ridondanza durante il failover e il failback non pianificati
Suggerimento
Per comprendere in dettaglio i vari stati di ridondanza durante il failover e il processo di failback non pianificati, vedere ridondanza di Archiviazione di Azure per le definizioni di ognuno di essi.
Quando un account di archiviazione è configurato per l'archiviazione con ridondanza geografica o l'archiviazione con ridondanza geografica e accesso in lettura, i dati vengono replicati tre volte all'interno delle aree primarie e secondarie con ridondanza locale. Quando un account di archiviazione è configurato per la replica con archiviazione con ridondanza geografica della zona o archiviazione con ridondanza geografica della zona e accesso in lettura, i dati sono ridondanti all'interno dell'area primaria di archiviazione con ridondanza della zona e replicati tre volte all'interno dell'area secondaria dell'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 (non pianificato), le voci DNS (Domain Name System) per gli endpoint del servizio di archiviazione vengono cambiate. Gli endpoint secondari dell'account di archiviazione diventano i nuovi endpoint primari e gli endpoint primari originali diventano i nuovi endpoint secondari. 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 della nuova area primaria. A questo punto, l'account di archiviazione diventa ridondante in locale e usa l'archiviazione con ridondanza locale.
Le configurazioni di ridondanza originali e correnti vengono archiviate nelle proprietà dell'account di archiviazione. Questa funzionalità consente di tornare alla configurazione originale quando si esegue il failback. Per un elenco completo delle configurazioni di ridondanza risultanti, leggere Pianificazione del ripristino e failover.
Per ripristinare la ridondanza geografica dopo un failover, sarà necessario riconfigurare l'account come archiviazione con ridondanza geografica. 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 all'area secondaria, tale accesso è disponibile. Tuttavia, il completamento della replica dal database primario all'area secondaria potrebbe richiedere del tempo.
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. Per valutare la potenziale perdita di dati, confrontare l'ora dell'ultima sincronizzazione con l'ultima volta in cui i dati sono stati scritti nel nuovo database primario.
Il processo di failback è essenzialmente lo stesso del processo di failover, ad eccezione del fatto che la configurazione della replica viene ripristinata allo stato originale di pre-failover.
Dopo il failback, è possibile riconfigurare l'account di archiviazione per sfruttare la ridondanza geografica. 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 non pianificato
Per informazioni su come avviare un failover non pianificato, vedere Avviare un failover dell'account.
Attenzione
Il failover non pianificato 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 avviare questo tipo di failover.
Per informazioni dettagliate sulle potenziali perdite e incoerenze dei dati, vedere Prevedere la perdita e le incoerenze dei dati.
Processo di failover e failback non pianificati
Questa sezione riepiloga il processo di failover per un failover gestito dal cliente (non pianificato).
Riepilogo della transizione del failover non pianificato
Dopo un failover gestito dal cliente (non pianificato):
- 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 (non pianificato) 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 (non pianificato) e deve essere riconfigurata manualmente.
Dettagli sulla transizione del failover non pianificato
I diagrammi seguenti illustrano il failover gestito dal cliente (non pianificato) e il processo di failback per 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 è necessario prevedere una perdita di dati. L'immagine seguente mostra lo scenario in cui gli endpoint primari non sono disponibili, ma prima che si verifichi il ripristino:
Processo di failover non pianificato (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 come illustrato:
Il failover gestito dal cliente (non pianificato) 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 per usare l'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 finché non verrà risolto il problema che causa l'interruzione originale.
Processo di failback non pianificato (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 il failback nell'area primaria originale. Il processo è descritto nell'immagine seguente:
- 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 cambiate. Gli endpoint all'interno dell'area secondaria diventano 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