Avviare un failover dell'account di archiviazione
Microsoft si impegna per fare in modo che i servizi di Azure siano sempre disponibili. Potrebbero tuttavia verificarsi interruzioni dei servizi occasionali non pianificate. Per ridurre al minimo i tempi di inattività, Archiviazione di Azure supporta il failover gestito dal cliente per mantenere i dati disponibili durante interruzioni parziali e complete.
Questo articolo illustra come avviare un failover per l'account di archiviazione usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni sul failover dell'account, vedere Pianificazione del ripristino di emergenza di Archiviazione di Azure e failover.
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.
Prerequisiti
Esaminare questi argomenti importanti descritti in dettaglio nell'articolo Indicazioni sul ripristino di emergenza prima di avviare un failover gestito dal cliente.
- Potenziale perdita di dati: deve essere prevista una perdita di dati durante un failover non pianificato dell'account di archiviazione. Per informazioni dettagliate sulle implicazioni di un failover di un account non pianificato e su come prepararsi per la perdita di dati, vedere la sezione Prevedere la perdita e le incoerenze dei dati.
- Ridondanza geografica: prima di poter eseguire un failover, l'account di archiviazione deve essere configurato per la ridondanza geografica. Prima che il processo di failover possa iniziare, è necessario completare la sincronizzazione iniziale dall'area primaria all'area secondaria. Se l'account non è configurato per la ridondanza geografica, è possibile modificarlo seguendo i passaggi descritti nell'articolo Modificare la modalità di replica di un account di archiviazione. Per altre informazioni sulle opzioni di ridondanza di Archiviazione di Azure, vedere l'articolo Ridondanza di Archiviazione di Azure.
- Informazioni sui diversi tipi di failover dell'account: esistono due tipi di failover gestito dal cliente. Vedere l'articolo Pianificare il failover per informazioni sui potenziali casi d'uso per ogni tipo e su come differiscono.
- Pianificare le funzionalità e i servizi non supportati: esaminare l'articolo Funzionalità e servizi non supportati ed eseguire le azioni appropriate prima di avviare un failover.
- Tipi di account di archiviazione supportati: assicurarsi che il tipo di account di archiviazione possa essere usato per avviare un failover. Vedere Tipi di account di archiviazione supportati.
- Delineare le aspettative per i tempi e i costi: il tempo necessario per completare il processo di failover gestito dal cliente può variare, ma in genere richiede meno di un'ora. Un failover non pianificato comporta la perdita della configurazione della ridondanza geografica. La riconfigurazione dell'archiviazione con ridondanza geografica in genere comporta tempi e costi aggiuntivi. Per altre informazioni, vedere la sezione Temi e costi del failover.
Avviare il failover
È possibile avviare un failover pianificato o non pianificato gestito dal cliente usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.
Nota
È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.
Completare i passaggi seguenti per avviare un failover dell'account usando il portale di Azure:
Passa all'account di archiviazione.
Selezionare Ridondanza all'interno del gruppo Gestione dati. L'immagine seguente mostra la configurazione della ridondanza geografica e lo stato del failover di un account di archiviazione.
Verificare che l'account di archiviazione sia configurato per l'archiviazione con ridondanza geografica (archiviazione con ridondanza geografica, archiviazione con ridondanza geografica e accesso in lettura, archiviazione con ridondanza geografica della zona o archiviazione con ridondanza geografica della zona e accesso in lettura). In caso contrario, selezionare la configurazione di ridondanza desiderata dall'elenco a discesa Ridondanza e selezionare Salva per eseguire il commit della modifica. Dopo la modifica della configurazione della ridondanza geografica, i dati vengono sincronizzati dall'area primaria all'area secondaria. Questa sincronizzazione richiede alcuni minuti e il failover non può essere avviato fino a quando non vengono replicati tutti i dati. Il messaggio seguente viene visualizzato fino al completamento della sincronizzazione:
Selezionare Prepararsi per il failover gestito dal cliente come illustrato nell'immagine seguente:
Selezionare il tipo di failover per cui ci si sta preparando. La pagina di conferma varia a seconda del tipo di failover selezionato. Se si seleziona
Unplanned Failover
:Viene visualizzato un avviso per segnalare la potenziale perdita di dati e per informazioni sulla necessità di riconfigurare manualmente la ridondanza geografica dopo il failover:
Se si seleziona
Planned failover
(anteprima):Viene visualizzato il valore Ora ultima sincronizzazione. Il failover non viene eseguito fino a quando tutti i dati vengono sincronizzati con l'area secondaria, impedendo la perdita dei dati.
Poiché la configurazione della ridondanza all'interno di ogni area non cambia durante un failover pianificato o un failback, non è necessario riconfigurare manualmente la ridondanza geografica dopo un failover.
Esaminare la pagina Prepararsi per il failover. Quando si è pronti, digitare sì e selezionare Failover per confermare e avviare il processo di failover.
Viene visualizzato un messaggio per indicare che il failover è in corso:
Monitorare il failback
È possibile monitorare lo stato del failover usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.
Lo stato del failover viene visualizzato nel portale di Azure in Notifiche, nel log attività e nella pagina Ridondanza dell'account di archiviazione.
Notifications
Per controllare lo stato del failover, selezionare l'icona di notifica a forma di campana all'estrema destra dell'intestazione della pagina globale del portale di Azure:
Log attività
Per visualizzare lo stato dettagliato di un failover, selezionare il collegamento Altri eventi nel log attività nella notifica oppure passare alla pagina Log attività dell'account di archiviazione:
Pagina di ridondanza
I messaggi nella pagina di ridondanza dell'account di archiviazione vengono visualizzati per fornire gli aggiornamenti dello stato del failover:
Se il failover sta per essere completato, la pagina di ridondanza potrebbe mostrare l'area secondaria originale come nuova replica primaria, ma visualizza comunque un messaggio che indica che il failover è in corso:
Al termine del failover, la pagina di ridondanza visualizza l'ora dell'ultimo failover e la posizione della nuova area primaria. Nel caso di un failover pianificato, viene visualizzata anche la nuova area secondaria. L'immagine seguente mostra lo stato del nuovo account di archiviazione dopo un failover non pianificato:
Implicazioni importanti del failover non pianificato
Quando si avvia un failover non pianificato, vengono aggiornati i record DNS per l'endpoint secondario in modo che l'endpoint secondario diventi l'endpoint primario. Assicurarsi di aver compreso l'impatto potenziale sull'account di archiviazione prima di avviare un failover.
Per valutare la portata della possibile perdita di dati prima di avviare un failover, controllare la proprietà Ora ultima sincronizzazione. Per altre informazioni sul controllo della proprietà Ora ultima sincronizzazione, vedere Controlla la proprietà Last Sync Time per un account di archiviazione.
Il tempo necessario per il failover dopo l'avvio può variare anche se in genere è inferiore a un'ora.
Dopo il failover, il tipo di account di archiviazione viene convertito automaticamente in archiviazione con ridondanza locale nella nuova area primaria. È possibile abilitare nuovamente l'archiviazione con ridondanza geografica o l'archiviazione con ridondanza geografica e accesso in lettura per l'account. Tenere presente che la conversione da archiviazione con ridondanza locale ad archiviazione con ridondanza geografica o archiviazione con ridondanza geografica e accesso in lettura comporta un costo aggiuntivo. Il costo è dovuto agli addebiti in uscita di rete per replicare nuovamente i dati nella nuova area secondaria. Per altre informazioni, vedere Dettagli sui prezzi per la larghezza di banda.
Dopo avere nuovamente abilitato l'archiviazione con ridondanza geografica per l'account di archiviazione, Microsoft inizia la replica dei dati dell'account nella nuova area secondaria. Il tempo di replica dipende da molti fattori, tra cui:
- Numero e dimensioni degli oggetti nell'account di archiviazione. Molti oggetti di piccole dimensioni possono richiedere più tempo di un numero inferiore di oggetti più grandi.
- Risorse disponibili per la replica in background, ad esempio CPU, memoria, disco e capacità WAN. Il traffico in tempo reale ha la priorità sulla replica geografica.
- Se si usa l'archiviazione BLOB, il numero di snapshot per BLOB.
- Se si usa l'archiviazione tabelle, la strategia di partizionamento dei dati . Il processo di replica non può essere ridimensionato oltre il numero di chiavi di partizione usate.
Quando si verifica un failover non pianificato, tutti i dati nell'area primaria vengono persi man mano che l'area secondaria diventa il nuovo database primario. Tutte le operazioni di scrittura eseguite nell'account di archiviazione dell'area primaria devono essere ripetute dopo la riattivazione della ridondanza geografica. Per altre informazioni, vedere Pianificazione del ripristino di emergenza di Archiviazione di Azure e failover.
Il provider di risorse di Archiviazione di Azure non esegue il failover durante il relativo processo. Di conseguenza, la proprietà Percorso dell'API REST di Archiviazione di Azure continua a restituire il percorso originale al termine del failover.
Il failover dell'account di archiviazione è una soluzione temporanea a un'interruzione del servizio e non deve essere usato come parte della strategia di migrazione dei dati. Per informazioni su come eseguire la migrazione degli account di archiviazione, vedere Panoramica della migrazione di Archiviazione di Azure.
Vedi anche
- Ripristino di emergenza e failover dell'account di archiviazione
- Controllare la proprietà Last Sync Time per un account di archiviazione
- Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata
- Esercitazione: Creare un'applicazione a disponibilità elevata con l'archivio BLOB