Надежность в Azure Traffic Manager

Эта статья содержит поддержку межрегионального восстановления после аварий и непрерывности бизнеса для Диспетчера трафика Azure.

Аварийное восстановление между регионами и непрерывность бизнес-процессов

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

Для восстановления после сбоя компания Microsoft использует модель общей ответственности. В этой модели корпорация Майкрософт гарантирует, что доступны базовые инфраструктуры и службы платформы. Однако многие службы Azure не делают автоматической репликации данных и не обеспечивают возврат из вышедшего из строя региона для перекрестной репликации в другой доступный регион. Для этих сервисов вы отвечаете за настройку плана аварийного восстановления, соответствующего вашей рабочей нагрузке. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления. Вы можете использовать специализированные функции для поддержки быстрого восстановления и разработки плана аварийного восстановления.

Диспетчер трафика Azure — это подсистема балансировки нагрузки трафика на основе DNS, которая позволяет распределять трафик между общедоступными приложениями в глобальных регионах Azure. Диспетчер трафика также предоставляет общедоступные конечные точки с высоким уровнем доступности и быстрым реагированием.

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

Аварийное восстановление в географическом регионе с несколькими регионами

DNS является одним из наиболее эффективных механизмов для перенаправления сетевого трафика. DNS эффективен, так как DNS часто является глобальным и внешним в центре обработки данных. DNS также защищен от сбоев на уровне региона или зоны доступности (AZ).

Существует два технических аспекта относительно настройки архитектуры аварийного восстановления.

• Использование механизма развертывания для репликации экземпляров, данных и конфигураций между основной и резервной средами. Этот тип аварийного восстановления можно выполнить нативно с помощью Azure Site Recovery, см. документацию по Azure Site Recovery, а также с использованием партнерских устройств и служб Microsoft Azure, таких как Veritas или NetApp.

• Разработка решения для перенаправления сетевого или Интернет-трафика с основного сайта на резервный. Этот тип аварийного восстановления можно достичь с помощью Azure DNS, Диспетчер трафика Azure(DNS) или сторонних глобальных подсистем балансировки нагрузки.

В этой статье уделяется внимание планированию аварийного восстановления с использованием Azure Traffic Manager.

Обнаружение сбоев, уведомление и управление

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

Настройка аварийного восстановления и обнаружения сбоев

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

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

Рис. Автоматический переход на другой ресурс, используя диспетчер трафика Azure

Однако только основной регион активно обрабатывает сетевые запросы от пользователей. Дополнительный регион становится активным, только если в основном регионе происходит нарушение работы службы. В этом случае все новые сетевые запросы перенаправляются в дополнительный регион. Поскольку резервное копирование базы данных происходит почти мгновенно, оба балансировщика нагрузки имеют IP-адреса, которые могут быть проверены на работоспособность, и экземпляры всегда запущены и работают. Эта топология предоставляет возможность перехода на низкий уровень RTO и переход на другой ресурс без какого-либо ручного вмешательства. Дополнительный регион для отработки отказа должен быть готов к работе сразу после сбоя основного региона.

Этот сценарий идеально подходит для использования диспетчера трафика Azure со встроенными пробами для различных типов проверок работоспособности, включая http/https и TCP. Диспетчер трафика Azure также имеет модуль правил, который может быть настроен на переход на другой ресурс при сбое, как описано ниже. Рассмотрим следующие решения с использованием диспетчера трафика.

• Клиент имеет конечную точку Регион № 1, известную как prod.contoso.com, со статическим IP-адресом 100.168.124.44 и конечную точку Регион № 2, известную как dr.contoso.com, со статическим IP-адресом 100.168.124.43.
• Каждая из этих сред оснащена публично доступной компонентой, например, балансировщиком нагрузки. Балансировщик нагрузки может быть настроен на наличие конечной точки на основе DNS или полного доменного имени (FQDN), как показано выше.
• Все экземпляры в регионе 2 реплицируются почти в реальном времени с регионом 1. Кроме того, обновляются образы компьютеров, а все данные конфигурации и программного обеспечения исправлены и точно соответствуют Региону № 1.
• Автомасштабирование было предварительно сконфигурировано.

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

1. Создайте новый профиль Диспетчера трафика Azure с именем contoso123 и выберите метод маршрутизации "Приоритетный". При наличии существующей группы ресурсов, которую требуется связать, можно выбрать ее. В противном случае создайте новую группу ресурсов.

   

   Схема. Создание профиля диспетчера трафика

2. Создание конечных точек в профиле диспетчера трафика

   На этом этапе вы создаете конечные точки, которые указывают на производственные и аварийные сайты восстановления. Здесь в качестве внешней конечной точки выберите Тип, но если ресурс размещен в Azure, можно выбрать конечную точку Azure. При выборе конечной точки Azure затем выберите Целевой ресурс, который является либо службой приложения, либо общедоступным IP-адресом, выделенным Azure. Приоритет установлен как 1, так как это основная служба для Региона № 1. Аналогичным образом создайте конечную точку аварийного восстановления в диспетчере трафика.

   

   Рис. Создание конечных точек аварийного восстановления

3. Настройка конфигурации проверки работоспособности и перехода на другой ресурс

   На этом шаге срок жизни DNS устанавливается на 10 секунд, что соблюдается большинством рекурсивных резольверов с выходом в Интернет. Эта конфигурация означает, что ни один резольвер DNS не будет кэшировать информацию более 10 секунд.

   При настройке параметров мониторинга конечной точки путь в данный момент установлен на "/" или root, но вы можете настроить параметры конечной точки, чтобы оценивать другой путь, например, prod.contoso.com/index.

   В приведенном ниже примере показан https как протокол проверки. Тем не менее можно выбрать http или tcp. Выбор протокола зависит от конечного приложения. Интервал проверки установлен на 10 секунд, что обеспечивает быструю проверку, а повторение попыток установлено на 3. В результате диспетчер трафика переключится на вторую конечную точку, если три последовательных интервала зарегистрируют сбой.

   Формула ниже определяет общее время автоматического переключения:

   Time for failover = TTL + Retry * Probing interval

   В этом случае значение равно 10 + 3 * 10 = 40 секунд (Макс).

   Если "Повторение попыток" имеет значение 1, а "Срок жизни" установлен на 10 секунд, то время для перехода на другой ресурс равно 10 + 1 * 10 = 20 секунд.

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

   

   Рис. Настройка конфигурации проверки работоспособности и резервного переключения

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

• Надежность в Azure

• См. дополнительные сведения о диспетчере трафика Azure.

• Дополнительные сведения по Azure DNS.