Implementazione del failover lato client in Griglia di eventi di Azure

  • Articolo

Il ripristino di emergenza comporta in genere la creazione di una risorsa di backup per evitare interruzioni quando un'area diventa non integra. Durante questo processo sarà necessaria un'area primaria e secondaria di Griglia di eventi di Azure risorse nel carico di lavoro.

Esistono diversi modi per eseguire il ripristino da una grave perdita di funzionalità dell'applicazione. In questo articolo verrà descritto l'elenco di controllo da seguire per preparare il client per il ripristino da un errore dovuto a una risorsa o a un'area non integra.

Griglia di eventi supporta il ripristino di emergenza geografico manuale e automatico (GeoDR) sul lato server. Per un maggiore controllo sul processo di failover è ancora possibile implementare la logica di ripristino di emergenza sul lato client. Per informazioni dettagliate sul ripristino di emergenza geografico automatico, vedere Ripristino di emergenza geografico sul lato server in Griglia di eventi di Azure.

La tabella seguente illustra il supporto per il failover lato client e il ripristino di emergenza geografico in Griglia di eventi.

Risorsa griglia di eventi Supporto del failover lato client Supporto per il ripristino di emergenza geografico (GeoDR)
Argomenti personalizzati Supportata Cross-Geo/Regional
Argomenti di sistema Non supportato Abilitato automaticamente
Domini Supportata Cross-Geo/Regional
Spazi dei nomi dei partner Supportato Non supportato
Namespaces (Spazi dei nomi) Supportato Non supportato

Considerazioni sul failover sul lato client

  1. Creare e configurare la risorsa di Griglia di eventi primaria .
  2. Creare e configurare la risorsa di Griglia di eventi secondaria .
  3. Tenere presente che entrambe le risorse devono avere la stessa configurazione, sottorisorse e funzionalità abilitate.
  4. Le risorse di Griglia di eventi devono essere ospitate in aree diverse.
  5. Se la risorsa griglia di eventi ha risorse dipendenti come una risorsa di archiviazione per i messaggi non recapitabili, è consigliabile usare la stessa area usata nella risorsa griglia di eventi secondaria.
  6. Assicurarsi che gli endpoint siano regolarmente test per garantire che le risorse del piano di ripristino siano presenti e funzionino correttamente.

Esempio di implementazione di failover lato client di base per argomenti personalizzati

Il codice di esempio seguente è un semplice server di pubblicazione .NET che tenta prima di tutto di pubblicare nell'argomento primario. In caso contrario, viene eseguito il failover dell'argomento secondario. In entrambi i casi, verifica anche l'API Integrità dell'altro argomento eseguendo un'operazione GET su https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Un argomento integro deve sempre rispondere con 200 OK quando viene effettuata un'operazione GET sull'endpoint /api/integrità.

Nota

Il codice di esempio seguente è solo a scopo dimostrativo e non è destinato all'uso in produzione.

using System;
using System.Net.Http;
using System.Collections.Generic;
using System.Threading.Tasks;
using Azure;
using Azure.Messaging.EventGrid;

namespace EventGridFailoverPublisher
{
    // This captures the "Data" portion of an EventGridEvent on a custom topic
    class FailoverEventData
    {
        public string TestStatus { get; set; }
    }

    class Program
    {
        static async Task Main(string[] args)
        {
            // TODO: Enter the endpoint each topic. You can find this topic endpoint value
            // in the "Overview" section in the "Event Grid topics" page in Azure Portal..
            string primaryTopic = "https://<primary-topic-name>.<primary-topic-region>.eventgrid.azure.net/api/events";
            string secondaryTopic = "https://<secondary-topic-name>.<secondary-topic-region>.eventgrid.azure.net/api/events";

            // TODO: Enter topic key for each topic. You can find this in the "Access Keys" section in the
            // "Event Grid topics" page in Azure Portal.
            string primaryTopicKey = "<your-primary-topic-key>";
            string secondaryTopicKey = "<your-secondary-topic-key>";

            Uri primaryTopicUri = new Uri(primaryTopic);
            Uri secondaryTopicUri = new Uri(secondaryTopic);

            Uri primaryTopicHealthProbe = new Uri($"https://{primaryTopicUri.Host}/api/health");
            Uri secondaryTopicHealthProbe = new Uri($"https://{secondaryTopicUri.Host}/api/health");

            var httpClient = new HttpClient();

            try
            {
                var client = new EventGridPublisherClient(primaryTopicUri, new AzureKeyCredential(primaryTopicKey));

                await client.SendEventsAsync(GetEventsList());
                Console.Write("Published events to primary Event Grid topic.");

                HttpResponseMessage health = httpClient.GetAsync(secondaryTopicHealthProbe).Result;
                Console.Write("\n\nSecondary Topic health " + health);
            }
            catch (RequestFailedException ex)
            {
                var client = new EventGridPublisherClient(secondaryTopicUri, new AzureKeyCredential(secondaryTopicKey));

                await client.SendEventsAsync(GetEventsList());
                Console.Write("Published events to secondary Event Grid topic. Reason for primary topic failure:\n\n" + ex);

                HttpResponseMessage health = await httpClient.GetAsync(primaryTopicHealthProbe);
                Console.WriteLine($"Primary Topic health {health}");
            }

            Console.ReadLine();
        }

        static IList<EventGridEvent> GetEventsList()
        {
            List<EventGridEvent> eventsList = new List<EventGridEvent>();

            for (int i = 0; i < 5; i++)
            {
                eventsList.Add(new EventGridEvent(
                    subject: "test" + i,
                    eventType: "Contoso.Failover.Test",
                    dataVersion: "2.0",
                    data: new FailoverEventData
                    {
                        TestStatus = "success"
                    }));
            }

            return eventsList;
        }
    }
}

Provala

Dopo aver creato tutti i componenti, è possibile testare l'implementazione di failover.

Per assicurarsi che il failover funzioni, è possibile modificare alcuni caratteri nella chiave dell'argomento primario per renderlo non più valido. Provare a eseguire di nuovo il server di pubblicazione. Con gli eventi di esempio seguenti continuerà a passare attraverso Griglia di eventi, ma quando si esamina il client, si noterà che ora vengono pubblicati tramite l'argomento secondario.

Estensioni possibili

Esistono molti modi per estendere questo esempio in base alle esigenze. Per scenari con volumi elevati, è consigliabile controllare regolarmente l'API integrità dell'argomento in modo indipendente. In questo modo, se un argomento smette di funzionare, non sarà necessario controllarlo a ogni singola pubblicazione. Dopo aver stabilito che un argomento non è integro, si può configurare la pubblicazione dell'argomento secondario per impostazione predefinita.

Analogamente, è possibile implementare la logica di failback in base alle specifiche esigenze. Se la pubblicazione nel data center più vicino è fondamentale per ridurre la latenza, si può verificare periodicamente l'API integrità di un argomento per cui si è verificato il failover. Una volta che è di nuovo integro, è possibile eseguire il failback al data center più vicino.

Passaggi successivi