Зональные ресурсы и устойчивость зон

В Azure зональный ресурс — это ресурс, закрепленный в одной зоне. Так как зональный ресурс находится в одной зоне доступности, он не является устойчивым к зонам. Если у зоны, содержащей ресурс, возникнет проблема, ресурс, скорее всего, столкнется с простоями.

Некоторые службы Azure требуют или позволяют развертывать зональные ресурсы. Вы можете развернуть ресурс зонально из-за соображений задержки или конкретных требований к службе. Можно закрепить отдельные ресурсы или наборы связанных ресурсов в одной зоне.

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

Типы развертывания ресурсов

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

Дополнительные сведения о зонах доступности и развертываниях ресурсов см. в разделе "Зоны доступности".

Рабочие нагрузки, объединяющие зонально-резервные и зональные ресурсы

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

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

Когда следует использовать зональное развертывание

Используйте зональные ресурсы только в том случае, если есть четкая потребность. Типичные причины развертывания в одной зоне включают случаи, когда ресурс должен быть зональным, служба доступна только в определенной зоне или рабочая нагрузка очень чувствительна к задержке между зонами.

Ресурсы, требующие зональных развертываний

Некоторые службы Azure поддерживают только зональные развертывания и не предоставляют развертывания с избыточностью по зонам.

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

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

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

• Сведения о типах виртуальных машин, доступных в каждом регионе, см. в разделе "Продукты", доступные по регионам.

• Чтобы проверить поддерживаемые типы и размеры виртуальных машин в каждой зоне определенного региона, см. статью "Проверка доступности номера SKU виртуальной машины".

Если нужный тип виртуальной машины доступен только в одной зоне в регионе, который вы используете, можно рассмотреть зональное развертывание для этой виртуальной машины, а затем найти другие способы обеспечения устойчивости виртуальной машины к сбоям между зонами. Но вы должны продолжать обеспечивать, что другие части вашего решения зонально-устойчивы.

Дополнительные сведения см. в службах Azure, поддерживающих зоны доступности.

Задержка между зонами

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

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

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

• Очень высокомасштабная синхронная репликация: Приложения и базы данных с отслеживанием состояния иногда выполняют очень большое количество операций записи с помощью синхронной репликации. Синхронная репликация означает, что данные записываются в несколько реплик до завершения операции записи. Распределение реплик между зонами доступности повышает устойчивость, но при использовании синхронной репликации задержка между зонами может увеличить задержку записи рабочей нагрузки. Эта повышенная задержка обычно не является значительной, но из-за того, как некоторые приложения разработаны, иногда это может стать проблематичным в большом масштабе.

Если вы подозреваете, что задержка между зонами влияет на рабочую нагрузку, проверьте его влияние в реалистичной среде, выполнив следующие действия для конкретной рабочей нагрузки:

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

2. Запустите тест производительности в пределах одной зоны доступности. Установите набор базовых метрик производительности.

   Это важно

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

3. Включите репликацию между зонами. В зависимости от компонентов, которые вы используете, можно включить зональную избыточность или перемещать реплики между зонами.

4. Повторное выполнение тестов производительности. Соберите те же метрики, которые вы собрали ранее.

5. Сравните влияние на производительность с вашими требованиями. Используйте ваши требования и данные о производительности, чтобы принять обоснованное решение о компромиссе между задержкой и устойчивостью к сбоям зон.

   Если тест демонстрирует, что задержка неприемлема для рабочей нагрузки, рассмотрите следующие действия:

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

     Подсказка

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

   • Если существует другой регион Azure, который соответствует вашим общим потребностям для размещения данных и других факторов, попробуйте использовать несколько зон в этом регионе.

   • Рассмотрите возможность перепроектирования приложения, чтобы свести к минимуму необходимый обмен данными между зонами. Например, можно объединить несколько небольших операций базы данных в одну операцию. Такой подход может снизить влияние задержки на рабочую нагрузку.

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

Ваши обязанности по зональному развертыванию

Зональный ресурс рискует простоем, когда ее зона доступности испытывает сбой. При развертывании зонального ресурса вы несете ответственность за устойчивость рабочей нагрузки к сбоям уровня зоны.

Чтобы обеспечить устойчивость зональных ресурсов, рассмотрите следующие обязанности:

• Развертывание и настройка нескольких ресурсов: Развертывание отдельных зональных ресурсов вручную в разных зонах или регионах. Определите, как обеспечить согласованность конфигурации для каждого ресурса. Использование инфраструктуры в качестве кода (IaC) рекомендуется, так как это обеспечивает быстрое развертывание нескольких идентичных ресурсов.

• Маршрутизация и распределение трафика: Необходимо выбрать компонент подсистемы балансировки нагрузки, обеспечить устойчивость зоны и настроить его для отправки трафика между ресурсами в разных зонах. Обычно вы настраиваете политику маршрутизации (например, active-active или active-passive), автоматические проверки работоспособности и процессы резервирования. Дополнительные сведения см. в разделе "Параметры балансировки нагрузки".

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

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

• Процессы восстановления зоны: После восстановления зоны вы несете ответственность за все необходимые действия восстановления, например восстановление ресурсов в основной зоне.

Распространенные подходы к устойчивости зонального развертывания

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

• Просмотрите всю рабочую нагрузку. Узнайте, как работает каждый компонент во время событий отключения зон, включая избыточные зональные ресурсы, зональные и нерегиональные ресурсы. Используйте руководство по надежности для каждой службы, чтобы узнать, как работает служба во время сценариев отключения зоны, и как отслеживать работоспособность служб во время отключения зоны.

• Узнайте о допустимой потере данных во время сбоя зоны. RPO указывает, сколько потери данных можно принять.

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

  При планировании зонального развертывания необходимо обеспечить соответствие требованиям RPO рабочей нагрузки в случае сбоя зоны.

• Понять допустимое время простоя при сбое зоны. RTO указывает, сколько простоев можно принять.

  Ресурсы Azure с избыточностью по зонам обычно обеспечивают очень низкое время восстановления (RTO) при сбоях в зоне и обычно требуют всего несколько секунд простоя.

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

• Поймите стоимость. Зональные ресурсы обычно выставляются по отдельности, поэтому развертывание нескольких зональных ресурсов может увеличить затраты на ресурсы.

Проектирование зонального развертывания для обеспечения устойчивости

При разработке зонального развертывания для обеспечения устойчивости рассмотрите, используете ли вы зоны доступности для обеспечения высокой доступности или аварийного восстановления. Различие между этими понятиями основано на требованиях RTO и RPO.

Если у вас есть низкое требование RTO и низкого уровня RPO, необходимо рассматривать зоны доступности как конструкцию высокой доступности . Но если RTO и RPO выше, вы можете рассматривать зоны доступности как конструкцию аварийного восстановления . Дополнительные сведения см. в разделе "Непрерывность бизнес-процессов", "Высокий уровень доступности" и "Аварийное восстановление". Уровень рабочей нагрузки поможет вам определить требования и необходимые действия.

Проектирование высокого уровня доступности

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

Некоторые приложения, развертываемые на зональных ВМ, обеспечивают встроенную поддержку высокой доступности, например, благодаря осознанию наличия реплик. Например, если вы используете SQL Server на виртуальных машинах Azure, группы доступности предоставляют возможности маршрутизации трафика и отработки отказа. Можно выбрать, следует ли использовать синхронную или асинхронную репликацию. Дополнительные сведения см. в статье "Непрерывность бизнес-процессов", "Высокий уровень доступности" и аварийное восстановление sql Server на виртуальных машинах Azure.

Разработка для аварийного восстановления

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

План аварийного восстановления помогает подготовиться к различным сценариям и определяет способ реагирования с помощью сочетания автоматизированных и ручных процессов.

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

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

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

• Аварийное восстановление на основе резервного копирования: Если решение может терпеть высокий уровень RTO и высокий RPO, рассмотрите возможность использования резервных копий в качестве стратегии аварийного восстановления. Если в зоне возникает сбой, можно восстановить резервные копии в другой зоне или регионе. Кроме того, вам нужно решить, создадите ли вы другие ресурсы Azure в вашем решении заранее или во время процесса аварийного переключения.

  В зональной архитектуре вы часто отвечаете за хранение и репликацию этих резервных копий.

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

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

• Рекомендации по использованию зон доступности и регионов в Azure Well-Architected Framework