Надежность в Диспетчер трафика Azure
Эта статья содержит поддержку аварийного восстановления между регионами и непрерывности бизнес-процессов для Диспетчер трафика Azure.
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с рекомендациями по разработке стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплицируют данные или не реплицируются из неудающегося региона для перекрестной репликации в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
Диспетчер трафика Azure — это подсистема балансировки нагрузки трафика на основе DNS, которая позволяет распределять трафик между общедоступными приложениями в глобальных регионах Azure. Диспетчер трафика также предоставляет общедоступные конечные точки с высоким уровнем доступности и быстрым реагированием.
Диспетчер трафика использует DNS для перенаправления клиентских запросов к соответствующей конечной точке службы на основе метода маршрутизации трафика. Диспетчер трафика также обеспечивает мониторинг работоспособности для каждой конечной точки. Конечной точкой может быть любая служба с доступом в Интернет, размещенная в среде Azure или за ее пределами. Диспетчер трафика предоставляет целый ряд методов маршрутизации трафика и параметров мониторинга конечных точек, подходящих для приложений с различными потребностями и моделями автоматической отработки отказа. Диспетчер трафика устойчив к сбоям, включая сбой всего региона Azure.
Аварийное восстановление в географическом регионе с несколькими регионами
DNS является одним из наиболее эффективных механизмов для перенаправления сетевого трафика. DNS эффективен, так как DNS часто является глобальным и внешним в центре обработки данных. DNS также изолирован от сбоев уровня региональной или зоны доступности (AZ).
Существует два технических аспекта относительно настройки архитектуры аварийного восстановления.
Использование механизма развертывания для репликации экземпляров, данных и конфигураций между основной и резервной средами. Этот тип аварийного восстановления можно выполнить в собственном коде с помощью Site Recovery в Azure, см . документацию по Azure Site Recovery с помощью партнерских устройств и служб Microsoft Azure, таких как Veritas или NetApp.
Разработка решения для перенаправления сетевого или Интернет-трафика с основного сайта на резервный. Этот тип аварийного восстановления можно достичь с помощью Azure DNS, Диспетчер трафика Azure(DNS) или сторонних глобальных подсистем балансировки нагрузки.
В этой статье основное внимание уделяется планированию аварийного восстановления Диспетчер трафика Azure.
Обнаружение сбоев, уведомление и управление
Во время аварии основная конечная точка получает пробы и ее состояние изменяется на пониженное, а веб-сайт аварийного восстановления становится подключенным. По умолчанию диспетчер трафика направляет весь трафик в первичную конечную точку (с наивысшим приоритетом). Если основная конечная точка оказывается с пониженной работоспособностью, диспетчер трафика направляет трафик к дополнительной конечной точке при условии, что она остается в работоспособном состоянии. В диспетчере трафика можно настроить больше конечных точек, которые будут служить дополнительными конечными точками восстановления при отказе или балансирами нагрузки, распределяя нагрузку между конечными точками.
Настройка аварийного восстановления и обнаружения сбоев
При наличии сложных архитектур и нескольких наборов ресурсов, способных выполнять одну и ту же функцию, можно настроить диспетчер трафика 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, выполните следующие действия.
Создайте новый Диспетчер трафика Azure профиль диспетчера трафика Azure с именем contoso123 и выберите метод маршрутизации в качестве приоритета. При наличии существующей группы ресурсов, которую требуется связать, можно выбрать ее. В противном случае создайте новую группу ресурсов.
Схема. Создание профиля диспетчера трафика
Создание конечных точек в профиле диспетчера трафика
На этом этапе создаются конечные точки, указывающие на рабочие веб-сайты и веб-сайты аварийного восстановления. Здесь в качестве внешней конечной точки выберите Тип, но если ресурс размещен в Azure, можно выбрать конечную точку Azure. При выборе конечной точки Azure затем выберите Целевой ресурс, который является либо службой приложения, либо общедоступным IP-адресом, выделенным Azure. Приоритет установлен как 1, так как это основная служба для Региона № 1. Аналогичным образом создайте конечную точку аварийного восстановления в диспетчере трафика.
Рис. Создание конечных точек аварийного восстановления
Настройка конфигурации проверки работоспособности и перехода на другой ресурс
На этом шаге срок жизни DNS устанавливается на 10 секунд, что соблюдается большинством рекурсивных резольверов с выходом в Интернет. Эта конфигурация означает, что ни один резольвер DNS не будет кэшировать информацию более 10 секунд.
При настройке мониторинга конечной точки параметр "путь" указывает на root или путь к 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 DNS.