Disponibilità elevata (affidabilità) in Azure Cosmos DB per NoSQL
Questo articolo descrive il supporto della disponibilità elevata (affidabilità) in Azure Cosmos DB per NoSQL e illustra entrambe le zone di disponibilità, nonché il ripristino di emergenza tra aree e la continuità aziendale.
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à.
Azure Cosmos DB è un servizio multi-tenant che gestisce in modo trasparente tutti i dettagli dei singoli nodi di calcolo. Non è necessario preoccuparsi di qualsiasi tipo di applicazione di patch o manutenzione pianificata. Azure Cosmos DB garantisce contratti di servizio per la disponibilità e la latenza P99 tramite tutte le operazioni di manutenzione automatica eseguite dal sistema.
Offerte di Azure Cosmos DB:
Resilienza di interruzione dei singoli nodi. Azure Cosmos DB riduce automaticamente le interruzioni delle repliche garantendo almeno tre repliche dei dati in ogni area di Azure per l'account entro un quorum di quattro repliche. Questa garanzia comporta un RTO pari a 0 e un RPO pari a 0 per interruzioni dei singoli nodi, senza richiedere modifiche o configurazioni dell'applicazione.
Resilienza dell'interruzione della zona. Quando si distribuisce un account Azure Cosmos DB usando le zone di disponibilità, Azure Cosmos DB fornisce un RTO pari a 0 e un RPO pari a 0, anche in un'interruzione della zona. Per informazioni su RTO, vedere Obiettivi di ripristino.
Con le zone di disponibilità abilitate, Azure Cosmos DB per NoSQL supporta una configurazione con ridondanza della zona.
Prerequisiti
Le repliche devono essere distribuite in un'area di Azure che supporta le zone di disponibilità. Per verificare se l'area supporta le zone di disponibilità, vedere l'elenco delle aree supportate.
Determinare se le zone di disponibilità aggiungono un valore sufficiente alla configurazione corrente in Impatto dell'uso delle zone di disponibilità.
Impatto sull'uso delle zone di disponibilità
L'impatto delle zone di disponibilità sulla disponibilità elevata del database Cosmos DB per NoSQL dipende dal livello di coerenza dell'account e dalle aree in cui sono abilitate le zone di disponibilità. In molti casi, le zone di disponibilità non aggiungono valore o aggiungono valore minimo se l'account è in più aree (a meno che non sia configurato con coerenza assoluta).
Consultare la tabella seguente per stimare l'impatto dell'uso delle zone di disponibilità nella configurazione dell'account corrente:
| Livello di coerenza dell'account | Aree con zone di disponibilità abilitate | Impatto sull'uso delle zone di disponibilità |
|---|---|---|
| Asincrona (decadimento ristretto o più debole) | Qualsiasi numero di aree di lettura secondarie. | Fornisce un valore minimo perché l'SDK fornisce già reindirizzamenti semplici per le letture quando un'area di lettura ha esito negativo. |
| Sincrono (forte) | Due o più aree di lettura secondarie | Fornisce un valore marginale perché il sistema può sfruttare il quorum dinamico se un'area di lettura perde la disponibilità, consentendo la continuazione delle scritture. |
| Sincrono (forte) | Un'area di lettura secondaria | Fornisce un valore maggiore perché la perdita di un'area di lettura in questo scenario può influire sulla disponibilità di scrittura. |
| Tutte le date | Scrivere aree e un numero qualsiasi di aree secondarie | Garantisce una maggiore disponibilità per le operazioni di scrittura per gli errori di zona. |
| Tutte le date | Area singola | Una singola area non può trarre vantaggio dalla funzionalità di failover in più aree. L'uso delle zone di disponibilità protegge dalla perdita totale di disponibilità a causa di un errore di zona. |
Miglioramenti del contratto di servizio
Poiché le zone di disponibilità sono fisicamente separate e forniscono fonti di alimentazione, rete e raffreddamento distinte, i contratti di servizio di disponibilità (contratti di servizio) sono superiori (99,995%) rispetto agli account con una singola area (99,99%). Le aree in cui le zone di disponibilità sono abilitate vengono addebitate al 25% premium, mentre quelle senza zone di disponibilità non comportano il livello Premium. Inoltre, il prezzo Premium per le zone di disponibilità è rinunciato per gli account configurati con scritture in più aree e/o per le raccolte configurate con la modalità di scalabilità automatica.
L'aggiunta di un'area aggiuntiva all'account Cosmos DB aumenta in genere la fattura esistente del 100% (in modo aggiuntivo non moltiplicativo) anche se esistono piccole variazioni dei costi tra aree. Per altri dettagli, vedere la pagina dei prezzi.
L'abilitazione di AZs, l'aggiunta di aree aggiuntive o l'attivazione di scritture in più aree può essere considerata un approccio a più livelli che aumenta la resilienza e la disponibilità di un determinato account Cosmos DB in ogni passaggio, dalla disponibilità di 4 9 per la configurazione senza az a singola area, fino a 4 e metà 9 per l'area singola con AZ, fino a 5 9 della disponibilità per la configurazione in più aree con l'opzione di scrittura in più aree abilitata. Per un riepilogo dei contratti di servizio per ogni configurazione, vedere la tabella seguente.
| KPI | Scritture a singola area senza zone di disponibilità | Scritture a singola area con zone di disponibilità | Scritture in più aree, a singola area senza zone di disponibilità | Scritture in più aree, a singola area con zone di disponibilità | Scritture in più aree con o senza zone di disponibilità |
|---|---|---|---|---|---|
| Contratto di servizio per la disponibilità in scrittura | 99,99% | 99,995% | 99,99% | 99,995% | 99,999% |
| Contratto di servizio per la disponibilità in lettura | 99,99% | 99,995% | 99,999% | 99,999% | 99,999% |
| Errori di zona: perdita di dati | Perdita di dati | Senza perdita di dati | Senza perdita di dati | Senza perdita di dati | Senza perdita di dati |
| Errori di zona: disponibilità | Perdita di disponibilità | Nessuna perdita di disponibilità | Nessuna perdita di disponibilità | Nessuna perdita di disponibilità | Nessuna perdita di disponibilità |
| Interruzione a livello di area: perdita di dati | Perdita di dati | Perdita di dati | Dipendente dal livello di coerenza. Per altre informazioni, vedere Coerenza, disponibilità e compromessi sulle prestazioni. | Dipendente dal livello di coerenza. Per altre informazioni, vedere Coerenza, disponibilità e compromessi sulle prestazioni. | Dipendente dal livello di coerenza. Per altre informazioni, vedere Coerenza, disponibilità e compromessi sulle prestazioni. |
| Interruzione a livello di area: disponibilità | Perdita di disponibilità | Perdita di disponibilità | Nessuna perdita di disponibilità per l'errore dell'area di lettura, temporanea per l'errore dell'area di scrittura | Nessuna perdita di disponibilità per l'errore dell'area di lettura, temporanea per l'errore dell'area di scrittura | Nessuna perdita di disponibilità in lettura, perdita temporanea di disponibilità in scrittura nell'area interessata |
| Prezzo (1) | Non applicabile | Velocità di ur/sec di provisioning x 1,25 | Aree di UR/s x N di cui è stato effettuato il provisioning | Ur/s di cui è stato effettuato il provisioning x 1,25 x N aree (2) | Frequenza di scrittura in più aree x N aree |
1 Per gli account serverless, le UR vengono moltiplicate per un fattore pari a 1,25.
2 La tariffa 1,25 si applica solo alle aree in cui si abilitano le zone di disponibilità.
Creare una risorsa con zone di disponibilità abilitate
È possibile configurare le zone di disponibilità solo quando si aggiunge una nuova area a un account NoSQL di Azure Cosmos DB.
Per abilitare il supporto della zona di disponibilità, è possibile usare:
Eseguire la migrazione al supporto della zona di disponibilità
Per informazioni su come eseguire la migrazione dell'account Cosmos DB al supporto della zona di disponibilità, vedere Eseguire la migrazione di Azure Cosmos DB per NoSQL al supporto della zona di disponibilità.
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.
Le interruzioni dell'area sono interruzioni che interessano tutti i nodi di Azure Cosmos DB in un'area di Azure, in tutte le zone di disponibilità. Per i rari casi di interruzioni dell'area, è possibile configurare Azure Cosmos DB per supportare vari risultati di durabilità e disponibilità.
Durabilità
Quando un account Azure Cosmos DB viene distribuito in una singola area, in genere non si verifica alcuna perdita di dati. L'accesso ai dati viene ripristinato dopo il ripristino dei servizi Di Azure Cosmos DB nell'area interessata. La perdita di dati può verificarsi solo con un'emergenza irreversibile nell'area di Azure Cosmos DB.
Per proteggersi dalla perdita completa dei dati che potrebbe causare emergenze irreversibili in un'area, Azure Cosmos DB offre due modalità di backup:
- Backup continui di ogni area ogni 100 secondi. Consentono di ripristinare i dati in qualsiasi momento con granularità di 1 secondo. In ogni area il backup dipende dai dati di cui è stato eseguito il commit in tale area. Se l'area dispone di zone di disponibilità abilitate, il backup viene archiviato negli account di archiviazione con ridondanza della zona.
- Backup periodici di backup completi di tutte le partizioni di tutti i contenitori nell'account, senza sincronizzazione tra partizioni. L'intervallo di backup minimo è di 1 ora.
Quando un account Azure Cosmos DB viene distribuito 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'RPO di un account Azure Cosmos DB distribuito in almeno due aree.
| Livello di coerenza | RPO per l'interruzione dell'area |
|---|---|
| Sessione, prefisso coerente, finale | Meno di 15 minuti |
| Obsolescenza associata | K e T |
| Assoluta | 0 |
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 decadimento ristretto.
Per altre informazioni sulle differenze tra i livelli di coerenza, vedere Livelli di coerenza in Azure Cosmos DB.
Failover gestito dal servizio
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 e per eseguire il failover trasparente nelle aree operative quando necessario.
Gli account a singola area potrebbero perdere l'accessibilità dopo un'interruzione a livello di area. Per garantire sempre la continuità aziendale, è consigliabile configurare l'account Azure Cosmos DB con una singola area di scrittura e almeno un secondo (lettura) e abilitare il failover gestito dal servizio.
Il failover gestito dal servizio consente ad Azure Cosmos DB di eseguire il failover dell'area di scrittura di un account con più aree per mantenere la continuità aziendale al costo della perdita di dati, come descritto in precedenza nella sezione Durabilità . I failover a livello di area vengono rilevati e gestiti nel client Azure Cosmos DB. Non richiedono modifiche dall'applicazione. Per istruzioni su come abilitare più aree di lettura e failover gestito dal servizio, vedere Gestire un account Azure Cosmos DB usando il portale di Azure.
Importante
Se è stata scelta la configurazione di scrittura a singola area con più aree di lettura, è consigliabile configurare gli account Azure Cosmos DB usati per i carichi di lavoro di produzione per abilitare il failover gestito dal servizio. Questa configurazione consente ad Azure Cosmos DB di eseguire il failover dei database dell'account nelle aree disponibili. In assenza di questa configurazione, l'account perderà la disponibilità di scrittura per tutta la durata dell'interruzione dell'area di scrittura. Il failover manuale non riesce a causa di una mancanza di connettività dell'area.
Avviso
Anche con il failover gestito dal servizio abilitato, un'interruzione parziale può richiedere un intervento manuale per il team del servizio Azure Cosmos DB. In questi scenari possono essere necessarie fino a 1 ora (o più) per rendere effettivo il failover. Per una migliore disponibilità di scrittura durante interruzioni parziali, è consigliabile abilitare le zone di disponibilità oltre al failover gestito dal servizio.
Più aree di scrittura
È possibile configurare Azure Cosmos DB per accettare scritture in più aree. Questa configurazione è utile 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. Per altre informazioni su come risolvere questi conflitti, vedere Tipi di conflitti e criteri di risoluzione quando si usano più aree di scrittura.
Importante
L'aggiornamento frequente dello stesso ID documento (o la ricreazione dello stesso ID documento dopo TTL o eliminazione) avrà un effetto sulle prestazioni di replica a causa di un numero maggiore di conflitti generati nel sistema.
Area di risoluzione dei conflitti
Quando un account Azure Cosmos DB è configurato con scritture in più aree, una delle aree fungerà da arbitro nei conflitti di scrittura.
Procedure consigliate per le scritture in più aree
Ecco alcune procedure consigliate da considerare quando si scrive in più aree.
Mantenere il traffico locale
Quando si usano scritture in più aree, l'applicazione deve emettere traffico di lettura e scrittura che ha origine nell'area locale esclusivamente nell'area locale di Cosmos DB. Per ottenere prestazioni ottimali, evitare chiamate tra aree.
È importante per l'applicazione ridurre al minimo i conflitti evitando gli antipattern seguenti:
Invio della stessa operazione di scrittura a tutte le aree per aumentare le probabilità di ottenere un tempo di risposta rapido
Determinare in modo casuale l'area di destinazione per un'operazione di lettura o scrittura per ogni richiesta
Uso di un criterio round robin per determinare l'area di destinazione per un'operazione di lettura o scrittura per ogni richiesta.
Evitare la dipendenza dal ritardo della replica
Non è possibile configurare account di scrittura in più aree per coerenza assoluta. L'area scritta in risponde immediatamente dopo che Azure Cosmos DB replica i dati in locale durante la replica asincrona dei dati a livello globale.
Anche se è poco frequente, potrebbe verificarsi un ritardo di replica in una o poche partizioni quando si esegue la replica geografica dei dati. Il ritardo di replica può verificarsi a causa di un raro blip nel traffico di rete o di frequenze superiori al solito di risoluzione dei conflitti.
Ad esempio, un'architettura in cui l'applicazione scrive nell'area A, ma legge dall'area B introduce una dipendenza dal ritardo di replica tra le due aree. Tuttavia, se l'applicazione legge e scrive nella stessa area, le prestazioni rimangono costanti anche in presenza di ritardo della replica.
Valutare l'utilizzo della coerenza della sessione per le operazioni di scrittura
Nella coerenza della sessione si usa il token di sessione per le operazioni di lettura e scrittura.
Per le operazioni di lettura, Azure Cosmos DB invia il token di sessione memorizzato nella cache al server con una garanzia di ricezione dei dati che corrispondono al token di sessione specificato (o più recente).
Per le operazioni di scrittura, Azure Cosmos DB invia il token di sessione al database con una garanzia di persistenza dei dati solo se il server ha raggiunto il token di sessione fornito. Negli account di scrittura in un'area singola, l'area di scrittura viene sempre rilevata fino al token di sessione. Tuttavia, negli account di scrittura in più aree, l'area in cui si scrive potrebbe non essere stata rilevata per le scritture rilasciate in un'altra area. Se il client scrive nell'area A con un token di sessione dall'area B, l'area A non sarà in grado di salvare in modo permanente i dati fino a quando non viene aggiornata alle modifiche apportate nell'area B.
È consigliabile usare i token di sessione solo per le operazioni di lettura e non per le operazioni di scrittura quando si passano token di sessione tra istanze client.
Attenuare gli aggiornamenti rapidi allo stesso documento
Gli aggiornamenti del server per risolvere o confermare l'assenza di conflitti possono essere in conflitto con le scritture attivate dall'applicazione quando lo stesso documento viene aggiornato ripetutamente. Aggiornamenti ripetuti in rapida successione allo stesso documento con latenze più elevate durante la risoluzione dei conflitti.
Anche se i picchi occasionali di aggiornamenti ripetuti dello stesso documento sono inevitabili, è possibile prendere in considerazione l'esplorazione di un'architettura in cui vengono creati nuovi documenti se il traffico con stato stabile rileva aggiornamenti rapidi allo stesso documento in un periodo prolungato.
Interruzioni di lettura e scrittura
I client di account a area singola riscontrano una perdita di disponibilità di lettura e scrittura fino al ripristino del servizio.
Gli account in più aree riscontrano comportamenti diversi a seconda delle configurazioni e dei tipi di interruzione seguenti.
| Impostazione | Outage | Impatto sulla disponibilità | Impatto sulla durabilità | Cosa fare |
|---|---|---|---|---|
| Singola area di scrittura | Interruzione dell'area di lettura | Tutti i client reindirizza automaticamente le letture ad altre aree. Non esiste alcuna perdita di disponibilità di lettura o scrittura per tutte le configurazioni. L'eccezione è una configurazione di due aree con coerenza assoluta, che perde la disponibilità di scrittura fino al ripristino del servizio. In alternativa, se si abilita il failover gestito dal servizio, il servizio contrassegna l'area come non riuscita e si verifica un failover. | Nessuna perdita di dati. | Durante l'interruzione, assicurarsi che siano presenti unità richiesta (UR) di cui è stato effettuato il provisioning nelle aree rimanenti per supportare il traffico di lettura. Quando l'interruzione è finita, le UR di cui è stato effettuato il provisioning sono corrette in base alle esigenze.When the outage is over, readjust provisioned UR as appropriate. |
| Singola area di scrittura | Interruzione dell'area di scrittura | I client reindirizza le letture ad altre aree. Senza failover gestito dal servizio, i client riscontrano una perdita di disponibilità in scrittura. Il ripristino della disponibilità di scrittura si verifica automaticamente al termine dell'interruzione. Con il failover gestito dal servizio, i client riscontrano una perdita di disponibilità in scrittura fino a quando il servizio non gestisce un failover in una nuova area di scrittura selezionata. |
Se non si seleziona il livello di coerenza assoluta, il servizio potrebbe non replicare alcuni dati nelle aree attive rimanenti. Questa replica dipende dal livello di coerenza selezionato. Se l'area interessata subisce una perdita permanente di dati, è possibile perdere dati non replicati. | Durante l'interruzione, assicurarsi che nelle aree rimanenti siano presenti UR con provisioning sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione perché non riesce. Quando l'interruzione è finita, le UR di cui è stato effettuato il provisioning sono corrette in base alle esigenze.When the outage is over, readjust provisioned UR as appropriate. Gli account che usano l'API per NoSQL potrebbero anche recuperare i dati non replicati nell'area non riuscita dal feed dei conflitti. |
| Più aree di scrittura | Eventuali interruzioni a livello di area | Esiste una possibilità di perdita temporanea della disponibilità di scrittura, analoga a una singola area di scrittura con failover gestito dal servizio. Il failover dell'area di risoluzione dei conflitti potrebbe anche causare una perdita di disponibilità di scrittura se si verifica un numero elevato di scritture in conflitto al momento dell'interruzione. | I dati aggiornati di recente nell'area non riuscita potrebbero non essere disponibili nelle aree attive rimanenti, a seconda del livello di coerenza selezionato. Se l'area interessata subisce una perdita permanente di dati, è possibile che si perdano dati non replicati. | Durante l'interruzione, assicurarsi che nelle aree rimanenti sia disponibile un numero sufficiente di UR di cui è stato effettuato il provisioning per supportare un maggior traffico. Quando l'interruzione è finita, è possibile riaggiustarne il provisioning in base alle esigenze. Se possibile, Azure Cosmos DB recupera automaticamente i dati non replicati nell'area non riuscita. Questo ripristino automatico usa il metodo di risoluzione dei conflitti configurato per gli account che usano l'API per NoSQL. Per gli account che usano altre API, questo ripristino automatico usa le ultime vittorie di scrittura. |
Altre informazioni sulle interruzioni dell'area di lettura
L'area interessata è disconnessa e contrassegnata come offline. Gli SDK di Azure Cosmos DB reindirizzano le chiamate di lettura all'area disponibile successiva nell'elenco delle aree preferite.
Se nessuna delle aree nell'elenco delle aree preferite è disponibile, esegue automaticamente il fallback all'area di scrittura corrente.
Non sono necessarie modifiche nel codice dell'applicazione per gestire le interruzioni dell'area di lettura. Quando l'area di lettura interessata è di nuovo online, viene sincronizzata con l'area di scrittura corrente ed è nuovamente disponibile per gestire le richieste di lettura dopo che è stata completamente rilevata.
Le letture successive vengono reindirizzate all'area ripristinata senza richiedere alcuna modifica del codice dell'applicazione. Durante il failover e la ricongiuzione di un'area precedentemente non riuscita, Azure Cosmos DB continua a rispettare le garanzie di coerenza di lettura.
Anche in un caso raro e sfortunato in cui un'area di scrittura di Azure è permanentemente irreversibile, non si verifica alcuna perdita di dati se l'account Azure Cosmos DB in più aree è configurato con coerenza assoluta. Un account Azure Cosmos DB in più aree presenta le caratteristiche di durabilità specificate in precedenza nella sezione Durabilità .
Altre informazioni sulle interruzioni dell'area di scrittura
Durante un'interruzione dell'area di scrittura, l'account Azure Cosmos DB promuove un'area secondaria come nuova area di scrittura primaria quando il failover gestito dal servizio è configurato nell'account Azure Cosmos DB. Il failover si verifica in un'altra area nell'ordine di priorità dell'area specificato.
Il failover manuale non deve essere attivato e non avrà esito positivo in presenza di un'interruzione dell'area di origine o di destinazione. Il motivo è che la procedura di failover include una verifica coerenza che richiede la connettività tra le aree.
Quando l'area interessata in precedenza è di nuovo online, tutti i dati di scrittura che non sono stati replicati quando l'area non è riuscita viene resa disponibile tramite il feed dei 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 in base alle esigenze.
Dopo il ripristino dell'area di scrittura interessata in precedenza, viene visualizzato come "online" in portale di Azure e diventa disponibile come area di lettura. A questo punto, è possibile tornare all'area ripristinata come area di scrittura usando [PowerShell, l'interfaccia della riga di comando di Azure o l'portale di Azure](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account. Non esiste alcuna perdita di dati o disponibilità prima, mentre o dopo aver cambiato l'area di scrittura. L'applicazione continua a offrire disponibilità elevata.
Avviso
In caso di interruzione dell'area di scrittura, in cui l'account Azure Cosmos DB promuove un'area secondaria come nuova area di scrittura primaria tramite failover gestito dal servizio, l'area di scrittura originale non verrà alzata di livello automaticamente quando l'area di scrittura viene ripristinata. È responsabilità dell'utente tornare all'area ripristinata come area di scrittura usando PowerShell, l'interfaccia della riga di comando di Azure o l'portale di Azure (una volta sicura per farlo, come descritto in precedenza).
Rilevamento, notifica e gestione di interruzioni
Per gli account a singola area, i client riscontrano una perdita di disponibilità di lettura e scrittura durante un'interruzione dell'area di Azure Cosmos DB. Gli account in più aree riscontrano comportamenti diversi, come descritto nella tabella seguente.
| Aree per le operazioni di scrittura | Failover gestito dal servizio | Risultati previsti | Cosa fare |
|---|---|---|---|
| Singola area di scrittura | Non abilitata | Se si verifica un'interruzione in un'area di lettura quando non si usa una coerenza assoluta, tutti i client reindirizzano ad altre aree. Non esiste alcuna perdita di disponibilità di lettura o scrittura e non si verifica alcuna perdita di dati. Quando si usa una coerenza assoluta, un'interruzione in un'area di lettura può influire sulla disponibilità di scrittura se rimangono meno di due aree di lettura. Se si verifica un'interruzione nell'area di scrittura, i client riscontrano una perdita di disponibilità in scrittura. Se non è stata selezionata una coerenza assoluta, il servizio potrebbe non replicare alcuni dati nelle aree attive rimanenti. Questa replica dipende dal livello di coerenza selezionato. Se l'area interessata subisce una perdita permanente di dati, è possibile che si perdano dati non replicati. Azure Cosmos DB ripristina la disponibilità di scrittura al termine dell'interruzione. |
Durante l'interruzione, assicurarsi che nelle aree rimanenti siano presenti UR con provisioning sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione perché non riesce. Quando l'interruzione è finita, le UR di cui è stato effettuato il provisioning sono corrette in base alle esigenze.When the outage is over, readjust provisioned UR as appropriate. |
| Singola area di scrittura | Attivata | Se si verifica un'interruzione in un'area di lettura quando non si usa una coerenza assoluta, tutti i client reindirizzano ad altre aree. Non esiste alcuna perdita di disponibilità di lettura o scrittura e non si verifica alcuna perdita di dati. Quando si usa una coerenza assoluta, l'interruzione di un'area di lettura può influire sulla disponibilità di scrittura se rimangono meno di due aree di lettura. Se si verifica un'interruzione nell'area di scrittura, i client riscontrano una perdita di disponibilità in scrittura finché Azure Cosmos DB non sceglie una nuova area come nuova area di scrittura in base alle preferenze. Se non è stata selezionata una coerenza assoluta, il servizio potrebbe non replicare alcuni dati nelle aree attive rimanenti. Questa replica dipende dal livello di coerenza selezionato. Se l'area interessata subisce una perdita permanente di dati, è possibile che si perdano dati non replicati. |
Durante l'interruzione, assicurarsi che nelle aree rimanenti siano presenti UR con provisioning sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione perché non riesce. Quando l'interruzione è in corso, è possibile spostare nuovamente l'area di scrittura nell'area originale e riaggiustare le UR di cui è stato effettuato il provisioning in base alle esigenze. Gli account che usano l'API per NoSQL possono anche recuperare i dati non replicati nell'area non riuscita dal feed dei conflitti. |
| Più aree di scrittura | Non applicabile | I dati aggiornati di recente nell'area non riuscita potrebbero non essere disponibili nelle aree attive rimanenti. I livelli di coerenza finale, coerente e di coerenza della sessione garantiscono un decadimento inferiore a 15 minuti. La decadimento ristretto garantisce meno di K aggiornamenti o T secondi, a seconda della configurazione. Se l'area interessata subisce una perdita permanente di dati, è possibile che si perdano dati non replicati. | Durante l'interruzione, assicurarsi che nelle aree rimanenti sia disponibile un numero sufficiente di UR di cui è stato effettuato il provisioning per supportare un maggior traffico. Quando l'interruzione è finita, è possibile riaggiustarne il provisioning in base alle esigenze. Se possibile, Azure Cosmos DB recupera i dati non replicati nell'area non riuscita. Questo ripristino usa il metodo di risoluzione dei conflitti configurato per gli account che usano l'API per NoSQL. Per gli account che usano altre API, questo ripristino usa le ultime vittorie di scrittura. |
Test per la disponibilità elevata
Anche se l'account Azure Cosmos DB è a disponibilità elevata, l'applicazione potrebbe non essere progettata correttamente per rimanere a disponibilità elevata. Per testare la disponibilità elevata end-to-end dell'applicazione come parte delle esercitazioni sul test dell'applicazione o sul ripristino di emergenza, disabilitare temporaneamente il failover gestito dal servizio per l'account. Richiamare il failover manuale usando PowerShell, l'interfaccia della riga di comando di Azure o il portale di Azure e quindi monitorare l'applicazione. Dopo aver completato il test, è possibile eseguire il failover nell'area primaria e ripristinare il failover gestito dal servizio per l'account.
Importante
Non richiamare il failover manuale durante un'interruzione di Azure Cosmos DB nell'area di origine o di destinazione. Il failover manuale richiede la connettività dell'area per mantenere la coerenza dei dati, quindi non avrà esito positivo.