Affidabilità in Archiviazione BLOB di Azure

Archiviazione BLOB di Azure è una soluzione di archiviazione oggetti per il cloud di Microsoft. È progettato per archiviare grandi quantità di dati non strutturati, ad esempio testo, dati binari, documenti, file multimediali e backup dell'applicazione. Come servizio di archiviazione di Azure di base, Archiviazione BLOB offre più funzionalità di affidabilità per garantire che i dati rimangano disponibili e durevoli durante eventi pianificati e non pianificati.

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 Blob Storage resiliente a una vasta gamma di potenziali interruzioni e problemi, inclusi errori temporanei, interruzioni delle zone di disponibilità e delle regioni. Descrive anche come usare i backup per eseguire il ripristino da altri tipi di problemi ed evidenzia alcune informazioni chiave sul contratto di servizio di archiviazione BLOB.

Annotazioni

Archiviazione BLOB fa parte della piattaforma di Archiviazione di Azure. Alcune delle funzionalità del servizio di Archiviazione BLOB sono comuni a molti servizi di Archiviazione di Azure. In questo articolo si usa Archiviazione di Azure per fare riferimento a queste funzionalità.

Raccomandazioni per la distribuzione di produzione

Per informazioni su come distribuire Archiviazione BLOB per supportare i requisiti di affidabilità della soluzione e su come l'affidabilità influisce su altri aspetti dell'architettura, vedere Procedure consigliate per l'architettura per Archiviazione BLOB in Azure Well-Architected Framework.

Panoramica dell'architettura di affidabilità

Archiviazione di Azure offre diverse opzioni di ridondanza che consentono di proteggere i dati da diversi tipi di errori. Ogni opzione offre un livello specifico di ridondanza dei dati, in modo da poter scegliere il livello più adatto ai requisiti dell'applicazione.

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 Informazioni sulle 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 ripetendo 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 Raccomandazioni per la gestione degli errori temporanei.

Per gestire in modo efficace gli errori temporanei quando si usa Archiviazione BLOB di Azure, implementare le raccomandazioni seguenti:

• Usare le librerie client di Archiviazione di Azure, che includono criteri di ripetizione dei tentativi predefiniti con backoff esponenziale e jitter. Gli SDK .NET, Java, Python e JavaScript gestiscono automaticamente i tentativi per gli errori temporanei. Per altre informazioni sulle opzioni di configurazione della ripetizione dei tentativi, vedere Implementare un criterio di ripetizione con .NET.

• Configurare i valori di timeout appropriati per le operazioni BLOB in base alle dimensioni dei BLOB e alle condizioni di rete. I BLOB più grandi richiedono timeout più lunghi, ma le operazioni più piccole possono usare valori più brevi per rilevare rapidamente gli errori.

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 BLOB offre un supporto della zona di disponibilità solido, tramite configurazioni di archiviazione con ridondanza della zona (ZRS) che distribuiscono automaticamente i dati tra più zone di disponibilità all'interno di un'area. A differenza dell'archiviazione con ridondanza locale (LRS), l'archiviazione con ridondanza della zona (ZRS) garantisce che Azure replichi in modo sincrono i dati BLOB 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.

La ridondanza della zona è abilitata a livello di account di archiviazione e si applica a tutti i contenitori BLOB all'interno di tale account. Non è possibile impostare livelli di ridondanza diversi per singoli contenitori. La configurazione della ridondanza viene applicata all'intero account di archiviazione. Quando si verifica l'interruzione di una zona di disponibilità, Archiviazione di Azure esegue automaticamente il routing delle richieste alle zone integre senza richiedere l'intervento dell'utente o 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.

Requisiti

• 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: La ridondanza della zona è disponibile sia per gli account di archiviazione Standard general-purpose v2 sia per gli account di archiviazione Premium Block Blob. I BLOB in blocchi, i BLOB di accodamento e i BLOB di pagine supportano tutti le configurazioni con ridondanza della zona, ma il tipo di account di archiviazione usato determina quali funzionalità sono disponibili. Per altre informazioni, vedere Tipi di account di archiviazione supportati.

Costo

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 altre informazioni, vedere Prezzi di Archiviazione BLOB.

Configurare il supporto delle zone di disponibilità

• Creare un account di archiviazione BLOB con ridondanza della zona. Per creare un nuovo account di archiviazione con archiviazione con ridondanza della zona (ZRS), vedere Creare un account di archiviazione e selezionare Archiviazione con ridondanza della zona (ZRS), Archiviazione con ridondanza geografica della zona (GZRS) o Archiviazione con ridondanza geografica della zona e accesso in lettura (RA-GZRS) come opzione di ridondanza durante la creazione dell'account.

• 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 BLOB è 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

Questa sezione descrive cosa aspettarsi quando un account di archiviazione BLOB è configurato per Archiviazione con ridondanza della zona e si verifica un'interruzione della zona di disponibilità.

• 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 anteprima potrebbero essere eliminate durante il processo di ripristino e devono essere ritentate. 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.

• Reindirizzamento del traffico: se una zona di disponibilità diventa offline, Azure avvia modifiche di rete come il ripristino del DNS (Domain Name System). Questi aggiornamenti assicurano che il traffico venga reindirizzato alle zone di disponibilità integre rimanenti. Il servizio mantiene la funzionalità completa usando le zone sopravvissute e non richiede 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.

Importante

Archiviazione con ridondanza geografica funziona solo nelle aree abbinate di Azure. Se l'area dell'account di archiviazione non è associata, considera 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.

Requisiti

• 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, considera 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.

Considerazioni

Quando si implementa l'archiviazione BLOB in più aree, considerare i fattori chiave 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.

Costo

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 altre informazioni, vedere Prezzi di Archiviazione BLOB.

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.

  Avvertimento

  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

    Avvertimento

    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.

  Importante

  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.

È 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.

La replica di oggetti offre un'opzione aggiuntiva per la replica dei dati tra aree che fornisce la copia asincrona di BLOB in blocchi tra gli account di archiviazione. A differenza delle opzioni di archiviazione con ridondanza geografica predefinite che usano aree associate fisse, la replica di oggetti consente di replicare i dati tra account di archiviazione in qualsiasi area di Azure, incluse le aree non abbinate. Questo approccio offre il controllo completo sulle aree di origine e di destinazione, i criteri di replica e i contenitori e i prefissi BLOB specifici da replicare.

È possibile configurare la replica di oggetti per replicare tutti i BLOB all'interno di un contenitore o sottoinsiemi specifici in base a prefissi e tag BLOB. La replica è asincrona e si verifica in background. È possibile configurare criteri di replica multipli e persino concatenare la replica tra più account di archiviazione per creare topologie sofisticate in più aree.

La replica di oggetti non è compatibile con tutti gli account di archiviazione. Ad esempio, non funziona con account di archiviazione che usano spazi dei nomi gerarchici (noti anche come account Azure Data Lake Storage Gen2).

Per altre informazioni, vedere Replica di oggetti per i BLOB in blocchi e Configurare la replica di oggetti.

Backup e ripristino

Archiviazione BLOB offre più meccanismi di protezione dei dati che integrano la ridondanza per strategie di backup complete. La ridondanza predefinita del servizio protegge da errori dell'infrastruttura e funzionalità di backup aggiuntive proteggono dall'eliminazione accidentale, dal danneggiamento e dalle attività dannose.

Il ripristino temporizzato (PITR) consente di ripristinare i dati BLOB in blocchi in uno stato precedente entro un periodo di conservazione configurato di un massimo di 365 giorni. Microsoft gestisce completamente questa funzionalità. Offre anche funzionalità di ripristino granulare a livello di contenitore o BLOB. I dati PITR vengono archiviati nella stessa area dell'account di origine e sono accessibili anche durante le interruzioni a livello di area se si usano configurazioni con ridondanza geografica.

Il controllo versioni BLOB mantiene automaticamente le versioni precedenti dei BLOB quando vengono modificate o eliminate. Ogni versione viene archiviata come oggetto separato ed è accessibile in modo indipendente. Le versioni vengono archiviate nella stessa area del BLOB corrente e seguono la stessa configurazione di ridondanza dell'account di archiviazione.

L'eliminazione temporanea fornisce una rete di sicurezza per BLOB e contenitori eliminati accidentalmente conservando i dati eliminati per un periodo configurabile. I dati eliminati temporaneamente rimangono nello stesso account di archiviazione e nella stessa area, per cui sono immediatamente disponibili per il ripristino. Per gli account con ridondanza geografica, anche i dati eliminati emergenza vengono replicati nell'area secondaria.

Gli snapshot BLOB creano copie temporizzate e di sola lettura dei BLOB che è possibile usare per scenari di backup e ripristino. Gli snapshot vengono archiviati nello stesso account di archiviazione e seguono le stesse impostazioni di ridondanza e replica geografica del BLOB di base.

Per i requisiti di backup tra aree, prendere considerare l'uso di Backup di Azure per BLOB, che offre una gestione centralizzata dei backup e può archiviare i dati di backup in aree diverse dai dati di origine. Questo servizio offre opzioni di backup operative e con insieme di credenziali con funzionalità di ripristino e criteri di conservazione configurabili. Per altre informazioni, vedere Panoramica del backup per BLOB.

Per la maggior parte delle soluzioni, non è consigliabile basarsi esclusivamente sui backup. Usare invece le altre funzionalità descritte in questa guida per supportare i requisiti di resilienza. Tuttavia, i backup proteggono da alcuni rischi che altri approcci non comportano. Per altre informazioni, vedere Che cosa sono ridondanza, replica e backup?.

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

• Panoramica dell'archiviazione BLOB
• Redondanza di Archiviazione di Azure
• Ripristino di emergenza e failover dell'account di archiviazione
• Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata
• Modificare la modalità di replica di un account di archiviazione