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

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

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

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

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

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

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

Примечание.

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

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

Чтобы создать частный сопоставитель Azure DNS с помощью портал Azure, см. краткое руководство. Создание частного сопоставителя Azure DNS с помощью портал 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, а для вторичного сайта — 100.168.124.43.
• Для основного и вторичного сайта существуют зоны Azure DNS. Допустим, что для основного сайта конечной точкой является prod.contoso.com, а для резервной копии сайта — dr.contoso.com. Также существует запись DNS для основного приложения, известного как www.contoso.com.
• Срок жизни находится на уровне или ниже значения RTO соглашения об уровне обслуживания, установленного в организации. Например, если предприятие задает значение RTO ответа приложения после сбоя 60 мин, то значение срока жизни должно быть меньше 60 мин, считается чем ниже, тем лучше. Вы можете настроить Azure DNS для отработки отказа вручную следующим образом:
  • Создание зоны DNS
  • Создание записей зоны DNS
  • Обновление записи CNAME

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

   

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

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

   

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

   В этом сценарии веб-сайту www.contoso.com задано срок жизни 30 мин, что значительно меньше установленного RTO, и указывает на рабочий веб-сайт prod.contoso.com. Эта конфигурация выполняется во время обычных бизнес-операций. Срок жизни для веб-сайтов 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 Azure и API можно использовать для автоматического обновления CNAME без ручного вмешательства. Автоматизация может быть создана с помощью функций Azure или в стороннем приложении мониторинга или даже из локальной среды.

Следующие шаги

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