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.
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.
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é Azure File Sync 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.
Si applica a
| Modello di gestione | Modello di fatturazione | Livello supporti | Ridondanza | PMI (Piccole e Medie Imprese) | NFS |
|---|---|---|---|---|---|
| Microsoft.Storage | Con provisioning v2 | SSD (Premium) | Locale |
|
|
| Microsoft.Storage | Con provisioning v2 | SSD (Premium) | Della zona |
|
|
| Microsoft.Storage | Con provisioning v2 | HDD (standard) | Locale |
|
|
| Microsoft.Storage | Con provisioning v2 | HDD (standard) | Della zona |
|
|
| Microsoft.Storage | Con provisioning v2 | HDD (standard) | Geografica |
|
|
| Microsoft.Storage | Con provisioning v2 | HDD (standard) | GeoZone (GZRS) |
|
|
| Microsoft.Storage | Con provisioning v1 | SSD (Premium) | Locale |
|
|
| Microsoft.Storage | Con provisioning v1 | SSD (Premium) | Della zona |
|
|
| Microsoft.Storage | Pagamento in base al consumo | HDD (standard) | Locale |
|
|
| Microsoft.Storage | Pagamento in base al consumo | HDD (standard) | Della zona |
|
|
| Microsoft.Storage | Pagamento in base al consumo | HDD (standard) | Geografica |
|
|
| Microsoft.Storage | Pagamento in base al consumo | HDD (standard) | GeoZone (GZRS) |
|
|
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.
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).
Importante
Il failover pianificato gestito dal cliente è disponibile in tutte le aree pubbliche che supportano GRS/GZRS, con le seguenti eccezioni:
- West India
- Switzerland West
Per determinare se una regione supporta GZRS, vedere l'elenco delle regioni di Azure. Per supportare GZRS, una regione deve supportare le zone di disponibilità e avere una regione abbinata.
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. 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 nella regione primaria e l'ultima operazione di scrittura nella regione secondaria è il RPO. L'RPO di Azure Files è in genere di 15 minuti o meno, anche se attualmente non è previsto alcun SLA sulla durata della replica dei dati nell'area secondaria.
Importante
L’archiviazione con ridondanza geografica e l’archiviazione con ridondanza geografica della zona non sono supportate per le condivisioni file SSD. Tuttavia, è possibile eseguire la sincronizzazione tra due condivisioni file di Azure per ottenere la ridondanza geografica.
Progettazione per alta disponibilità
È 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à 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 Azure Files e altri servizi 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 Azure Storage in modo che l'endpoint secondario diventa il nuovo endpoint primario per l'account di archiviazione Azure, 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 Tempi 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à 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 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 è 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 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.
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.