Clientseitige Failoverimplementierung in Azure Event Grid

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 beschreiben wir die Checkliste, die Sie befolgen müssen, um Ihre Kunden darauf vorzubereiten, sich von einem Ausfall aufgrund einer nicht funktionsfähigen Ressource oder Region zu erholen.

Event Grid unterstützt manuelle und automatische Geo-Notfallwiederherstellung (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.

Überlegungen zum clientseitigen Failover

1. Erstellen und konfigurieren Sie Ihre primäre Event Grid-Ressource.
2. Erstellen und konfigurieren Sie Ihre sekundäre Ereignisrasterressource.
3. Beachten Sie, dass beide Ressourcen die gleiche Konfiguration, Unterressourcen und Funktionen aktiviert haben müssen.
4. Ereignisrasterressourcen müssen in verschiedenen Regionen gehostet werden.
5. Wenn die Event Grid-Ressource abhängige Ressourcen wie eine Speicherressource für das Dead-Lettering aufweist, 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 die Ressourcen Ihres Wiederherstellungsplans bereitgestellt sind und ordnungsgemäß funktionieren.

Grundlegendes clientseitiges Failoverimplementierungsbeispiel 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 es nicht erfolgreich ist, schlägt es beim sekundären Thema fehl. 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.

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

Nachdem Sie nun alle Komponenten eingerichtet haben, können Sie 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 basierend auf 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 Failbacklogik basierend auf Ihren spezifischen Anforderungen 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

• Erfahren Sie, wie Sie Ereignisse an einem HTTP-Endpunkt empfangen.
• Erfahren Sie, wie Ereignisse an Hybridverbindungen weitergeleitet werden.
• Informationen zur Notfallwiederherstellung mit Azure DNS und Traffic Manager