Надежность в Диспетчер трафика Azure
В этой статье содержатся конкретные рекомендации по надежности Диспетчер трафика Azure, а также поддержка аварийного восстановления между регионами и непрерывности бизнес-процессов для Диспетчер трафика Azure.
Более подробный обзор принципов надежности в Azure см. в статье "Надежность Azure".
Рекомендации по надежности
В этом разделе содержатся рекомендации по обеспечению устойчивости и доступности. Каждая рекомендация входит в одну из двух категорий:
Элементы работоспособности охватывают такие области, как элементы конфигурации и правильная функция основных компонентов, составляющих рабочую нагрузку Azure, такие как параметры конфигурации ресурсов Azure, зависимости от других служб и т. д.
Элементы риска охватывают такие области, как требования к доступности и восстановлению, тестирование, мониторинг, развертывание и другие элементы, которые, если остались неразрешенными, повышают вероятность проблем в среде.
Матрица приоритетов рекомендаций по надежности
Каждая рекомендация помечается в соответствии со следующей матрицей приоритетов:
| Изображения | Приоритет | Описание |
|---|---|---|
|
Высокая | Необходимо немедленное исправление. |
|
Средняя | Исправление в течение 3–6 месяцев. |
|
Низкая | Необходимо проверить. |
Сводка рекомендаций по надежности
Availability
Состояние монитора Диспетчер трафика должно быть в сети
Состояние монитора должно быть в сети, чтобы обеспечить отработку отказа для рабочей нагрузки приложения. Если работоспособность Диспетчер трафика отображает состояние "Понижение", состояние одной или нескольких конечных точек также может быть понижено.
Дополнительные сведения о мониторинге конечных точек Диспетчер трафика см. в Диспетчер трафика мониторинге конечных точек.
Сведения об устранении неполадок с пониженным состоянием в Диспетчер трафика Azure см. в разделе "Устранение неполадок с состоянием пониженного состояния" на Диспетчер трафика Azure.
Профили диспетчера трафика должны иметь несколько конечных точек
При настройке диспетчера трафика Azure необходимо подготовить не менее двух конечных точек для отработки отказа рабочей нагрузки в другой экземпляр.
Дополнительные сведения о типах конечных точек Диспетчер трафика см. в Диспетчер трафика конечных точках.
Эффективность системы
Значение TTL профилей пользователей должно находиться в 60 секундах
Срок жизни влияет на то, как быстро клиент получит ответ после отправки запроса в диспетчер трафика Azure. Если сократить срок жизни, клиент в случае отработки отказа будет перенаправлен на работающую конечную точку быстрее. Задайте срок жизни 60 секунд для скорейшей маршрутизации трафика на работоспособную конечную точку.
Дополнительные сведения о настройке срока жизни DNS см. в разделе "Настройка времени dns в реальном времени".
Аварийное восстановление
Настройка по крайней мере одной конечной точки в другом регионе
В профилях должно быть по несколько конечных точек, чтобы гарантировать доступность при сбое одной из них. Кроме того, рекомендуется размещать конечные точки в разных регионах.
Дополнительные сведения о типах конечных точек Диспетчер трафика см. в Диспетчер трафика конечных точках.
Убедитесь, что конечная точка настроена на "(Все мир)" для географических профилей
Для географической маршрутизации трафик направляется в конечные точки в зависимости от заданных регионов. Отработка отказа не определена заранее на случай, если регион станет недоступным. Наличие конечной точки, в которой региональное группирование настроено на "Все (мир)" для географических профилей, позволит избежать черного выделения трафика и гарантировать, что служба остается доступной.
Сведения о добавлении и настройке конечной точки см. в статье "Добавление, отключение, включение, удаление или перемещение конечных точек".
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с Рекомендации для разработки стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплика te данные или возвращаются из неудающегося региона, чтобы перекрестно реплика te в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
Диспетчер трафика Azure — это подсистема балансировки нагрузки трафика на основе DNS, которая позволяет распределять трафик между общедоступными приложениями в глобальных регионах Azure. Диспетчер трафика также предоставляет общедоступные конечные точки с высоким уровнем доступности и быстрым реагированием.
Диспетчер трафика использует DNS для перенаправления клиентских запросов к соответствующей конечной точке службы на основе метода маршрутизации трафика. Диспетчер трафика также обеспечивает мониторинг работоспособности для каждой конечной точки. Конечной точкой может быть любая служба с доступом в Интернет, размещенная в среде Azure или за ее пределами. Диспетчер трафика предоставляет целый ряд методов маршрутизации трафика и параметров мониторинга конечных точек, подходящих для приложений с различными потребностями и моделями автоматической отработки отказа. Диспетчер трафика устойчив к сбоям, включая сбой всего региона Azure.
Аварийное восстановление в географическом регионе с несколькими регионами
DNS является одним из наиболее эффективных механизмов для перенаправления сетевого трафика. DNS эффективен, так как DNS часто является глобальным и внешним в центре обработки данных. DNS также изолирован от сбоев уровня региональной или зоны доступности (AZ).
Существует два технических аспекта относительно настройки архитектуры аварийного восстановления.
Использование механизма развертывания для репликации экземпляров, данных и конфигураций между основной и резервной средами. Этот тип аварийного восстановления можно выполнить в собственном коде с помощью Site Recovery, см. документацию по 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.