Affidabilità in Azure DocumentDB

Azure DocumentDB è un servizio di database NoSQL completamente gestito per lo sviluppo di applicazioni moderne con compatibilità MongoDB. Azure DocumentDB supporta una configurazione a disponibilità elevata (HA) con repliche hot-standby con replica sincrona e ridondanza di zona. Fornisce anche una replica di lettura facoltativa in un'altra area Azure e backup automatici con conservazione temporizzato per proteggersi da perdite accidentali di 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 resiliente Azure DocumentDB a varie potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità, interruzioni dell'area e manutenzione del servizio. Descrive anche il comportamento del backup e fornisce informazioni chiave sulla disponibilità elevata e sulla replica tra aree.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Per un elenco delle raccomandazioni per migliorare l'affidabilità del cluster, vedere Procedure consigliate per la disponibilità elevata e la replica tra aree in Azure DocumentDB.

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 che distribuisci è un cluster di Azure DocumentDB. Per ogni cluster è possibile scegliere un livello di calcolo e configurare l'archiviazione. Il livello selezionato determina le funzionalità disponibili per le funzionalità di affidabilità, ad esempio disponibilità elevata e influisce anche sul modo in cui si pianifica la capacità per gli scenari di resilienza.

Le applicazioni si connettono a un cluster usando stringhe di connessione ed endpoint. Azure DocumentDB fornisce endpoint di connessione per le operazioni di lettura/scrittura e, se configurati, endpoint per i cluster di replica in lettura. Questi endpoint consentono all'applicazione di continuare a usare modelli di connessione stabili mentre il servizio gestisce il comportamento di failover in background.

All'interno di ogni cluster, i dati sono organizzati come database, raccolte e documenti. Questo modello di dati compatibile con MongoDB è la base per decisioni di progettazione a livello di carico di lavoro, ad esempio strategia di partizionamento orizzontale, modelli di lettura e scrittura e ambito di backup e ripristino.

Architettura fisica

Azure DocumentDB esegue il cluster in partizioni, che rappresentano nodi (macchine virtuali) che eseguono il servizio. È possibile distribuire uno shard o scalare orizzontalmente fino a più shard. L'implementazione di più shard migliora la capacità di scalare, ma di per sé non fornisce alta disponibilità.

Quando si abilita HA, Azure DocumentDB esegue il provisioning di un insieme corrispondente di shard di standby. Ogni partizione primaria ha una partizione di standby. Il servizio replica i dati in modo sincrono tra ogni coppia di standby primario e promuove la partizione di standby se la partizione primaria ha esito negativo. Per altre informazioni sulla disponibilità elevata, vedere Disponibilità elevata in Azure DocumentDB.

Azure DocumentDB usa Archiviazione di Azure per la durabilità delle partizioni. Se HA è disabilitata, ogni shard usa l'archiviazione con ridondanza locale (LRS). LRS mantiene tre copie dei dati, ma non è resiliente in caso di perdita di una zona di disponibilità. Per i dettagli sulla durabilità di LRS, vedere Riepilogo delle opzioni di ridondanza.

Per altre informazioni, vedere Disponibilità e ripristino di emergenza in Azure DocumentDB: 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 ulteriori informazioni, vedi Raccomandazioni per la gestione di errori temporanei.

Azure DocumentDB è compatibile con il protocollo MongoDB, quindi le applicazioni in genere si connettono usando driver MongoDB. Sei responsabile della configurazione delle impostazioni dei tentativi del driver dell'applicazione per gestire gli errori transitori, in particolare le interruzioni di connessione e le brevi interruzioni nelle operazioni di scrittura durante gli eventi di failover. Segui queste linee guida:

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.

Per usare il supporto della zona di disponibilità in Azure DocumentDB, abilitare la disponibilità elevata. Quando si abilita la disponibilità elevata in un'area che supporta le zone di disponibilità, il cluster diventa con ridondanza tra zone perché Azure DocumentDB colloca le partizioni di standby in una zona di disponibilità diversa rispetto alle partizioni primarie corrispondenti. I frammenti di standby non ricevono richieste dai client a meno che il frammento primario non si guasti.

Se si disabilita la disponibilità elevata, Azure DocumentDB non inserisce partizioni di standby in un'altra zona di disponibilità, quindi un errore della zona di disponibilità può rendere il cluster non disponibile.

Requisiti

• Supporto per l'area: Per usare le zone di disponibilità con Azure DocumentDB, scegliere un'area che supporti sia Azure DocumentDB che le zone di disponibilità. Selezionare Prodotti disponibili in base all'area e confrontarlo con le aree che supportano le zone di disponibilità.

• Alta disponibilità: È necessario abilitare HA sul cluster. HA richiede che il cluster utilizzi il tier di elaborazione M30 (o superiore).

Considerazioni

Sebbene alcune API di Azure DocumentDB includano riferimenti alle modalità di distribuzione nella stessa zona, Azure DocumentDB non supporta distribuzioni a disponibilità elevata nella stessa zona. Il servizio supporta distribuzioni ad alta disponibilità con ridondanza della zona.

Distribuzione di istanze tra zone

Microsoft seleziona due zone di disponibilità per il cluster. Nelle distribuzioni a disponibilità elevata con ridondanza di zona, Azure DocumentDB colloca tutti gli shard primari in una zona e tutti gli shard secondari nell'altra zona.

Cost

Quando l'alta disponibilità è abilitata, Azure DocumentDB esegue il provisioning di uno shard di standby per ogni shard primario, aumentando così i costi di calcolo e di archiviazione del cluster. Nelle regioni che supportano le zone di disponibilità, HA rende anche il cluster ridondante tra zone. In alcune modalità di distribuzione, Azure DocumentDB abilita l'alta disponibilità per impostazione predefinita. Per i carichi di lavoro di produzione, mantieni attivata l'alta disponibilità. Per i carichi di lavoro di sviluppo e test, è possibile disabilitare l'alta disponibilità per ridurre i costi. Per informazioni dettagliate sui prezzi, vedere prezzi di Azure DocumentDB.

Configurare il supporto delle zone di disponibilità

• Crea un nuovo cluster Azure DocumentDB con ridondanza della zona: Quando crei un cluster in un'area geografica che supporta le zone di disponibilità, abilita la disponibilità elevata per rendere il cluster con ridondanza della zona. Per i passaggi dettagliati, vedere Avvio rapido: Creare un cluster documentDB Azure usando il portale di Azure.

• Abilita la ridondanza della zona di disponibilità in un cluster Azure DocumentDB esistente: Puoi abilitare HA in un cluster esistente. Non è previsto alcun tempo di inattività del database quando la disponibilità elevata è abilitata o disabilitata in un cluster di Azure DocumentDB. Per i passaggi dettagliati, vedere Ridimensionare un cluster DocumentDB Azure.

Comportamento quando tutte le zone sono integre

Questa sezione descrive che cosa aspettarsi quando si configura un cluster Azure DocumentDB per l'alta disponibilità in un'area geografica che supporta le zone di disponibilità e in cui tutte le zone sono operative.

• Operazione tra zone: Gli shard primari servono tutte le richieste dei client. Gli shard in standby in una zona di disponibilità diversa non ricevono richieste dei client a meno che il primario non abbia un guasto.

• Replica dei dati tra zone: La replica tra le partizioni primarie e di standby è sincrona. Le scritture vengono salvate in modo persistente sia sugli shard primari sia su quelli standby prima che il servizio restituisca una risposta.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando si configura un cluster Azure DocumentDB per l'alta disponibilità in una regione che supporta le zone di disponibilità e si verifica un'interruzione del servizio in una delle zone.

• Rilevamento e risposta: Microsoft monitora l'integrità delle partizioni e gestisce automaticamente le operazioni di rilevamento e failover. Se una partizione primaria non è più disponibile a causa di un'interruzione della zona, Azure DocumentDB promuove automaticamente la partizione di standby e quindi ricompila la ridondanza creando una nuova partizione di standby.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia 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 eventuali problemi.

• Richieste attive: Le richieste in corso che non sono state confermate prima del failover possono non riuscire e devono essere ritentate dal client. Se l'applicazione gestisce gli errori temporanei, questi tentativi vengono in genere completati automaticamente.

• Perdita di dati prevista: Azure DocumentDB replica i dati in modo sincrono tra le partizioni primaria e standby, quindi non è prevista alcuna perdita di dati.

• Tempo di inattività previsto: Non è previsto alcun tempo di inattività per le operazioni di lettura. Per le operazioni di scrittura, può verificarsi una breve interruzione durante il completamento del failover. Se l'applicazione ritenta correttamente gli errori temporanei , questo in genere viene visualizzato come un breve rallentamento.

• Ridistribuzione: Il stringa di connessione non cambia, quindi i client continuano a usare lo stesso endpoint. Il servizio reindirizza automaticamente il traffico ai frammenti di standby promossi e ricostruisce nuovi frammenti di standby.

Ripristino della zona

Quando la zona di disponibilità viene ripristinata, Azure DocumentDB ripristina automaticamente le normali operazioni in tutte le zone usate dal cluster.

Verifica dei guasti di zona

La piattaforma Azure DocumentDB gestisce il routing del traffico, il failover e il ripristino di zona per i cluster a ridondanza di zona. Non è necessario avviare o verificare le procedure di failover della zona di disponibilità.

Resilienza agli errori a livello di area

Ogni Azure cluster DocumentDB viene distribuito in una singola area Azure. Per supportare la resilienza agli errori dell'area, configurare la replica tra aree aggiungendo un cluster di replica in un'altra area.

Replica tra più aree

Azure DocumentDB supporta la replica tra aree tramite un cluster di replica. Il cluster di replica viene visualizzato come cluster separato nel gruppo di risorse. È possibile utilizzare questo cluster di replica per il ripristino di emergenza e la scalabilità in lettura. Azure DocumentDB replica automaticamente e in modo asincrono le modifiche ai dati dal cluster primario al cluster di replica.

Se l'area primaria ha esito negativo, il cluster di replica può essere alzato di livello per diventare il cluster di lettura/scrittura. La stringa di connessione globale di lettura/scrittura viene aggiornata automaticamente per puntare al cluster promosso.

Questa sezione riepiloga le considerazioni sull'affidabilità per la replica tra aree. Per altre informazioni, vedere Gestire la replica tra aree e nella stessa area nel cluster Azure DocumentDB e Procedure consigliate per la replica tra aree e nella stessa area in Azure DocumentDB.

Failover tra regioni

Azure DocumentDB supporta tre modalità di promozione:

• Promozione forzata: Promuove immediatamente il cluster di replica per accettare operazioni di scrittura e reindirizza il traffico di scrittura in ingresso attraverso la stringa di connessione globale in lettura/scrittura. Questa modalità riduce al minimo i tempi di inattività, ma può comportare una perdita di dati perché perde eventuali scritture non replicate.

• Failover gestito dal servizio: È possibile configurare il cluster per l'uso del failover gestito dal servizio. Microsoft monitora il cluster primario e attiva automaticamente una promozione forzata se il cluster primario non è integro.

• Promozione normale: Impedisce la perdita di dati, ma richiede tempi di inattività durante la replica delle scritture non replicate. La promozione controllata richiede che entrambi i cluster siano in stato integro, quindi non è possibile eseguirla durante un'interruzione della regione.

Per altre informazioni, vedere Modalità di failover tra aree in Azure DocumentDB.

Requisiti

• Supporto per l'area: È possibile usare la replica tra aree in tutte le aree Azure che supportano Azure DocumentDB.

• Livello di calcolo: La replica tra aree richiede il livello di calcolo M30 o superiore.

Considerazioni

• Accesso alla rete: I cluster di replica non ereditano le impostazioni di rete dal cluster primario. Configurare le regole del firewall o gli endpoint privati separatamente nel cluster di replica e testare la connettività prima di un failover. Per altre informazioni, vedere Scritture continue, operazioni di lettura nelle repliche cluster e stringhe di connessione.

• Supporto delle funzionalità: I cluster di replica non supportano il ripristino temporizzato (PITR) o la disponibilità elevata nell'area.

  Se HA è abilitata sul cluster primario, sei responsabile della riabilitazione di HA sul cluster promosso.

  Per ulteriori informazioni, vedere limiti e quote del servizio Azure DocumentDB.

Cost

La replica tra aree aggiunge costi per le risorse di calcolo e archiviazione del cluster di replica. Si applicano anche gli addebiti per il trasferimento dei dati tra aree. Per informazioni dettagliate sui prezzi, vedere Azure prezzi di DocumentDB e Prezzi della larghezza di banda.

Configurare il supporto per più aree

• Creare un cluster di replica: Per abilitare la replica tra aree, creare un cluster di replica dal cluster primario. È possibile creare un cluster di replica quando si crea il cluster primario o successivamente. Per la procedura, vedere Gestire la replica tra più aree e la stessa area nel cluster Azure DocumentDB.

• Configurare il failover automatico: Se si desidera che Azure promuova automaticamente la replica in caso di interruzioni nell'area primaria, attivare il failover gestito dal servizio. Per altre informazioni, vedere Abilitare il failover gestito dal servizio.

  Note

  Microsoft in genere attiva il failover gestito dal servizio solo in eventi estremi, ad esempio un'interruzione dell'intera area o un numero elevato di clienti interessati. Potrebbe verificarsi un ritardo prima dell'attivazione del failover. Se è necessario ripristinare rapidamente la disponibilità, è consigliabile gestire il processo di failover usando l'innalzamento di livello forzato avviato dal cliente.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando si configura un cluster documentDB Azure per la replica tra aree e tutte le aree sono operative.

• Operazione tra aree: Il cluster primario gestisce tutto il traffico di lettura/scrittura. Il cluster di replica è destinato al traffico in sola lettura, che può essere usato per scalare i carichi di lavoro in lettura o per mantenere il traffico di lettura all'interno di una regione specifica. La stringa di connessione globale in lettura/scrittura punta sempre al cluster attualmente scrivibile, quindi i client non devono tenere traccia di quale regione sia primaria.

• Replica dei dati tra aree: La replica tra il cluster primario e il cluster di replica è asincrona. Le scritture vengono sottoposte a commit nel cluster primario e riconosciute al client prima di essere replicate nel cluster di replica. Questo approccio impedisce che la latenza di rete tra aree influisca sulle prestazioni di scrittura. Poiché la replica è asincrona, è previsto un ritardo di replica tra i cluster primario e di replica e qualsiasi scrittura non replicata può essere persa durante un failover forzato.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando si configura un cluster documentDB Azure per la replica tra aree ed è presente un'interruzione nell'area del cluster primario.

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

  • Se il failover gestito dal servizio è abilitato, Azure DocumentDB rileva l'interruzione ed esegue automaticamente una promozione forzata del cluster di replica.
  • Se il failover gestito dal servizio non è abilitato, sei responsabile di rilevare l'interruzione del servizio e avviare una promozione forzata.

  Per altre informazioni, vedere Modalità di failover tra aree in Azure DocumentDB.

• Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli eventuali errori dell'area e configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

• Richieste attive: Eventuali richieste attive all'area primaria non riuscita potrebbero non riuscire. Una volta completato il failover, le applicazioni dovrebbero riconnettersi e ritentare l'operazione sul cluster promosso.

• Perdita di dati prevista: I failover in caso di guasti della regione non sono pianificati, quindi le scritture non replicate potrebbero andare perse perché la replica è asincrona.

• Tempo di inattività previsto: Il tempo di inattività complessivo dipende dal tempo di rilevamento, dalla modalità di failover e dal comportamento di riconnessione del client.

  Per la promozione forzata avviata dal cliente, il tempo di inattività totale include il tempo necessario per rilevare l'interruzione del servizio e avviare i propri processi di risposta, nonché il tempo necessario per completare la promozione.

  Una volta avviata una promozione, in genere viene completata entro pochi minuti.

• Redistribuzione: La stringa di connessione globale di lettura/scrittura punta automaticamente al cluster promosso dopo la promozione. Le applicazioni che usano stringhe di connessione specifiche del cluster potrebbero richiedere aggiornamenti della configurazione in modo da indirizzare il traffico al cluster integro.

Ripristino della regione

Azure DocumentDB non esegue automaticamente il failback nell'area originale dopo il ripristino. Per restituire le operazioni di scrittura nell'area originale, eseguire un'altra promozione dopo aver ristabilito la topologia preferita. Usare una promozione controllata per evitare la perdita di dati durante il failback. Una promozione normale richiede una piccola quantità di tempo di inattività ed è possibile eseguirla alla volta scelta, ad esempio durante una finestra di manutenzione. Per ulteriori informazioni, vedi Avviare una promozione controllata.

Testare gli errori dell'area

Testare regolarmente il processo di ripristino di emergenza promuovendo il cluster di replica in un ambiente controllato.

• Usare la promozione forzata per simulare il comportamento in caso di interruzione. Questo test può comportare la perdita di dati, pertanto è consigliabile eseguire questo test in un ambiente non di produzione. Per altre informazioni, vedere Attivare una promozione forzata.

• Usa la promozione controllata per le esercitazioni di commutazione pianificate quando vuoi evitare la perdita di dati. Per ulteriori informazioni, vedi Avviare una promozione controllata.

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

Azure DocumentDB esegue automaticamente backup continui che consentono il ripristino a un momento specifico (PITR). Questi backup automatici consentono di ripristinare le versioni originali dopo l'eliminazione o la modifica accidentale dei dati. Azure DocumentDB esegue backup senza influire sulle prestazioni o sulla disponibilità delle operazioni del database.

Azure DocumentDB archivia i backup separatamente dai dati di origine. Nelle aree che supportano le zone di disponibilità, il servizio archivia gli snapshot di backup in tre zone di disponibilità. Azure DocumentDB gestisce questi backup e non è possibile esportarli. Il servizio conserva i backup per 35 giorni per i cluster attivi, 7 giorni per i cluster con burstable attivo (M10, M20, M25) e 7 giorni per i cluster eliminati.

È possibile ripristinare un backup in un nuovo cluster. Dopo aver eseguito questa operazione, è necessario eseguire un set di attività post-ripristino.

Per altre informazioni, vedere Ripristinare un cluster in Azure DocumentDB.

Resilienza alla manutenzione del servizio

Microsoft applica regolarmente gli aggiornamenti del servizio ed esegue altre operazioni di manutenzione. La piattaforma Azure gestisce automaticamente queste attività, garantendo che la manutenzione sia fluida e trasparente per l'utente. Non è previsto alcun tempo di inattività durante gli eventi di manutenzione, a meno che non ti sia stato comunicato tramite la manutenzione pianificata di integrità dei servizi di Azure.

Gli eventi di manutenzione pianificata possono comunque causare brevi errori temporanei per le operazioni client. L'applicazione deve gestire questi eventi seguendo le indicazioni sui tentativi di ripetizione in Resilienza agli errori temporanei.

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.

Per Azure DocumentDB, i contratti di servizio di disponibilità si applicano solo quando il cluster dispone di disponibilità elevata abilitata. I contratti di servizio di disponibilità diversi si applicano alle configurazioni seguenti:

• Cluster abilitati per l'alta disponibilità che si estendono su più aree di Azure tramite la replica tra aree.

• Cluster abilitati per l'alta disponibilità in una singola regione.

Contenuti correlati

• Compatibilità delle funzionalità con MongoDB
• Migrazione da MongoDB a Azure DocumentDB
• Crea un cluster di Azure DocumentDB
• Affidabilità in Azure