Создание собственного плана аварийного восстановления для разделов и доменов Сетки событий Azure

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

Создание скриптов для автоматизации

Поддерживайте автоматизацию конвейеров развертывания, ручные процессы могут привести к задержкам при отработке отказа. Обеспечьте резервное копирование всех развертываний Azure в скриптах или шаблонах, чтобы при необходимости их можно было легко реплицировать в одном или нескольких регионах. Не пытайтесь изобретать колесо, используйте то, что уже проверено и работает, существует множество средств автоматизации, способных решить проблемы, связанные с автоматизацией облачного развертывания, такие как Azure DevOps или GitHub Actions, существуют дополнительные средства, которые помогут вам на этапе развертывания, использовать тот, с которым вам удобнее работать и используйте это руководство только в качестве контрольного списка.

Определение регионов в плане

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

Выбор маршрутизатора между регионами

После определения регионов необходимо определить маршрутизатор между регионами, который поможет вам распределить трафик между регионами, если потребуется. Диспетчер трафика — это подсистема балансировки нагрузки трафика на основе DNS, которая позволяет распределять трафик между общедоступными приложениями в глобальных регионах Azure. Диспетчер трафика также предоставляет общедоступные конечные точки с высокой доступностью и быстрой скоростью реагирования, если вам нужны дополнительные функции, такие как перенаправление между регионами и доступность, обратный прокси-сервер, кэш статического содержимого, политики WAF, возможно, следует обратить внимание на Front Door.

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

Теперь пришло время создать ресурсы раздела Сетка событий Azure, используйте следующий пример Bicep, чтобы создать раздел с подпиской на событие веб-перехватчика.

Повторите процесс развертывания раздела для выбранного дополнительного региона.

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

Сохраните URL-адреса конечных точек раздела для каждого созданного ресурса, вы увидите примерно следующее:

Регион 1: https://my-primary-topic.my-region-1.eventgrid.azure.net/api/events

Регион 2: https://my-secondary-topic.my-secondary-1.eventgrid.azure.net/api/events

Создание Диспетчера трафика для конечных точек Сетки событий Azure

Ранее созданные конечные точки ресурсов Сетки событий Azure будут использоваться при создании и настройке профиля Диспетчера трафика в Azure. Дополнительные сведения см. в следующем кратком руководстве. Создание профиля Диспетчера трафика с помощью портала Azure.

Диспетчер трафика — это глобальный ресурс, предоставляющий уникальное DNS-имя, например: https://myeventgridtopic.trafficmanager.net. После настройки обеих конечных точек раздела Сетка событий Azure в Диспетчер трафика, когда основной регион станет недоступным, трафик будет автоматически перенаправляться во второй регион.

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

Интеграция сценариев развертывания в процесс CI/CD

Теперь, когда конфигурация работает должным образом и события доставляются в определенные регионы, вам потребуется интегрировать шаблон со средством автоматизации. Дополнительные сведения см. в Кратком руководстве. Интеграция Bicep с Azure Pipelines или Кратком руководстве. Развертывание файлов Bicep с помощью GitHub Actions.

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

Дальнейшие действия