Clientseitige Failoverimplementierung in Azure Event Grid

  • Artikel

Bei der Notfallwiederherstellung wird in der Regel eine Sicherungsressource erstellt, um Unterbrechungen zu verhindern, wenn eine Region fehlerhaft wird. Während dieses Prozesses wird eine primäre und sekundäre Region mit Azure Event Grid-Ressourcen in Ihrer Workload benötigt.

Es gibt verschiedene Möglichkeiten, die Wiederherstellung nach einem schwerwiegenden Verlust der Anwendungsfunktionalität durchzuführen. In diesem Artikel wird die Checkliste beschrieben, die Sie befolgen müssen, um Ihren Client auf die Wiederherstellung nach einem Fehler aufgrund einer fehlerhaften Ressource oder Region vorzubereiten.

Event Grid unterstützt manuelle und automatische Notfallwiederherstellung mit Georeplikation (GeoDR) auf der Serverseite. Sie können weiterhin die clientseitige Notfallwiederherstellungslogik implementieren, wenn Sie den Failoverprozess präziser steuern möchten. Ausführliche Informationen zur automatischen Notfallwiederherstellung mit Georeplikation finden Sie unter Server-side geo disaster recovery in Azure Event Grid (Serverseitige Notfallwiederherstellung mit Georeplikation in Azure Event Grid).

In der folgenden Tabelle wird die Unterstützung für clientseitigen Failover und Notfallwiederherstellung mit Georeplikation in Event Grid veranschaulicht.

Event Grid-Ressource Clientseitige Failoverunterstützung Unterstützung für Notfallwiederherstellung mit Georeplikation (GeoDR)
Benutzerdefinierte Themen Unterstützt Geoübergreifend/regional
Systemthemen Nicht unterstützt Automatisch aktiviert
Domänen Unterstützt Geoübergreifend/regional
Partnernamespaces Unterstützt Nicht unterstützt
Namespaces Unterstützt Nicht unterstützt

Überlegungen zum clientseitigen Failover

  1. Erstellen und konfigurieren Sie Ihre primäre Event Grid-Ressource.
  2. Erstellen und konfigurieren Sie Ihre sekundäre Event Grid-Ressource.
  3. Beachten Sie, dass für beide Ressourcen die gleiche Konfiguration, die gleichen Unterressourcen und die gleichen Funktionen aktiviert sein müssen.
  4. Event Grid-Ressourcen müssen in verschiedenen Regionen gehostet werden.
  5. Wenn die Event Grid-Ressource abhängige Ressourcen wie eine Speicherressource für unzustellbare Nachrichten enthält, sollten Sie dieselbe Region verwenden, die in der sekundären Event Grid-Ressource verwendet wird.
  6. Stellen Sie sicher, dass Ihre Endpunkte regelmäßig getestet werden, um sicherzustellen, dass Ihre Wiederherstellungsplanressourcen vorhanden sind und ordnungsgemäß funktionieren.

Beispiel für die Implementierung eines grundlegenden clientseitigen Failovers für benutzerdefinierte Themen

Der folgende Beispielcode ist ein einfacher .NET-Herausgeber, der zuerst versucht, die Veröffentlichung in Ihrem primären Thema vorzunehmen. Wenn dies nicht möglich ist, erfolgt dann ein Failover zum sekundären Thema. In beiden Fällen wird außerdem mit einem GET-Vorgang für https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health die Integritäts-API des anderen Themas überprüft. Ein fehlerfreies Thema sollte immer mit 200 OK antworten, wenn ein GET-Vorgang für den Endpunkt /api/Health ausgeführt wird.

Hinweis

Der folgende Beispielcode dient nur zu Demonstrationszwecken und ist nicht für die Verwendung in der Produktion vorgesehen.

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

Ausprobieren

Sie haben nun alle Komponenten eingerichtet und können Ihre Failoverimplementierung testen.

Um sicherzustellen, dass das Failover funktioniert, können Sie einige Zeichen im Schlüssel Ihres primären Themas ändern, sodass er nicht mehr gültig ist. Versuchen Sie dann erneut, den Herausgeber auszuführen. Im folgenden Beispiel werden Ereignisse weiterhin durch Event Grid fließen. Wenn Sie sich aber Ihren Client ansehen, werden Sie erkennen, dass sie jetzt über das sekundäre Thema veröffentlicht werden.

Mögliche Erweiterungen

Es gibt viele Möglichkeiten, dieses Beispiel entsprechend Ihren Anforderungen zu erweitern. Bei Szenarien mit hohem Volumen kann es sinnvoll sein, die Integritäts-API in regelmäßigen Abständen unabhängig zu überprüfen. Auf diese Weise müssten Sie sie beim Ausfall eines Themas nicht bei jeder einzelnen Veröffentlichung überprüfen. Sobald Sie wissen, dass ein Thema nicht fehlerfrei ist, können Sie Ereignisse standardmäßig über das sekundäre Thema veröffentlichen.

Ebenso können Sie basierend auf Ihren spezifischen Anforderungen eine Failbacklogik implementieren. Falls die Veröffentlichung im nächstgelegenen Rechenzentrum zum Verringern der Wartezeit für Sie entscheidend ist, können Sie die Integritäts-API eines Themas, für das ein Failover ausgeführt wurde, in regelmäßigen Abständen testen. Sobald es wieder fehlerfrei ist, kann das Failback zum nächstgelegenen Rechenzentrum sicher durchgeführt werden.

Nächste Schritte