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 qualora l'endpoint primario non sia più disponibile. Questo articolo descrive i concetti e i processi coinvolti nel ripristino di emergenza e nel failover dell'account di archiviazione.
Importante
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 archiviazione si trovino nella stessa area di Azure. Se viene eseguito il failover solo dell'account di archiviazione, le operazioni di sincronizzazione e suddivisione in livelli cloud avranno esito negativo finché non viene eseguito il failover del servizio di sincronizzazione archiviazione nell'area secondaria. Se si desidera eseguire il failover di un account di archiviazione contenente condivisioni file di Azure usate 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 Sincronizzazione file di Azure.
Failover pianificato gestito dal cliente (anteprima)
Il failover pianificato gestito dal cliente può essere usato in più scenari, tra cui test di ripristino di emergenza pianificati, un approccio proattivo alle emergenze su larga scala o per il ripristino da interruzioni non correlate all'archiviazione.
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.
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.
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 caso di 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 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 usare l'archiviazione con ridondanza locale o della zona. Per altre informazioni, vedere Ridondanza di File di Azure.
File di Azure supporta il failover dell'account per gli account di archiviazione standard 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. Una volta completato il failover, i clienti possono iniziare a scrivere nel 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 nell'area primaria e l'ultima operazione di scrittura nell'area secondaria è noto come obiettivo del punto di ripristino (RPO). L'obiettivo del punto di ripristino di File di Azure è in genere di 15 minuti al massimo, anche se attualmente non è previsto alcun contratto di servizio sulla durata della replica dei dati nell'area secondaria.
Importante
L'archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona non è supportata per le condivisioni file di Azure premium. Tuttavia, è possibile eseguire la sincronizzazione tra due condivisioni file di Azure per ottenere la ridondanza geografica.
Progettare la disponibilità elevata
È importante progettare l'applicazione per la disponibilità elevata fin dall'inizio. Per materiale sussidiario 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 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.
È anche consigliabile progettare l'applicazione in modo da 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.
Come procedura consigliata, progettare l'applicazione in modo da controllare la proprietà Data e 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 eseguire una sottoscrizione al dashboard per l'integrità dei servizi di Azure per tenere traccia dell'integrità e dello stato di File di Azure e altri servizi di Azure.
Informazioni sul processo di failover dell'account
Il failover dell'account gestito dal cliente consente di eseguire il failover dell'intero account di archiviazione nell'area secondaria se quella 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. È consigliabile sospendere 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 in un account di archiviazione nell'area primaria e tali dati vengono copiati in modo asincrono nell'area secondaria. L'immagine seguente illustra lo scenario quando l'area primaria è disponibile:
Se per qualsiasi motivo l'endpoint primario non è disponibile, il cliente non può più scrivere nell'account di archiviazione. L'immagine seguente illustra lo scenario in cui l'endpoint primario non è più disponibile, ma non è ancora stato eseguito il ripristino:
Il cliente avvia il failover dell'account nell'endpoint secondario. Il processo di failover aggiorna la voce DNS fornita da Archiviazione di Azure in modo che l'endpoint secondario diventi il nuovo endpoint primario per l'account di archiviazione, come illustrato nell'immagine seguente:
L'accesso in scrittura viene ripristinato per gli account con ridondanza geografica dopo che la voce DNS è stata aggiornata e le richieste vengono indirizzate al nuovo endpoint primario. Gli endpoint del servizio di archiviazione esistenti rimangono invariati 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.
Importante
Al termine del failover, l'account di archiviazione viene configurato come account con ridondanza locale nel nuovo endpoint primario/nella nuova area primaria. Per riprendere la replica in una nuova area secondaria, riconfigurare l'account per la ridondanza geografica.
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.
Prevenire la perdita di dati
Attenzione
Un failover dell'account in genere comporta una perdita di dati. È importante comprendere le implicazioni dell'avvio di un failover dell'account.
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.
Tutti i dati già copiati nell'area secondaria vengono mantenuti quando si verifica il failover. Tuttavia, gli eventuali dati scritti nell'area primaria non copiati in quella secondaria vengono persi definitivamente.
Controllare la proprietà Ora 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 assicurarsi che le condivisioni file siano in uno stato coerente quando si verifica un failover, ogni 15 minuti viene creato uno snapshot di sistema nell'area primaria, che viene replicato nell'area secondaria. Quando si verifica un failover nell'area secondaria, lo stato della condivisione sarà basato sullo snapshot di sistema più recente nell'area secondaria. Se si verifica un errore nell'area primaria, è probabile che l'area secondaria rimanga indietro rispetto all'area primaria perché tutte le operazioni di scrittura nell'area primaria non saranno ancora state replicate nell'area secondaria. A causa del ritardo geografico o di altri problemi, lo snapshot di sistema più recente nell'area secondaria potrebbe risalire a più di 15 minuti prima.
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 failover dall'area primaria a quella secondaria, l'account di archiviazione viene configurato come account 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, l'area primaria originale precedente al failover diventa nuovamente l'area primaria e viene configurata in modo da essere ridondante a livello locale o della zona, a seconda che la configurazione primaria originale fosse archiviazione con ridondanza geografica o archiviazione con ridondanza geografica della zona. 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 in cui i dati sono stati scritti nella nuova area primaria 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 un failover dell'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.
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. Si avrà di nuovo accesso in scrittura all'account di archiviazione solo dopo il completamento del failover gestito da Microsoft.