Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Частные зоны Azure DNS обеспечивают безопасное разрешение имен в виртуальных сетях Azure. Частные зоны DNS можно ограничить одним или несколькими виртуальными сетями, а организации обычно используют их для внутренних приложений. Имена узлов, которые вы разрешаете, — это локальные DNS-имена, которые не доступны публично через Интернет. Разрешенные IP-адреса часто являются частными IP-адресами, которые недоступны из Интернета. Azure DNS — это глобальная служба, которая не привязана к определенной зоне доступности или одному региону.
При использовании Azure надежность — это общая ответственность. Корпорация Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.
В этой статье описывается, как сделать Azure DNS частные зоны устойчивыми к различным потенциальным сбоям и проблемам, включая временные ошибки и сбои на уровне региона. Он также предоставляет ключевые сведения о соглашении об уровне обслуживания Azure DNS частных зон (SLA).
Рекомендации по развертыванию в рабочей среде для обеспечения надежности
Для производственных нагрузок мы рекомендуем следовать следующим советам.
Настройте подходящие значения TTL: Задайте значения времени жизни (TTL), которые обеспечивают баланс между производительностью и временем восстановления. Более низкие значения TTL обеспечивают более быстрое переключение при отказе, но увеличивают объём запросов. Рассмотрим 300 секунд (5 минут) в качестве отправной точки для рабочих нагрузок.
Сегментирование больших зон DNS: Если у вас есть большая зона DNS, рассмотрите возможность сегментирования зоны , чтобы повысить общую надежность и эффективность работы.
Обзор архитектуры надежности
В этом разделе описываются некоторые важные аспекты работы службы, наиболее релевантные с точки зрения надежности. В этом разделе представлена логическая архитектура, включающая некоторые ресурсы и функции, которые развертываются и используются. Он также обсуждает аппаратную архитектуру, которая содержит сведения о том, как работает служба изнутри.
Логическая архитектура
Основной ресурс, который вы развертываете, — это зона, представляющая набор записей DNS, которые сопоставляют имена узлов (доменные имена) с IP-адресами. Имена узлов, разрешаемые зоной, обычно являются локальными DNS-именами, которые не доступны через Интернет.
Частные зоны DNS создаются как автономные ресурсы и связывают их с определенными виртуальными сетями путем создания каналов виртуальной сети. Когда dns-запросы приходят от клиентов в этих виртуальных сетях, частные зоны DNS участвуют в процессе разрешения. Вы можете вручную создавать записи в зоне DNS или настраивать автоматическую регистрацию виртуальных машин по ссылкам виртуальной сети. Частные зоны Azure DNS поддерживают DNS-разрешение между виртуальными сетями в разных регионах Azure, даже без явной настройки пиринга между виртуальными сетями. Однако все виртуальные сети должны быть связаны с частной зоной DNS.
Процесс разрешения DNS-имен включает несколько компонентов, включая сопоставители DNS и промежуточные уровни, которые обрабатывают запросы, прежде чем достичь доверенных DNS-серверов. Частные зоны используют те же протоколы и поведение DNS, что и общедоступные зоны, включая значения TTL и механизмы кэширования.
Important
Надежность общего решения зависит от конфигурации ресурсов, к которым относятся записи DNS, например виртуальные машины и подсистемы балансировки нагрузки.
Эта статья не охватывает эти ресурсы, но их конфигурации доступности напрямую влияют на устойчивость вашего приложения. Ознакомьтесь с руководствами по надежности служб Azure в решении , чтобы узнать, как каждая служба поддерживает требования к надежности.
Физическая архитектура
Azure DNS является нерегиональной службой. Microsoft развертывает свою инфраструктуру в нескольких зонах доступности в нескольких Azure регионах по всему миру. Эта конструкция позволяет Azure DNS оставаться устойчивыми во время сбоя зоны доступности или региона, так как инфраструктура в другой зоне или регионе продолжает реагировать на запросы на разрешение.
Глобальные интернет-протоколы, такие как Anycast, DNS и протокол BGP, автоматически направляют входящие запросы разрешения DNS в ближайшую здоровую инфраструктуру Azure DNS.
Устойчивость к временным сбоям
Временные ошибки являются короткими, периодическими сбоями в компонентах. Они часто происходят в распределенной среде, такой как облачная платформа, и являются обычной частью операций. Временные ошибки исправляют себя через короткий период времени. Важно, чтобы приложения могли обрабатывать временные ошибки, обычно повторяя затронутые запросы.
Все облачные приложения должны следовать рекомендациям по обработке временных ошибок Azure при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.
Azure DNS обрабатывает временные ошибки через глобальную инфраструктуру DNS.
Если во время разрешения DNS возникает временный сбой, клиент или промежуточный сопоставитель должен повторить запрос. Настройте значения времени ожидания соответствующим образом. Время ожидания от 2 до 5 секунд обычно достаточно для DNS-клиента.
Время жизни каждой записи DNS также влияет на то, как решение обрабатывает ошибки. Если значение TTL очень низкое, клиенты чаще отправляют запросы к Azure DNS, что повышает вероятность кратковременных сбоев. Если время жизни (TTL) очень велико, то в случае реального сбоя на сервере бэкенда, требующего переключения на другой IP-адрес, у клиентов возможны задержки при аварийном переключении до истечения TTL. Тщательно настройте TTLs для балансировки доступности, задержки и реагирования.
Устойчивость к сбоям зоны доступности
Зоны доступности — это физически отдельные группы центров обработки данных в регионе Azure. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.
Azure DNS работает в качестве нерегиональной службы. Microsoft распределяет свою инфраструктуру между несколькими зонами доступности в нескольких регионах Azure и реплицирует изменения в частных зонах DNS в этой инфраструктуре. Вы не выбираете зоны доступности или настраиваете избыточность зоны. Во время сбоя зоны доступности инфраструктура в другой зоне или регионе продолжает реагировать на запросы на разрешение.
Если ресурс, развернутый в одной зоне доступности, например виртуальной машины, становится недоступным во время сбоя зоны, Azure DNS продолжает возвращать настроенный IP-адрес ресурса, так как он не отслеживает работоспособность конечных точек. Если вы переключаетесь при отказе на ресурс в исправной зоне, вы должны обновить запись DNS, чтобы клиенты использовали исправный ресурс. В качестве альтернативы разместите ресурсы за балансировщиком нагрузки с межзонным резервированием, который направляет трафик на виртуальные машины в работоспособных зонах.
Устойчивость к сбоям на уровне региона
Azure DNS частные зоны устойчивы к сбоям регионов, так как данные зоны доступны глобально. Если в регионе происходит сбой, его виртуальные сети и ресурсы, такие как виртуальные машины, могут быть недоступны, но разрешение имён по-прежнему работает.
В следующем примере показано, как данные частной зоны остаются доступными в нескольких регионах. Частная зона azure.contoso.com связана с виртуальными сетями в трех регионах: регион A, регион B и регион C. Авторегистрация включена в регионах A и B. На схеме показан регион A, в котором возникает сбой:
Предположим, что временный сбой происходит в регионе A. Виртуальные машины в регионах B и C по-прежнему могут запрашивать DNS-имена в частной зоне, включая имена, которые автоматически регистрируются из региона A. Они могут продолжать разрешать IP-адрес vm1 в регионе A, даже если виртуальная машина 1 недоступна. Прерывание работы службы в регионе A не влияет на разрешение имен в других регионах.
В предыдущем примере не рассматривается сценарий аварийного восстановления, в котором при отказе решение переключается на заменяющую VM1 виртуальную машину в другом регионе. Однако, так как частные зоны являются глобальными, вы можете повторно создать виртуальную машину 1 в виртуальной сети другого региона, чтобы взять на себя рабочую нагрузку.
Если вы создаёте виртуальные сети и сетевые ресурсы в нескольких регионах, необходимо спланировать и реализовать много-региональную стратегию для приложений, которым требуется аварийное переключение между регионами.
Устойчивость к угрозам безопасности и неправильной настройке
Атаки безопасности и ошибки конфигурации являются двумя наиболее значительными рисками надежности для зон DNS. Несколько классов атак специально нацелены на разрешение DNS, а случайная ошибка в конфигурации может столь же серьёзно нарушить работу ваших рабочих нагрузок.
Подробные рекомендации по безопасности, относящиеся к частным зонам DNS, см. в разделе "Защита частных зон DNS и записей".
Устойчивость к сбоям служб
Azure DNS — это высокоустойчивая служба с SLA на доступность 100 %, если ваше приложение соответствует определённым условиям. Сбои служб являются чрезвычайно необычными, но проблемы с сетью или другой инфраструктурой могут нарушить подключение к службе Azure DNS.
Мониторинг сбоев служб
Microsoft автоматически не уведомляет вас об отключении региона. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.
Проверка сбоев служб
Azure Chaos Studio предоставляет набор ошибок для имитации проблем с разрешением DNS. Например, агент Chaos Studio предоставляет тип сбоя DNS Failure, а Azure Kubernetes Service (AKS) Chaos Mesh предоставляет возможность DNS Chaos. Эти типы сбоев можно использовать для проверки реагирования приложений и инфраструктуры при сбое запросов разрешения DNS, которые могут возникнуть во время частичного сбоя сети.
Устойчивость к сбоям средств управления и портала
Если вы управляете зоной DNS на портале Azure, подготовьтесь к сценариям, где его невозможно получить, особенно если необходимо перенастроить зону DNS во время сбоя платформы.
Вы можете использовать различные средства для развертывания Azure DNS частных зон и управления ими. Узнайте, как использовать Azure CLI или Azure PowerShell для управления частной зоной. Кроме того, используйте инфраструктуру в качестве кода (IaC), например Bicep или Terraform, для развертывания и настройки частной зоны. Эти средства остаются в эксплуатации, даже если портал Azure ухудшается.
Резервное копирование и восстановление
Azure DNS — это служба без сохранения состояния. Не поддерживаются управляемое резервное копирование и восстановление на определённый момент времени для частных DNS-зон.
Чтобы сохранить полную конфигурацию ресурсов Azure, определите частные зоны DNS с помощью IaC, например Bicep или Terraform, и сохраните определения в системе управления версиями. Периодически тестируйте определения, чтобы их можно было использовать для повторного развертывания конфигурации.
Устойчивость к обслуживанию служб
Корпорация Майкрософт регулярно применяет обновления служб и выполняет другое обслуживание. Платформа Azure автоматически обрабатывает эти действия, обеспечивая простое и прозрачное обслуживание. Во время мероприятий технического обслуживания простой не ожидается, если только вас не предупредили через Работоспособность служб Azure о плановом обслуживании.
Соглашение об уровне обслуживания
Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLA для онлайн-услуг.
Azure DNS предоставляет соглашение об уровне обслуживания, гарантирующее 100 % доступности для допустимых ответов на DNS-запросы при соблюдении определённых условий. К этим условиям относятся повторные попытки неудачных запросов по крайней мере 60 секунд подряд. Ознакомьтесь с документом соглашения об уровне обслуживания для получения подробных условий.