Implementación de conmutación por error del lado cliente en Azure Event Grid

Artículo
11/15/2023

La recuperación ante desastres suele implicar la creación de un recurso de copia de seguridad para evitar interrupciones cuando una región deja de funcionar correctamente. Durante este proceso, se necesitarán una región principal y secundaria de recursos de Azure Event Grid en la carga de trabajo.

Hay diferentes maneras de recuperarse de una pérdida grave de la funcionalidad de la aplicación. En este artículo se describirá la lista de comprobación que deberá seguir para preparar al cliente para recuperarse de un error debido a un recurso o región que no funcionan correctamente.

Event Grid admite la recuperación ante desastres geográfica manual y automática (GeoDR) en el lado servidor. Aún puede implementar la lógica de recuperación ante desastres en el lado del cliente si desea un mayor control sobre el proceso de conmutación por error. Para obtener más información acerca de GeoDR automática, consulte Recuperación de desastres geográfica del lado servidor en Azure Event Grid.

En la tabla siguiente se muestra la compatibilidad con la conmutación por error del lado cliente y la recuperación ante desastres geográfica en Event Grid.

Recurso de Event Grid	Compatibilidad con la conmutación por error del lado cliente	Compatibilidad con la recuperación ante desastres geográfica (GeoDR)
Temas personalizados	Compatible	Entre regiones/Regional
Temas del sistema	No compatible	Habilitada automáticamente
Dominios	Compatible	Entre regiones/Regional
Espacios de nombres de los asociados	Compatible	No compatible
Espacios de nombres	Compatible	No compatible

Consideraciones de la conmutación por error del lado cliente

Cree y configure el recurso principal de Event Grid.
Cree y configure el recurso secundario de Event Grid.
Tenga en cuenta que ambos recursos deben tener habilitada la misma configuración, subrecursos y funcionalidades.
Los recursos de Event Grid deben hospedarse en regiones diferentes.
Si el recurso de Event Grid tiene recursos dependientes, como un recurso de almacenamiento para mensajes fallidos, debe usar la misma región que se usa en el recurso secundario de Event Grid.
Asegúrese de que los puntos de conexión se prueban periódicamente para garantizar que los recursos del plan de recuperación están listos y funcionan correctamente.

Ejemplo básico de implementación de conmutación por error del lado cliente para temas personalizados

El siguiente código de ejemplo es un publicador .NET sencillo que intenta publicar primero en el tema principal. Si no tiene éxito, conmuta por error al tema secundario. En cualquier caso, también comprueba la API de mantenimiento del otro tema mediante una operación GET en https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Un tema correcto siempre debe responder con 200 Correcto cuando se realiza una operación GET en el punto de conexión /api/health.

Nota

El siguiente código de ejemplo solo es una demostración, no está destinado para uso en producción.

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

Prueba

Ahora que tiene todos los componentes en su sitio, puede probar la implementación de la conmutación por error.

Para asegurarse de que la conmutación por error funciona, puede cambiar algunos caracteres de la clave del tema principal para que ya no sea válido. Intente ejecutar de nuevo el publicador. Con el siguiente ejemplo, los eventos seguirán fluyendo a través de Event Grid; sin embargo, al examinar el cliente, verá que ahora se publican a través del tema secundario.

Posibles extensiones

Hay muchas maneras de ampliar este ejemplo según sus necesidades. En escenarios de gran volumen, puede que quiera comprobar periódicamente la API de mantenimiento del tema de forma independiente. Así, si un tema deja de funcionar, no necesitará comprobarlo con cada publicación. Una vez que sepa que un tema ya no tiene un estado correcto, puede adoptar como valor predeterminado la publicación en el tema secundario.

Igualmente, puede que quiera implementar la lógica de conmutación por recuperación según sus necesidades específicas. Si publicar en el centro de datos más cercano es fundamental para reducir la latencia, puede sondear periódicamente la API de mantenimiento de un tema que se haya conmutado por error. Cuando su estado vuelva a ser correcto, es seguro conmutar por recuperación al centro de datos más cercano.

Pasos siguientes

Más información sobre cómo recibir eventos en un punto de conexión HTTP.
Descubra cómo enrutar eventos a Conexiones híbridas.
Aprenda sobre la recuperación ante desastres mediante Azure DNS y Traffic Manager.

Compartir a través de