Ripristino di emergenza e failover per File di Azure

Microsoft si impegna per fare in modo che i servizi di Azure siano sempre disponibili. Tuttavia, potrebbero verificarsi interruzioni del servizio non pianificate ed è necessario disporre di un piano di ripristino di emergenza per gestire un'interruzione del servizio a livello di area. Un parte importante del piano di ripristino di emergenza è la preparazione del failover nell'endpoint secondario quando l'endpoint primario non è più disponibile. Questo articolo descrive i concetti e i processi coinvolti nel ripristino di emergenza e nel failover dell'account di archiviazione.

failover di Sincronizzazione file di Azure

Se si usa Sincronizzazione file di Azure, leggere prima questa sezione. Se non si usa Sincronizzazione file di Azure, questa sezione non si applica.

Sincronizzazione file di Azure supporta il failover dell'account di archiviazione solo se viene eseguito anche il failover del servizio di sincronizzazione archiviazione. Questo perché Sincronizzazione file di Azure richiede che l'account di archiviazione e il Servizio di Sincronizzazione Storage siano nella stessa area di Azure. Se viene eseguito solo il failover dell'account di archiviazione, le operazioni di sincronizzazione e gestione dei livelli nel cloud avranno esito negativo finché non viene eseguito il failover del Servizio di Sincronizzazione dell'Archiviazione nell'area secondaria.

Se si vuole eseguire il failover di un account di archiviazione contenente condivisioni file di Azure utilizzate come endpoint cloud in Sincronizzazione file di Azure, vedere Procedure consigliate per il ripristino di emergenza di Sincronizzazione file di Azure e Ripristino del server di Sincronizzazione file di Azure.

Al termine del failover di un account di archiviazione(ad esempio, dal Canada centrale al Canada orientale), Sincronizzazione file di Azure non riconosce automaticamente la nuova posizione dell'account di archiviazione. Il piano di controllo rimane registrato nella regione ARM originale, mentre solo il piano dati viene migrato alla nuova regione.

Per completare un failover per Sincronizzazione file di Azure, seguire questa procedura:

1. Contattare il supporto di Microsoft per richiedere che Sincronizzazione file di Azure rispetti la nuova posizione dell'account di archiviazione.
2. Dopo l'aggiornamento di Sincronizzazione file di Azure, instrada il traffico server (piano dati) verso la nuova regione. Il piano di controllo del servizio di sincronizzazione archiviazione potrebbe comunque riflettere l'area originale nel portale di Azure.

Il portale di Azure visualizza solo la posizione del piano di controllo per Azure File Sync. Non espone l'endpoint del piano dati. È possibile verificare che i server puntino all'area corretta usando supporto tecnico Microsoft.

Failover pianificato gestito dal cliente

Puoi utilizzare il failover pianificato gestionato dal cliente in più scenari, inclusi test di disaster recovery pianificati, un approccio proattivo ai disastri su larga scala o per recuperare da interruzioni non legate allo storage.

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.

Non è prevista la perdita di dati durante il failover pianificato e il processo di failback, purché le aree primarie e secondarie siano disponibili durante l'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).

Costi e metriche di ripristino

Per formulare una strategia di ripristino di emergenza efficace, un'organizzazione deve comprendere:

• Quanti dati può permettersi di perdere in un'interruzione (obiettivo del punto di ripristino o RPO)
• Quanto rapidamente deve essere in grado di ripristinare funzioni e dati aziendali (obiettivo del tempo di ripristino o RTO)

Il costo del ripristino di emergenza aumenta in genere con un RPO/RTO inferiore o pari a zero. Le aziende che devono essere operative in pochi secondi dopo un'emergenza e non possono sostenere alcuna perdita di dati pagheranno di più per il ripristino di emergenza, mentre quelle con numeri RPO/RTO più elevati pagheranno di meno. Azure offre soluzioni che possono funzionare con vari requisiti RPO e RTO.

Scegliere l'opzione di ridondanza appropriata

File di Azure offre diverse opzioni di ridondanza per proteggere i dati da eventi pianificati e non pianificati, che vanno da errori hardware temporanei, a interruzioni di rete e alimentazione, fino a calamità naturali. Tutte le condivisioni file di Azure possono utilizzare l'archiviazione con ridondanza locale (LRS) o della zona (ZRS). Per altre informazioni, vedere Ridondanza di File di Azure.

File di Azure supporta il failover dell'account per le condivisioni file HDD configurati con archiviazione con ridondanza geografica e archiviazione con ridondanza geografica della zona per la protezione dalle interruzioni a livello di area. Con il failover dell'account, è possibile avviare il processo di failover per l'account di archiviazione se l'endpoint primario non è più disponibile. Il failover aggiorna l'endpoint secondario, che in questo modo diventa l'endpoint primario dell'account di archiviazione. Quando il failover è completato, i client possono iniziare a scrivere sul nuovo endpoint primario.

L'archiviazione con ridondanza geografica e l'archiviazione con ridondanza geografica della zona pongono comunque un rischio di perdita dei dati perché i dati vengono copiati nell'area secondaria in modo asincrono, quindi si verifica un ritardo prima che un'operazione di scrittura nell'area primaria venga copiata nell'area secondaria. In caso di interruzione, le operazioni di scrittura nell'endpoint primario che non sono ancora state copiate nell'endpoint secondario andranno perse. Questo significa che un errore che influisce sull'area primaria potrebbe comportare la perdita di dati se l'area primaria non può essere ripristinata. L'intervallo tra le operazioni di scrittura più recenti nella regione primaria e l'ultima operazione di scrittura nella regione secondaria è il RPO. L'RPO di File di Azure è in genere di 15 minuti o meno, anche se attualmente non è previsto alcun SLA sulla durata della replica dei dati nell'area secondaria.

Progettazione per alta disponibilità

Progetta la tua applicazione per un'alta disponibilità fin dall'inizio. Consulta queste risorse Azure per indicazioni su come progettare la tua applicazione e pianificare il disaster recovery:

• 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 consigliate di progettazione per la disponibilità elevata.
• Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata: materiale sussidiario per la creazione di applicazioni per sfruttare i vantaggi dell'archiviazione con ridondanza geografica per le archiviazioni file SMB.

Progetta anche la tua applicazione per prepararti alla possibilità di fallimenti di scrittura. L'applicazione deve esporre gli errori di scrittura in modo che l'utente sia avvisato di una possibile interruzione nell'area primaria.

Come procedura consigliata, progettare l'applicazione in modo da controllare la proprietà Ora 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.

Tenere traccia delle interruzioni

È possibile abbonarsi alla Dashboard di Integrità dei Servizi Azure per monitorare lo stato di salute e lo stato di File di Azure e altri servizi Azure.

Informazioni sul processo di failover dell'account

Quando utilizzi il failover dell'account gestito dal cliente, puoi eseguire il failover dell'intero account di archiviazione nell'area secondaria se l'area primaria non è più disponibile per qualsiasi motivo. Quando si forza un failover nell'area secondaria, i clienti possono iniziare a scrivere i dati nell'endpoint secondario al termine del failover. Il failover richiede in genere circa un'ora. Sospendi il carico di lavoro il più possibile prima di avviare un failover dell'account.

Per informazioni su come avviare un failover dell'account, vedere Avviare un failover dell'account.

Come funziona il failover di un account

In circostanze normali, un client scrive i dati su un account di archiviazione nella regione primaria, e il sistema copia tali dati asincronamente nella regione secondaria.

Se l'endpoint principale diventa non disponibile per qualsiasi motivo, il client non può scrivere sull'account di archiviazione. Puoi quindi avviare un failover dell'account. Questa azione aggiorna la voce DNS fornita da Archiviazione di Azure in modo che l'endpoint secondario diventi il nuovo endpoint principale per il tuo account di storage.

L'accesso in scrittura viene ripristinato per gli account con ridondanza geografica dopo l'aggiornamento del record DNS e l'instradamento delle richieste al nuovo endpoint primario. Gli endpoint esistenti dei servizi di storage rimangono gli stessi dopo il failover. I lease e gli handle di file non vengono mantenuti in caso di failover, quindi i client devono smontare e rimontare le condivisioni file.

Anticipare la perdita di dati durante il failover

Poiché i dati vengono scritti in modo asincrono dall'area primaria all'area secondaria, se l'area primaria diventa non disponibile, è possibile che le operazioni di scrittura più recenti non siano ancora state copiate nella regione secondaria.

Quando si forza un failover, tutti i dati nell'area primaria vengono persi perché l'area secondaria diventa la nuova area primaria. La nuova area primaria è configurata in modo da essere ridondante a livello locale dopo il failover.

Il processo di failover mantiene tutti i dati già copiati sul secondario. Tuttavia, qualsiasi dato scritto al primario che non sia stato copiato anche nel secondario viene perso in modo permanente.

Controllare la proprietà dell'Ora dell'ultima sincronizzazione

La proprietà Data e 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. Tutti i dati scritti prima dell'ora dell'ultima sincronizzazione sono disponibili nell'area secondaria, mentre i dati 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.

Per garantire che le condivisioni file siano in uno stato coerente quando avviene un failover, la regione primaria crea uno snapshot di sistema ogni 15 minuti e lo replica nella regione secondaria. Quando si verifica un failover nell'area secondaria, lo stato della condivisione è basato sullo snapshot di sistema più recente nell'area secondaria. Se si verifica un guasto nella regione primaria, è probabile che la regione secondaria non sia aggiornata quanto la primaria, poiché non tutte le operazioni di scrittura nella regione primaria sono ancora state replicate nella regione secondaria. A causa di ritardo geografico (ritardo di replica tra regioni) o altri problemi, l'ultimo snapshot di sistema nella regione secondaria potrebbe essere più vecchio di 15 minuti.

Tutte le operazioni di scrittura eseguite nell'area primaria precedenti all'ora dell'ultima sincronizzazione sono state replicate correttamente nell'area secondaria, vale a dire che sono disponibili per la lettura dall'area secondaria. Le eventuali operazioni di scrittura nell'area primaria eseguite dopo l'ora dell'ultima sincronizzazione potrebbero o meno essere state replicate correttamente nell'area secondaria, vale a dire che potrebbero non essere disponibili per le operazioni di lettura.

È possibile eseguire una query sul valore della proprietà Data e ora ultima sincronizzazione usando Azure PowerShell, l'interfaccia della riga di comando di Azure o la libreria client. La proprietà Last Sync Time è un valore di data/ora GMT. Per altre informazioni, vedere Controllare la proprietà Last Sync Time per un account di archiviazione.

Prestare attenzione quando si effettua il failback all'area primaria originale

Come accennato in precedenza, dopo il passaggio dall'area primaria a quella secondaria, il tuo account di archiviazione viene configurato con ridondanza locale nella nuova area primaria. È quindi possibile configurare l'account nella nuova area primaria per la ridondanza geografica. Quando l'account viene configurato per la ridondanza geografica dopo un failover, la nuova area primaria inizia immediatamente a copiare i dati nella nuova area secondaria, che era quella primaria prima del failover originale. Può tuttavia trascorrere del tempo prima che i dati esistenti nella nuova area primaria vengano completamente copiati nella nuova area secondaria.

Dopo che l'account di archiviazione è stato riconfigurato per la ridondanza geografica, è possibile avviare un failback dalla nuova area primaria alla nuova area secondaria. In questo caso, la regione primaria originale precedente al failover diventa nuovamente la regione primaria e viene configurata in modo da essere ridondante localmente o a zona, a seconda che la configurazione primaria originale fosse GRS o GZRS. Tutti i dati nell'area primaria dopo il failover (quella secondaria originale) vengono persi durante il failback. Se la maggior parte dei dati nell'account di archiviazione non è stata copiata nella nuova area secondaria prima del failback, potrebbe verificarsi la perdita di una grande quantità di dati.

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 le ultime volte in cui i dati sono stati scritti sul nuovo principale per valutare la perdita di dati prevista.

Dopo un'operazione di failback, è possibile riconfigurare la nuova area primaria 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. Se l'area primaria originale è stata configurata per l'archiviazione con ridondanza della zona, è possibile configurarla come archiviazione con ridondanza geografica della zona. Per altre opzioni, vedere Modificare la modalità di replica di un account di archiviazione.

Avviare il failover di un account

È possibile avviare un failover dell'account dal portale di Azure, da PowerShell, dall'interfaccia della riga di comando di Azure o dall'API del provider di risorse di Archiviazione di Azure. Per altre informazioni su come avviare un failover, vedere Avviare il failover di un account.

Procedure consigliate per il failover geografico pianificato

Prima di avviare un failover pianificato, assicurarsi che tutte le attività delle applicazioni e dei client nelle condivisioni di file di Azure siano completamente arrestate. Le operazioni di lettura o scrittura attive durante il failover possono causare che le condivisioni file entrino in uno stato incoerente dopo il completamento del failover.

Prima di avviare il failover:

• Arrestare tutte le applicazioni e i client che accedono alle condivisioni file di Azure.
• Verificare che non siano presenti operazioni di I/O attive (lettura o scrittura) in qualsiasi condivisione file nell'account di archiviazione.
• Verificare che non esistano handle di file aperti nelle condivisioni di file.
• Usare il cmdlet Get-AzStorageFileHandle di Azure PowerShell per elencare gli handle di file attivi e gli indirizzi IP client connessi.
• Disattivare tutti gli indirizzi IP dei client visualizzati nei risultati prima di avviare l'operazione di failover per l'account di archiviazione.

Procedere con il failover pianificato solo quando tutte le condivisioni file sono inattive e non rimangono connessioni client attive.

Failover gestito da Microsoft

In casi estremi, in cui un'area va persa a causa di una grave emergenza, Microsoft potrebbe avviare un failover a livello di area. In tal caso, non è necessaria alcuna azione da parte dell'utente. Solo dopo il completamento del failover gestito da Microsoft, si avrà di nuovo accesso in scrittura all'account di archiviazione.

Vedi anche

• Ridondanza di File di Azure
• Panoramica della protezione dati di File di Azure
• Avviare un failover dell'account di archiviazione