Procedure consigliate per proteggere le applicazioni da interruzioni e situazioni critiche del bus di servizio
Le applicazioni criciali devono funzionare in modo continuo, anche in presenza di interruzioni impreviste o situazioni di emergenza. 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 termine "interruzione" indica la temporanea indisponibilità del bus di servizio di Azure. Un'interruzione può interessare alcuni componenti del bus di servizio, ad esempio un archivio di messaggistica, o anche l'intero data center. Una volta risolto il problema, il bus di servizio torna di nuovo disponibile. In genere, un'interruzione non causa la perdita di messaggi o 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.
Il termine emergenza indica la perdita permanente di un'unità di scala del bus di servizio o di un data center. Il data center potrebbe o meno diventare nuovamente disponibile. In genere, un'emergenza determina la perdita di alcuni o di tutti i messaggi o di altri dati. Un'emergenza può essere causata, ad esempio, da un incendio, un'inondazione o un terremoto.
Protezione da interruzioni e emergenze - Livello Premium
I concetti relativi alla disponibilità elevata e al ripristino di emergenza sono integrati direttamente nel livello Premium bus di servizio di Azure, sia all'interno della stessa area (tramite zone di disponibilità) che in aree diverse (tramite il ripristino di emergenza geografico).
Ripristino di emergenza geografico
bus di servizio livello Premium 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, disponibile solo per lo SKU Premium, implementa il ripristino di emergenza dei metadati e si basa su spazi dei nomi primari e secondari. Con il ripristino di emergenza geografico, vengono replicati solo i metadati per le entità tra spazi dei nomi primari e secondari.
Zone di disponibilità
Il livello premium bus di servizio supporta le zone di disponibilità, fornendo posizioni isolate dagli errori all'interno della stessa area di Azure. bus di servizio gestisce tre copie dell'archivio di messaggistica (1 primario e 2 secondario). bus di servizio mantiene sincronizzate tutte e tre le copie per le operazioni di gestione e dati. Se la copia primaria ha esito negativo, una delle copie secondarie viene promossa a primaria senza tempi di inattività percepiti. Se le applicazioni visualizzano disconnessioni temporanee da bus di servizio, la logica di ripetizione dei tentativi nell'SDK si riconnette automaticamente a bus di servizio.
Quando si usano zone di disponibilità, i metadati e i dati (messaggi) vengono replicati tra data center nella zona di disponibilità.
Nota
Il supporto delle zone di disponibilità per il livello Premium è disponibile solo nelle aree di Azure in cui sono presenti le zone di disponibilità.
Quando si crea uno spazio dei nomi del livello Premium tramite il portale, il supporto per le zone di disponibilità (se disponibile nell'area selezionata) viene abilitato automaticamente per lo spazio dei nomi. Quando si crea uno spazio dei nomi di livello Premium tramite altri meccanismi, ad esempio modelli di Azure Resource Manager/Bicep, interfaccia della riga di comando o PowerShell, la proprietà zoneRedundant deve essere impostata in modo esplicito su true per abilitare le zone di disponibilità (se disponibili nell'area selezionata). 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.
Protezione da interruzioni e emergenze - Livello standard
Per ottenere resilienza contro le interruzioni del data center con il piano tariffario di messaggistica standard, è 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 della replica attiva e della replica passiva sono soluzioni per utilizzo generico e non funzionalità specifiche di bus di servizio. La logica di replica (invio a 2 spazi dei nomi diversi) si trova nelle applicazioni mittente e il ricevitore deve avere una logica personalizzata per il rilevamento dei duplicati.
Se l'applicazione non richiede la comunicazione permanente da mittente a ricevitore, l'applicazione può implementare una coda lato client durevole per evitare la perdita di messaggi e proteggere il mittente da eventuali errori di bus di servizio temporanei.
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. È possibile utilizzare le proprietà ServiceBusMessage.MessageId o ServiceBusMessage.Subject oppure una proprietà personalizzata per contrassegnare il messaggio. Il ricevitore deve mantenere l'elenco dei messaggi già ricevuti.
L'esempio [replica geografica con bus di servizio livello standard][Replica geografica con bus di servizio livello Standard] illustra la replica attiva delle entità di messaggistica.
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 questo punto, le entità attive e di backup cambiano ruoli. Il client di invio considera l'entità attiva precedente come la nuova entità di backup e l'entità di backup precedente è la 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é è possibile che il ricevitore riceva 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 i messaggi possono essere 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 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 il ricevitore non è in grado di ricevere la prima copia di m prima che la coda primaria diventi non disponibile, il ricevitore riceve inizialmente solo la seconda copia di m, ma riceve una seconda copia di m quando la coda primaria diventa disponibile.
L'esempio Attività di replica di 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: