Affidabilità in vCore di Azure Cosmos DB for MongoDB

SI APPLICA A: MongoDB vCore

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

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

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.

Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante 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à. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle aree di disponibilità.

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

La disponibilità elevata evita i tempi di inattività del database mantenendo le repliche di standby di ogni partizione in un cluster. Se una partizione diventa inattiva, Azure Cosmos DB for MongoDB vCore commuta le connessioni in ingresso dalla partizione con errore 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 riscontri un errore.

Se la disponibilità elevata è disabilitata, ogni partizione ha una propria archiviazione con ridondanza locale (LRS) con tre repliche sincrone gestite dal servizio Archiviazione di Azure. Se si verifica un unico errore di replica, il servizio Archiviazione di Azure lo rileva 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.

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 Scalabilità di un cluster esistente nel portale di Azure.

Ripristino di emergenza e continuità aziendale 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 automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare 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 eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.

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

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 for MongoDB.

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 for MongoDB vCore esegue automaticamente il 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 sono necessarie 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 for 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 automaticamente promossa per diventare la nuova partizione primaria e una successiva partizione secondaria viene compilata per la nuova primaria. Inoltre, se una partizione secondaria diventa non disponibile, il servizio crea automaticamente una nuova partizione secondaria con una copia completa dei dati dalla primaria.

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 primaria e secondaria garantisce che non ci sia perdita di dati se si verifica un failover.

Passaggi successivi

• Altre informazioni sulla compatibilità delle funzionalità con MongoDB.
• Esaminare le opzioni per eseguire la migrazione da MongoDB ad Azure Cosmos DB for MongoDB vCore.
• Per iniziare, creare un account.