Affidabilità in Azure Cosmos DB

Azure Cosmos DB per NoSQL è un servizio di database multimodello distribuito a livello globale che supporta modelli di dati documento con schemi flessibili. Azure Cosmos DB offre funzionalità complete di affidabilità, tra cui più livelli di coerenza che consentono di bilanciare le prestazioni e la disponibilità, le distribuzioni con ridondanza della zona che proteggono da errori della zona di disponibilità, la replica in più aree con failover gestito dal servizio o gestito dal cliente e opzioni di backup continue e periodiche per la protezione dei dati.

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 Azure Cosmos DB resiliente a varie potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità, interruzioni dell'area e manutenzione del servizio. Descrive anche come usare i backup per eseguire il ripristino da altri tipi di problemi ed evidenzia le informazioni chiave sul contratto di servizio Azure Cosmos DB.

Raccomandazioni per la distribuzione di produzione

Azure Well-Architected Framework offre raccomandazioni su affidabilità, sicurezza, costi, operazioni e prestazioni. Per comprendere in che modo queste aree influiscono tra loro e contribuiscono a una soluzione di Azure Cosmos DB affidabile, vedere Architecture consigliate per Azure Cosmos DB.

Panoramica dell'architettura di affidabilità

Questa sezione descrive alcuni degli aspetti importanti del funzionamento del servizio più rilevanti dal punto di vista dell'affidabilità. La sezione presenta l'architettura logica, che include alcune delle risorse e delle funzionalità distribuite e usate. Illustra anche l'architettura fisica, che fornisce informazioni dettagliate sul funzionamento del servizio sotto le quinte.

Architettura logica

La risorsa primaria distribuita è un Azure Cosmos DB account. Ogni account può avere più database con più contenitori. I contenitori fungono da unità logiche di distribuzione e scalabilità. È possibile creare contenitori come raccolte, tabelle e grafici, a seconda dell'API usata per interagire con Azure Cosmos DB. Per altre informazioni sul modello di risorse, vedere Database, contenitori ed elementi in Azure Cosmos DB. Ogni contenitore usa il partizionamento, che supporta prestazioni elevate e scalabilità elevata.

È possibile configurare la velocità effettiva, che rappresenta la quantità di risorse di sistema che è possibile usare per l'esecuzione di query e l'uso dei dati. È possibile effettuare il provisioning manuale del throughput, utilizzare l'autoscaling per regolare dinamicamente la capacità in base ai requisiti del carico di lavoro o utilizzare il tipo di account senza server per essere addebitati in base all'utilizzo effettivo.

Un singolo account può coprire più regioni Azure, aumentandone la resilienza alle interruzioni regionali. È possibile configurare più aree per la lettura e, se si usa il livello Business Critical, è possibile usare più aree per la scrittura. Azure Cosmos DB replica automaticamente i tuoi dati a livello geografico. Il comportamento della replica geografica è influenzato dalla configurazione usata, ad esempio il livello di coerenza, che indica come si vogliono fare compromessi tra coerenza dei dati, disponibilità, latenza e velocità effettiva. Diversi livelli di coerenza ottimizzano per problemi diversi, supportano garanzie diverse e offrono diversi tipi di replica tra aree.

Architettura fisica

Azure Cosmos DB archivia più repliche dei tuoi dati per la ridondanza. Il servizio riduce automaticamente le interruzioni delle repliche mantenendo il quorum tra le repliche in ogni area. Questo approccio garantisce disponibilità elevata e protegge dalla perdita di dati durante singoli errori del nodo, senza richiedere modifiche o configurazione dell'applicazione.

Internamente, Azure Cosmos DB gestisce i dati tramite vari costrutti, tra cui partizioni fisiche, set di partizioni e set di replica. Per ulteriori informazioni dettagliate sul funzionamento di Azure Cosmos DB, vedere la distribuzione globale dei dati con Azure Cosmos DB - dietro le quinte.

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

È consigliabile usare gli SDK Azure Cosmos DB. Gli SDK implementano automaticamente il supporto per una serie di considerazioni sulla resilienza, tra cui la gestione degli errori temporanei tramite tentativi automatici e l'rispetto delle risposte al limite di velocità inviate dal servizio. Per altre informazioni, vedere Design applicazioni resilienti con SDK Azure Cosmos DB.

Quando si usa un account multiregione, l'SDK supporta anche una strategia di disponibilità basata su soglie, detta anche hedging, in cui invia richieste di lettura parallele a più aree e accetta la risposta più veloce. Questo approccio può migliorare le prestazioni dell'applicazione quando un'area riscontra temporaneamente una latenza più elevata del solito.

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.

Azure Cosmos DB supporta la ridondanza zonale. Quando si abilita la ridondanza della zona, Azure distribuisce le repliche dei dati in più zone di disponibilità, offrendo resilienza ai problemi e alle interruzioni del data center. Microsoft seleziona le zone di disponibilità da usare.

Un account Azure Cosmos DB può usare più aree (località) per la distribuzione globale, la scalabilità e il failover. La ridondanza della zona viene configurata separatamente per ogni regione nel tuo account.

L'uso della ridondanza della zona in Azure Cosmos DB non influisce sulle prestazioni o sulla latenza. Non richiede modifiche alla modalità di coerenza selezionata e non richiede alcuna modifica al codice dell'applicazione.

È consigliabile usare la ridondanza della zona nelle aree in cui è supportata, in particolare per gli account a singola area. Poiché le zone di disponibilità sono fisicamente separate e forniscono alimentazione, rete e raffreddamento distinte, i contratti di servizio di disponibilità per Azure Cosmos DB sono superiori per gli account con ridondanza della zona rispetto agli account che non usano zone di disponibilità.

Se non si abilita la ridondanza della zona, l'account è nonzonale in quella zona. Gli account non zonali possono posizionare le repliche in una singola zona di disponibilità, causando potenziali tempi di inattività se si verifica un problema in quella zona specifica.

Requirements

• Supporto della regione: È possibile abilitare la ridondanza della zona nelle regioni di Azure che supportano le zone di disponibilità. Per verificare se l'area supporta le zone di disponibilità, vedere l'elenco delle aree supportate.

  La ridondanza di zona non è un'impostazione per l'intero account. Azure Cosmos DB gli account possono estendersi su più aree e ogni area può essere configurata in modo indipendente per l'uso delle zone di disponibilità. Le regioni che non supportano le zone di disponibilità non impediscono l'abilitazione della ridondanza delle zone in altre regioni all'interno dello stesso account.

• Account serverless con ridondanza di zona: È possibile configurare account serverless con ridondanza di zona solo al momento della loro creazione. Non è possibile convertire gli account serverless esistenti senza zone di disponibilità in una configurazione della zona di disponibilità. Per i carichi di lavoro cruciali, è consigliabile usare la velocità effettiva con provisioning.

Considerations

• Interruzioni simultanee delle zone: Un account in una singola regione con ridondanza di zona può mantenere la disponibilità di lettura e scrittura quando un'interruzione influisce su una singola zona di disponibilità. Tuttavia, se l'interruzione influisce su più zone di disponibilità o sull'intera area, gli account a area singola perdono l'accesso in lettura e scrittura fino al ripristino del servizio. Prendi in considerazione la distribuzione di un account multi-regione se è necessario essere resilienti al fallimento di più zone contemporaneamente.

• Account in più aree: Se si dispone di un account con più aree, è possibile abilitare facoltativamente la ridondanza della zona in una o tutte le aree dell'account che supportano le zone di disponibilità. È consigliabile abilitare la ridondanza della zona quando l'account è configurato per l'uso di una singola area o se è configurato per l'uso di una singola area di scrittura con più aree di lettura.

Cost

Nelle regioni dove è abilitata la ridondanza a zone vengono addebitate con un costo aggiuntivo. Tuttavia, il prezzo premium per le zone di disponibilità è annullato per gli account configurati con scritture multi-regione e per le raccolte configurate per utilizzare la modalità di scalabilità automatica del throughput. Per altre informazioni, vedere Prezzi di Azure Cosmos DB.

Configurare il supporto delle zone di disponibilità

Per la maggior parte degli account, si abilita la ridondanza della zona solo quando si aggiunge una nuova area a un account Azure Cosmos DB. Per abilitare il supporto delle zone di disponibilità in un account esistente, aggiungere una regione e abilitare la ridondanza zonale. È possibile seguire un processo per aggiungere un'area temporanea in modo da poter configurare la ridondanza della zona nell'area originale. Per i passaggi dettagliati, vedere abilitare la ridondanza di zona in un account Azure Cosmos DB.

Per gli account serverless, è necessario abilitare la ridondanza della zona quando si crea l'account.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando si configura un account Azure Cosmos DB per la ridondanza della zona e tutte le zone sono operative.

• Operazione di zona incrociata: Azure Cosmos DB instrada automaticamente le richieste alle repliche tra zone di disponibilità, in modo che qualsiasi replica possa gestire una richiesta.

• Replica dei dati tra zone: Quando un client apporta una modifica a qualsiasi dato, tale modifica viene applicata a più repliche in zone diverse per ottenere il quorum. Questo approccio viene definito replica sincrona. La replica sincrona garantisce un elevato livello di coerenza dei dati, riducendo così la probabilità di perdita di dati durante un errore di zona. Le zone di disponibilità si trovano relativamente vicine, il che significa che c'è un effetto minimo sulla latenza o sulla velocità effettiva.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando si configura un account Azure Cosmos DB per la ridondanza della zona e si verifica un'interruzione in una delle zone.

• Rilevamento e risposta: La piattaforma Azure Cosmos DB è responsabile del rilevamento di un errore in una zona di disponibilità. Non è necessario eseguire alcuna operazione per avviare un failover di zona.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Azure Integrità risorse per monitorare l'integrità di una singola risorsa ed è possibile configurare Integrità risorse avvisi per segnalare eventuali 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: Quando una zona di disponibilità non è più disponibile, Azure Cosmos DB termina tutte le richieste in corso connesse alle repliche nella zona interessata e l'applicazione deve ritentare tali richieste. Assicurarsi che l'applicazione sia preparata seguendo le indicazioni sulla gestione degli errori temporanei.

• Perdita di dati prevista: Non si verifica alcuna perdita di dati prevista da un errore di zona.

• Tempo di inattività previsto: Durante le interruzioni della zona, le connessioni potrebbero riscontrare brevi interruzioni che in genere durano alcuni secondi perché il traffico viene ridistribuito. Assicurarsi che le applicazioni vengano preparate seguendo le indicazioni sulla gestione degli errori temporanei.

• Redistribution: Azure Cosmos DB reindirizza automaticamente le richieste in ingresso a repliche integre in altre zone di disponibilità. Quando una zona di disponibilità ha un'interruzione, la piattaforma rialloca automaticamente il throughput fornito ad altre repliche.

Ripristino della zona

Quando la zona di disponibilità viene ripristinata, Azure Cosmos DB ripristina automaticamente le repliche nella zona di disponibilità e reindirizza il traffico tra le repliche come di consueto.

Verifica dei guasti di zona

Il failover e il ripristino della zona di disponibilità per Azure Cosmos DB sono completamente gestiti da Microsoft. Non è necessario avviare o convalidare i processi per la gestione dei guasti delle zone di disponibilità.

Resilienza agli errori a livello di area

Quando si distribuisce un account Azure Cosmos DB in una singola area, un'interruzione a livello di area che influisce su tutti i nodi Azure Cosmos DB in genere non causa la perdita di dati, ma impedisce all'applicazione di accedere ai dati. Azure Cosmos DB ripristina l'accesso ai dati dopo il ripristino del servizio nell'area interessata. La perdita di dati si verifica solo se si verifica un'emergenza irreversibile nell'area.

Per prepararsi ai rari casi di interruzioni dell'area, è possibile configurare Azure Cosmos DB per supportare vari livelli di durabilità e disponibilità usando uno di questi approcci:

• Più aree di lettura con una singola area di scrittura. Facoltativamente, è possibile abilitare il failover gestito dal servizio o il failover automatico per partizione (PPAF).
• Più regioni di scrittura.

La tabella seguente riepiloga le opzioni di ripristino disponibili in base alla configurazione dell'account e al tipo di interruzione. Le sezioni successive di questo articolo forniscono informazioni dettagliate su queste opzioni e sul comportamento associato.

SDK e resilienza

Gli SDK Azure Cosmos DB sono una parte importante della strategia di resilienza dell'applicazione. Quando si dispone di un account in più aree, la configurazione dell'SDK influisce sulla modalità di instradamento delle richieste tra aree, incluse le aree preferite a cui connettersi e le aree a cui devono essere escluse. Gli SDK monitorano la disponibilità di aree e partizioni e possono riconfigurarsi dinamicamente per usare aree e partizioni integre, ad esempio tramite l'interruttore a livello di partizione.

Per altre informazioni su come l'SDK supporta la disponibilità elevata, vedere la documentazione relativa alla disponibilità elevata per l'SDK usato:

• Azure Cosmos DB .NET SDK v3
• Azure Cosmos DB Java SDK v4
• SDK di Python per Azure Cosmos DB

Potenziale perdita di dati durante le interruzioni dell'area

Quando si distribuisce un account Azure Cosmos DB in più aree, la durabilità dei dati dipende dal livello di coerenza configurato nell'account. La tabella seguente illustra in dettaglio, per tutti i livelli di coerenza, l'obiettivo del punto di ripristino (RPO) di un account Azure Cosmos DB distribuito in almeno due aree. L'RPO rappresenta la perdita potenziale di dati durante un'interruzione di regione.

K = Numero di versioni (ovvero aggiornamenti) di un elemento.

T = Intervallo di tempo dall'ultimo aggiornamento.

Per gli account con più aree, il valore minimo di K e T è 100.000 operazioni di scrittura o 300 secondi. Questo valore definisce il valore RPO minimo per i dati quando si usa il decadimento ristretto.

Per altre informazioni sulle differenze tra i livelli di coerenza, vedere Livelli di coerenza in Azure Cosmos DB.

Più aree di lettura con una singola area di scrittura

Se la soluzione richiede tempi di attività continui durante le interruzioni dell'area, è possibile configurare Azure Cosmos DB per replicare i dati in più aree, con scritture gestite dall'area primaria. Facoltativamente, è possibile configurare le applicazioni per connettersi a aree di lettura specifiche, che possono contribuire a migliorare le prestazioni. Se un'area ha un'interruzione, l'account può continuare a funzionare da aree integre.

Failover tra regioni

È possibile configurare Azure Cosmos DB SDK con un elenco di aree di lettura con priorità. L'SDK connette l'applicazione alla prima area disponibile nell'elenco. Durante un'interruzione dell'area di lettura, l'SDK rileva l'interruzione dell'area tramite i codici di risposta back-end, lo contrassegna come non disponibile e instrada le operazioni future alla successiva area disponibile nell'elenco delle preferenze. Assicurarsi che l'elenco delle aree preferite sia impostato correttamente e allineato ai requisiti di business e latenza. Per indicazioni dettagliate, vedere Risolvere i problemi di disponibilità di Azure Cosmos DB SDK.

Il failover è il processo di rendere non disponibile una delle aree dell'account, completamente o in parte. L'effetto di un failover dipende dal fatto che l'area sia un'area di scrittura o un'area di lettura:

• Se un'area di scrittura non è più disponibile, un'altra area diventa l'area di scrittura.
• Se un'area di lettura non è più disponibile, tale area non può gestire le richieste di lettura e altre aree vengono invece usate per le operazioni di lettura.

Azure Cosmos DB offre più tipi di failover:

• Failover automatico per partizione (PPAF): Internamente, Azure Cosmos DB distribuisce i dati tra più partizioni fisiche. Se si verifica un problema con l'infrastruttura che supporta una partizione, potrebbero non essere interessate altre partizioni. PPAF consente agli account di area a scrittura singola di eseguire automaticamente il failover di singole partizioni in un'area secondaria mantenendo le partizioni integre nell'area primaria. PPAF può aiutare a ridurre al minimo i tempi di inattività e a consentire un recupero più rapido durante un guasto parziale di una regione. Per ulteriori informazioni, vedere Come integrare e adottare il failover automatico per partizione (PPAF) in Azure Cosmos DB.

  Annotazioni

  Il failover automatico per partizione è disponibile in anteprima pubblica. Questa funzionalità viene fornita senza un contratto di servizio. Per ulteriori informazioni, vedere Condizioni supplementari per l'uso delle versioni di anteprima di Microsoft Azure.

• Failover forzato: È possibile portare offline una delle aree dell'account. È anche noto come un failover gestito dal cliente o un'operazione di area offline. Questo è l'approccio consigliato per ripristinare rapidamente la disponibilità durante un'interruzione. Sei responsabile del rilevamento delle interruzioni e dell'attivazione del failover. È anche possibile usare i failover forzati per simulare scenari di down dell'area per i test, ad esempio durante un'esercitazione sul ripristino di emergenza.

  Se si porta offline l'area di scrittura, l'area di lettura con la priorità più alta successiva diventa la nuova area di scrittura. Se si porta offline un'area di lettura, le applicazioni possono connettersi a qualsiasi altra area di lettura nell'account.

  Un failover forzato dell'area di scrittura comporta la possibilità di perdita di dati per eventuali scritture non replicate.

  Dopo un failover forzato, Microsoft deve riportare online l'area. Per le aree integre, questo processo è automatizzato, ma può richiedere fino a diversi giorni. Se la regione non torna online entro un giorno o due, aprite un caso di supporto per richiedere assistenza.

• Modificare l'area di scrittura: Quando le aree sono integre, è possibile modificare l'area di scrittura dell'account. Questa modifica è in effetti un failover pianificato della regione di scrittura per il tuo account.

  La modifica dell'area di scrittura non comporta alcuna perdita di dati, perché la replica dei dati viene aggiornata prima che venga alzata di livello la nuova area di scrittura. Potrebbe verificarsi una breve interruzione, ma i client che usano la logica di ripetizione dei tentativi e altre tecniche di gestione degli errori temporanei non hanno in genere un impatto significativo.

  Questa operazione richiede che le aree siano integre, quindi non possono essere usate durante un'interruzione dell'area.

• Failover gestito dal servizio: Quando l'account usa il failover gestito dal servizio, Microsoft è responsabile della scelta di quando eseguire il failover tra aree. Per abilitare il failover gestito dal servizio, specificare le priorità per ogni area. Tuttavia, il processo di dichiarazione di interruzione e attivazione del failover gestito dal servizio può richiedere tempo significativo, potenzialmente un'ora o più. Per un ripristino più rapido, eseguire un failover forzato anziché attendere l'attivazione del failover gestito dal servizio.

  Se Microsoft attiva il failover gestito dal servizio per l'area di scrittura dell'account, eventuali scritture non replicate potrebbero andare perse.

  Dopo un failover gestito dal servizio, Microsoft deve riportare online un'area. Microsoft porta automaticamente l'area online, ma questo processo può richiedere diversi giorni.

Requirements

Region support: È possibile configurare qualsiasi area Azure come area di lettura per l'account Azure Cosmos DB.

Cost

L'aggiunta di un'area di lettura aggiuntiva a un account Azure Cosmos DB aumenta i costi esistenti per ogni area. Per altre informazioni, vedere Prezzi di Azure Cosmos DB.

Configurare più aree di lettura

• Aggiungere aree di lettura a un account: È possibile configurare più aree nell'account quando si crea l'account o in qualsiasi momento dopo la creazione dell'account. Per altre informazioni, vedere Aggiungere/rimuovere aree dall'account del database.

• Abilitare il failover: Alcuni tipi di failover devono essere configurati in anticipo:

  • Per-partition automatic failover: Per ulteriori informazioni, vedere Come effettuare l'onboarding e adottare il Per-Partition Automatic Failover (PPAF) per Azure Cosmos DB.

  • Failover gestito dal servizio: Abilitare prima di tutto il failover gestito dal servizio. Impostare quindi le priorità di failover per ogni area nell'account.

Pianificazione e gestione della capacità

Se l'applicazione distribuisce le richieste tra aree e un'area passa offline, le aree rimanenti riscontrano un volume di richieste superiore. Usare il throughput con scalabilità automatica per regolare dinamicamente la capacità secondo la domanda. Se si usa la velocità effettiva con provisioning, pianificare una capacità adeguata per gestire la perdita di un'area senza riduzione del servizio e prendere in considerazione il provisioning eccessivo. Per altre informazioni, vedere Gestire la capacità con il provisioning eccessivo.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando si configura un account Azure Cosmos DB con più aree di lettura e tutte le aree sono operative.

• Operazione tra aree: L'applicazione configura l'area che deve ricevere operazioni di lettura. È possibile configurare l'applicazione con un elenco di aree con priorità o per escludere alcune aree. Per altre informazioni sul funzionamento della selezione dell'area, vedere Eseguire la diagnostica e risolvere i problemi relativi alla disponibilità degli SDK di Azure Cosmos DB in ambienti multiregionali.

  Tutte le operazioni di scrittura vengono indirizzate all'area di scrittura dell'account.

• Replica dei dati tra aree: Tutte le operazioni di scrittura si verificano nell'area primaria dell'account. Le scritture vengono replicate nelle altre aree di lettura in base al livello di coerenza configurato dell'account. Per informazioni sul ritardo massimo di replica, vedere Potenziale perdita di dati durante le interruzioni dell'area.

Comportamento durante un errore di regione di lettura

Questa sezione descrive cosa aspettarsi quando si configura un account Azure Cosmos DB con più aree di lettura e si verifica un'interruzione in una delle aree di lettura dell'account.

• Rilevamento e risposta: La responsabilità di rilevare l'interruzione e rispondere dipende dal tipo di failover usato dall'account.

  • PPAF: PPAF in genere non si applica per le interruzioni dell'area di lettura. Tuttavia, per gli account con coerenza assoluta e solo due aree, la perdita dell'area di lettura riduce l'account a una singola area, che non può mantenere il quorum dinamico. In questo scenario, PPAF può essere attivato per mantenere la disponibilità spostando le partizioni interessate nella zona sana.

  • Failover forzato: L'utente è responsabile dell'esecuzione di un failover forzato. Per i passaggi dettagliati, vedere Eseguire un failover forzato per l'account Azure Cosmos DB.

    Se non si esegue un failover, il comportamento dell'account dipende dal livello di coerenza:

    • Coerenza assoluta: la coerenza assoluta richiede due o più aree per mantenere il quorum dinamico. Se ci sono meno di due aree disponibili e non si esegue un failover, l'account non sarà più disponibile per la scrittura fino al ripristino del servizio.

    • Coerenza con decadimento ristretto: La coerenza con decadimento ristretto si basa sulla gestione di una soglia di decadimento specifica tra le aree. Se la durata dell'interruzione della regione supera la soglia, il sistema non può mantenere la coerenza tra le scritture. Se non si esegue un failover, l'account perde la disponibilità di scrittura fino al ripristino del servizio.

  • Failover gestito dal servizio: Se il failover gestito dal servizio è abilitato, Microsoft rileva l'interruzione e avvia un failover dell'account. Tuttavia, questo processo può richiedere tempo significativo, potenzialmente un'ora o più. Per un ripristino più rapido, eseguire un failover forzato anziché attendere l'attivazione del failover gestito dal servizio.

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

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

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

• Richieste attive: Le richieste attive potrebbero essere terminate e devono essere ritentate dal client al termine del failover. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

• Perdita di dati prevista: Un'interruzione in un'area di lettura non causa la perdita di dati. Azure Cosmos DB continua a rispettare le garanzie di coerenza di lettura.

• Tempo di inattività previsto: La quantità di tempo di inattività che il tuo account subisce dipende dal tipo di failover utilizzato dall'account.

  • PPAF: Quando PPAF è abilitato, il sistema rileva e recupera automaticamente dall'errore, in genere entro 3 minuti, senza alcun intervento manuale.

  • Failover forzato: Il tempo di inattività dipende da:

    • Quanto tempo è necessario per individuare l'interruzione e avviare un failover.

    • Tempo necessario per il failover, in genere di pochi secondi.

      Avvertimento

      Non eseguire alcuna operazione di configurazione (piano di controllo) nell'area interessata durante gli scenari di interruzione, perché comportano incoerenze dell'account e ripristino ritardato. Alcuni degli esempi di operazioni del piano di controllo da evitare includono:

      • Cambia l'area di scrittura o modifica la priorità di failover
      • Aggiornare l'account alla configurazione in scrittura multipla
      • Aggiornamento dei livelli di coerenza o di altre impostazioni dell'account
      • Aggiornamento delle configurazioni dell'endpoint privato o delle impostazioni di rete
      • Aggiornamento della velocità effettiva o delle operazioni di ridimensionamento dell'account
      • Qualsiasi altra operazione che modifica le impostazioni di configurazione o area dell'account

  • Failover gestito dal servizio: Microsoft è responsabile dell'avvio del failover gestito dal servizio e il tempo di inattività dell'account dipende dal tempo necessario Microsoft per dichiarare l'interruzione e avviare il failover. In alcune situazioni, potrebbe essere necessario un'ora o più. Se si verifica un'interruzione delle operazioni di scrittura dell'account ed è necessario ripristinare rapidamente la disponibilità di scrittura, eseguire un failover forzato.

• Ridistribuzione: Per il failover forzato o il failover gestito dal servizio, l'area interessata viene disconnessa e contrassegnata come offline.

  Non sono necessarie modifiche nel codice dell'applicazione per gestire le interruzioni di lettura a livello di area. Gli SDK Azure Cosmos DB reindirizzano le operazioni di lettura alla prossima area disponibile nell'elenco delle aree preferite. Se nessuna delle regioni nell'elenco delle regioni preferite è disponibile, le operazioni di lettura ripiegano automaticamente sull'area di scrittura corrente dell'account come configurato nel servizio.

  Annotazioni

  Se si usano endpoint privati con un account Azure Cosmos DB, assicurarsi che il DNS privato venga instradato correttamente dopo l'operazione dell'area offline. Per indicazioni dettagliate, vedere Considerazioni sul failover per gli endpoint privati.

Comportamento durante un errore di area di scrittura

Questa sezione descrive cosa aspettarsi quando si configura un account Azure Cosmos DB con più aree di lettura e si verifica un'interruzione nell'area di scrittura dell'account.

• Rilevamento e risposta: La responsabilità di rilevare l'interruzione e rispondere dipende dal tipo di failover usato dall'account.

  • PPAF: Microsoft rileva automaticamente l'interruzione e avvia un failover di alcune partizioni, se appropriato. L'applicazione non deve eseguire alcuna azione.

  • Failover forzato: L'utente è responsabile dell'esecuzione di un failover forzato. Per i passaggi dettagliati, vedere Eseguire un failover forzato per l'account Azure Cosmos DB.

    Se non si esegue un failover, l'account perde la disponibilità di scrittura fino al ripristino del servizio.

    Se si verifica un'interruzione dell'area di scrittura dell'account, evitare di eseguire un'operazione di modifica dell'area di scrittura. Le modifiche all'area di scrittura non hanno esito positivo se si verifica un'interruzione dell'area di origine o di destinazione. Il motivo è che la procedura di modifica dell'area include una verifica coerenza che richiede la connettività tra le aree.

  • Failover gestito dal servizio: Microsoft rileva automaticamente l'interruzione e avvia un failover dell'account. L'applicazione non deve eseguire alcuna azione.

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

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

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

• Richieste attive: Le richieste attive potrebbero essere terminate e devono essere ritentate dal client al termine del failover. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

• Perdita di dati prevista: Se si configura l'account con coerenza assoluta, non si verifica alcuna perdita di dati. In caso contrario, eventuali scritture non replicate potrebbero essere perse dopo il completamento del failover. Per informazioni sulla perdita massima di dati prevista durante un'interruzione dell'area, vedere Potenziale perdita di dati durante le interruzioni dell'area.

• Tempo di inattività previsto: La quantità di tempo di inattività che il tuo account sperimenta dipende dal tipo di failover usato.

  • PPAF: Quando PPAF è abilitato, prevedere una breve interruzione, che in genere è di circa 3 minuti.

  • Failover forzato: Il tempo di inattività dipende da:

    • Quanto tempo è necessario per individuare l'interruzione e avviare un failover.
    • Tempo necessario per il failover, in genere di pochi secondi.

  Avvertimento

  Non eseguire alcuna operazione del piano di gestione durante gli scenari di interruzione nell'area interessata, poiché ciò provoca incoerenze dell'account e ritarda il ripristino. Alcuni degli esempi di operazioni del piano di controllo da evitare includono:

  • Modificare la regione di scrittura o modificare la priorità di failover
  • Aggiornare l'account alla configurazione in scrittura multipla
  • Aggiornamento dei livelli di coerenza o di altre impostazioni dell'account
  • Aggiornamento delle configurazioni dell'endpoint privato o delle impostazioni di rete
  • Aggiornamento della velocità effettiva o delle operazioni di ridimensionamento dell'account
  • Qualsiasi altra operazione che modifica le impostazioni di configurazione o area dell'account
  • Failover gestito dal servizio: Microsoft è responsabile dell'avvio del failover gestito dal servizio e il tempo di inattività dell'account dipende dal tempo necessario Microsoft per dichiarare l'interruzione e avviare il failover. In alcune situazioni, potrebbe essere necessario un'ora o più. Per ripristinare rapidamente la disponibilità di scrittura, eseguire un failover forzato.

• Ridistribuzione: La ridistribuzione del traffico di scrittura dipende dal tipo di failover usato dall'account.

  • PPAF: Azure Cosmos DB esegue automaticamente il failover della partizione non funzionante in una regione funzionante.

  • Failover forzato: Quando si esegue un failover forzato, la regione di scrittura dell'account cambia nella regione specificata.

  Annotazioni

  Se si usano endpoint privati con un account Azure Cosmos DB, assicurarsi che il DNS privato venga instradato correttamente dopo l'operazione dell'area offline. Per indicazioni dettagliate, vedere Considerazioni sul failover per gli endpoint privati.

  • Failover gestito dal servizio: Azure Cosmos DB promuove automaticamente una delle aree secondarie dell'account come nuova area di scrittura primaria. Il failover avviene in un'altra area nell'ordine di priorità dell'area specificato.

Ripristino della regione

Microsoft deve riportare online un'area. Quando un'area viene ripristinata dopo un'interruzione, Microsoft porta automaticamente online l'area. Tuttavia, questo processo può richiedere diversi giorni.

Dopo che l'area è online, le azioni eseguite sono diverse a seconda che l'interruzione si trovi in un'area di lettura o in un'area di scrittura.

• Dopo le interruzioni dell'area di lettura: Quando l'area interessata è di nuovo online, viene sincronizzata con l'area di scrittura corrente ed è nuovamente disponibile per gestire le richieste di lettura dopo che è stata completata. Le letture successive vengono reindirizzate all'area ripristinata senza richiedere alcuna modifica del codice dell'applicazione. Sia durante il failover che durante il ricongiungimento di un'area che ha riscontrato errori in precedenza, Azure Cosmos DB continua a rispettare le garanzie di coerenza di lettura.

• Dopo le interruzioni della regione di scrittura: Quando la regione interessata è di nuovo online, la regione appare come "online" nel portale di Azure e diventa disponibile come regione di lettura. A questo punto, è possibile modificare nuovamente l'area di scrittura nell'area ripristinata.

  Importante

  L'area ripristinata non verrà alzata di livello automaticamente quando l'area di scrittura viene ripristinata . È responsabilità dell'utente tornare alla regione ripristinata come regione di scrittura, una volta che è sicuro farlo.

  Non esiste alcuna perdita di dati o disponibilità prima, mentre o dopo la modifica dell'area di scrittura. L'applicazione continua a offrire disponibilità elevata.

  Se le scritture non sono state replicate prima che l'area sia stata offline, è possibile leggere le scritture non replicate dal feed dei conflitti. L'applicazione può leggere il feed dei conflitti, risolvere eventuali conflitti in base alla logica specifica dell'applicazione e scrivere nuovamente i dati aggiornati nel contenitore in base alle esigenze.

Testare gli errori dell'area

L'applicazione potrebbe non gestire correttamente i failover delle regioni, anche se l'account Azure Cosmos DB è ad alta disponibilità. Per testare la disponibilità elevata end-to-end dell'applicazione come parte dei test dell'applicazione o delle esercitazioni per il ripristino di emergenza, disabilitare temporaneamente il failover gestito dal servizio per l'account. Richiama il failover forzato tramite PowerShell, l'interfaccia della riga di comando di Azure o il portale di Azure e quindi monitora l'applicazione. Dopo aver completato il test, è possibile eseguire il failback nell'area primaria una volta che questa torna online automaticamente, e quindi ripristinare il failover gestito dal servizio per l'account. Se la regione non torna online entro un giorno o due, aprite un caso di supporto per richiedere assistenza.

Se l'account usa PPAF, è possibile simulare un failover di partizione. Per ulteriori informazioni, vedere Testare l'impostazione PPAF (simulare l'errore).

Più aree di scrittura

È possibile configurare Azure Cosmos DB per accettare le scritture in più aree. Questa configurazione può offrire resilienza molto elevata alle interruzioni dell'area. È utile anche per ridurre la latenza di scrittura nelle applicazioni distribuite geograficamente.

Quando si configura un account Azure Cosmos DB per più aree di scrittura, la coerenza assoluta non è supportata e potrebbero verificarsi conflitti di scrittura. L'area hub funge da arbitro nei conflitti di scrittura. Per altre informazioni su come risolvere questi conflitti, vedere Tipi di conflitti e criteri di risoluzione quando si usano più aree di scrittura.

È importante considerare la progettazione dell'applicazione e come funziona con più aree di scrittura. Esaminare le procedure ottimali per le operazioni di scrittura in regioni multiple.

Requirements

Region support: È possibile configurare qualsiasi area Azure come area di lettura o scrittura per l'account Azure Cosmos DB.

Cost

L'aggiunta di un'area di scrittura aggiuntiva a un account Azure Cosmos DB aumenta i costi esistenti per ogni area. Per altre informazioni, vedere Prezzi di Azure Cosmos DB.

Configurare più aree di scrittura

È possibile configurare più aree di scrittura nell'account quando si crea l'account o in qualsiasi momento dopo la creazione dell'account. Per altre informazioni, vedere Configurare più aree di scrittura.

Per usare in modo efficace più aree di scrittura, l'app deve anche essere configurata in modo appropriato. Vedere Configurare la scrittura in più regioni nelle applicazioni che usano Azure Cosmos DB.

Pianificazione e gestione della capacità

Se l'applicazione distribuisce le richieste tra aree e un'area passa offline, le aree rimanenti riscontrano un volume di richieste superiore. Usare il throughput con scalabilità automatica per regolare dinamicamente la capacità secondo la domanda. Se si usa la velocità effettiva con provisioning, pianificare una capacità adeguata per gestire la perdita di un'area senza riduzione del servizio e prendere in considerazione il provisioning eccessivo. Per altre informazioni, vedere Gestire la capacità con il provisioning eccessivo.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando si configura un account Azure Cosmos DB con più aree di scrittura e tutte le aree sono operative.

• Operazione tra aree: Quando un account è configurato con più aree di scrittura, l'applicazione configura l'area da usare per le operazioni di lettura e scrittura. È possibile configurare l'applicazione con un elenco di aree con priorità o per escludere alcune aree. Per altre informazioni sul funzionamento della selezione dell'area, vedere Eseguire la diagnostica e risolvere i problemi relativi alla disponibilità degli SDK di Azure Cosmos DB in ambienti multiregionali. Per informazioni su come configurare l'applicazione, vedere Configurare le scritture in più aree nelle applicazioni che usano Azure Cosmos DB.

• Replica dei dati tra aree: I dati vengono replicati tra aree in modo asincrono. Il ritardo di replica dipende dal livello di coerenza dell'account. Non è possibile usare la coerenza assoluta per le scritture in più aree. Per altre informazioni, vedere Potenziale perdita di dati durante le interruzioni dell'area.

  Quando un account è configurato per più aree di scrittura, le applicazioni in aree diverse potrebbero apportare modifiche in conflitto tra loro. Azure Cosmos DB offre funzionalità di risoluzione dei conflitti. Per altre informazioni, vedere Tipi di conflitto e criteri di risoluzione quando si usano più aree di scrittura. Per informazioni su come configurare criteri di risoluzione dei conflitti personalizzati, vedere Gestire i criteri di risoluzione dei conflitti in Azure Cosmos DB.

  Annotazioni

  L'aggiornamento frequente dello stesso ID documento o la ricreazione dello stesso ID documento dopo la scadenza del TTL o l'eliminazione influisce negativamente sulle prestazioni di replica a causa di un numero maggiore di conflitti generati nel sistema.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando si configura un account Azure Cosmos DB con più aree di scrittura e si verifica un'interruzione in una delle aree di lettura o scrittura dell'account.

• Rilevamento e risposta: L'applicazione rileva la perdita dell'area. Azure Cosmos DB SDK offrono funzionalità di selezione automatica delle aree che instradano le operazioni di lettura e scrittura alle aree integre.

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

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

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

• Richieste attive: Le richieste attive potrebbero essere terminate e devono essere ritentate dal client al termine del failover. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

• Perdita di dati prevista: I dati aggiornati di recente potrebbero non essere disponibili in altre aree. Per informazioni sulla perdita massima di dati prevista durante un'interruzione dell'area, vedere Potenziale perdita di dati durante le interruzioni dell'area. Nel caso improbabile che l'area interessata subisca una perdita permanente di dati, è possibile che si perdano dati non replicati.

• Tempo di inattività previsto: Non è previsto alcun tempo di inattività nelle configurazioni con più scritture, purché gli SDK siano configurati correttamente con ApplicationRegions o PreferredRegions.

  Suggerimento

  Per ottenere risultati ottimali, le applicazioni distribuite a livello globale devono essere gestite da un servizio di bilanciamento del carico globale, ad esempio Frontdoor di Azure o Gestione traffico di Azure. Questi servizi possono rilevare un degrado regionale e instradare automaticamente il traffico alle istanze dell'applicazione in una regione sana.

• Redistribution: Gli SDK di Azure Cosmos DB rilevano automaticamente che l'area non è funzionante e reindirizzano le operazioni di lettura e scrittura alla successiva regione disponibile nell'elenco delle regioni preferite. Nel codice dell'applicazione non sono necessarie modifiche.

  Suggerimento

  Se l'applicazione è preceduta da Frontdoor di Azure o Traffic Manager, tali servizi rilevano anche un degrado regionale e instradano il traffico a una regione operativa.

Ripristino della regione

Quando l'area interessata torna online, l'area viene visualizzata come "online" nel portale di Azure e diventa nuovamente disponibile.

Tutti i dati di scrittura che non sono stati replicati quando si è verificato un guasto nella regione vengono resi disponibili tramite il feed di conflitti. Le applicazioni possono leggere il feed dei conflitti, risolvere i conflitti in base alla logica specifica dell'applicazione e scrivere nuovamente i dati aggiornati nel contenitore Azure Cosmos DB come appropriato.

Testare gli errori dell'area

Per testare scenari di failover di scrittura in più regioni, è possibile rendere offline una regione di scrittura usando un failover forzato. Questo processo simula un'interruzione dell'area ed è possibile osservare come risponde l'applicazione.

Backup e ripristino

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

La perdita di dati può verificarsi a causa di eliminazioni accidentali o altri problemi nell'applicazione che causano il danneggiamento dei dati. Quando si usa un account a area singola, la perdita di dati può verificarsi anche a causa di un'emergenza irreversibile nell'area Azure Cosmos DB. Per proteggersi dalla perdita di dati, Azure Cosmos DB offre un set di funzionalità di backup e ripristino. È possibile configurare i backup e la conservazione in base ai requisiti di recuperabilità e ai costi. Per altre informazioni, vedere Backup online e ripristino dei dati su richiesta in Azure Cosmos DB.

Resilienza alla manutenzione del servizio

Azure Cosmos DB gestisce in modo trasparente tutti i dettagli dei singoli nodi di calcolo ed esegue automaticamente l'applicazione di patch e altri tipi di manutenzione pianificata. I contratti di servizio Azure Cosmos DB per la disponibilità e la latenza si applicano a tutte le operazioni di manutenzione automatica eseguite dal sistema.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per ulteriori informazioni, vedere Accordi sul livello di servizio (SLA) per i servizi online.

Azure Cosmos DB fornisce contratti di servizio per una gamma di configurazioni e caratteristiche del servizio, tra cui disponibilità, latenza, velocità effettiva e coerenza.

I contratti di servizio di disponibilità sono diversi a seconda che si usi una delle funzionalità del prodotto seguenti:

• Velocità effettiva con provisioning
• Account a singola area con supporto della zona di disponibilità (ridondanza zonale)
• Account che usano più aree di lettura
• Account che usano più aree di scrittura (livello Business Critical)

Contenuti correlati

• L'affidabilità di Azure
• Panoramica di Azure Cosmos DB
• Livelli di coerenza in Azure Cosmos DB
• Distribuzione globale dei dati con Azure Cosmos DB
• Diagnose e risolvere i problemi di disponibilità degli SDK di Azure Cosmos DB in ambienti multiregionali