Надежность в Диспетчер трафика Azure

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

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

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

Note

В этой статье описывается, как служба диспетчера трафика является устойчивой к различным проблемам или как вы можете сделать ее устойчивой. В нем не объясняется, как использовать Traffic Manager для переключения на резерв между приложениями или областями. Пример архитектуры отработки отказа см. в веб-приложении Multitier, созданном для обеспечения высокой доступности и аварийного восстановления.

Рекомендации по развертыванию в производственной среде

Платформа Azure Well-Architected предоставляет рекомендации по надежности, производительности, безопасности, затратам и операциям. Сведения о том, как эти области влияют друг на друга и способствуют надежному решению Traffic Manager, см. в разделе о лучших архитектурных практиках для Диспетчер трафика Azure в Well-Architected Framework.

Обзор архитектуры надежности

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

Логическая архитектура

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

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

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

Important

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

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

Физическая архитектура

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

Глобальные интернет-протоколы, такие как Anycast, DNS и BGP, автоматически направляют входящие запросы разрешения DNS в ближайшую здоровую инфраструктуру диспетчера трафика.

Устойчивость к временным сбоям

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

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

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

При использовании диспетчера трафика следует учитывать следующие типы временных сбоев отдельно:

  • Временные ошибки во время разрешения DNS: Если во время разрешения DNS возникает временный сбой, клиент или промежуточный сопоставитель должен повторить попытку.

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

Время жизни записи DNS определяет, как решение обрабатывает ошибки. Если срок жизни очень низкий, клиенты должны сделать больше запросов к диспетчеру трафика и существуют более потенциальные возможности для временных сбоев. Если срок жизни очень высок, в случае реального сбоя конечной точки клиенты могут столкнуться с задержками при переключении на резервный ресурс, пока не истечет срок действия TTL. Тщательно настройте TTLs для балансировки доступности, задержки и реагирования. При использовании Azure DNS он может автоматически настроить TTL записи для сопоставления значения TTL профиля, которое составляет 60 секунд по умолчанию. Дополнительные сведения см. в рекомендации по повышению производительности диспетчера трафика.

Устойчивость к сбоям зоны доступности

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

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

Устойчивость к сбоям на уровне региона

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

Устойчивость к сбоям средств управления и портала

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

Как и другие службы Azure, диспетчер трафика поддерживает развертывание и управление с помощью различных средств. Мы рекомендуем ознакомиться с тем, как использовать Azure CLI или Azure PowerShell для управления профилем. В качестве альтернативы разверните и настройте ваш профиль, используя технологии инфраструктуры как код, такие как Bicep или Terraform. Эти средства остаются в эксплуатации, даже если портал Azure ухудшается.

Резервное копирование и восстановление

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

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

Устойчивость к обслуживанию служб

Корпорация Майкрософт регулярно применяет обновления служб и выполняет другое обслуживание. Платформа Azure автоматически обрабатывает эти действия, обеспечивая простое и прозрачное обслуживание. Во время мероприятий технического обслуживания простой не ожидается, если только вас не предупредили через Работоспособность служб Azure о плановом обслуживании.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLA для онлайн-услуг.

Диспетчер трафика Azure предоставляет 100% соглашение об уровне обслуживания для ответов DNS-запросов, если клиенты повторяют неудачные запросы.

Связанный контент

  • Last updated on