Ripristino di emergenza geografico per il bus di servizio di Azure

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.

bus di servizio di Azure già diffuso 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 e 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. Uno spazio dei nomi Premium può avere due o più unità di messaggistica e queste unità di messaggistica vengono distribuite in più domini di errore all'interno di un data center, supportando un modello di cluster bus di servizio attivo.

Per uno spazio dei nomi di livello Premium, il rischio di interruzione viene ulteriormente distribuito tra tre strutture separate fisicamente (zone di disponibilità) e il servizio dispone di riserve di capacità sufficienti per gestire immediatamente la perdita irreversibile completa di un data center. Il modello cluster all-active bus di servizio di Azure all'interno di un dominio di errore insieme al supporto della zona di disponibilità è superiore a qualsiasi prodotto broker di messaggi locale in termini di resilienza contro errori hardware gravi e persino una perdita irreversibile di intere strutture del data center. Tuttavia, potrebbero esserci gravi situazioni con distruzione fisica diffusa che anche tali misure non possono difendersi sufficientemente.

La funzionalità di ripristino di emergenza geografico bus di servizio è progettata per semplificare il ripristino da un'emergenza di questa grandezza e abbandonare un'area di Azure non riuscita per un'ottima soluzione e senza dover modificare le configurazioni dell'applicazione. L'abbandono di un'area di Azure comporta in genere diversi servizi e questa funzionalità mira principalmente a mantenere l'integrità della configurazione dell'applicazione composita. La funzionalità è disponibile a livello globale per lo SKU Premium bus di servizio.

La funzionalità di ripristino di emergenza geografico garantisce che l'intera configurazione di uno spazio dei nomi (code, argomenti, sottoscrizioni, filtri) venga replicata continuamente da uno spazio dei nomi primario a uno spazio dei nomi secondario quando abbinata e consente di avviare un failover una sola volta dal database primario al secondario in qualsiasi momento. Il failover sposta nuovamente il nome alias scelto per lo spazio dei nomi nello spazio dei nomi secondario e quindi interrompe l'associazione. Una volta avviato, il failover è pressoché istantaneo.

Elementi importanti da considerare

  • La funzionalità abilita la continuità immediata delle operazioni con la stessa configurazione, ma non replica i messaggi contenuti in code o sottoscrizioni di argomenti o code di messaggi non recapitabili. Per mantenere la semantica della coda, tale replica richiede non solo la replica dei dati dei messaggi, ma di ogni modifica dello stato nel broker. Per la maggior parte degli spazi dei nomi bus di servizio, il traffico di replica richiesto supera molto il traffico dell'applicazione e con code a velocità effettiva elevata, la maggior parte dei messaggi viene comunque replicata nel database secondario mentre è già stata eliminata dal database primario, causando traffico eccessivamente sprecato. Per le route di replica a latenza elevata, che si applica a molte associazioni scelte per il ripristino di emergenza geografico, potrebbe anche essere impossibile che il traffico di replica continui a mantenere il passo con il traffico dell'applicazione a causa di effetti di limitazione causati dalla latenza.
  • Le assegnazioni di controllo degli accessi in base al ruolo (RBAC) di Microsoft Entra per bus di servizio 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.
  • Le configurazioni seguenti non vengono replicate.
    • Configurazioni di rete virtuale
    • Connessioni a endpoint privato
    • Accesso a tutte le reti abilitato
    • Accesso al servizio attendibile abilitato
    • Accesso alla rete pubblica
    • Azione di rete predefinita
    • Identità e impostazioni di crittografia (crittografia della chiave gestita dal cliente o crittografia BYOK)
    • Abilitare la scalabilità automatica
    • Disabilitare l'autenticazione locale
  • L'associazione di uno spazio dei nomi partizionato a uno spazio dei nomi non partizionato non è supportata.
  • Se AutoDeleteOnIdle è abilitato per un'entità, l'entità potrebbe non essere presente nello spazio dei nomi secondario quando si verifica il failover. Quando il database secondario diventa primario l'ultimo stato di accesso, che non fa parte dei metadati, non sarà disponibile per la nuova entità primaria e potrebbe essere eliminata come parte della AutoDeleteOnIdle pulizia.

Suggerimento

Per replicare il contenuto delle code e delle sottoscrizioni di argomenti e gestire gli spazi dei nomi corrispondenti nelle configurazioni attive/attive per gestire interruzioni e emergenze, non è consigliabile usare questo set di funzionalità di ripristino di emergenza geografico, ma seguire le indicazioni sulla replica.

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'interruzione può essere provocata ad esempio da un'interruzione dell'alimentazione nel data center. 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 non essere più disponibile oppure potrebbe essere 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 dovrebbero esserci perdite di dati e i messaggi possono essere recuperati dopo il backup del data center.

La funzionalità di ripristino di emergenza geografico del bus di servizio di Azure è una soluzione di ripristino di emergenza. I concetti e il flusso di lavoro illustrati in questo articolo sono applicabili a scenari di emergenza, non a interruzioni temporanee. Per una descrizione dettagliata del ripristino di emergenza in Microsoft Azure, vedere questo articolo.

Concetti e terminologia di base

La funzionalità di ripristino di emergenza implementa il ripristino di emergenza dei metadati e si basa sugli spazi dei nomi primari e secondari di ripristino di emergenza. La funzionalità di ripristino di emergenza geografico è disponibile solo per lo SKU Premium. Non è necessario apportare modifiche alla stringa di connessione, perché la connessione viene effettuata tramite un alias.

In questo articolo viene usata la terminologia seguente:

  • Alias: nome per una configurazione di ripristino di emergenza impostata. L'alias fornisce una singola stringa di connessione FQDN (nome di dominio completo) stabile. Le applicazioni usano questa stringa di connessione alias per connettersi a uno spazio dei nomi. L'uso di un alias garantisce che la stringa di connessione rimanga invariata quando viene attivato il failover.

  • Spazio dei nomi primario/secondario: spazi dei nomi corrispondenti all'alias. Lo spazio dei nomi primario è "attivo" e riceve messaggi (può essere uno spazio dei nomi esistente o nuovo). Lo spazio dei nomi secondario è "passivo" e non riceve messaggi. I metadati vengono sincronizzati tra entrambi gli spazi dei nomi, quindi entrambi possono facilmente accettare messaggi senza modifiche al codice dell'applicazione o alla stringa di connessione. Per fare in modo che solo lo spazio dei nomi attivo riceva i messaggi, è necessario usare l'alias.

  • Metadati: entità come code, argomenti e sottoscrizioni e le relative proprietà del servizio associate allo spazio dei nomi. Solo le entità e le relative impostazioni vengono replicate automaticamente. I messaggi non vengono replicati.

  • Failover: processo di attivazione dello spazio dei nomi secondario.

Attrezzaggio

La sezione seguente è una panoramica per configurare l'associazione tra gli spazi dei nomi.

Immagine che mostra il funzionamento del ripristino di emergenza geografico.

È prima di tutto necessario creare uno spazio dei nomi primario o usarne uno esistente e creare un nuovo spazio dei nomi secondario, quindi associare i due spazi dei nomi. L'associazione fornisce un alias che può essere usato per la connessione. Poiché si usa un alias, non è necessario modificare le stringhe di connessione. È possibile aggiungere solo nuovi spazi dei nomi all'associazione di failover.

  1. Creare lo spazio dei nomi primario di livello Premium.

  2. Creare lo spazio dei nomi premium secondario in un'area diversa. Questo passaggio è facoltativo. È possibile creare lo spazio dei nomi secondario durante la creazione dell'associazione nel passaggio successivo.

  3. Nel portale di Azure, passare allo spazio dei nomi primario.

  4. Selezionare Ripristino geografico nel menu di sinistra, quindi Avvia associazione nella barra degli strumenti.

    Screenshot che mostra la pagina Ripristino geografico con il collegamento Avvia associazione selezionato.

  5. Alla pagina Avvia associazione, seguire questi passaggi:

    1. Selezionare uno spazio dei nomi secondario o crearne uno in un'area diversa. In questo esempio viene usato uno spazio dei nomi esistente come spazio dei nomi secondario.

    2. Per Alias, immettere un alias per l'associazione del ripristino di emergenza geografico.

    3. Quindi, selezionare Crea.

      Screenshot che mostra la pagina Avvia associazione nella portale di Azure.

  6. Verrà visualizzata la pagina bus di servizio alias di ripristino di emergenza geografico, come illustrato nell'immagine seguente. È anche possibile passare alla pagina Alias di ripristino di emergenza geografico dalla pagina dello spazio dei nomi primario selezionando il ripristino geografico nel menu a sinistra.

    Screenshot che mostra la pagina bus di servizio alias di ripristino di emergenza geografico con spazi dei nomi primari e secondari.

  7. Alla pagina Alias ripristino di emergenza geografico, selezionare Criteri di accesso condiviso nel menu di sinistra per accedere alla stringa di connessione primaria per l'alias. Usare questa stringa di connessione al posto della stringa di connessione diretta allo spazio dei nomi primario/secondario. Inizialmente, l'alias fa riferimento allo spazio dei nomi primario.

  8. Passare alla pagina Panoramica. È possibile effettuare le seguenti operazioni:

    1. Interrompere l'associazione tra gli spazi dei nomi primario e secondario. Selezionare Interrompi associazione nella barra degli strumenti.
    2. Effettuare manualmente il failover allo spazio dei nomi secondario.
      1. Selezionare Failover nella barra degli strumenti.

      2. Verificare di voler eseguire il failover nello spazio dei nomi secondario digitando l'alias.

      3. Attivare l'opzione failover Cassaforte per eseguire in modo sicuro il failover nello spazio dei nomi secondario.

        Nota

        • Il failover sicuro assicura che le repliche di ripristino di emergenza geografico in sospeso vengano completate prima di passare al database secondario. Mentre il failover forzato o manuale non attende il completamento delle repliche in sospeso prima di passare al database secondario.
        • Attualmente, il failover sicuro ha esito negativo se gli spazi dei nomi primario e secondario non si trovano nella stessa sottoscrizione di Azure.
      4. Selezionare quindi Failover.

        Screenshot che mostra la pagina Failover.

        Importante

        Il failover attiva lo spazio dei nomi secondario e rimuove lo spazio dei nomi primario dall'associazione Di ripristino di emergenza geografico. Creare un altro spazio dei nomi per predisporre una nuova associazione di ripristino di emergenza geografico.

  9. Infine, è necessario aggiungere funzionalità di monitoraggio per rilevare i casi in cui è necessario un failover. Nella maggior parte dei casi, il servizio fa parte di un ecosistema di grandi dimensioni, quindi i failover automatici sono raramente possibili, in quanto spesso i failover devono essere eseguiti in modo sincronizzato con il sottosistema o l'infrastruttura rimanente.

bus di servizio standard a Premium

Se è stata eseguita la migrazione dello spazio dei nomi bus di servizio di Azure Standard a bus di servizio di Azure Premium, è necessario usare l'alias preesistente, ovvero lo spazio dei nomi standard bus di servizio stringa di connessione) per creare la configurazione del ripristino di emergenza tramite PS/CLI o API REST.

Poiché, durante la migrazione, lo spazio dei nomi standard bus di servizio di Azure stringa di connessione/DNS diventa un alias per lo spazio dei nomi bus di servizio di Azure Premium.

Le applicazioni client devono usare questo alias( ovvero lo spazio dei nomi standard bus di servizio di Azure stringa di connessione) per connettersi allo spazio dei nomi Premium in cui è stata configurata l'associazione di ripristino di emergenza.

Se si usa il portale di Azure per configurare la configurazione del ripristino di emergenza, il portale astrae questo avviso.

Flusso del failover

Un failover viene attivato manualmente dal cliente (sia in modo esplicito con un comando o tramite la logica di business di proprietà del client che attiva il comando) e mai da Azure. Offre al cliente la proprietà completa e la visibilità per la risoluzione dell'interruzione nel backbone di Azure.

Immagine che mostra il flusso di failover dallo spazio dei nomi primario a quello secondario.

In seguito all'attivazione del failover:

  1. La stringa di connessione alias viene aggiornata in modo che faccia riferimento allo spazio dei nomi Premium secondario.

  2. I client (mittenti e destinatari) si connettono automaticamente allo spazio dei nomi secondario.

  3. L'associazione esistente tra lo spazio dei nomi Premium primario e quello secondario viene interrotta.

Dopo aver avviato il failover:

  1. È necessario poter eseguire di nuovo il failover nel caso in cui si verifichi un'altra interruzione. Configurare quindi un altro spazio dei nomi passivo e aggiornare l'associazione.

  2. Eseguire il pull dei messaggi dallo spazio dei nomi primario precedente quando è di nuovo disponibile. Successivamente, usare tale spazio dei nomi per la messaggistica regolare di fuori della configurazione del ripristino geografico oppure eliminare lo spazio dei nomi primario precedente.

Nota

È supportata solo la semantica di inoltro in caso di errore. In questo scenario, si esegue il failover e quindi si esegue di nuovo l'associazione con un nuovo spazio dei nomi. Il failback, ad esempio in un cluster SQL, non è supportato.

È possibile automatizzare il failover con sistemi di monitoraggio o con soluzioni di monitoraggio personalizzate. Tale automazione, tuttavia, richiede pianificazione e lavoro aggiuntivi che esulano dall'ambito di questo articolo.

Immagine che mostra come automatizzare il failover.

Gestione

Se si è commesso un errore, ad esempio, sono state abbinate le aree sbagliate durante l'installazione iniziale, è possibile interrompere l'associazione dei due spazi dei nomi in qualsiasi momento. Per usare gli spazi dei nomi associati come normali spazi dei nomi, eliminare l'alias.

Usare lo spazio dei nomi esistente come alias

Se si ha uno scenario in cui non è possibile modificare le connessioni di producer e consumer, è possibile riutilizzare il nome dello spazio dei nomi come nome alias. Vedere il codice di esempio su GitHub qui.

Esempi

Gli esempi su GitHub mostrano come configurare e avviare un failover. Questi esempi illustrano i concetti seguenti:

  • Esempio e impostazioni .NET necessarie in Microsoft Entra ID per l'uso di Azure Resource Manager con bus di servizio, per configurare e abilitare il ripristino di emergenza geografico.
  • Passaggi necessari per eseguire il codice di esempio.
  • Modalità di utilizzo di uno spazio dei nomi esistente come alias.
  • I passaggi per abilitare alternativamente il ripristino di emergenza geografico tramite PowerShell o l'interfaccia della riga di comando.
  • L'invio e la ricezione dallo spazio dei nomi primario o secondario corrente tramite l'alias.

Considerazioni

Tenere presente le considerazioni seguenti per questa versione:

  • Quando si pianifica il failover, è consigliabile considerare anche il fattore tempo. Ad esempio, se si perde la connettività per più di 15-20 minuti, è possibile decidere di avviare il failover.
  • Il fatto che non vengano replicati dati significa che le sessioni attive non vengono replicate. Inoltre, il rilevamento dei duplicati e i messaggi pianificati potrebbero non funzionare. Nuove sessioni, nuovi messaggi pianificati e nuovi duplicati funzionano.
  • È necessario provare a effettuare il failover di un'infrastruttura distribuita complessa almeno una volta.
  • La sincronizzazione delle entità può richiedere tempo, circa un minuto per 50-100 entità. Anche le sottoscrizioni e le regole contano come entità.

Zone di disponibilità

Lo SKU 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 per le zone di disponibilità per il bus di servizio di Azure 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 del livello Premium tramite altri meccanismi, ad esempio modelli ARM/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.

Endpoint privati

Questa sezione presenta altre considerazioni sull'uso del ripristino di emergenza geografico con spazi dei nomi che usano endpoint privati. Per informazioni sull'uso di endpoint privati con il bus di servizio in generale, vedere Integrare il bus di servizio di Azure con Collegamento privato di Azure.

Nuove associazioni

Se si tenta di creare un'associazione tra uno spazio dei nomi primario con un endpoint privato e uno spazio dei nomi secondario senza un endpoint privato, l'associazione ha esito negativo. L'associazione ha esito positivo solo se gli spazi dei nomi primari e secondari hanno endpoint privati. È consigliabile usare le stesse configurazioni per gli spazi dei nomi primario e secondario e per le reti virtuali in cui sono stati creati gli endpoint privati.

Nota

Quando si tenta di associare lo spazio dei nomi primario con un endpoint privato e lo spazio dei nomi secondario, il processo di convalida controlla solo se esiste un endpoint privato nello spazio dei nomi secondario. Non verifica se l'endpoint funziona o funziona dopo il failover. È responsabilità dell'utente assicurarsi che lo spazio dei nomi secondario con endpoint privato funzioni come previsto dopo il failover.

Per verificare che le configurazioni degli endpoint privati siano uguali, inviare una richiesta Get queues allo spazio dei nomi secondario dall'esterno della rete virtuale e verificare che si riceva un messaggio di errore dal servizio.

Associazioni esistenti

Se l'associazione tra lo spazio dei nomi primario e quello secondario esiste già, la creazione dell'endpoint privato nello spazio dei nomi primario ha esito negativo. Per risolvere il problema, creare prima un endpoint privato nello spazio dei nomi secondario e quindi crearne uno per lo spazio dei nomi primario.

Nota

Mentre l'accesso allo spazio dei nomi secondario è consentito in sola lettura, è possibile eseguire aggiornamenti nelle configurazioni degli endpoint privati.

Quando si crea una configurazione di ripristino di emergenza per l'applicazione e il bus di servizio, è necessario creare endpoint privati per entrambi gli spazi dei nomi, primario e secondario, del bus di servizio nelle reti virtuali che ospitano entrambe le istanze, primaria e secondaria, dell'applicazione.

Si supponga di avere due reti virtuali: VNET-1, VNET-2 e questi spazi dei nomi primari e secondari: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. È necessario eseguire la procedura seguente:

  • In ServiceBus-Namespace1-Primarycreare due endpoint privati che usano subnet da VNET-1 e VNET-2
  • In ServiceBus-Namespace2-Secondarycreare due endpoint privati che usano le stesse subnet da VNET-1 e VNET-2

Endpoint privati e reti virtuali

Il vantaggio di questo approccio è che il failover può verificarsi a livello di applicazione indipendentemente dallo spazio dei nomi del bus di servizio. Si considerino gli scenari seguenti:

Failover solo applicazione: in questo caso, l'applicazione non esiste in VNET-1 ma passa alla rete virtuale-2. Poiché entrambi gli endpoint privati sono configurati sia in VNET-1 che in VNET-2 per gli spazi dei nomi primario e secondario, l'applicazione funziona solo.

bus di servizio failover solo dello spazio dei nomi: in questo caso, poiché entrambi gli endpoint privati sono configurati in entrambe le reti virtuali sia per gli spazi dei nomi primari che secondari, l'applicazione funziona solo.

Nota

Per materiale sussidiario sul ripristino di emergenza geografico di una rete virtuale, vedere Rete virtuale - Continuità aziendale.

Controllo degli accessi in base al ruolo

Le assegnazioni di controllo degli accessi in base al ruolo (RBAC) di Microsoft Entra per bus di servizio 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.

Passaggi successivi

Per altre informazioni sulla messaggistica del bus di servizio, vedere gli articoli seguenti: