Блог

Мы завершаем разработку плана BCP / DR для аккредитации и хотим записать шаги для аварийного восстановления шлюза приложений. Мы хотим предоставить доказательства того, что шаги, которые мы подробно описали в плане, воспроизводимы и выполнимы во время аварийного восстановления. Сначала мы хотим попробовать это в непроизводственной среде.

Будут ли эти шаги идеальными для сценария DR для шлюза приложений?

1. Экспортируйте существующий шаблон шлюза (рабочий, поскольку он у нас единственный)
2. Воссоздайте шлюз при тестировании / постановке (возможно, потребуется отредактировать некоторые конфигурации в экспортированном шаблоне)
3. Создайте тестовый DNS и укажите общедоступный IP-адрес нового шлюза приложений.
4. подключите службу приложений к этому тестовому шлюзу

или нам лучше использовать диспетчер трафика для распределения трафика между несколькими шлюзами приложений в разных центрах обработки данных?

Использование диспетчера трафика для распределения трафика между несколькими шлюзами приложений в разных центрах обработки данных — лучший подход для достижения этого сценария DR.

См . : https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-faq#how-do-i-achieve-a-dr-scenario-across-datacenters-by-using-application-gateway

Аварийное восстановление с помощью диспетчера трафика предоставляет несколько подходов для обеспечения отработки отказа и высокой доступности с помощью избыточной архитектуры. Некоторые из популярных подходов упоминаются в приведенном ниже документе: https://docs.microsoft.com/en-us/azure/networking/disaster-recovery-dns-traffic-manager

Архитектура, компоненты и рекомендации по этому типу настройки можно найти в приведенном ниже документе: https://docs.microsoft.com/en-us/azure/architecture/high-availability/reference-architecture-traffic-manager-application-gateway