Affidabilità in Azure Cosmos DB per MongoDB vCore

  • Articolo

SI APPLICA A: VCore mongoDB

Questo articolo contiene informazioni dettagliate sulla resilienza a livello di area con zone di disponibilità e ripristino di emergenza tra aree e continuità aziendale per Azure Cosmos DB per MongoDB vCore.

Per una panoramica dell'architettura dell'affidabilità in Azure, vedere Affidabilità di Azure.

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono almeno tre gruppi separati fisicamente di data center in ogni area di Azure. I data center in ogni zona sono dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. In caso di errore in una zona locale, le zone di disponibilità sono progettate in modo tale che i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.

Gli errori possono essere correlati a software e hardware o a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene raggiunta con la ridondanza e l'isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Possono essere configurate in due modi. Possono essere ridondanti della zona, con replica automatica tra le zone o a zona, con istanze aggiunte a una zona specifica. Questi approcci possono essere combinati. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'utilizzo delle zone e delle aree.

Per ottenere il supporto della zona di disponibilità, è necessario abilitare la disponibilità elevata.

La disponibilità elevata evita il tempo di inattività del database mantenendo le repliche standby di ogni partizione in un cluster. Se una partizione diventa inattiva, Azure Cosmos DB per MongoDB vCore commuta le connessioni in ingresso dalla partizione non riuscita alla replica di standby.

Quando la disponibilità elevata è abilitata in un'area che supporta le zone di disponibilità, viene effettuato il provisioning delle partizioni di replica a disponibilità elevata in una zona di disponibilità diversa rispetto alle partizioni primarie. Le repliche a disponibilità elevata non ricevono richieste dai client a meno che la partizione primaria non riesca.

Se la disponibilità elevata è disabilitata, ogni partizione ha una propria archiviazione con ridondanza locale con tre repliche sincrone gestite dal servizio Archiviazione di Azure. Se si verifica un errore di replica singola, il servizio Archiviazione di Azure rileva l'errore e ricrea in modo trasparente i dati pertinenti. Per la durabilità dell'archiviazione con ridondanza locale, vedere Riepilogo delle opzioni di ridondanza. Tuttavia, in caso di errore dell'area, si corre il rischio di tempi di inattività estesi e di possibili perdite di dati.

Prerequisiti

Il cluster vCore di Azure Cosmos DB per MongoDB deve essere creato nelle aree seguenti:

  • Australia orientale
  • Asia sud-orientale
  • Canada centrale
  • Europa settentrionale
  • Regno Unito meridionale
  • Europa occidentale
  • Stati Uniti centrali
  • Stati Uniti orientali
  • Stati Uniti orientali 2
  • Stati Uniti centro-meridionali
  • Stati Uniti occidentali 2

Creare una risorsa con zone di disponibilità abilitate

Per abilitare le zone di disponibilità, è necessario abilitare la disponibilità elevata durante la creazione di un cluster o nella sezione Ridimensiona di un cluster esistente nel portale di Azure.

Continuità aziendale e ripristino di emergenza tra aree

Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.

Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano i dati in modo automatico o eseguono il fallback da un'area con errore per eseguire la replica incrociata in un'altra area abilitata. Per tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi di lavoro. La maggior parte dei servizi che eseguono offerte sulla piattaforma distribuita come servizio di Azure forniscono funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare un ripristino rapido e sviluppare un piano di ripristino di emergenza.

Azure Cosmos DB per MongoDB vCore non offre failover automatico predefinito o ripristino di emergenza. La pianificazione della disponibilità elevata è un passaggio fondamentale quando la soluzione viene ridimensionata.

Ripristino di emergenza in area geografica singola

Per ottimizzare il tempo di attività, pianificare in anticipo la continuità aziendale e prepararsi al ripristino di emergenza con Azure Cosmos DB per MongoDB vCore.

Anche se i servizi di Azure sono progettati per ottimizzare il tempo di attività, potrebbero verificarsi interruzioni del servizio non pianificate. Un piano di ripristino di emergenza garantisce che sia disponibile una strategia per la gestione delle interruzioni del servizio a livello di area.

Azure Cosmos DB per MongoDB vCore esegue automaticamente i backup dei dati a intervalli regolari. I backup automatici vengono eseguiti senza impatto sulle prestazioni o sulla disponibilità delle operazioni del database. Tutti i backup vengono eseguiti automaticamente in background e archiviati separatamente dai dati di origine in un servizio di archiviazione. Questi backup automatici sono utili negli scenari in cui si eliminano o si modificano accidentalmente le risorse e in seguito richiedono le versioni originali.

I backup automatici vengono conservati in vari intervalli in base al fatto che il cluster sia attualmente attivo o eliminato di recente.

Periodo di memorizzazione
Cluster attivi 35 giorni
Cluster eliminati 7 giorni

Progettare la disponibilità elevata

La disponibilità elevata deve essere abilitata per i cluster vCore critici di Azure Cosmos DB per MongoDB che eseguono carichi di lavoro di produzione. In un cluster abilitato per la disponibilità elevata ogni partizione funge da partizione primaria insieme a una partizione di hot standby di cui è stato effettuato il provisioning in un'altra zona di disponibilità. La replica tra la partizione primaria e quella secondaria è sincrona per impostazione predefinita. Qualsiasi modifica al database viene mantenuta sia nelle partizioni primarie che secondarie (hot standby) prima che venga ricevuta una risposta dal database.

Il servizio gestisce i controlli di integrità e gli heartbeat per ogni partizione primaria e secondaria del cluster. Se una partizione primaria non è più disponibile a causa di un'interruzione della zona o dell'area, la partizione secondaria viene alzata di livello automaticamente per diventare la nuova partizione primaria e una successiva partizione secondaria viene compilata per il nuovo database primario. Inoltre, se una partizione secondaria diventa non disponibile, il servizio crea automaticamente una nuova partizione secondaria con una copia completa dei dati dal database primario.

Se il servizio attiva un failover dalla partizione primaria alla partizione secondaria, le connessioni vengono indirizzate senza problemi alla nuova partizione primaria.

La replica sincrona tra le partizioni primarie e secondarie garantisce alcuna perdita di dati se si verifica un failover.

Passaggi successivi