Implementação de failover do lado do cliente na Grade de Eventos do Azure

Artigo
11/15/2023

A recuperação de desastres normalmente envolve a criação de um recurso de backup para evitar interrupções quando uma região não se torna íntegra. Durante esse processo, uma região primária e secundária dos recursos da Grade de Eventos do Azure será necessária em sua carga de trabalho.

Há diferentes maneiras de se recuperar de uma perda grave da funcionalidade do aplicativo. Neste artigo, vamos descrever a lista de verificação que você precisará seguir para preparar seu cliente para se recuperar de uma falha devido a um recurso ou região não íntegros.

A Grade de Eventos suporta recuperação de desastres geográficos (GeoDR) manual e automática no lado do servidor. Você ainda pode implementar a lógica de recuperação de desastres do lado do cliente se quiser um maior controle sobre o processo de failover. Para obter detalhes sobre GeoDR automático, consulte Recuperação de desastres geográficos do lado do servidor na Grade de Eventos do Azure.

A tabela a seguir ilustra o failover do lado do cliente e o suporte à recuperação de desastres geográficos na Grade de Eventos.

Recurso Grade de Eventos	Suporte a failover do lado do cliente	Suporte de recuperação de desastres geográficos (GeoDR)
Tópicos Personalizados	Suportado	Cross-Geo / Regional
Tópicos do sistema	Não suportado	Ativado automaticamente
Domínios	Suportado	Cross-Geo / Regional
Namespaces de parceiros	Suportado	Não suportado
Espaços de Nomes	Suportado	Não suportado

Considerações sobre failover do lado do cliente

Crie e configure seu recurso principal de Grade de Eventos.
Crie e configure seu recurso secundário de Grade de Eventos.
Tenha em mente que ambos os recursos devem ter a mesma configuração, subrecursos e recursos habilitados.
Os recursos da Grade de Eventos devem ser hospedados em regiões diferentes.
Se o recurso Grade de Eventos tiver recursos dependentes, como um recurso de armazenamento para letras mortas, você deverá usar a mesma região usada no recurso secundário de Grade de Eventos.
Certifique-se de que seus endpoints sejam testados regularmente para fornecer garantia de que os recursos do seu plano de recuperação estão no lugar e funcionando corretamente.

Exemplo de implementação básica de failover do lado do cliente para tópicos personalizados

O código de exemplo a seguir é um editor .NET simples que tenta publicar em seu tópico principal primeiro. Se não for bem-sucedido, falhará no tópico secundário. Em ambos os casos, ele também verifica a api de integridade do outro tópico fazendo um GET on https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Um tópico saudável deve sempre responder com 200 OK quando um GET é feito no ponto de extremidade /api/health .

Nota

O código de exemplo a seguir é apenas para fins de demonstração e não se destina ao uso em produção.

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

Experimente

Agora que você tem todos os seus componentes no lugar, você pode testar sua implementação de failover.

Para certificar-se de que o failover está funcionando, você pode alterar alguns caracteres na chave de tópico principal para torná-lo inválido. Tente executar o editor novamente. Com os seguintes exemplos de eventos, os eventos continuarão fluindo pela Grade de Eventos, no entanto, quando você olhar para o seu cliente, verá que eles estão sendo publicados por meio do tópico secundário.

Possíveis extensões

Há muitas maneiras de estender essa amostra com base em suas necessidades. Para cenários de alto volume, convém verificar regularmente a api de integridade do tópico de forma independente. Dessa forma, se um tópico cair, você não precisa verificá-lo com todas as publicações. Depois de saber que um tópico não está íntegro, você pode usar como padrão a publicação no tópico secundário.

Da mesma forma, você pode querer implementar a lógica de failback com base em suas necessidades específicas. Se a publicação no data center mais próximo for fundamental para reduzir a latência, você poderá investigar periodicamente a api de integridade de um tópico que falhou. Quando estiver saudável novamente, é seguro fazer failback para o data center mais próximo.

Próximos passos

Saiba como receber eventos em um ponto de extremidade http
Descubra como encaminhar eventos para conexões híbridas
Saiba mais sobre a recuperação de desastres usando o DNS do Azure e o Gerenciador de Tráfego

Partilhar via