Condividi tramite

Affidabilità nel bus di servizio di Azure

Il bus di servizio di Azure è un servizio broker di messaggi aziendale completamente gestito che offre funzionalità di messaggistica asincrone affidabili per la disaccoppiamento di applicazioni e servizi. Il bus di servizio supporta le code per la comunicazione da punto a punto e gli argomenti con sottoscrizioni per i modelli di messaggistica di pubblicazione-sottoscrizione. Il servizio offre funzionalità di affidabilità predefinite, tra cui durata dei messaggi, garanzie di consegna almeno una volta e code di messaggi non recapitabili per gestire l'elaborazione dei messaggi non riuscita.

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 il bus di servizio resiliente a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità e interruzioni dell'area. Vengono inoltre evidenziate alcune informazioni chiave sul contratto di servizio del bus di servizio.

Raccomandazioni per la distribuzione di produzione

Azure Well-Architected Framework offre raccomandazioni su affidabilità, prestazioni, sicurezza, costi e operazioni. Per comprendere in che modo queste aree influiscono tra loro e contribuiscono a una soluzione affidabile di App Service, vedere Migliori pratiche architettoniche per il bus di servizio di Azure nel framework Azure Well-Architected.

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

Uno spazio dei nomi funge da contenitore di gestione per il bus di servizio e può essere configurato per l'uso del livello Basic, Standard o Premium. Configuri il servizio a livello di spazio dei nomi assegnando la capacità, configurando la sicurezza di rete e abilitando Geo-Replication e Geo-Disaster Recovery.

All'interno di uno spazio dei nomi si distribuiscono code e argomenti, ovvero entità di messaggistica con semantica diversa. Per altre informazioni, vedereCode, argomenti e sottoscrizioni del bus di servizio.

È possibile configurare partizioni nel proprio spazio dei nomi, che distribuisce code e argomenti tra più broker di messaggi e archivi di messaggistica. Uno spazio dei nomi può usare più partizioni per eseguire l'elaborazione parallela e la scalabilità orizzontale. Service Bus garantisce l'ordine solo all'interno di una singola partizione. Il partizionamento svolge un ruolo chiave nella progettazione dell'affidabilità dell'applicazione. Quando si progetta l'applicazione, fare un compromesso tra ottimizzare la disponibilità e la coerenza. Per il livello Premium , si abilita il partizionamento nello spazio dei nomi . Per gli spazi dei nomi di livello Basic e Standard, configurare le partizioni nell'entità e , facoltativamente, quando si inviano messaggi.

È possibile usare il bus di servizio e i relativi approcci di progettazione asincroni per aumentare la disponibilità delle applicazioni. Per altre informazioni, vedere Modelli di messaggistica asincrona e disponibilità elevata.

Architettura fisica

Il bus di servizio fornisce le risorse di calcolo e archiviazione sottostanti. Per ogni spazio dei nomi, più broker di messaggi elaborano i messaggi e più archiviazioni di messaggistica archiviano i messaggi. Esistono tre copie dell'archivio di messaggistica: una primaria e due secondarie. Il bus di servizio mantiene sincronizzate tutte e tre le copie per le operazioni di gestione e i dati. Se la copia primaria riscontra un errore, una delle copie secondarie viene promossa a primaria senza tempi di inattività percepiti.

Per i namespace che usano il livello Basic o Standard, il Service Bus fornisce ridondanza tramite un'infrastruttura multi-tenant condivisa che replica automaticamente i messaggi tra le zone di disponibilità, dove disponibili. Il servizio gestisce più archivi di messaggistica e mantiene tutte le copie sincronizzate sia per le operazioni di gestione che per i dati.

Per gli spazi dei nomi del livello Premium, il bus di servizio fornisce unità di messaggistica dedicate, ognuna con risorse di CPU e memoria dedicate. Gli spazi dei nomi del livello Premium possono essere ridimensionati automaticamente in base alle esigenze del carico di lavoro. Per ulteriori informazioni, vedere Aggiornamento automatico delle unità di messaggistica di uno spazio dei nomi di Azure Service Bus.

L'infrastruttura del Service Bus si estende su più macchine fisiche e rack distribuiti tra domini di errore, riducendo il rischio di guasti catastrofici che interessano il namespace. Nelle aree con zone di disponibilità, l'infrastruttura si estende in data center fisici separati. Il servizio implementa meccanismi di failover e rilevamento degli errori trasparenti in modo che continui a funzionare entro i livelli di servizio garantiti e in genere senza interruzioni evidenti quando si verificano tali errori.

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 altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

L'SDK di Azure Service Bus include la logica di ripetizione automatica con backoff esponenziale per le operazioni che non riescono a causa di condizioni temporanee, come i timeout di rete o l'indisponibilità temporanea del servizio. Quando le applicazioni riscontrano disconnessioni temporanee dal bus di servizio, l'SDK tenta automaticamente di riconnettersi usando i criteri di ripetizione dei tentativi configurati.

Per ottimizzare la gestione degli errori temporanei nelle applicazioni, usare l'SDK del bus di servizio più recente, che include la logica di ripetizione dei tentativi più recente e le funzionalità di gestione delle connessioni. Per altre informazioni, vedere Libreria client del bus di servizio di Azure per .NET.

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.

Service Bus supporta le distribuzioni geograficamente ridondanti in tutti i livelli di servizio. Quando si crea uno spazio dei nomi del bus di servizio in un'area supportata, la ridondanza della zona viene abilitata automaticamente senza costi aggiuntivi. Il modello di distribuzione con ridondanza della zona si applica a tutte le funzionalità del bus di servizio, tra cui partizionamento e sessioni.

Il Service Bus replica in modo trasparente la tua configurazione, i metadati e i dati dei messaggi in più zone di disponibilità nella regione. La ridondanza della zona fornisce il failover automatico senza alcun intervento richiesto dall'utente. Tutti i componenti del bus di servizio, tra cui calcolo, rete e archiviazione, vengono replicati tra zone. Il bus di servizio dispone di riserve di capacità sufficienti per gestire immediatamente la perdita completa di una zona. Anche se un'intera zona di disponibilità non è più disponibile, il bus di servizio continua a funzionare senza perdita di dati o interruzione delle applicazioni di messaggistica.

Diagramma che mostra uno spazio dei nomi del bus di servizio con ridondanza della zona.

Requisiti

  • Supporto per l'area: I namespace del bus di servizio con ridondanza di zona possono essere distribuiti nelle aree di Azure con il supporto delle zone di disponibilità. Il bus di servizio abilita automaticamente il supporto della zona di disponibilità quando si crea uno spazio dei nomi in un'area supportata, senza alcuna configurazione aggiuntiva necessaria.

  • Livelli: Tutti i livelli del bus di servizio (Basic, Standard e Premium) supportano le zone di disponibilità senza requisiti aggiuntivi.

Considerazioni

Gli spazi dei nomi di Service Bus includono una zoneRedundant proprietà. In precedenza, questa proprietà era necessaria per abilitare le zone di disponibilità, ma questo comportamento è stato modificato e la zoneRedundant proprietà è deprecata. Questa proprietà potrebbe ancora essere visualizzata come false anche quando la ridondanza della zona è abilitata. Tutti gli spazi dei nomi nelle aree con zone di disponibilità presentano la ridondanza della zona.

Costo

La ridondanza della zona nel bus di servizio non comporta costi aggiuntivi.

Configurare il supporto delle zone di disponibilità

Gli spazi dei nomi del bus di servizio supportano automaticamente la ridondanza zonale quando vengono distribuiti nelle aree supportate. Non sono necessarie altre configurazioni.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando i namespace del Service Bus sono configurati per la ridondanza zonale e tutte le zone di disponibilità sono operative.

  • Routing del traffico tra zone. Il bus di servizio usa un modello attivo-attivo in cui i messaggi vengono distribuiti tra più zone di disponibilità. Le connessioni client vengono bilanciate automaticamente tra le zone e il servizio indirizza le operazioni all'infrastruttura di messaggistica disponibile indipendentemente dalla zona.

  • Replica dei dati tra zone. Il bus di servizio usa la replica sincrona tra zone di disponibilità, inclusi i metadati e i dati dei messaggi. Prima di essere considerate complete, è necessario che più copie dell'archivio di messaggistica riconoscano le operazioni di scrittura, garantendo la coerenza dei dati tra le zone durante le normali operazioni.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando gli spazi dei nomi del bus di servizio sono configurati per la ridondanza della zona e si verifica un'interruzione delle zone di disponibilità.

  • Rilevamento e risposta: Microsoft rileva automaticamente gli errori di zona e avvia il failover in zone integre. Non è necessaria alcuna azione del cliente per il failover a livello di zona.
  • 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: durante un errore di zona, il bus di servizio potrebbe eliminare le richieste attive. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

  • Perdita di dati prevista: non si verifica alcuna perdita di dati durante un errore di zona perché il bus di servizio replica in modo sincrono i messaggi tra le zone prima del riconoscimento.

  • Tempo di inattività previsto: un errore della zona potrebbe causare alcuni secondi di inattività. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

  • Reindirizzamento del traffico: il bus di servizio rileva la perdita della zona e reindirizza automaticamente le nuove richieste a un'altra replica in una delle zone di disponibilità integre.

    L'SDK del bus di servizio gestisce in genere la gestione delle connessioni e la logica di ripetizione dei tentativi in modo trasparente.

Ripristino della zona

Quando una zona di disponibilità viene ripristinata, il bus di servizio reintegra automaticamente la zona nella topologia del servizio attiva. La zona ripristinata inizia ad accettare nuove connessioni ed elaborare messaggi insieme alle altre zone. I dati replicati nelle zone sopravvissute durante l'interruzione rimangono intatti e la normale replica sincrona riprende in tutte le zone. Non è necessario intervenire per il ripristino e la reintegrazione della zona.

Verifica dei guasti di zona

Il bus di servizio gestisce il routing del traffico, il failover e il ripristino delle zone in caso di interruzioni, pertanto non è necessario convalidare i processi di errore delle zone di disponibilità né fornire ulteriore input.

Resilienza agli errori a livello di area

Service Bus fornisce due tipi di supporto per più aree, entrambi richiedono namespace Premium:

  • La replica geografica fornisce la replica attiva-passiva dei metadati e dei dati dei messaggi tra un'area primaria e un'area secondaria. Usare Geo-Replication per la maggior parte delle applicazioni che devono rimanere resilienti alle interruzioni regionali e che hanno una bassa tolleranza per la perdita di dati dei messaggi.

  • Ripristino di emergenza geografico dei metadati fornisce la replica attiva-passiva della configurazione e dei metadati tra una area primaria e una secondaria, ma non replica i dati dei messaggi. Prendere in considerazione l'uso di Geo-Disaster Recovery per le applicazioni che gestiscono la propria replica dei dati o che non richiedono la replica dei dati.

Sia la replica geografica sia il ripristino di emergenza geografico dei metadati richiedono l'avvio manuale del failover o della promozione di un'area secondaria a nuova area primaria. Microsoft non esegue automaticamente il failover o la promozione, anche se la regione primaria è inattiva.

I namespace nei livelli Basic e Standard non includono funzionalità native multi-regione, ma è possibile implementare modelli di replica a livello di applicazione usando più namespace in diverse regioni. Per altre informazioni, vedere la sezione Soluzioni personalizzate in più aree per la resilienza di seguito.

Geo-Replication

Il livello Premium supporta la replica geografica. Questa funzionalità replica sia i metadati, ad esempio entità, configurazione e proprietà, sia i dati, ad esempio i messaggi nelle code e negli argomenti, inclusi proprietà e stato dei messaggi, per lo spazio dei nomi. Configurare l'approccio alla replica per la configurazione e i dati dello spazio dei nomi. Questa funzionalità garantisce che i messaggi rimangano disponibili in un'altra area e consentano di passare all'area secondaria quando necessario.

Usare Geo-Replication per scenari che richiedono resilienza alle interruzioni dell'area e hanno una bassa tolleranza per la perdita di dati dei messaggi.

Lo spazio dei nomi si estende fondamentalmente tra regioni. Un'area funge da primaria e l'altra funge da secondaria. La sottoscrizione di Azure mostra un singolo spazio dei nomi.

Diagramma che mostra uno spazio dei nomi del bus di servizio configurato per la replica geografica.

In qualsiasi momento, è possibile alzare di livello l'area secondaria a un'area primaria. Quando si promuove l'area secondaria, il bus di servizio reindirizza il nome di dominio completo (FQDN) dello spazio dei nomi all'area secondaria selezionata e declassa l'area primaria precedente a area secondaria. Si decide se eseguire una promozione pianificata, ovvero attendere il completamento della replica dei dati o un'innalzamento di livello forzato, con conseguente perdita di dati.

Annotazioni

Il Service Bus Geo-Replication utilizza il termine promozione perché rappresenta meglio il processo di promozione di una regione secondaria a una regione primaria (e successivamente retrocedere una regione primaria a una regione secondaria). Potresti anche vedere il termine failover usato per descrivere un processo generale.

Questa sezione riepiloga gli aspetti importanti della replica geografica. Esaminare la documentazione completa per comprendere esattamente il funzionamento. Per altre informazioni, vedere Replica geografica del bus di servizio.

Requisiti

  • Supporto per l'area: È possibile scegliere qualsiasi area di Azure che supporti il bus di servizio come area primaria o secondaria. Non è necessario usare le aree abbinate di Azure, quindi è possibile scegliere aree secondarie in base ai requisiti di latenza, conformità o residenza dei dati.

  • Livello: Per abilitare la replica geografica, lo spazio dei nomi deve usare il livello Premium.

  • Ripristino di emergenza geografico dei metadati: non è possibile configurare uno spazio dei nomi per l'uso della replica geografica e del ripristino di emergenza geografico.

Considerazioni

  • Limitazioni delle funzionalità: Quando si abilita la replica geografica, esistono alcune restrizioni. Per altre informazioni, vedere Replica geografica del bus di servizio.

  • Endpoint privati: se si usano endpoint privati per connettersi allo spazio dei nomi, è anche necessario configurare la rete nelle aree primarie e secondarie. Per altre informazioni, vedere Endpoint privati nella documentazione di Azure Event Hubs.

Costo

Per informazioni sul funzionamento dei prezzi per la replica geografica, vedere Prezzi.

Configurare il supporto per più aree

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando uno spazio dei nomi del bus di servizio è configurato per la replica geografica e l'area primaria è operativa.

  • Routing del traffico tra aree: le applicazioni client si connettono tramite il nome di dominio completo per lo spazio dei nomi e i loro traffico viene instradato all'area primaria.

    Solo l'area primaria elabora attivamente i messaggi dai client durante le normali operazioni. L'area secondaria riceve messaggi replicati, ma in caso contrario rimane passiva in modalità standby.

  • Replica dei dati tra aree: Il comportamento di replica dei dati tra l'area primaria e quella secondaria dipende dal fatto che l'associazione di replica sia configurata per l'uso della replica sincrona o asincrona.

    • Sincrono: I messaggi vengono replicati nell'area secondaria prima del completamento dell'operazione di scrittura.

      Questa modalità offre la massima garanzia che i dati del messaggio sono sicuri perché devono essere sottoposti a commit nell'area primaria e secondaria. Tuttavia, la replica sincrona aumenta notevolmente la latenza di scrittura per i messaggi in arrivo. È inoltre necessario che l'area secondaria sia disponibile per accettare l'operazione di scrittura, pertanto un'interruzione nell'area secondaria causa l'esito negativo dell'operazione di scrittura.

      • Asincrono: I messaggi vengono scritti nell'area primaria e quindi l'operazione di scrittura viene completata. Poco dopo, replica i messaggi nell'area secondaria.

      Questa modalità offre una velocità effettiva di scrittura superiore rispetto alla replica sincrona perché non esiste una latenza di replica tra aree durante le operazioni di scrittura. Inoltre, la modalità di replica asincrona può tollerare la perdita dell'area secondaria, consentendo comunque operazioni di scrittura nell'area primaria. Tuttavia, se l'area primaria presenta un'interruzione, i dati che non sono ancora stati replicati nell'area secondaria potrebbero non essere disponibili o persi.

      Quando si configura la replica asincrona, si configura il tempo massimo di ritardo accettabile per l'esecuzione della replica. In qualsiasi momento, è possibile verificare il ritardo di replica corrente usando le metriche di Monitoraggio di Azure.

      Se il ritardo di replica asincrona aumenta oltre il limite massimo specificato, l'area primaria inizia a limitare le richieste in ingresso in modo che la replica possa recuperare. Per evitare questa situazione, è importante selezionare le aree secondarie che non sono troppo distanti geograficamente e assicurarsi che la capacità sia sufficiente per la velocità effettiva.

      Alcuni tipi di metadati vengono replicati in modo sincrono anche se si seleziona la modalità di replica asincrona.

      Per altre informazioni, vedere Modalità di replica.

Comportamento durante un'interruzione della regione

Questa sezione descrive cosa aspettarsi quando uno spazio dei nomi del bus di servizio è configurato per Geo-Replication ed è presente un'interruzione nell'area primaria o secondaria.

  • Rilevamento e risposta: È responsabilità dell'utente decidere quando alzare di livello l'area secondaria dello spazio dei nomi per diventare la nuova area primaria. Microsoft non effettua questa decisione o avvia il processo per l'utente, anche se si verifica un'interruzione regionale. Per i criteri suggeriti da considerare quando si decide se eseguire il failover, vedere Scenari consigliati per attivare l'innalzamento di livello.

    Per ulteriori informazioni su come promuovere un'area secondaria a nuova area primaria, vedere Flusso di promozione.

    Quando si alza di livello un'area secondaria, scegliere se eseguire una promozione pianificata o una promozione forzata. Una promozione pianificata attende che la regione secondaria raggiunga lo stesso livello prima di accettare il nuovo traffico. Questo approccio elimina la perdita di dati, ma introduce tempi di inattività.

    Durante un'interruzione nell'area primaria, in genere è necessario eseguire una promozione forzata. Se l'area primaria è disponibile e si attiva una promozione per un altro motivo, è possibile scegliere una promozione pianificata.

  • 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: Il comportamento dipende dal fatto che l'interruzione dell'area si verifichi nell'area primaria o nell'area secondaria:

    • Interruzione dell'area primaria: Se l'area primaria non è disponibile, tutte le richieste attive vengono terminate. Le applicazioni client devono ripetere le operazioni al termine dell'innalzamento di livello.

    • Interruzione dell'area secondaria: Un'interruzione nell'area secondaria potrebbe causare problemi per le richieste attive nelle situazioni seguenti:

      • Se si usa la modalità di replica sincrona, l'area primaria non può completare le operazioni di scrittura se un'area secondaria non è disponibile.

      • Se si usa la modalità di replica asincrona, lo spazio dei nomi limita e non accetta nuovi messaggi dopo che il ritardo della replica raggiunge il valore massimo configurato.

      Per continuare a usare lo spazio dei nomi nell'area primaria, rimuovere lo spazio dei nomi secondario dalla configurazione della replica geografica.

  • Perdita di dati prevista: La quantità di perdita di dati dipende dal tipo di promozione eseguita (pianificata o forzata) e dalla modalità di replica (sincrona o asincrona):

    • Promozione pianificata: Non è prevista alcuna perdita di dati. Tuttavia, durante un'interruzione dell'area, una promozione pianificata potrebbe non essere possibile perché richiede che tutte le aree primarie e secondarie siano disponibili.

    • Promozione forzata, replica sincrona: Non è prevista alcuna perdita di dati.

    • Promozione forzata, replica asincrona: È possibile che si verifichi una perdita di dati per i messaggi recenti che non vengono replicati nell'area secondaria e per le modifiche dello stato che non sono ancora state replicate. La quantità dipende dal ritardo di replica. Per verificare il ritardo di replica corrente, usare le metriche di Monitoraggio di Azure.

    Se si esegue una promozione forzata, non è possibile recuperare i dati persi, anche dopo che l'area primaria diventa disponibile.

  • Tempo di inattività previsto: La quantità di tempo di inattività previsto dipende dal fatto che si esegua una promozione pianificata o forzata:

    • Promozione pianificata: Il primo passaggio di una promozione pianificata replica i dati nell'area secondaria. Questo processo viene in genere completato rapidamente, ma in alcune situazioni potrebbe richiedere fino alla durata del ritardo di replica. Al termine della replica, il processo di promozione richiede in genere da 5 a 10 minuti. A volte i server DNS (Domain Name System) possono impiegare più tempo per aggiornare le voci e replicare completamente i loro record ai client.

      La regione primaria non accetta operazioni di scrittura durante l'intero processo di promozione.

      Questa opzione potrebbe non essere possibile durante un'interruzione dell'area perché richiede che tutte le aree primarie e secondarie siano disponibili.

    • Promozione forzata: Durante una promozione forzata, Service Bus non attende il completamento della replica dei dati e avvia immediatamente la promozione. Il processo di promozione richiede in genere da 5 a 10 minuti. A volte può essere necessario più tempo per la replica completa e l'aggiornamento delle voci DNS tra i client.

      La regione primaria non accetta operazioni di scrittura durante l'intero processo di promozione.

  • Reindirizzamento del traffico: Dopo il completamento della promozione, l'FQDN dello spazio dei nomi punta alla nuova regione primaria. Tuttavia, questo reindirizzamento dipende dalla velocità di aggiornamento dei record DNS dei client, inclusi i server DNS che devono rispettare il "time-to-live" (o TTL, tempo di vita) dei record DNS dello spazio dei nomi.

Ripristino della regione

Dopo il ripristino dell'area primaria originale, se si vuole restituire lo spazio dei nomi all'area primaria originale, seguire la stessa procedura di promozione dell'area.

Se è stata eseguita una promozione forzata durante l'interruzione dell'area, non è possibile recuperare i dati persi, anche dopo che l'area primaria diventa disponibile.

Test per guasti a livello di area

Per testare la replica geografica, alzare temporaneamente di livello l'area secondaria alla replica primaria e verificare che le applicazioni client possano passare da un'area all'altra con interruzioni minime.

Monitorare la durata dell'innalzamento di livello e verificare che i runbook e l'automazione funzionino correttamente. Dopo il test, è possibile eseguire il failback alla configurazione originale.

Comprendere il potenziale tempo di inattività e la perdita di dati che potrebbero verificarsi durante e dopo il processo di promozione. Testare la replica geografica in un ambiente non di produzione che rispecchi la configurazione dello spazio dei nomi di produzione.

Ripristino di emergenza geografico dei metadati

Il livello Premium supporta i metadati del recupero da disastri geografici. Questa funzionalità migliora il ripristino da scenari di emergenza, inclusa la perdita irreversibile di un'area. Il ripristino di emergenza geografico replica solo la configurazione e i metadati dello spazio dei nomi. Tuttavia, non replica i dati dei messaggi. Per supportare il ripristino di emergenza, questa funzionalità garantisce che uno spazio dei nomi in un'altra area sia preconfigurato e pronto per accettare immediatamente i messaggi dai client. Geo-Disaster Recovery funge da soluzione di recupero unidirezionale e non supporta il failback nell'area primaria precedente.

Il Geo-Disaster Recovery dei metadati funziona meglio per le applicazioni che non devono necessariamente mantenere ogni messaggio e possono tollerare una perdita di dati durante uno scenario di disastro. Il ripristino dei metadati Geo-Disaster potrebbe anche essere appropriato per le applicazioni che replicano i dati stessi o che non richiedono affatto la replica dei dati. Ad esempio, se i messaggi rappresentano immagini di grandi dimensioni convertite successivamente in anteprime, è possibile decidere di perdere alcuni messaggi da un'area non riuscita se è possibile riprendere rapidamente l'elaborazione di nuovi messaggi in un'altra area e ricostruire i messaggi in un secondo momento per recuperare i messaggi.

Importante

Il ripristino di emergenza geografico favorisce la continuità delle operazioni che presenta la stessa configurazione, ma non replica i dati dei messaggi. Se è necessario replicare i dati dei messaggi, prendere in considerazione l'uso della replica geografica.

Quando si configurano i metadati di ripristino in caso di disastro geografico, si crea un alias a cui le applicazioni client si connettono. L'alias è un FQDN che indirizza tutto il traffico allo spazio dei nomi primario per impostazione predefinita.

Diagramma che mostra due spazi dei nomi del bus di servizio configurati per il ripristino di emergenza geografico dei metadati.

Se l'area primaria ha esito negativo o si verifica un altro tipo di emergenza, è possibile avviare manualmente un failover unidirezionale da un'area primaria all'area secondaria in qualsiasi momento. È possibile scegliere di eseguire un failover sicuro, che attende il completamento delle repliche prima di passare all'area secondaria, anche se questa opzione potrebbe non essere disponibile durante un'interruzione dell'area. Una volta avviato un failover, viene completato quasi immediatamente. Durante il processo di failover, l'alias del ripristino di emergenza geografico viene reindirizzato allo spazio dei nomi secondario e l'associazione viene rimossa.

Questa sezione riepiloga gli aspetti importanti del ripristino di Geo-Disaster. Esaminare la documentazione completa per comprendere esattamente il funzionamento. Per altre informazioni, vedere Ripristino di emergenza geografico del bus di servizio.

Requisiti

  • Supporto per l'area: È possibile selezionare qualsiasi area di Azure che supporti il bus di servizio come spazio dei nomi primario o secondario. Non è necessario usare le aree abbinate di Azure, quindi è possibile scegliere aree secondarie in base ai requisiti di latenza, conformità o residenza dei dati.

  • Livello: per abilitare il ripristino di emergenza geografico dei metadati, entrambi gli spazi dei nomi devono usare il livello Premium.

  • Partizionamento: Non è possibile associare uno spazio dei nomi partizionato a uno spazio dei nomi non partizionato.

  • Ripristino di emergenza geografico dei metadati: non è possibile configurare uno spazio dei nomi per l'uso della replica geografica e del ripristino di emergenza geografico.

Considerazioni

  • Limitazioni delle funzionalità: Quando si abilita Geo-Disaster ripristino, esistono alcune restrizioni. Per altre informazioni, vedere Punti importanti da considerare e considerazioni.

  • Assegnazioni di ruolo: Le assegnazioni di controllo degli accessi in base al ruolo di Microsoft Entra alle entità nello spazio dei nomi primario non vengono replicate nello spazio dei nomi secondario. Creare manualmente assegnazioni di ruolo nello spazio dei nomi secondario per accedervi.

  • Progettazione delle applicazioni: Geo-Disaster Recovery richiede considerazioni specifiche quando si progettano le applicazioni client. Per maggiori informazioni, vedere Considerazioni.

  • Endpoint privati: se si usano endpoint privati per connettersi allo spazio dei nomi, configurare la rete nell'area primaria e secondaria. Per altre informazioni, vedere endpoint privati.

  • Spazi dei nomi migrati da Standard a Premium: Se lo spazio dei nomi era precedentemente nel livello Standard ed è stato eseguito la migrazione al livello Premium, è necessario gestire l'alias in modo diverso. Per ulteriori informazioni, vedere Azure Service Bus da Standard a Premium.

Costo

Quando si abilita il ripristino di emergenza geografico dei metadati, si paga sia per gli spazi dei nomi primario sia per quello secondario.

Configurare il supporto per più aree

  • Creare l'associazione del ripristino di emergenza geografico dei metadati. Per configurare il ripristino di emergenza tra namespace primari e secondari, vedere Configurazione e flusso di failover.

  • Disabilitare il ripristino di emergenza geografico dei metadati. Per interrompere l'associazione tra namespace, vedere Configurazione e flusso di failover.

Pianificazione e gestione della capacità

Quando si pianificano distribuzioni in più aree, assicurarsi che entrambe le aree dispongano di capacità sufficiente per gestire il carico completo in caso di errore di un'area. L'area secondaria rimane passiva durante le normali operazioni, ma deve gestire immediatamente il traffico dopo il failover. Pianificare come aumentare la capacità dello spazio dei nomi secondario, affinché possa ricevere traffico di produzione senza ritardi. Se è possibile tollerare tempi di inattività aggiuntivi durante il processo di failover, è possibile scegliere di ridimensionare la capacità dello spazio dei nomi secondario durante o dopo il failover. Per ridurre i tempi di inattività, effettuare il provisioning della capacità nello spazio dei nomi secondario in anticipo in modo che rimanga pronto per ricevere il carico di produzione.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando uno spazio dei nomi di Service Bus è configurato per il ripristino geografico in caso di disastro e la regione primaria è operativa.

  • Instradamento del traffico tra regioni: Le applicazioni client si connettono attraverso l'alias Geo-Disaster Recovery per lo spazio dei nomi e il traffico viene indirizzato verso lo spazio dei nomi primario nella regione primaria.

    Solo lo spazio dei nomi primario elabora attivamente i messaggi dai client durante le normali operazioni. Lo spazio dei nomi secondario rimane passivo in modalità standby ed eventuali richieste di accesso ai dati hanno esito negativo.

  • Replica dei dati tra aree: Solo i metadati di configurazione vengono replicati tra gli spazi dei nomi. La replica della configurazione viene eseguita in modo continuo e asincrono.

    Tutti i dati dei messaggi rimangono solo nello spazio dei nomi primario e non vengono replicati nello spazio dei nomi secondario.

Comportamento durante un'interruzione della regione

Questa sezione descrive cosa aspettarsi quando uno spazio dei nomi del bus di servizio è configurato per il ripristino di emergenza geografico e si verifica un'interruzione nell'area primaria.

  • Rilevamento e risposta: L'utente è responsabile del monitoraggio dello stato di integrità della regione e di avviare manualmente il failover. Microsoft non esegue automaticamente il failover o alza di livello un'area secondaria, anche se l'area primaria è inattiva.

    Per ulteriori informazioni su come avviare il failover, vedere Processo di failover.

    Quando si avvia un failover, scegliere se eseguire un failover sicuro o uno standard (failover forzato o manuale). Un failover sicuro attende il completamento della replica nell'area secondaria prima che abbia inizio il failover. Questo approccio riduce la perdita di metadati, ma comporta tempi di inattività. Il failover sicuro richiede che i namespace si trovino nella stessa sottoscrizione di Azure.

    Durante un'interruzione nell'area primaria, in genere è necessario eseguire un failover forzato. Se l'area primaria è disponibile e si attiva un failover per un'altra area, potrebbe essere preferibile scegliere un failover pianificato.

    Il failover è un'operazione unidirezionale, pertanto è necessario ristabilire l'associazione del ripristino di emergenza geografico in un secondo momento. Per altre informazioni, vedere Ripristino dell'area.

  • 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: Le richieste attive in corso terminano all'avvio del failover. Le applicazioni client devono ripetere le operazioni dopo il completamento del failover.

  • Perdita di dati prevista:

    • Metadati: La configurazione e i metadati vengono in genere replicati nello spazio dei nomi secondario. Tuttavia, la replica dei metadati viene eseguita in modo asincrono, quindi le modifiche recenti potrebbero non essere replicate, in particolare le modifiche complesse. Verificare la configurazione dello spazio dei nomi secondario prima che i client accedano.

    • Dati del messaggio: I dati dei messaggi non vengono replicati tra aree. Se l'area primaria diventa inattiva, i messaggi nello spazio dei nomi primario diventano non disponibili.

      I messaggi non vengono persi definitivamente, a meno che un'emergenza irreversibile non causi una perdita totale dell'area primaria. Se l'area viene ripristinata, è possibile recuperare i messaggi dallo spazio dei nomi primario in un secondo momento.

  • Tempo di inattività previsto: Il failover si verifica in genere entro 5-10 minuti. La replica completa e l'aggiornamento delle voci DNS da parte dei client possono richiedere più tempo.

  • Reindirizzamento del traffico: I client che usano l'alias di ripristino Geo-Disaster per connettersi allo spazio dei nomi vengono reindirizzato automaticamente allo spazio dei nomi secondario dopo il failover. Tuttavia, questo reindirizzamento dipende dai server DNS che rispettano il TTL dei record DNS dello spazio dei nomi e i client che ricevono tali record DNS aggiornati.

Ripristino della regione

Dopo il ripristino dell'area primaria originale, è necessario ristabilire manualmente l'associazione e, facoltativamente, eseguire il failback. Creare una nuova associazione del ripristino di emergenza geografico con l'area ripristinata come secondaria, quindi eseguire un altro failover per tornare all'area originale. Questo processo comporta la potenziale perdita di dati dei messaggi inviati al database primario temporaneo.

Se l'emergenza causa la perdita di tutte le zone nell'area primaria, i dati potrebbero non essere irreversibili. In altri scenari, i dati del messaggio rimangono nello spazio dei nomi primario precedente al failover e sono recuperabili. È possibile ottenere messaggi cronologici dallo spazio dei nomi primario precedente dopo aver ripristinato l'accesso. L'utente è responsabile della configurazione delle applicazioni per ricevere ed elaborare tali messaggi. Microsoft non li ripristina automaticamente nell'area secondaria.

Test per guasti a livello di area

Per testare i processi di risposta e ripristino di emergenza, eseguire un failover pianificato durante una finestra di manutenzione. Avvia il failover dal namespace primario al namespace secondario e verifica che le applicazioni possano connettersi ed elaborare messaggi dal nuovo namespace primario.

Monitorare la durata del failover e verificare che i runbook e l'automazione funzionino correttamente. Dopo il test, è possibile eseguire il failback alla configurazione originale.

Comprendere il potenziale tempo di inattività e la perdita di dati che potrebbero verificarsi durante e dopo il processo di failover. Testare i metadati Geo-Disaster Recovery in un ambiente non di produzione che rispecchia la configurazione del namespace di produzione.

Soluzioni personalizzate in più aree per la resilienza

La replica geografica e il ripristino di emergenza geografico offrono resilienza per le interruzioni di aree e altri problemi e sono adatti per la maggior parte dei carichi di lavoro. Tuttavia, potrebbero non soddisfare le proprie esigenze nelle situazioni seguenti:

  • Sono previsti requisiti per la replica personalizzata o per la gestione simultanea di più aree attive.
  • Si usa un livello del bus di servizio che non supporta queste funzionalità.

Esistono diversi modelli di progettazione per ottenere diversi tipi di supporto in più aree nel bus di servizio. Molti dei modelli richiedono la distribuzione di più spazi dei nomi e la configurazione dell'applicazione per l'uso appropriato degli spazi dei nomi. Per ulteriori informazioni, vedere gli articoli seguenti:

Resilienza alla manutenzione del servizio

Il bus di servizio esegue una manutenzione regolare. Durante la manutenzione pianificata, i namespace vengono spostati in un nodo di riserva che contiene gli aggiornamenti più recenti. Quando si verifica questo spostamento, l'SDK client si disconnette e si riconnette automaticamente all'interno del namespace. In genere, gli aggiornamenti vengono eseguiti entro 30 secondi. È importante che le applicazioni siano preparate per eventuali disconnessioni di rete temporanee che si verificano durante i periodi di manutenzione.

Per altre informazioni, vedere Indicazioni sugli eventi di manutenzione di Azure per il bus di servizio di Azure.

Backup e ripristino

Il bus di servizio non è progettato come posizione di archiviazione a lungo termine per i dati. In genere, i dati vengono archiviati in un argomento o in una coda per un breve periodo di tempo e vengono quindi elaborati o salvati in modo permanente in un altro sistema di archiviazione dati, a questo punto vengono eliminati. A causa di questa progettazione, il bus di servizio gestisce automaticamente le repliche dei dati dei messaggi, ma non offre funzionalità di backup e ripristino per i dati dei messaggi.

Per gli scenari che richiedono la conservazione dei messaggi a lungo termine, è consigliabile implementare l'archiviazione a livello di applicazione in Archiviazione di Azure o in altri servizi di archiviazione durevoli.

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 altre informazioni, vedere Contratti di servizio per Servizi online.

Service Bus fornisce un accordo sul livello di servizio (SLA) per tutti gli spazi dei nomi. La SLA di disponibilità è superiore quando lo spazio dei nomi soddisfa tutti i criteri seguenti:

  • Usa il livello Premium.
  • Si trova in un'area con zone di disponibilità.
  • Usa il partizionamento.

Contenuti correlati

  • Last updated on