Affidabilità nel servizio di archiviazione code di Azure

Azure Queue Storage è un servizio per l'archiviazione e la distribuzione di un numero elevato di messaggi. Archiviazione code viene comunemente usata per creare un backlog di lavoro da elaborare in modo asincrono. Fornisce un recapito affidabile dei messaggi per architetture di applicazioni ad accoppiamento libero. Un messaggio in coda può avere dimensioni di fino a 64 KB e una coda può contenere milioni di messaggi, fino al limite di capacità totale di un account di archiviazione.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere resiliente l'archiviazione delle code a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni delle zone di disponibilità e interruzioni regionali. Descrive anche come usare i backup per il ripristino da altri tipi di problemi ed evidenzia alcune informazioni chiave sul contratto di servizio di archiviazione code.

Note

Archiviazione code fa parte della piattaforma Archiviazione di Azure. Alcune delle funzionalità del servizio di archiviazione code sono comuni a molti servizi di archiviazione di Azure.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Per gli ambienti di produzione:

• Abilitare l'archiviazione con ridondanza della zona per gli account di archiviazione che contengono risorse del servizio di archiviazione code. Archiviazione con ridondanza della zona offre una disponibilità più elevata replicando i dati in modo sincrono in più zone di disponibilità nell'area primaria. Una disponibilità più elevata consente di proteggere gli account di archiviazione da errori della zona di disponibilità.

• Se è necessaria resilienza alle interruzioni dell'area e l'area primaria dell'account di archiviazione è associata, valutare la possibilità di abilitare Archiviazione con ridondanza geografica. Archiviazione con ridondanza geografica replica i dati in modo asincrono nell'area abbinata. Nelle aree supportate è possibile combinare la ridondanza geografica con la ridondanza della zona usando Archiviazione con ridondanza geografica della zona.

Per i requisiti di messaggistica avanzati, è consigliabile usare il bus di servizio di Azure. Per informazioni sulle differenze tra l'archiviazione code e il bus di servizio, vedere Confrontare le code di Archiviazione di Azure e le code del bus di servizio.

Panoramica dell'architettura di affidabilità

Archiviazione code funziona come servizio di messaggistica distribuita all'interno dell'infrastruttura della piattaforma di Archiviazione di Azure. Il servizio fornisce ridondanza tramite più copie dei dati della coda e dei messaggi. Il modello di ridondanza specifico dipende dalla configurazione dell'account di archiviazione.

L'archiviazione con ridondanza locale replica i dati all'interno degli account di archiviazione in una o più zone di disponibilità di Azure che si trovano nell'area primaria desiderata. Anche se non è possibile scegliere la zona di disponibilità preferita, Azure può spostare o espandere gli account LRS tra zone per migliorare il bilanciamento del carico. Non c'è alcuna garanzia che i dati verranno distribuiti tra le zone. Per altre informazioni sulle zone di disponibilità, vedere Che cosa sono le zone di disponibilità?.

Una casella blu rappresenta l'area primaria. Contiene una casella grigia che rappresenta il data center. Una casella viola scuro all'interno della casella del data center rappresenta Archiviazione con ridondanza locale. Contiene una casella viola chiaro che include l'account di archiviazione e tre icone con etichetta copia 1, copia 2 e copia 3.

Archiviazione con ridondanza della zona, Archiviazione con ridondanza geografica e Archiviazione con ridondanza geografica della zona offrono protezioni aggiuntive. Questo articolo descrive in dettaglio queste opzioni.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Consigli per la gestione degli errori temporanei.

Archiviazione code viene comunemente usata nelle applicazioni per contribuire a gestire gli errori temporanei in altri componenti. L'uso della messaggistica asincrona con un servizio come Archiviazione code permette alle applicazioni di eseguire il ripristino da errori temporanei elaborando i messaggi in un secondo momento. Per altre informazioni, vedere Introduzione alla messaggistica asincrona.

All'interno del servizio stesso, Archiviazione code gestisce automaticamente gli errori temporanei usando diversi meccanismi forniti dalla piattaforma di Archiviazione di Azure e dalle librerie client. Il servizio è progettato per fornire funzionalità di accodamento messaggi resilienti anche durante i problemi temporanei dell'infrastruttura.

Le librerie client di Archiviazione code includono criteri di ripetizione predefiniti che gestiscono automaticamente gli errori temporanei comuni, come timeout di rete, mancata disponibilità temporanea del servizio (HTTP 503) e risposte sulla limitazione (HTTP 429). Quando l'applicazione rileva queste condizioni temporanee, le librerie client riprovano automaticamente usando strategie di backoff esponenziale.

Per gestire in modo efficace gli errori temporanei usando Archiviazione code, è possibile eseguire le azioni seguenti:

• Configurare i timeout appropriati nel client del servizio di archiviazione code per bilanciare la velocità di risposta con la resilienza ai rallentamenti temporanei. I timeout predefiniti nelle librerie client di Archiviazione di Azure sono in genere adatti per la maggior parte degli scenari.

• Implementare modelli di interruttore nell'applicazione quando elabora i messaggi dalle code. Gli schemi di interruttore automatico impediscono guasti a catena quando i servizi downstream riscontrano problemi.

• Usare i timeout di visibilità in modo appropriato quando l'applicazione riceve messaggi. I timeout di visibilità assicurano che i messaggi diventino disponibili per i tentativi se l'applicazione rileva errori durante l'elaborazione.

Per altre informazioni sull'architettura di Azure Table Storage e su come progettare applicazioni resilienti e su larga scala, vedere Elenco di controllo per le prestazioni e la scalabilità di Queue Storage.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Archiviazione code di Azure è con ridondanza della zona quando viene distribuita con la configurazione di Archiviazione con ridondanza della zona. A differenza dell'archiviazione con ridondanza locale (LRS), l'archiviazione con ridondanza della zona (ZRS) garantisce che Azure replichi in modo sincrono i dati della coda in più zone di disponibilità. Archiviazione con ridondanza della zona garantisce che i dati rimangano accessibili anche se si verifica un'interruzione di un'area. ZRS garantisce che le code rimangano accessibili anche se un'intera zona di disponibilità non è più disponibile. Prima di completare tutte le operazioni di scrittura, tutte le operazioni di scrittura devono essere riconosciute in più zone, che offrono garanzie di coerenza assoluta.

La ridondanza della zona è abilitata a livello di account di archiviazione e si applica a tutte le risorse del servizio di archiviazione code all'interno di tale account. Non è possibile configurare singole code per livelli di ridondanza diversi. L'impostazione si applica all'intero account di archiviazione. Quando si verifica un'interruzione di una zona di disponibilità, Azure Storage instrada automaticamente le richieste alle zone operative senza richiedere nessun intervento da parte dell'applicazione.

Una casella blu rappresenta l'area primaria. Contiene una casella viola scuro che rappresenta Archiviazione con ridondanza della zona. Questa casella contiene tre caselle bianche che rappresentano la zona di disponibilità 1, la zona di disponibilità 2 e la zona di disponibilità 3. Ogni casella della zona di disponibilità contiene una casella grigia che rappresenta un data center. Ogni casella del data center contiene una casella viola chiaro che include l'account di archiviazione e un'icona con etichetta copia 1, copia 2 e copia 3.

Requirements

• Supporto per l'area: È possibile distribuire account di Archiviazione di Azure con ridondanza della zona in qualsiasi area che supporta le zone di disponibilità.

• Tipi di account di archiviazione: È necessario utilizzare un account di archiviazione Standard per utilizzo generico v2 per abilitare Archiviazione con ridondanza della zona per il servizio di Archiviazione code. Gli account di archiviazione Premium non supportano il servizio di archiviazione code.

Cost

Quando si abilita Archiviazione con ridondanza della zona, vengono addebitati costi a una tariffa diversa rispetto a Archiviazione con ridondanza locale a causa del sovraccarico aggiuntivo di replica e archiviazione.

Per informazioni dettagliate sui prezzi, vedere Prezzi di Archiviazione code.

Configurare il supporto delle zone di disponibilità

• Creare un account di archiviazione e una coda con ridondanza della zona seguendo questa procedura.

  1. Creare un account di archiviazione e selezionare Archiviazione con ridondanza della zona, Archiviazione con ridondanza geografica della zona o Archiviazione con ridondanza geografica e accesso in lettura come opzione di ridondanza durante la creazione dell'account.

  2. Creare una coda.

• Modificare il tipo di replica. Per informazioni su come modificare un account di archiviazione esistente in Archiviazione con ridondanza della zona e per conoscere le opzioni di configurazione e i requisiti, vedere Modificare la modalità di replica di un account di archiviazione.

• Disabilitare la ridondanza della zona. Convertire gli account di Archiviazione con ridondanza della zona in una configurazione non zonale, come Archiviazione con ridondanza locale, usando la stessa procedura usata per la modifica della configurazione della ridondanza.

Comportamento quando tutte le zone sono integre

La sezione seguente descrive cosa aspettarsi quando un piano di archiviazione code è configurato per la ridondanza della zona e tutte le zone di disponibilità sono in funzione.

• Routing del traffico tra zone: Archiviazione di Azure con Archiviazione con ridondanza della zona distribuisce automaticamente le richieste tra cluster di archiviazione in più zone di disponibilità. La distribuzione del traffico è trasparente per le applicazioni e non richiede alcuna configurazione lato client.

• Replica dei dati tra zone: tutte le operazioni di scrittura in Archiviazione con ridondanza della zona vengono replicate in modo sincrono in tutte le zone di disponibilità all'interno dell'area. Quando si caricano o si modificano i dati, l'operazione non viene considerata completa fino a quando i dati non vengono replicati correttamente in tutte le zone di disponibilità. Questa replica sincrona garantisce una coerenza assoluta e una perdita di dati pari a zero durante gli errori della zona.

Comportamento durante un errore di zona

Quando una zona di disponibilità non è più disponibile, Archiviazione code gestisce automaticamente il processo di failover eseguendo le azioni seguenti.

• Rilevamento e risposta: Microsoft rileva automaticamente gli errori della zona e avvia i processi di ripristino. Non è necessaria alcuna azione del cliente per gli account di Archiviazione con ridondanza della zona.

  Se una zona non è più disponibile, Azure esegue aggiornamenti di rete, ad esempio il ripristino del DNS (Domain Name System).

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità risorse di Azure per monitorare l'integrità di una singola risorsa ed è possibile configurare gli avvisi di Integrità risorse per notificare i problemi. È anche possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare i problemi.

• Richieste attive: Le richieste in corso potrebbero essere eliminate durante il processo di ripristino e andrebbero ripetute. Le applicazioni devono implementare la logica di ripetizione dei tentativi per gestire queste interruzioni temporanee.

• Perdita di dati prevista: Non si verifica alcuna perdita di dati durante gli errori di zona perché i dati vengono replicati in modo sincrono in più zone prima del completamento delle operazioni di scrittura.

• Tempo di inattività previsto: un breve periodo di inattività, in genere, alcuni secondi, può verificarsi durante il ripristino automatico perché il traffico viene reindirizzato alle zone integre. Quando si progettano le applicazioni per Archiviazione con ridondanza della zona, è consigliabile seguire le procedure per la gestione degli errori temporanei, tra cui l'implementazione dei criteri di ripetizione con backoff esponenziale.

• Rerouting del traffico. Se una zona non è più disponibile, Azure esegue gli aggiornamenti di rete, ad esempio il repointing DNS (Domain Name System), in modo che le richieste vengano indirizzate alle zone di disponibilità integre rimanenti. Il servizio gestisce tutte le funzionalità usando le zone sopravvissute senza l'intervento del cliente.

Ripristino della zona

Quando la zona di disponibilità che ha riscontrato un problema viene ripristinata, Azure Storage ripristina automaticamente il normale funzionamento in tutte le zone di disponibilità. Il servizio garantisce automaticamente la coerenza dei dati sincronizzando tutte le operazioni che si sono verificate durante il periodo di interruzione.

Verifica dei guasti di zona

Quando si usa Archiviazione con ridondanza della zona, Archiviazione di Azure gestisce automaticamente la replica, il routing del traffico e le risposte verso il basso della zona. Poiché questa funzionalità è completamente gestita, non è necessario avviare o convalidare i processi di errore della zona di disponibilità.

Resilienza agli errori a livello di area

Archiviazione di Azure, tra cui Archiviazione BLOB di Azure, File di Azure, Archiviazione tabelle di Azure e Archiviazione code di Azure, offre una gamma di funzionalità di ridondanza geografica e failover in base a requisiti diversi.

Important

Archiviazione con ridondanza geografica funziona solo nelle aree abbinate di Azure. Se l'area dell'account di archiviazione non è associata, considerare l'uso delle soluzioni personalizzate multi-regionali per la resilienza.

Archiviazione con ridondanza geografica per le aree abbinate

Archiviazione di Azure offre diversi tipi di Archiviazione con ridondanza geografica nelle aree abbinate. Indipendentemente dal tipo di Archiviazione con ridondanza geografica usata, i dati nell'area secondaria vengono sempre replicati usando Archiviazione con ridondanza locale. Questo approccio offre protezione dagli errori hardware all'interno dell'area secondaria.

• Archiviazione con ridondanza geografica offre il supporto per i failover pianificati e non pianificati nell'area abbinata di Azure quando si verifica un'interruzione nell'area primaria. La GRS replica asincronamente i dati dalla regione primaria alla regione di coppia.

  

  Due caselle blu rappresentano l'area primaria e l'area secondaria. Ognuno di essi contiene una casella grigia che rappresenta il data center. Una casella viola scuro all'interno della casella del data center rappresenta Archiviazione con ridondanza locale. Contiene una casella viola chiaro che include l'account di archiviazione e tre icone con etichetta copia 1, copia 2 e copia 3. Una linea tratteggiata che rappresenta Archiviazione con ridondanza geografica include le caselle di Archiviazione con ridondanza locale in entrambe le aree. Freccia con etichetta punti di replica geografica dall'account di archiviazione nell'area primaria all'account di archiviazione nell'area secondaria.

• Archiviazione con ridondanza geografica della zona replica i dati in più zone di disponibilità nell'area primaria e nell'area abbinata.

  

  Una casella blu rappresenta l'area primaria. Contiene una casella viola scuro che rappresenta Archiviazione con ridondanza della zona. Questa casella contiene tre caselle bianche che rappresentano la zona di disponibilità 1, la zona di disponibilità 2 e la zona di disponibilità 3. Ogni casella della zona di disponibilità contiene una casella grigia che rappresenta un data center. Ogni casella del data center contiene una casella viola chiaro che include l'account di archiviazione e un'icona con etichetta copia 1, copia 2 e copia 3. Un'altra casella blu rappresenta l'area secondaria. Tale casella contiene una casella grigia che rappresenta il data center. Una casella viola scuro all'interno della casella del data center rappresenta Archiviazione con ridondanza locale. Contiene una casella viola chiaro che include l'account di archiviazione e tre icone con etichetta copia 1, copia 2 e copia 3. Una linea punteggiata che rappresenta Archiviazione con ridondanza geografica della zona include le caselle di Archiviazione con ridondanza della zona e Archiviazione con ridondanza locale in entrambe le aree. Freccia con etichetta punti di replica geografica da Archiviazione con ridondanza della zona nell'area primaria all'account di archiviazione nell'area secondaria.

Archiviazione con ridondanza geografica

• Archiviazione con ridondanza geografica e accesso in lettura e Archiviazione con ridondanza geografica della zona estende Archiviazione con ridondanza geografica e Archiviazione con ridondanza geografica della zona, con il vantaggio aggiunto dell'accesso in lettura all'endpoint secondario. Queste opzioni sono ideali per le applicazioni progettate per applicazioni business critical a disponibilità elevata. Nel caso improbabile che l'endpoint primario subisca un'interruzione, le applicazioni configurate per l'accesso in lettura all'area secondaria possono continuare a funzionare.

Tipi di failover

Archiviazione di Azure supporta tre tipi di failover per diversi scenari.

• Failover non pianificato gestito dal cliente: l'utente è responsabile dell'avvio del ripristino se si verifica un errore di archiviazione a livello di area nell'area primaria.

• Failover pianificato gestito dal cliente: L'utente è responsabile dell'avvio del ripristino se un'altra parte della soluzione presenta un errore nell'area primaria ed è necessario passare l'intera soluzione a un'area secondaria. Usare un failover pianificato quando l'archiviazione rimane operativa nell'area primaria, ma è necessario eseguire il failover dell'intera soluzione in un'area secondaria, ad esempio per le esercitazioni sul ripristino di emergenza progettate per garantire i requisiti di conformità e controllo.

• Failover gestito da Microsoft: in circostanze eccezionali, Microsoft potrebbe avviare il failover per tutti gli account di Archiviazione con ridondanza geografica in un'area. Tuttavia, il failover gestito da Microsoft è un'ultima risorsa e dovrebbe essere eseguito solo dopo un lungo periodo di interruzione. Non è consigliabile basarsi sul failover gestito da Microsoft.

Gli account con ridondanza geografica possono usare uno di questi tipi di failover. Non è necessario preconfigurare un account di archiviazione per usare in anticipo uno dei tipi di failover.

Requirements

• Supporto per la regione: Le configurazioni geograficamente ridondanti di Archiviazione di Azure usano le regioni accoppiate di Azure per la replica delle regioni secondarie. L'area secondaria viene determinata automaticamente in base alla selezione dell'area primaria e non può essere personalizzata. Per un elenco completo delle aree abbinate di Azure, vedere l'elenco delle aree di Azure.

  Se l'area dell'account di archiviazione non è associata, considerare l'uso delle soluzioni personalizzate multi-regionali per la resilienza.

• Tipi di account di archiviazione: L'archiviazione con ridondanza geografica e il failover e il failback avviati dal cliente sono disponibili in tutte le aree abbinate di Azure che supportano account di archiviazione di Azure per utilizzo generico v2.

Considerations

Quando si implementa Archiviazione code in più aree, prendere in considerazione i fattori importanti seguenti.

• Latenza di replica asincrona: la replica dei dati nell'area secondaria è asincrona, ovvero si verifica un ritardo tra quando i dati vengono scritti nell'area primaria e quando diventano disponibili nell'area secondaria. Questo ritardo può causare una potenziale perdita di dati se si verifica un errore dell'area primaria prima della replica dei dati recenti. La perdita di dati viene misurata dall'obiettivo del punto di ripristino (RPO). È possibile prevedere che il ritardo di replica sia inferiore a 15 minuti, ma questa volta è una stima e non è garantita.

  È possibile controllare la proprietà Ora dell'ultima sincronizzazione per comprendere quanti dati potrebbero andare persi se l'account di archiviazione ha un failover non pianificato.

• Accesso all'area secondaria: con configurazioni di Archiviazione con ridondanza geografica e Archiviazione con ridondanza geografica della zona, l'area secondaria non è accessibile per le letture fino a quando non si verifica un failover.

  Le configurazioni di Archiviazione con ridondanza geografica e accesso in lettura e Archiviazione con ridondanza geografica della zona consentono l'accesso in lettura all'area secondaria durante le normali operazioni, ma a causa della latenza di replica asincrona, potrebbero restituire dati leggermente obsoleti.

• Limitazioni delle funzionalità: alcune funzionalità di Archiviazione di Azure non sono supportate o presentano limitazioni quando si usa Archiviazione con ridondanza geografica o il failover gestito dal cliente. Esaminare la compatibilità delle funzionalità prima di implementare la ridondanza geografica.

Cost

Le configurazioni dell'account di Archiviazione di Azure in più aree comportano costi aggiuntivi per la replica e l'archiviazione tra aree nell'area secondaria. Il trasferimento dei dati tra aree di Azure viene addebitato in base alle tariffe standard della larghezza di banda tra aree.

Per informazioni dettagliate sui prezzi, vedere Prezzi di Archiviazione code.

Configurare il supporto per più aree

• Creare un nuovo account di Archiviazione con ridondanza geografica. Per creare un account con ridondanza geografica, vedere Creare un account di archiviazione e selezionare Archiviazione con ridondanza geografica e accesso in lettura, Archiviazione con ridondanza geografica della zona o Archiviazione con ridondanza geografica e accesso in lettura durante la creazione dell'account.

• Abilitare la ridondanza geografica in un account di archiviazione esistente. Per convertire un account di archiviazione esistente nell'archiviazione con ridondanza geografica, vedere Modificare la modalità di replica di un account di archiviazione.

  Warning

  Dopo aver riconfigurato l'account per la ridondanza geografica, potrebbe essere necessario molto tempo prima che i dati esistenti nella nuova area primaria vengano copiati completamente nella nuova area secondaria.

  Per evitare la perdita di una grande quantità di dati, controllare il valore della proprietà Ora dell'ultima sincronizzazione prima di avviare un failover non pianificato. Per valutare la potenziale perdita di dati, confrontare l'ora dell'ultima sincronizzazione con l'ultima volta in cui i dati sono stati scritti nella nuova regione primaria.

• Disabilitare la ridondanza geografica. Convertire gli account con ridondanza geografica in configurazioni a singola area, ad esempio Archiviazione con ridondanza locale o Archiviazione con ridondanza della zona usando lo stesso processo di modifica della configurazione della ridondanza.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando un account di archiviazione è configurato per la ridondanza geografica e tutte le aree sono operative.

• Routing del traffico tra aree: Archiviazione di Azure usa un approccio attivo-passivo in cui tutte le operazioni di scrittura e la maggior parte delle operazioni di lettura vengono indirizzate all'area primaria.

  Per le configurazioni di Archiviazione con ridondanza geografica e accesso in lettura e Archiviazione con ridondanza geografica della zona, le applicazioni possono facoltativamente leggere dall'area secondaria accedendo all'endpoint secondario. Questo approccio richiede la configurazione esplicita dell'applicazione e non è automatica. Inoltre, a causa del ritardo di replica asincrona, i dati nell'area secondaria potrebbero essere leggermente obsoleti.

• Replica dei dati tra aree: le operazioni di scrittura vengono innanzitutto sottoposte a commit nell'area primaria usando i tipi di ridondanza configurati seguenti:

  • Archiviazione con ridondanza locale per Archiviazione con ridondanza geografica e Archiviazione con ridondanza geografica e accesso in lettura
  • Archiviazione con ridondanza della zona per Archiviazione con ridondanza geografica della zona e Archiviazione con ridondanza geografica della zona e accesso in lettura

  Al termine del completamento nell'area primaria, i dati vengono replicati in modo asincrono nell'area secondaria in cui sono archiviati usando Archiviazione con ridondanza locale.

  La natura asincrona della replica tra aree significa che in genere si verifica un ritardo tra il momento in cui i dati vengono scritti nell'area primaria e quando sono disponibili nell'area secondaria. È possibile monitorare l'ora di replica usando la proprietà Ora dell'ultima sincronizzazione.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando un account di archiviazione è configurato per la ridondanza geografica ed è presente un'interruzione nell'area primaria.

• Failover gestito dal cliente (non pianificato): usare un failover non pianificato quando l'archiviazione nell'area primaria non è disponibile.

  • Rilevamento e risposta: Nel caso improbabile che l'account di archiviazione non sia disponibile nell'area primaria, è possibile prendere in considerazione l'avvio di un failover non pianificato gestito dal cliente. Per prendere questa decisione, considerare i fattori seguenti:

    • Indica se Integrità risorse di Azure riscontra dei problemi di accesso all'account di archiviazione nell'area primaria

    • Indica se Microsoft consiglia di eseguire il failover in un'altra area

    Warning

    Un failover non pianificato può comportare la perdita di dati. Prima di avviare un failover gestito dal cliente, decidere se il ripristino del servizio giustifica il rischio di perdita di dati.

  • Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. Tuttavia:

    • È possibile usare Integrità risorse di Azure per monitorare l'integrità di una singola risorsa ed è possibile configurare gli avvisi di Integrità risorse per notificare i problemi.

    • È possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori dell'area, ed è possibile configurare gli avvisi di integrità dei servizi per notificare i problemi.

  • Richieste attive: Durante il processo di failover, gli endpoint dell'account di archiviazione primario e secondario diventano temporaneamente non disponibili sia per le letture che per le scritture. Eventuali richieste attive potrebbero essere eliminate e le applicazioni client devono riprovare al termine del failover.

  • Perdita di dati prevista: la perdita di dati è comune durante un failover non pianificato a causa del ritardo di replica asincrona, il che significa che le scritture recenti potrebbero non essere replicate. È possibile controllare la proprietà Ora dell'ultima sincronizzazione per comprendere quanti dati potrebbero andare persi durante un failover non pianificato. La perdita di dati prevista viene spesso definita obiettivo del punto di ripristino (RPO). In genere, è possibile prevedere che l'RPO sia inferiore a 15 minuti, ma tale tempo non è garantito.

  • Tempo di inattività previsto: La quantità di tempo di inattività previsto viene spesso definita obiettivo del tempo di ripristino (RTO). Il failover gestito dal cliente viene in genere completato entro 60 minuti, a seconda delle dimensioni e della complessità dell'account.

  • Reindirizzamento del traffico: Al termine del failover, Azure aggiorna automaticamente gli endpoint dell'account di archiviazione in modo che le applicazioni non debbano essere riconfigurate. Se l'applicazione mantiene memorizzate nella cache le voci DNS (Domain Name System), potrebbe essere necessario cancellare la cache per assicurarsi che l'applicazione invii traffico alla nuova area primaria.

  • Configurazione post-failover: al termine di un failover non pianificato, l'account di archiviazione nell'area di destinazione usa il livello di Archiviazione con ridondanza locale. Se è necessario eseguire di nuovo la replica geografica, è necessario riabilitare Archiviazione con ridondanza geografica e attendere che i dati vengano replicati nella nuova area secondaria.

  Per altre informazioni su come avviare il failover gestito dal cliente, vedere Funzionamento del failover gestito dal cliente (non pianificato) e Avviare un failover dell'account di archiviazione.

• Failover gestito dal cliente (pianificato): usare un failover pianificato quando l'archiviazione rimane operativa nell'area primaria; tuttavia, è necessario eseguire il failover dell'intera soluzione in un'area secondaria per un altro motivo. Ad esempio, un altro servizio di Azure potrebbe riscontrare un problema ed è necessario passare all'uso di un'area secondaria per l'intera soluzione. In alternativa, è possibile usare un failover pianificato per condurre un'esercitazione di ripristino di emergenza ai fini della conformità e degli audit.

  • Rilevamento e risposta: Sei responsabile della decisione di effettuare il failover. Questa decisione è generalmente necessaria quando il failover tra le aree è necessario anche se l'account di archiviazione è integro. Ad esempio, è possibile attivare un failover quando si verifica un'interruzione principale di un altro componente dell'applicazione da cui non è possibile eseguire il ripristino nell'area primaria.

    • Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. Tuttavia:

      • È possibile usare Integrità risorse di Azure per monitorare l'integrità di una singola risorsa ed è possibile configurare gli avvisi di Integrità risorse per notificare i problemi.

      • È possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori dell'area, ed è possibile configurare gli avvisi di integrità dei servizi per notificare i problemi.

  • Richieste attive: Durante il processo di failover, gli endpoint dell'account di archiviazione primario e secondario diventano temporaneamente non disponibili sia per le letture che per le scritture. Eventuali richieste attive potrebbero essere eliminate e le applicazioni client devono riprovare al termine del failover.

  • Perdita di dati prevista: Non è prevista alcuna perdita di dati perché il processo di failover viene completato solo dopo la sincronizzazione di tutti i dati, con un RPO pari a zero.

  • Tempo di inattività previsto: Il failover viene in genere completato entro 60 minuti, il che significa che l'obiettivo RTO previsto è di 60 minuti, a seconda delle dimensioni e della complessità dell'account. Durante il processo di failover, gli endpoint dell'account di archiviazione primario e secondario diventano temporaneamente non disponibili sia per le letture che per le scritture.

  • Reindirizzamento del traffico: Al termine del failover, Azure aggiorna automaticamente gli endpoint dell'account di archiviazione in modo che le applicazioni non debbano essere riconfigurate. Se l'applicazione mantiene memorizzate nella cache le voci DNS, potrebbe essere necessario cancellare la cache per assicurarsi che l'applicazione invii traffico alla nuova area primaria.

  • Configurazione post-failover: Al termine di un failover pianificato, l'account di archiviazione nell'area di destinazione continua a essere replicato geograficamente e rimane nel livello GRS.

  Per altre informazioni su come avviare il failover gestito dal cliente, vedere Funzionamento del failover gestito dal cliente (pianificato) e Avviare un failover dell'account di archiviazione.

• Failover gestito da Microsoft: Nel raro caso di un'emergenza grave in cui Microsoft determina che l'area primaria è permanentemente irreversibile, potrebbe essere avviato un failover automatico nell'area secondaria. Microsoft gestisce l'intero processo e non è necessaria alcuna azione del cliente. La quantità di tempo trascorsa prima che si verifichi il failover dipende dalla gravità dell'emergenza e dal tempo necessario per valutare la situazione.

  • Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. Tuttavia:

    • È possibile usare Integrità risorse di Azure per monitorare l'integrità di una singola risorsa ed è possibile configurare gli avvisi di Integrità risorse per notificare i problemi.

    • È possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori dell'area, ed è possibile configurare gli avvisi di integrità dei servizi per notificare i problemi.

  Important

  Usare le opzioni di failover gestite dal cliente per sviluppare, testare e implementare i piani di ripristino di emergenza. Non basarsi sul failover gestito da Microsoft, che verrebbe usato solo in circostanze estreme. È probabile che venga avviato un failover gestito da Microsoft per un'intera area. Non può essere avviato per singoli account di archiviazione, sottoscrizioni o clienti. Il failover può verificarsi in momenti diversi per diversi servizi di Azure. È consigliabile usare il failover gestito dal cliente.

Ripristino della regione

Il processo di failback differisce in modo significativo tra gli scenari di failover gestiti da Microsoft e gestiti dal cliente.

• Failover gestito dal cliente (non pianificato): dopo un failover non pianificato, l'account di archiviazione viene configurato con Archiviazione con ridondanza locale. Per eseguire il failback, è necessario ristabilire la relazione di Archiviazione con ridondanza geografica e attendere la replica dei dati.

• Failover gestito dal cliente (pianificato): dopo un failover pianificato, l'account di archiviazione rimane con replica geografica. È possibile avviare un altro failover gestito dal cliente per eseguire il failback nell'area primaria originale. Si applicano le stesse considerazioni sul failover.

• Failover gestito da Microsoft: se Microsoft avvia un failover, è probabile che si sia verificata un'emergenza significativa nell'area primaria e che l'area primaria non sia recuperabile. Qualsiasi sequenza temporale o piano di ripristino dipende dalla portata delle attività di ripristino e di emergenza a livello di area. Per informazioni dettagliate, è consigliabile monitorare le comunicazioni sull'integrità dei servizi di Azure.

Test per guasti a livello di area

È possibile simulare errori a livello di area per testare le procedure di ripristino di emergenza.

• Test di failover pianificati: per gli account di Archiviazione con ridondanza geografica, è possibile eseguire operazioni di failover pianificate durante le finestre di manutenzione per testare il failover completo e il processo di failback. Il failover pianificato non richiede la perdita di dati, ma comporta tempi di inattività sia durante il failover che il failback.

• Test dell'endpoint secondario: per le configurazioni di Archiviazione con ridondanza geografica e accesso in lettura e Archiviazione con ridondanza geografica della zona, testare regolarmente le operazioni di lettura sull'endpoint secondario per garantire che l'applicazione possa leggere correttamente i dati dall'area secondaria.

Soluzioni personalizzate in più aree per la resilienza

Le funzionalità di failover tra aree di Archiviazione di Azure potrebbero non essere adatte a causa dei motivi seguenti:

• L'account di archiviazione si trova in un'area non abbinata.

• Gli obiettivi di disponibilità operativa aziendale non sono soddisfatti dal tempo di ripristino o dalla perdita di dati offerti dalle opzioni di failover predefinite.

• È necessario eseguire il failover in un'area che non è accoppiata con la propria area primaria.

• È necessaria una configurazione attiva/attiva tra aree.

Questa sezione offre una panoramica generale di alcuni approcci da considerare. Una panoramica completa delle topologie di distribuzione in più aree per Archiviazione di Azure non rientra nell'ambito di questo articolo.

Note

Per i requisiti avanzati per più aree, prendere in considerazione l'uso del bus di servizio, che include il supporto per le aree non abbinate.

È possibile distribuire Archiviazione di Azure in più aree usando account di archiviazione separati in ogni area. Questo approccio offre flessibilità nella selezione dell'area, la possibilità di usare aree non abbinate e un controllo più granulare sui tempi di replica e sulla coerenza dei dati. Quando si implementano più account di archiviazione tra aree, è necessario configurare la replica dei dati tra aree, implementare il bilanciamento del carico e i criteri di failover e garantire la coerenza dei dati tra aree.

Questo approccio richiede di gestire la distribuzione dei messaggi, gestire la sincronizzazione dei dati tra le code nei diversi account di archiviazione e implementare la logica di failover personalizzata.

Backup e ripristino

Archiviazione code non offre funzionalità di backup tradizionali, ad esempio il ripristino temporizzato. Ciò è dovuto al fatto che le code sono progettate per l'archiviazione dei messaggi temporanei anziché persistenza dei dati a lungo termine. I messaggi vengono in genere elaborati e rimossi dalle code durante il normale funzionamento dell'applicazione.

Per scenari che richiedono durabilità dei messaggi oltre le opzioni di ridondanza predefinite, è consigliabile implementare la registrazione o la persistenza dei messaggi a livello di applicazione in un archivio dati permanente, ad esempio Archiviazione BLOB o Database SQL di Azure. Questo approccio consente di mantenere la cronologia dei messaggi utilizzando Queue Storage per il suo scopo previsto di bufferizzazione temporanea dei messaggi e coordinamento dell'elaborazione.

Contratto di servizio

Il contratto di servizio per Archiviazione di Azure descrive la disponibilità prevista del servizio e le condizioni che devono essere soddisfatte per raggiungere tale aspettativa di disponibilità. Il contratto di servizio di disponibilità per cui si è idonei dipende dal livello di archiviazione e dal tipo di replica usato. Per altre informazioni, vedere Contratti di servizio per i servizi online.

Contenuti correlati

• Informazioni su Archiviazione code
• Redondanza di Archiviazione di Azure
• Failover e pianificazione del ripristino di emergenza di Archiviazione di Azure
• Cosa sono le zone di disponibilità?
• Affidabilità di Azure
• Raccomandazioni per la gestione degli errori temporanei