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

В этой статье содержатся подробные сведения о поддержке аварийного восстановления между регионами и непрерывности бизнес-процессов для Azure DNS.

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

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

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

Решение Azure DNS для аварийного восстановления использует стандартные механизмы DNS для перехода на резервный сайт. Ручной вариант с помощью Azure DNS лучше всего подходит при использовании в сочетании с холодным резервным или пилотным методом.

Поскольку DNS-сервер находится вне зоны резервирования или зоны аварийного восстановления, он защищён от простоев. Вы можете разработать простой сценарий отказоустойчивости, если оператор имеет сетевое подключение во время аварии и может сделать переключение. Если решение выполняется скриптом, необходимо убедиться, что сервер или служба, выполняющая скрипт, также изолирована от проблемы, влияющей на рабочую среду. Кроме того, низкий TTL для зоны предотвращает кэширование резолвера в течение длительного времени, позволяя пользователю получить доступ к сайту в рамках RTO (Recovery Time Objective). Для холодного резерва и контрольной лампы, так как может потребоваться предварительный разогрев и выполнение других административных задач, вы также должны дать достаточно времени, прежде чем сделать переключение.

Note

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

Сведения о создании частной зоны DNS Azure с помощью портала Azure см. в кратком руководстве. Создание частной зоны DNS Azure с помощью портала Azure.

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

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

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

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

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

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

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

Ручное переключение Azure DNS для восстановления после аварий использует стандартный механизм DNS для переключения на резервный сайт. Вариант ручной настройки через Azure DNS лучше всего подходит при использовании в сочетании с методом холодного резервирования или методом пилотного света.

Рисунок - Ручное переключение с помощью Azure DNS

Предположения, сделанные для решения, являются следующими:

• Как первичные, так и вторичные конечные точки имеют статические IP-адреса, которые часто не изменяются. Предположим, что для первичного сайта IP-адрес равен 100.168.124.44, а IP-адрес вторичного сайта — 100.168.124.43.
• Зона Azure DNS существует как для первичного, так и вторичного сайта. Предположим, что для основного сайта конечная точка prod.contoso.com, а для сайта резервного копирования dr.contoso.com. Запись DNS для основного приложения под названием www.contoso.com также существует.
• TTL находится на уровне или ниже значения RTO в соглашении об уровне обслуживания, установленного в организации. Например, если предприятие устанавливает RTO для аварийного реагирования приложения на 60 минут, то значение TTL должно быть меньше 60 минут, причем чем меньше, тем лучше. Вы можете настроить Azure DNS для ручного переключения при отказе следующим образом:
  • Создание зоны DNS
  • Создание записей зоны DNS
  • Обновление записи CNAME

1. Создайте зону DNS (например, www.contoso.com) как показано ниже:

   

   Рисунок. Создание зоны DNS в Azure

2. В этой зоне создайте три записи (например, www.contoso.com, prod.contoso.com и dr.contoso.com), как показано ниже.

   

   Рисунок. Создание записей зоны DNS в Azure

   В этом сценарии у сайта www.contoso.com время жизни (TTL) составляет 30 минут, что значительно ниже указанного времени восстановления (RTO) и он направляет на основной сайт prod.contoso.com. Эта конфигурация выполняется во время обычных бизнес-операций. Для TTL prod.contoso.com и dr.contoso.com задано значение 300 секунд или 5 минут. Вы можете использовать службу мониторинга Azure, например Azure Monitor или Azure App Insights, или любые решения для мониторинга партнеров, такие как Dynatrace. Вы даже можете использовать самостоятельно разработанные решения, которые могут отслеживать и обнаруживать сбои на уровне приложений и виртуальной инфраструктуры.

3. После того как сбой будет обнаружен, измените значение записи, чтобы оно указывало на dr.contoso.com, как показано ниже.

   

   Рис. Обновление записи CNAME в Azure

   В течение 30 минут, в течение которых большинство сопоставителей обновят кэшированный файл зоны, любой запрос к www.contoso.com будет перенаправлен на dr.contoso.com. Чтобы изменить значение CNAME, можно также выполнить следующую команду Azure CLI:

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   Этот шаг можно выполнить вручную или с помощью автоматизации. Его можно сделать вручную с помощью консоли или Azure CLI. Пакет SDK и API Azure можно использовать для автоматизации обновления CNAME, чтобы не требуется вмешательство вручную. Автоматизация может быть создана с помощью функций Azure или в стороннем приложении мониторинга или даже из локальной среды.

Дальнейшие шаги

• Надежность в Azure
• Дополнительные сведения о диспетчере трафика Azure.
• Дополнительные сведения об Azure DNS.