Condividi tramite

Procedure consigliate per proteggere le applicazioni da interruzioni e situazioni critiche del bus di servizio

  • Articolo

Le applicazioni criciali devono funzionare in modo continuo, anche in presenza di interruzioni impreviste o situazioni di emergenza. La resilienza nei confronti di interruzioni disastrose delle risorse di elaborazione dati è un requisito per molte aziende e in alcuni casi è persino richiesta dalle normative di settore. Questo articolo descrive le tecniche che è possibile usare per proteggere le applicazioni del bus di servizio da una potenziale emergenza o interruzione del servizio.

Il bus di servizio di Azure distribuisce già il rischio di errori irreversibili di singoli computer o persino di rack completi in cluster che si estendono su più domini di errore all'interno di un data center e implementa meccanismi di rilevamento degli errori e di failover trasparenti in modo che il servizio continui a funzionare entro i livelli di servizio garantiti e in genere senza interruzioni evidenti quando si verificano tali errori.

Inoltre, il rischio di interruzione è ulteriormente distribuito tra tre strutture fisicamente separate (zone di disponibilità) e il servizio dispone di riserve di capacità sufficienti per far fronte immediatamente alla perdita irreversibile completa di un data center. Il modello di cluster del bus di servizio di Azure attivo all'interno di un dominio di errore insieme al supporto delle zone di disponibilità è superiore a qualsiasi prodotto broker messaggi locale in termini di resilienza contro errori hardware gravi e persino una perdita irreversibile di intere strutture del data center. Potrebbero comunque verificarsi situazioni gravi con distruzione fisica diffusa, che persino queste misure potrebbero non riuscire a contrastare.

La funzionalità di replica geografica e ripristino di emergenza geografico del bus di servizio di Azure è progettata per semplificare il ripristino da uno scenario di emergenza di questo calibro e abbandonare definitivamente un'area di Azure con errori senza dover cambiare le configurazioni delle applicazioni.

Emergenze e interruzioni

È importante notare la distinzione tra "interruzioni" ed "emergenze".

Un'interruzione è l'indisponibilità temporanea del bus di servizio di Azure e può interessare alcuni componenti del servizio, ad esempio un archivio di messaggistica, oppure l'intero data center. Dopo la risoluzione del problema, tuttavia, il bus di servizio torna di nuovo disponibile. Un'interruzione non determina in genere la perdita di messaggi o di altri dati. Un esempio di errore di un componente è la mancata disponibilità di un particolare archivio di messaggistica. Un esempio di interruzione a livello di data center è un'interruzione dell'alimentazione o il guasto di un commutatore di rete. Un'interruzione può durare da pochi minuti ad alcuni giorni. Alcune interruzioni sono solo brevi perdite di connessione dovute a problemi di rete o temporanei.

Il termine emergenza indica la perdita permanente o a lungo termine di un cluster del bus di servizio, un'area di Azure o un data center. L'area o il data center potrebbe o meno tornare di nuovo disponibile oppure potrebbe rimanere inattivo per ore o giorni. Un'emergenza può essere causata, ad esempio, da un incendio, un'inondazione o un terremoto. Una situazione di emergenza che diventa permanente potrebbe causare la perdita di alcuni messaggi, eventi o altri dati. Tuttavia, nella maggior parte dei casi non dovrebbe verificarsi la perdita dei dati e i messaggi possono essere ripristinati dopo aver eseguito il backup del data center.

Protezione da interruzioni ed emergenze

Esistono due funzionalità che forniscono il ripristino di emergenza geografico nel bus di servizio di Azure per il livello Premium. In primo luogo, è disponibile il ripristino di emergenza geografico (ripristino di emergenza dei metadati) che fornisce la replica dei metadati (entità, configurazione, proprietà). In secondo luogo, è presente la replica geografica, attualmente in anteprima pubblica, che fornisce la replica dei metadati e dei dati (dati dei messaggi e proprietà/modifiche dello stato dei messaggi) stessi. Nessuna delle due funzionalità di ripristino di emergenza geografico deve essere confusa con le zone di disponibilità di Azure. Indipendentemente dal fatto che si tratti di ripristino di emergenza dei metadati o replica geografica, entrambe le funzionalità di ripristino geografico offrono resilienza tra aree di Azure, ad esempio Stati Uniti orientali e Stati Uniti occidentali.

Le zone di disponibilità sono presenti in tutti i livelli del bus di servizio e il supporto offre resilienza all'interno di un'area geografica specifica, ad esempio Stati Uniti orientali. Per una descrizione dettagliata del ripristino di emergenza in Microsoft Azure, vedere questo articolo.

I concetti di disponibilità elevata e ripristino di emergenza sono integrati nel livello Premium del bus di servizio di Azure, sia all'interno della stessa area (tramite le zone di disponibilità) che tra aree diverse (tramite il ripristino di emergenza geografico e la replica geografica).

Opzioni per il ripristino di emergenza geografico

Ripristino di emergenza geografico

Il livello Premium del bus di servizio supporta il ripristino di emergenza geografico a livello di spazio dei nomi. Per altre informazioni, vedere Ripristino di emergenza geografico per il bus di servizio di Azure. La funzionalità di ripristino di emergenza geografico, disponibile solo per il livello Premium, implementa il ripristino di emergenza dei metadati e si basa sugli spazi dei nomi primari e secondari. Con il ripristino di emergenza geografico, vengono replicati solo i metadati per le entità tra gli spazi dei nomi primario e secondario.

Replica geografica

Il livello Premium del bus di servizio supporta anche la replica geografica a livello di spazio dei nomi. Per altre informazioni, vedere Replica geografica per il bus di servizio di Azure (anteprima pubblica). La funzionalità di replica geografica, disponibile solo per il livello Premium e attualmente in anteprima pubblica, implementa il ripristino di emergenza dei metadati e dei dati e si basa sulle aree primarie e secondarie. Con la replica geografica, sia i metadati che i dati per le entità vengono replicati tra le aree primarie e secondarie.

Differenze di funzionalità generali

La funzionalità Ripristino di emergenza geografico (ripristino di emergenza dei metadati) replica i metadati per uno spazio dei nomi da uno spazio dei nomi primario a uno spazio dei nomi secondario. Supporta un failover una sola volta nell'area secondaria. Durante il failover avviato dal cliente, viene eseguito un nuovo puntamento del nome alias per lo spazio dei nomi allo spazio dei nomi secondario e quindi l'associazione viene interrotta. Non vengono replicati dati diversi dai metadati né vengono replicati assegnazioni di controllo degli accessi in base al ruolo.

La funzionalità Replica geografica replica tutti i dati e i metadati da un'area primaria a una o più aree secondarie. Quando un failover viene eseguito dal cliente, l'area secondaria selezionata diventa quella primaria e l'area primaria precedente diventa l'area secondaria. Gli utenti possono eseguire un nuovo failover nell'area primaria originale quando lo desiderano.

Zone di disponibilità

Tutti i livelli del bus di servizio supportano le zone di disponibilità, fornendo località con isolamento di errore all'interno della stessa area di Azure. Il bus di servizio gestisce 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. Se le applicazioni riscontrano disconnessioni temporanee dal bus di servizio, la logica di ripetizione dei tentativi nell'SDK si riconnette automaticamente al bus di servizio.

Quando si usano le zone di disponibilità, sia i metadati che i dati (messaggi) vengono replicati tra data center nella zona di disponibilità.

Nota

Il supporto per le zone di disponibilità è disponibile solo nelle aree di Azure in cui sono presenti le zone di disponibilità.

Quando si crea uno spazio dei nomi, il supporto per le zone di disponibilità (se disponibile nell'area selezionata) viene abilitato automaticamente per lo spazio dei nomi. Non sono previsti costi aggiuntivi per l'uso di questa funzionalità e non è possibile disabilitare o abilitare questa funzionalità dopo la creazione dello spazio dei nomi.

Nota

In precedenza era necessario impostare la proprietà zoneRedundant su true per abilitare le zone di disponibilità, tuttavia questo comportamento è stato modificato per abilitare le zone di disponibilità per impostazione predefinita. Anche gli spazi dei nomi esistenti vengono migrati alle zone di disponibilità quando possibile e la proprietà zoneRedundant è deprecata. La proprietà zoneRedundant potrebbe essere ancora visualizzata come false, anche quando sono state abilitate le zone di disponibilità. Spazi dei nomi esistenti di cui viene eseguita la migrazione:

Protezione contro le emergenze - Livello Standard

Per ottenere resilienza contro le emergenze con il livello Standard del bus di servizio, è possibile usare la replica attiva o passiva. Per ogni approccio, se una coda o un argomento specifico deve rimanere accessibile in presenza di un'interruzione del data center, è possibile creare tale coda o argomento in entrambi gli spazi dei nomi. Entrambe le entità possono avere lo stesso nome. Ad esempio, una coda primaria può essere raggiunta in contosoPrimary.servicebus.windows.net/myQueue, mentre la rispettiva coda secondaria può essere raggiunta in contosoSecondary.servicebus.windows.net/myQueue.

Nota

La configurazione di replica attiva e replica passiva è costituita da soluzioni per utilizzo generico e non funzionalità specifiche del bus di servizio. La logica di replica (con l'invio a due spazi dei nomi diversi) si trova nelle applicazioni mittenti e il ricevitore deve disporre di una logica personalizzata per il rilevamento dei duplicati.

Se l'applicazione non richiede una comunicazione mittente-ricevitore permanente, può implementare una coda permanente sul lato client in modo da impedire la perdita di messaggi e proteggere il mittente da eventuali errori temporanei del bus di servizio.

Replica attiva

La replica attiva usa entità in entrambi gli spazi dei nomi per ogni operazione. Ogni client invia sempre due copie di un messaggio. La prima viene inviata all'entità primaria, ad esempio contosoPrimary.servicebus.windows.net/sales, la seconda all'entità secondaria, ad esempio contosoSecondary.servicebus.windows.net/sales.

Un client riceve messaggi da entrambe le code. Il ricevitore elabora la prima copia di un messaggio ed elimina la seconda. Per eliminare i messaggi duplicati, il mittente deve contrassegnare ogni messaggio con un identificatore univoco. Entrambe le copie del messaggio devono essere contrassegnate con lo stesso identificatore. Per contrassegnare il messaggio con tag, è possibile usare la proprietà ServiceBusMessage.MessageId o ServiceBusMessage.Subject oppure una proprietà personalizzata. Il ricevitore deve mantenere l'elenco dei messaggi già ricevuti.

Nota

Nella replica attiva il numero delle operazioni raddoppia. Di conseguenza, questo approccio può comportare costi più elevati.

Replica passiva

Quando non si verificano errori, nella replica passiva viene usata solo una delle due entità di messaggistica. Un client invia il messaggio all'entità attiva. Se l'operazione sull'entità attiva non riesce e viene restituito un codice di errore per segnalare che il data center che ospita l'entità attiva potrebbe non essere disponibile, il client invia una copia del messaggio all'entità di backup. A quel punto l'entità attiva e quella di backup si scambiano i ruoli. Il client mittente considera l'entità attiva precedente come nuova entità di backup e l'entità di backup precedente come nuova entità attiva. Se entrambe le operazioni di invio hanno esito negativo, i ruoli delle due entità rimangono invariati e viene restituito un errore.

Un client riceve messaggi da entrambe le code. Poiché potrebbe ricevere due copie dello stesso messaggio, il ricevitore deve eliminare i messaggi duplicati. È possibile eliminare i duplicati nel modo descritto per la replica attiva.

In genere, la replica passiva è più vantaggiosa di quella attiva perché nella maggior parte dei casi viene eseguita una sola operazione. La latenza, la velocità effettiva e il costo sono identici a quelli di uno scenario non replicato.

Quando si usa la replica passiva, negli scenari seguenti è possibile che i messaggi vengano persi o ricevuti due volte:

  • Ritardo o perdita del messaggio: si supponga che il mittente abbia inviato con esito positivo un messaggio m1 alla coda primaria e che quindi la coda diventi non disponibile prima della ricezione di m1 da parte del ricevitore. Il mittente invia un secondo messaggio m2 alla coda secondaria. Se la coda primaria è temporaneamente non disponibile, m1 viene ricevuto solo quando la coda torna nuovamente disponibile. Quando si verifica un'emergenza, il ricevitore potrebbe non ricevere mai il messaggio m1.
  • Ricezione di duplicati: si supponga che il mittente invii un messaggio m alla coda primaria. Il bus di servizio elabora m ma non riesce a inviare una risposta. Dopo il timeout dell'operazione di invio, il mittente invia una copia identica di m alla coda secondaria. Se la prima copia di m viene ricevuta prima che la coda primaria diventi non disponibile, le due copie di m verranno ricevute quasi contemporaneamente. Se invece la prima copia di m non viene ricevuta prima che la coda primaria diventi non disponibile, il ricevitore riceverà inizialmente solo la seconda copia di m. L'altra copia di m verrà ricevuta quando la coda primaria diventerà disponibile.

L'esempio Attività di replica della messaggistica di Azure con .NET Core illustra la replica dei messaggi tra spazi dei nomi.

Passaggi successivi

Per altre informazioni sul ripristino di emergenza, vedere gli articoli seguenti: