Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il failover pianificato gestito dal cliente può essere utile in scenari quali pianificazione e ripristino di emergenza e test, correzione proattiva di emergenze su larga scala previste e interruzioni non correlate all'archiviazione.
Durante il processo di failover pianificato, le aree primarie e secondarie dell'account di archiviazione vengono scambiate. L'area primaria originale viene abbassata di livello e diventa la nuova secondaria mentre l'area secondaria originale viene alzata di livello e diventa la nuova primaria. L'account di archiviazione deve essere disponibile sia nelle aree primarie che secondarie prima di poter avviare un failover pianificato.
Questo articolo descrive cosa accade durante il failover e il failback pianificati gestiti dal cliente in ogni fase del processo. Per informazioni sul funzionamento di un failover a causa di un'interruzione imprevista dell'endpoint di archiviazione, vedere Come funziona il failover gestito dal cliente (non pianificato).
Importante
Il feedback degli utenti viene incorporato nel failover pianificato gestito dal cliente (anteprima) e la funzionalità è temporaneamente indisponibile in tutte le regioni. Al termine, la documentazione aggiornata verrà rilasciata per riflettere le aree in cui è disponibile la funzionalità.
Gestione della ridondanza durante il failover e il failback pianificati
Suggerimento
Per comprendere in dettaglio i vari stati di ridondanza durante il failover e il processo di failback gestiti dal cliente, vedere ridondanza di Archiviazione di Azure per le definizioni di ognuno di essi.
Durante il processo di failover pianificato, gli endpoint del servizio di archiviazione dell'area primaria diventano di sola lettura, mentre gli aggiornamenti rimanenti terminano la replica nell'area secondaria. Successivamente, tutte le voci DNS (Servizio dei Nomi di Dominio) dell'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. La replica dei dati all'interno di ogni area rimane invariata anche se le aree primarie e secondarie sono cambiate.
Il processo di failback pianificato è essenzialmente lo stesso del processo di failover pianificato, ma con un'unica eccezione. Durante il failback pianificato, Azure memorizza la configurazione di ridondanza originale dell'account di archiviazione e la ripristina al suo stato originale durante il failback. Ad esempio, se l'account di archiviazione è stato originariamente configurato come archiviazione con ridondanza geografica della zona, l'account di archiviazione avrà quel tipo di archiviazione dopo il failback.
Nota
A differenza del failover gestito dal cliente (non pianificato), durante il failover pianificato la replica dall'area primaria a quella secondaria deve essere completata prima che le voci DNS per gli endpoint vengano modificate nel nuovo database secondario. Per questo motivo, non ci si aspetta perdita di dati durante il failover o il failback pianificato, purché sia la regione primaria che quella secondaria siano disponibili durante tutto il processo.
Come avviare un failover
Per informazioni su come avviare un failover, vedere Avviare un failover dell'account.
Processo di failover e failback pianificati
I diagrammi seguenti illustrano cosa accade durante un failover pianificato gestito dal cliente e il failback di un account di archiviazione.
- 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
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 tipico di un account di archiviazione configurato come GRS.
Processo di failover pianificato (GRS/RA-GRS)
Avvia il test di ripristino di emergenza eseguendo un failover dell'account di archiviazione nella regione secondaria. Di seguito vengono descritti i passaggi all'interno del processo di failover pianificato e l'immagine successiva fornisce un'illustrazione:
L'account di archiviazione sia nell'area primaria che in quella secondaria subirà una perdita temporanea dell'accesso in lettura e scrittura.
La replica di tutti i dati dall'area primaria all'area secondaria viene completata.
Le voci DNS per gli endpoint del servizio di archiviazione nell'area secondaria vengono alzate di livello e diventano i nuovi endpoint primari per l'account di archiviazione.
Il failover richiede in genere circa un'ora.
Al termine del failover, l'area primaria originale diventa la nuova replica secondaria (1) e l'area secondaria originale diventa la nuova primaria (2). Gli URI per gli endpoint del servizio di archiviazione per BLOB, tabelle, code e file rimangono invariati, ma le loro voci DNS vengono modificate in modo da puntare alla nuova area primaria (3). Gli utenti possono riprendere la scrittura dei dati nell'account di archiviazione nella nuova area primaria e i dati vengono quindi copiati in modo asincrono nel nuovo database secondario (4), come illustrato nell'immagine seguente:
Durante lo stato del failover, eseguire i test di ripristino di emergenza.
Processo di failback pianificato (GRS/RA-GRS)
Al termine del test, eseguire un altro failover per eseguire il failback nell'area primaria originale. Durante il processo di failover, come illustrato nell'immagine seguente:
L'account di archiviazione sia nell'area primaria che in quella secondaria subirà una perdita temporanea dell'accesso in lettura e scrittura.
Tutti i dati terminano la replica dall'area primaria corrente all'area secondaria corrente.
Le voci DNS per gli endpoint del servizio di archiviazione vengono modificate in modo da tornare all'area primaria prima dell'esecuzione del failover iniziale.
Il failback richiede in genere circa un'ora.
Al termine del failback, l'account di archiviazione viene ripristinato nella configurazione di ridondanza originale. Gli utenti possono riprendere la scrittura dei dati nell'account di archiviazione nell'area primaria originale (1) mentre la replica nel database secondario originale (2) continua come prima del failover:
