Implementering av redundans på klientsidan i Azure Event Grid

Artikel
11/15/2023

Haveriberedskap innebär vanligtvis att du skapar en säkerhetskopieringsresurs för att förhindra avbrott när en region blir skadad. Under den här processen behövs en primär och sekundär region med Azure Event Grid-resurser i din arbetsbelastning.

Det finns olika sätt att återställa från en allvarlig förlust av programfunktioner. I den här artikeln ska vi beskriva checklistan som du måste följa för att förbereda klienten för att återställa från ett fel på grund av en resurs eller region som inte är felfri.

Event Grid stöder manuell och automatisk geo-haveriberedskap (GeoDR) på serversidan. Du kan fortfarande implementera haveriberedskapslogik på klientsidan om du vill ha en större kontroll över redundansväxlingsprocessen. Mer information om automatisk GeoDR finns i Geo-haveriberedskap på serversidan i Azure Event Grid.

I följande tabell visas stöd för redundans på klientsidan och geo-haveriberedskap i Event Grid.

Event Grid-resurs	Stöd för redundans på klientsidan	Geo-haveriberedskapsstöd (GeoDR)
Anpassade ämnen	Stöds	Cross-Geo/Regional
Systemämnen	Stöds inte	Aktiverad automatiskt
Domäner	Stöds	Cross-Geo/Regional
Partnernamnområden	Stöds	Stöds inte
Namnrymder	Stöds	Stöds inte

Överväganden vid redundans på klientsidan

Skapa och konfigurera din primära Event Grid-resurs.
Skapa och konfigurera din sekundära Event Grid-resurs.
Tänk på att båda resurserna måste ha samma konfiguration, underresurser och funktioner aktiverade.
Event Grid-resurser måste finnas i olika regioner.
Om Event Grid-resursen har beroende resurser som en lagringsresurs för obeställbara bokstäver bör du använda samma region som används i den sekundära Event Grid-resursen.
Se till att slutpunkterna regelbundet testas för att garantera att återställningsplanens resurser är på plats och fungerar korrekt.

Exempel på grundläggande implementering av redundans på klientsidan för anpassade ämnen

Följande exempelkod är en enkel .NET-utgivare som försöker publicera till ditt primära ämne först. Om det inte lyckas redundansväxlar det det sekundära ämnet. I båda fallen kontrollerar den även hälso-API för det andra ämnet genom att göra en GET på https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Ett felfritt ämne bör alltid svara med 200 OK när en GET görs på slutpunkten /api/health.

Kommentar

Följande exempelkod är endast i demonstrationssyfte och är inte avsedd för produktionsanvändning.

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;
        }
    }
}

Prova nu

Nu när du har alla komponenter på plats kan du testa implementeringen av redundans.

För att säkerställa att redundansväxlingen fungerar kan du ändra några tecken i den primära ämnesnyckeln så att den inte längre är giltig. Prova att köra utgivaren igen. Med följande exempelhändelser fortsätter att flöda genom Event Grid, men när du tittar på klienten ser du att de nu publiceras via det sekundära ämnet.

Möjliga tillägg

Det finns många sätt att utöka det här exemplet utifrån dina behov. För scenarier med stora volymer kan det vara bra att regelbundet kontrollera ämnet hälso-API oberoende. Om ett ämne slutar fungera behöver du då inte kontrollera det vid varje publicering. När du vet att ett ämne inte är felfritt kan du som standard publicera till det sekundära ämnet.

På samma sätt kan du behöva implementera felåterställningslogik baserat på dina specifika behov. Om publicering till det närmaste datacentret är viktigt för att du ska kunna minska svarstiden kan du regelbundet avsöka hälso-API för ett ämne som har redundansväxlat. När det är felfritt igen är det säkert att växla tillbaka till det närmare datacentret.

Nästa steg

Lär dig hur du tar emot händelser på en http-slutpunkt
Upptäck hur du dirigerar händelser till Hybridanslutningar
Lär dig om haveriberedskap med hjälp av Azure DNS och Traffic Manager

Dela via