Partager via

Implémentation du basculement côté client dans Azure Event Grid

  • Article

La récupération d’urgence implique généralement la création d’une ressource de sauvegarde pour éviter les interruptions lorsqu’une région devient défectueuse. Au cours de ce processus, une région primaire et secondaire de Azure Event Grid ressources sera nécessaire dans votre charge de travail.

Il existe différentes façons de récupérer d’une perte grave de fonctionnalités d’application. Dans cet article, nous allons décrire la liste de contrôle que vous devez suivre pour préparer votre client à récupérer après une défaillance due à une ressource ou une région non saine.

Désormais, Event Grid prend en charge la Géoreprise d’activité après sinistre (GeoDR) automatique côté serveur. Vous pouvez toujours implémenter une logique de récupération d’urgence côté client si vous souhaitez plus de contrôle sur le processus de basculement. Pour plus d’informations sur le processus GeoDR automatique, consultez Géoreprise d’activité après sinistre côté serveur dans Azure Event Grid.

Le tableau suivant illustre la prise en charge du basculement côté client et de la Géoreprise d’activité après sinistre dans Event Grid.

Ressource Event Grid Prise en charge du basculement côté client Prise en charge de la Géoreprise d’activité après sinistre (GeoDR)
Rubriques personnalisées Pris en charge Intergéographique / régionale
Rubriques sur le système Non prise en charge Activé automatiquement
Domaines Pris en charge Intergéographique / régionale
Espaces de noms de partenaires Pris en charge Non prise en charge
Espaces de noms Pris en charge Non prise en charge

Considérations relatives au basculement côté client

  1. Créez et configurez votre ressource Event Grid principale.
  2. Créez et configurez votre ressource Event Grid secondaire.
  3. Gardez à l’esprit que les deux ressources doivent avoir la même configuration, les mêmes sous-ressources et les mêmes fonctionnalités activées.
  4. Les ressources Event Grid doivent être hébergées dans différentes régions.
  5. Si la ressource Event Grid a des ressources dépendantes, comme une ressource de stockage pour le dead-lettering, vous devez utiliser la même région que celle utilisée pour la ressource Event Grid secondaire.
  6. Assurez-vous que vos points de terminaison sont régulièrement testés pour garantir que vos ressources de plan de récupération sont en place et fonctionnent correctement.

Exemple d’implémentation de basculement de base côté client pour les rubriques personnalisées

L’exemple de code suivant est un serveur de publication .NET simple qui tente de publier en premier dans votre rubrique principale. S’il n’y parvient pas, il bascule vers la rubrique secondaire. Dans les deux cas, il vérifie également l’API d’intégrité de l’autre rubrique en exécutant une opération GET sur https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Une rubrique saine doit toujours envoyer la réponse 200 OK quand une opération GET est exécutée sur le point de terminaison /api/health.

Notes

L’exemple de code suivant est uniquement fourni à des fins de démonstration et n’est pas destiné à une utilisation en production.

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

Faites un essai

Maintenant que tous vos composants sont en place, vous pouvez tester votre implémentation de basculement.

Pour vérifier que votre basculement fonctionne, vous pouvez modifier quelques caractères de la clé de rubrique principale pour la rendre non valide. Réessayez d’exécuter l’éditeur d’événements. Les exemples d’événements suivants continuent de transiter par Event Grid. Toutefois, lorsque vous examinez votre client, vous verrez qu’ils sont désormais publiés via la rubrique secondaire.

Extensions possibles

Il existe de nombreuses façons d’étendre cet exemple selon vos besoins. Pour les scénarios à volumes élevés, il est souhaitable de vérifier régulièrement l’API d’intégrité de la rubrique. De cette façon, si une rubrique devient indisponible, vous n’avez pas besoin de la vérifier à chaque publication. Une fois que vous savez qu’une rubrique n’est pas saine, vous pouvez choisir de publier par défaut dans la rubrique secondaire.

De même, vous pouvez implémenter la logique de restauration automatique en fonction de vos besoins. Si le fait de publier dans le centre de données le plus proche est indispensable pour réduire la latence, vous pouvez vérifier régulièrement l’API d’intégrité d’une rubrique ayant subi un basculement. Une fois qu’elle est saine, vous pouvez effectuer sans risque une restauration automatique vers le centre de données le plus proche.

Étapes suivantes