Поделиться через

Реализация отработки отказа на стороне клиента в Сетка событий Azure

  • Статья

Аварийное восстановление обычно включает создание ресурса резервного копирования, чтобы предотвратить прерывания, когда регион становится неработоспособным. Во время этого процесса в рабочей нагрузке потребуется основной и дополнительный регион Сетка событий Azure ресурсов.

Существует несколько способов восстановления после серьезной потери функциональных возможностей приложения. В этой статье мы рассмотрим список проверка, который необходимо выполнить, чтобы подготовить клиента к восстановлению после сбоя из-за неработоспособного ресурса или региона.

Сетка событий поддерживает ручное и автоматическое геоизбыточное аварийное восстановление (GeoDR) на стороне сервера. Если вам требуется больший контроль над процессом отработки отказа, можно реализовать логику аварийного восстановления на стороне клиента. Дополнительные сведения об автоматическом геоизбыточном аварийном восстановлении (GeoDR) см. в разделе Аварийное восстановление с георепликацией на стороне сервера в Сетке событий Azure.

В следующей таблице показана поддержка отработки отказа на стороне клиента и геоизбыточного аварийного восстановления в сетке событий.

Ресурс "Сетка событий" Поддержка отработки отказа на стороне клиента Поддержка геоизбытого аварийного восстановления (GeoDR)
Пользовательские разделы Поддерживается Межрегиональная или региональная
Системные темы Не поддерживается Включен автоматически
Домены Поддерживается Межрегиональная или региональная
Пространства имен партнеров Поддерживается Не поддерживается
Пространства имен Поддерживается Не поддерживается

Рекомендации по отработки отказа на стороне клиента

  1. Создайте и настройте основной ресурс Сетки событий.
  2. Создайте и настройте дополнительный ресурс Сетки событий.
  3. Помните, что оба ресурса должны иметь одинаковую конфигурацию, подресурсы и возможности.
  4. Ресурсы сетки событий должны размещаться в разных регионах.
  5. Если ресурс сетки событий имеет зависимые ресурсы, такие как ресурс хранилища для недоставки, следует использовать тот же регион, используемый в дополнительном ресурсе Сетки событий.
  6. Убедитесь, что конечные точки регулярно тестируются, чтобы обеспечить правильность работы ресурсов плана восстановления.

Базовый пример реализации отработки отказа на стороне клиента для пользовательских разделов

Следующий пример кода — это простой издатель .NET, который пытается сначала опубликовать в основном разделе. Если он не удается, он выполняет отработку отказа вторичного раздела. В любом случае также запускается проверка работоспособности API другого раздела с помощью запроса GET для https://<topic-name>.<topic-region>.eventgrid.azure.net/api/health. Если отправить запрос GET к конечной точке /api/health, работоспособный раздел всегда возвращает ответ с кодом 200 ОК.

Примечание.

Приведенный ниже пример кода служит только для демонстрации и не предназначен для использования в рабочей среде.

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

Попробуйте

Теперь, когда у вас есть все необходимые компоненты, вы можете протестировать реализацию отработки отказа.

Чтобы убедиться, что отработка отказа работает, можно изменить несколько символов в ключе первичного раздела, чтобы сделать его недействительным. Попробуйте еще раз запустить издатель. В следующих примерах событий будут продолжаться потоки через Сетку событий, однако при просмотре клиента вы увидите, что они публикуются через дополнительный раздел.

Возможность расширения

В зависимости от ваших потребностей существует множество вариантов того, как дополнить этот пример. Для масштабных сценариев вам может понадобиться отдельно регулярно проверять API работоспособности раздела. Таким образом, если произошел сбой в работе раздела, вам не нужно проверять его при каждой публикации. Как только вы узнали, что раздел неработоспособен, вы можете по умолчанию выполнять публикацию в дополнительный раздел.

Точно так же в зависимости от своих потребностей вы можете реализовать логику восстановления после отказа. Если вам крайне важно выполнить публикацию в ближайший центр обработки данных, чтобы сократить задержку, вы можете периодически проверять API работоспособности раздела, для которого была выполнена отработка отказа. После того как он будет работоспособным снова, он безопасно вернуться к более близкому центру обработки данных.

Следующие шаги