Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Многие регионы Azure предоставляют зоны доступности, которые разделены группами центров обработки данных в пределах региона. Каждая зона доступности имеет независимую энергетику, охлаждение и сетевую инфраструктуру, так что при возникновении сбоя в одной из зон, региональные службы, ресурсы и высокий уровень доступности поддерживаются остальными зонами.
Зоны доступности обычно разделяются несколькими километрами и обычно находятся в пределах 100 километров. Это расстояние означает, что они находятся достаточно близко, чтобы иметь низкозатратные подключения к другим зонам доступности по высокопроизводительной сети. Тем не менее, они достаточно далеко друг от друга, чтобы снизить вероятность того, что несколько из них будут затронуты местными сбоями или погодой.
Расположения центров обработки данных выбираются с помощью строгих критериев оценки рисков уязвимостей. Этот процесс определяет все значительные риски, связанные с центром обработки данных, и рассматривает общие риски между зонами доступности.
Azure не взимает плату за передачу данных между зонами доступности в одном регионе, независимо от того, используется ли частный или общедоступный IP-адрес.
На следующей схеме показано несколько примеров регионов Azure. Регионы 1 и 2 поддерживают зоны доступности, а регионы 3 и 4 не имеют зон доступности.
Подсказка
Сведения о том, какие регионы поддерживают зоны доступности, см. в списке регионов Azure.
Центры обработки данных и зоны доступности
Зона доступности — это логическая группировка одного или нескольких физически отдельных центров обработки данных в пределах региона. Каждая зона доступности создается таким образом, что если что-то происходит неправильно в одном (например, проблема с питанием или сетью), другие продолжают работать. Единый центр обработки данных не предоставляет такой уровень защиты самостоятельно.
Типы поддержки зон доступности
Службы Azure могут предоставлять два типа поддержки зоны доступности для своих ресурсов: с резервированием по зонам и зональное. Каждая служба может поддерживать один или несколько этих типов. Убедитесь, что вы понимаете, как каждая служба в рабочей нагрузке поддерживает зоны доступности, обращаясь к руководству по надежности каждой службы.
Каждая служба может реализовать поддержку зоны доступности разными способами. В следующих разделах описаны два типа служб поддержки зоны доступности:
Ресурсы с избыточностью между зонами: ресурсы с избыточностью между зонами реплицируются или распределяются по нескольким зонам доступности службой. Зонально-избыточные службы данных реплицируют данные в нескольких зонах, чтобы сбой в одной зоне не влиял на доступность данных. Некоторые службы автоматически становятся зонально избыточными в поддерживаемых регионах, в то время как для других служб необходимо настроить ресурс на зональную избыточность. Для большинства служб корпорация Майкрософт выбирает зоны, используемые ресурсами. Иногда можно выбрать набор зон.
При зонально избыточном развертывании Microsoft управляет распределением запросов и репликацией данных между зонами. Если сбой возникает в зоне доступности, Microsoft автоматически управляет переключением на другую зону.
Зональные ресурсы: зональный ресурс развертывается в одной, самостоятельно выбранной зоне доступности.
Зональные развертывания не обеспечивают автоматическую устойчивость к отказам в зонах доступности. Однако зональные ресурсы изолированы от сбоев в других зонах. Они также могут помочь вам достичь необычно строгих требований к задержке или производительности. Например, для высокочастотных рабочих нагрузок, созданных с помощью виртуальных машин, можно развернуть несколько виртуальных машин в одной и той же зоне, чтобы уменьшить задержку между ними.
Чтобы обеспечить устойчивость зональных ресурсов к сбоям зоны доступности, необходимо разработать архитектуру с отдельными ресурсами в нескольких зонах доступности в пределах региона. Майкрософт не управляет процессом для вас. Если сбой возникает в зоне доступности, вы несете ответственность за переключение на другую зону.
Некоторые службы могут иметь дополнительные требования для поддержки зоны доступности. Например, некоторые могут поддерживать только зоны доступности для определенных уровней или номеров SKU или в подмножестве регионов Azure. Руководства по надежности содержат подробные сведения о любых требованиях, необходимых для включения зон доступности в службах.
Когда вы настраиваете ресурс для зональной избыточности или используете несколько экземпляров зонального ресурса в разных зонах доступности, ваш ресурс считается устойчивым к недоступности зоны: то есть он устойчив к сбоям в одной зоне доступности.
Дополнительные сведения об использовании зональных развертываний и поддержании устойчивости зоны см. в разделе "Зональные ресурсы" и "Устойчивость зональных зон".
Если ресурс не настроен для использования зон доступности, либо из-за региона, который не поддерживает зоны, либо из-за выбора конфигурации, он называется незональнымили региональным развертыванием. Azure может размещать незональные ресурсы в любом регионе. Вы не выбираете, какие ресурсы попадают в какие зоны. Если в какой-либо зоне доступности в регионе произойдет сбой, незональные ресурсы могут оказаться в затронутой зоне и столкнуться с простоем.
Настройка ресурсов для поддержки зоны доступности
Каждая служба имеет собственный метод настройки поддержки зоны доступности. Сведения о том, как каждая служба поддерживает зоны доступности и как настроить эту поддержку, см. в разделе руководства по надежности Azure для каждой службы.
Физические и логические зоны доступности
Каждому центру обработки данных назначается физическая зона. Физические зоны сопоставляются с логическими зонами в подписке Azure, а разные подписки могут иметь другой порядок сопоставления. Подписки Azure автоматически получают свое назначение сопоставления в момент их создания. Из-за этого сопоставление зоны для одной подписки может отличаться от сопоставления для других подписок.
Например, подписка A может иметь физическую зону 1, сопоставленную с логической зоной 2, а подписка B имеет физическую зону 1, сопоставленную с логической зоной 3:
Чтобы понять сопоставление логических и физических зон для подписки, используйте API Azure Resource Manager (ARM) List Locations. Azure CLI или Azure PowerShell можно использовать для получения сведений из API.
Чтобы сравнить сопоставление зон для устойчивых решений, охватывающих несколько подписок, используйте специализированный API ARM checkZonePeers. Чтобы использовать checkZonePeers API, необходимо включить функцию Microsoft.Resources/AvailabilityZonePeering. Дополнительные сведения о включении функций см. в статье "Регистрация функций в подписке Azure".
az rest --method get \
--uri '/subscriptions/{subscriptionId}/locations?api-version=2022-12-01' \
--query 'value[?availabilityZoneMappings != `null`].{displayName: displayName, name: name, availabilityZoneMappings: availabilityZoneMappings}'
Зоны доступности и обновления Azure
Для каждого региона корпорация Майкрософт стремится развернуть обновления в службах Azure в пределах одной зоны доступности одновременно. Этот подход снижает влияние обновлений на активную рабочую нагрузку, что позволяет рабочей нагрузке продолжать работать в других зонах во время обновления. Чтобы использовать преимущества поэтапных обновлений зон, рабочая нагрузка должна быть уже настроена для выполнения в нескольких зонах. Дополнительные сведения о развертывании обновлений Azure см. в статье "Продвижение безопасных методов развертывания".
Задержка между зонами
В каждом регионе зоны доступности подключаются через высокопроизводительную сеть. Корпорация Майкрософт стремится обеспечить взаимодействие между зонами с задержкой кругового пути менее 2 миллисекунда. Низкая задержка позволяет обеспечить высокую производительность взаимодействия в регионе и синхронную репликацию данных в нескольких зонах доступности.
Примечание.
Целевая задержка относится к задержке сетевых каналов. В зависимости от используемого протокола связи и сетевых прыжков, необходимых для любого конкретного сетевого потока, наблюдаемая задержка может отличаться.
В большинстве рабочих нагрузок можно распределять компоненты решения по зонам доступности без заметного влияния на производительность. Если у вас есть рабочая нагрузка с высокой степенью чувствительности к задержке между зонами, важно проверить задержку между выбранными зонами доступности с помощью фактических протоколов и конфигурации. Чтобы сократить трафик между зонами, можно использовать зональные развертывания, но оптимально использовать несколько зон доступности в плане стратегии надежности. Дополнительные сведения об использовании зональных развертываний и поддержании устойчивости зоны см. в разделе "Зональные ресурсы" и "Устойчивость зональных зон".
Руководство по архитектуре зоны доступности
Для достижения надежных рабочих нагрузок:
- Рабочие нагрузки должны быть настроены для использования нескольких зон доступности, если регион, в котором они находятся, поддерживает зоны доступности.
- Для критически важных рабочих нагрузок следует рассмотреть решение, которое поддерживает мульти-региональные и мульти-зональные возможности.
Дополнительные сведения об использовании регионов и зон доступности в архитектуре решения см . в рекомендациях по использованию зон доступности и регионов.