Considerazioni sul failover per gli account Azure Cosmos DB con endpoint privati

Azure Cosmos DB funziona in modo diverso da molti altri servizi di Azure quando si tratta di configurazioni a disponibilità elevata. Anziché basarsi su un'istanza secondaria distribuita dal cliente per la resilienza, gli account Azure Cosmos DB vengono configurati con una configurazione in più aree che replica attivamente i dati tra aree selezionate. Per mantenere la disponibilità, durante un'interruzione regionale, il failover (regione offline) può essere avviato in un'altra regione.

Quando viene eseguito il failover di un account Azure Cosmos DB, il nome del servizio rimane invariato. Se l'endpoint pubblico viene usato per la connettività, i sistemi possono comunque accedere al servizio tramite la stessa risoluzione DNS, indipendentemente dal relativo stato di failover. La risoluzione DNS funziona perfettamente anche quando una sola area o un subset di servizi è interessata da un'interruzione. Questa resilienza predefinita riduce il numero di attività di continuità aziendale e ripristino di emergenza (BCDR) necessarie per Azure Cosmos DB.

Per i clienti che usano endpoint privati, è necessaria una configurazione aggiuntiva per garantire il supporto del failover. Questo documento fornisce un'architettura di esempio di un account Azure Cosmos DB in più aree usando endpoint privati per la rete sicura e illustra in dettaglio i passaggi necessari per diversi scenari BCDR.

Architettura di esempio

Questa architettura usa aree primarie e secondarie per supportare sia gli scenari attivi/attivi che attivi/passivi per gli scenari di failover. Ogni area include una rete in cui vengono distribuiti l'account Azure Cosmos DB e altre soluzioni del carico di lavoro. L'account Azure Cosmos DB in più aree include endpoint privati in entrambe le aree per garantire una connettività senza problemi. Questa configurazione consente alle applicazioni di connettersi all'endpoint privato più vicino, ottimizzando le prestazioni mantenendo al tempo stesso la resilienza durante un evento di failover.

I due endpoint privati non possono usare la stessa zona DNS privata per lo stesso endpoint. Di conseguenza, ogni area ha una propria zona DNS privata. Ogni zona a livello di area è collegata alla rete hub per tale area specifica. Questa progettazione sfrutta lo scenario del server d'inoltro DNS per fornire la risoluzione. Di conseguenza, indipendentemente dall'area della macchina virtuale che accede all'endpoint privato, è disponibile un endpoint locale per connettersi ad Azure Cosmos DB. Per le connessioni provenienti da un data center, viene stabilita una connessione VPN alla rete hub nella rispettiva area.

Per la risoluzione DNS, ogni data center configurerebbe l'inoltro condizionato a uno dei due insiemi di server risolutore Domain Name Server, garantendo che si risolva alla posizione di rete più vicina per una connettività ottimale.

Concetti relativi all'architettura

Azure Cosmos DB supporta più endpoint privati per account, consentendo di creare endpoint distribuiti a livello di area tra reti virtuali diverse. Ad esempio, è possibile avere un endpoint privato di Azure Cosmos DB in entrambe le aree, ognuna indipendentemente che gestisce il traffico dalla rispettiva rete virtuale.

Nelle topologie hub-spoke tradizionali, questa configurazione è meno comune a causa delle limitazioni della zona DNS privata. Ogni zona può contenere un solo record per ogni nome DNS. Dopo aver collegato un endpoint privato a una zona DNS privato, eventuali endpoint aggiuntivi in altre aree devono usare zone DNS private separate per evitare conflitti DNS.

Inoltre, gli endpoint privati di Azure Cosmos DB non sono associati all'area. È possibile distribuire un endpoint privato in un'area per accedere a un account Azure Cosmos DB ospitato in un'area diversa, abilitando configurazioni di rete flessibili.

Per garantire una corretta risoluzione, ogni area deve avere una propria zona DNS privata specifica dell'area mappata all'endpoint locale. Questa configurazione consente alle risorse in ogni area di instradare correttamente il traffico. Durante la distribuzione di endpoint privati nella stessa area dell'account Azure Cosmos DB è spesso preferibile per l'ottimizzazione dei costi e della latenza, il supporto di endpoint privati in più aree può essere fondamentale per scenari di disponibilità elevata e failover a livello di area, garantendo un accesso privato continuo anche se un'area non è più disponibile.

Scenari di failover

Questa topologia supporta gli scenari seguenti, ognuno con le proprie considerazioni sul failover DNS.

Scenario 1: Failover di Azure Cosmos DB

In questo scenario, un problema con l'account Azure Cosmos DB richiede il failover in un'area secondaria. Poiché Azure Cosmos DB è progettato per la disponibilità elevata, le interruzioni a livello di area non sono comuni, ma devono comunque essere pianificate.

Quando viene attivato il failover forzato (area offline) di Azure Cosmos DB, viene eseguito il failover nell'area secondaria, il routing di rete rimane invariato. Non sono necessarie modifiche al DNS, ogni area continua a usare l'endpoint privato locale per comunicare con Azure Cosmos DB. Dopo il failover (area offline): il servizio funzionerà come illustrato:

Quando l'area primaria torna a funzionare correttamente, viene eseguito il failback dell'account Azure Cosmos DB, ripristinando l'area di scrittura originale senza richiedere modifiche alla configurazione di rete.

Scenario 2: Failover di altri servizi

In questo scenario, il problema non riguarda l'account Azure Cosmos DB, ma con i servizi che si connettono, ad esempio servizi dell'applicazione, macchine virtuali o contenitori. È necessario eseguire il failover di questi servizi verso una regione secondaria secondo i rispettivi piani di recupero di emergenza.

Ad esempio, le macchine virtuali potrebbero usare Azure Site Recovery per replicare in anticipo i carichi di lavoro, mentre i servizi dell'applicazione potrebbero essere ridistribuiti nell'area secondaria usando pipeline CI/CD o funzionalità di scalabilità nativa della piattaforma.

Quando i servizi sono attivi nell'area secondaria, possono iniziare immediatamente a connettersi ad Azure Cosmos DB tramite l'endpoint privato locale a livello di area. Azure Cosmos DB non richiede alcuna modifica per supportare questo. Gli endpoint sono già stati sottoposti a provisioning per consentire l'accesso senza soluzione di continuità da più aree.

Se è presente una rete locale connessa tramite VPN, la connettività continuerà purché la risoluzione DNS tramite l'hub rimanga operativa. Tuttavia, se l'infrastruttura DNS dell'hub è interessata ,ad esempio a causa di un'interruzione di una macchina virtuale o di un servizio DNS, potrebbe essere necessario riconfigurare i server d'inoltro DNS locali per puntare ai resolver DNS dell'area secondaria fino al ripristino dell'area primaria.

Dopo il failover, i servizi nell'area secondaria funzioneranno come illustrato:

Dopo aver ripristinato l'area primaria, è possibile riportare i servizi e ripristinare eventuali modifiche temporanee al DNS per i sistemi locali.

Scenario 3: Interruzione dell'intera regione

In questo scenario si verifica un'interruzione regionale sufficientemente grave da richiedere che sia l'account Azure Cosmos DB che i servizi applicativi dipendenti vengano trasferiti in un'area secondaria.

Questo failover segue un modello combinato simile ai due scenari precedenti: l'account Azure Cosmos DB esegue il failover nell'area di scrittura secondaria e i servizi di Azure (ad esempio app Web, macchine virtuali o contenitori) vengono ridistribuiti o attivati nell'area secondaria. L'area primaria è effettivamente non funzionale, ma l'architettura garantisce che i servizi continuino a essere eseguiti dall'area secondaria con interruzioni minime.

Come nei casi precedenti, se la rete hub primario non è in grado di gestire la risoluzione DNS, ad esempio a causa di un'interruzione dell'infrastruttura DNS, i server d'inoltro DNS condizionali locali devono essere aggiornati temporaneamente per usare i resolver nell'area secondaria per mantenere la connettività dell'endpoint privato.

Dopo il failover, l'architettura funziona come illustrato:

Dopo aver ripristinato l'area primaria, è possibile eseguire il failback dei carichi di lavoro e ripristinare la configurazione originale delle impostazioni DNS locali.

Scenario 4: Configurazione multi-scrittura

In questo scenario, Azure Cosmos DB è configurato per le scritture in più aree, consentendo di accettare le scritture in più aree contemporaneamente. Si verifica un'interruzione in un'area, che influisce sui servizi dell'applicazione locale, ma Azure Cosmos DB rimane disponibile a livello globale a causa della natura distribuita.

Poiché gli account con più scritture hanno endpoint di lettura/scrittura specifici a livello di area, non è necessario alcun failover di Azure Cosmos DB. L'applicazione esegue semplicemente il failover in un'altra area attiva in cui i servizi sono ancora in esecuzione e possono continuare a leggere e scrivere in Azure Cosmos DB usando l'endpoint privato a livello di area. Comportamenti chiave in questo scenario:

• Non è necessario alcun failover di Azure Cosmos DB. Le altre aree continuano a gestire le scritture senza problemi.
• I servizi applicativi (ad esempio, App Services, Azure Kubernetes Service o Macchine virtuali) vengono riattivati o ridimensionati in un'area alternativa.
• È già stato effettuato il provisioning degli endpoint privati a livello di area, abilitando la connettività immediata senza modifiche DNS.
• I client on-premise continuano a operare finché i server di inoltro DNS possono risolvere un endpoint privato valido. Se i servizi DNS nella regione guasta sono interessati, devono puntare temporaneamente ai risolutori DNS nella regione attiva.

Quando l'area primaria viene ripristinata, i servizi dell'applicazione possono eseguire il failback, se necessario. Non sono necessarie modifiche ad Azure Cosmos DB. La piattaforma continua a replicare i dati in tutte le aree di scrittura configurate.

Contenuti correlati

• Panoramica degli endpoint privati di Azure Cosmos DB
• Come gestire il failover dell'account Azure Cosmos DB
• Integrazione DNS dell'endpoint privato di Azure Cosmos DB