Включение устойчивости зоны для рабочих нагрузок Azure

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

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

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

Что такое устойчивость зоны?

Службы Azure могут быть устойчивы к сбоям зоны доступности двумя основными способами:

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

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

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

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

Процедура включения зоны

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

Предпосылки

Перед началом работы выполните следующие действия.

• Определите каждую рабочую нагрузку. Рабочая нагрузка ссылается на коллекцию ресурсов приложений, данных и вспомогательной инфраструктуры, которая работает вместе для достижения определенных бизнес-результатов. Дополнительные сведения о рабочих нагрузках и их определении см. вWell-Architected рабочих нагрузок Framework.

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

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

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

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

  Тип рабочей нагрузки	Description	Влияние нарушения
  Критически важный для миссии	Критически важные потоки и рабочие нагрузки, которые должны быть высоконадежными, всегда доступными, устойчивыми к сбоям и операционным	Любое нарушение основных функций немедленно рискует катастрофическим ущербом для бизнеса или представляет риски для человеческой жизни.
  Критически важный для бизнеса	Основные потоки и рабочие нагрузки, которые работают с важными бизнес-функциями	Нарушения рискуют некоторыми финансовыми потерями или ущербом бренда.
  Операционные аспекты бизнеса	Способствует эффективности бизнес-операций, но из прямой линии обслуживания клиентам	Может терпеть некоторые нарушения.
  Административный	Внутренние рабочие потоки и рабочие нагрузки, не согласованные с бизнес-операциями	Может терпеть нарушения.

  Дополнительные сведения о классификации рабочих нагрузок в соответствии с рейтингом критическости см. в разделе "Назначение оценки критическости" для каждого потока.

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

Шаг 1. Приоритет служб Azure для обеспечения устойчивости зоны

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

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

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

   Многие ключевые сетевые службы автоматически обеспечивают зоновую избыточность, но следует сосредоточиться на таких компонентах, как шлюзы Azure ExpressRoute, шлюз VPN Azure, шлюз приложений Azure, Azure Load Balancer и брандмауэр Azure.

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

   Для обеспечения устойчивости хранилища операционных данных сосредоточьтесь на таких службах, как База данных SQL Azure, Управляемый экземпляр SQL Azure, служба хранилища Azure Data Lake Storage, Azure Cosmos DB, гибкий сервер Azure PostgreSQL, гибкий сервер Azure MySQL и кэш Azure для Redis.

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

   Вычислительные службы включают виртуальные машины Azure, масштабируемые наборы виртуальных машин Azure, службу Azure Kubernetes (AKS), Службу приложений Azure, среду службы приложений, Функции Azure, Azure Service Fabric и приложения контейнеров Azure.

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

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

Шаг 2. Оценка подходов к конфигурации зоны

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

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

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

Шаг 3. Проверка задержки

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

Подходы к конфигурации зоны для служб Azure

Каждая служба Azure поддерживает определенный тип поддержки зоны доступности, которая основана на предполагаемом использовании и внутренней архитектуре службы. Если у вас есть ресурс, который не настроен для использования зон доступности (или незонального ресурса), может потребоваться перенастроить его с поддержкой зоны доступности. Руководство по надежности для этой службы предоставляет рекомендации или ссылки на инструкции по настройке зоны доступности.

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

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

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

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

Подход к настройке служб Azure по зонам

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

Услуга	Может быть избыточным между зонами	Может быть зональным	Типичный подход к конфигурации зоны	Типичное влияние на затраты
Поиск по искусственному интеллекту Azure			Всегда устойчива к зонам	N/A
Управление API Azure			Модификация	Минимальный уровень, необходимый
Конфигурация приложений Azure			Всегда устойчива к зонам	N/A
Служба приложений Azure			Включения	Минимально необходимый уровень и количество экземпляров
Служба приложений Azure — среда службы приложений			Включения	Минимальное количество экземпляров, необходимое
Шлюз приложений Azure			Всегда устойчива к зонам	N/A
Azure Backup			Передислокация	Умеренное увеличение затрат
Бастион Azure			Передислокация	Без влияния на затраты
Пакетная служба Azure			Передислокация	Отсутствие влияния на затраты для одинакового количества виртуальных машин.
Хранилище BLOB-объектов Azure			Включения	Умеренное увеличение затрат
Кэш Azure для Redis — Корпоративная			Передислокация	Без влияния на затраты
Кэш Azure для Redis — стандартный и премиум			Включения	Минимальный уровень, необходимый
Приложения контейнеров Azure			Передислокация	Минимальное количество реплик, необходимое
Экземпляры контейнеров Azure			Передислокация	Без влияния на затраты
Реестр контейнеров Azure			Всегда устойчива к зонам	N/A
Azure Cosmos DB для работы с NoSQL			Модификация	Нет при использовании автомасштабирования или многорегиональной записи
Фабрика данных Azure			Всегда устойчива к зонам	N/A
Хранилище озера данных Azure			Включения	Умеренное увеличение затрат
База данных Azure для MySQL — гибкий сервер			Передислокация	Требуется основной и высокодоступный (HA) экземпляр
База данных Azure для PostgreSQL — гибкий сервер			Включения	Требуется основной экземпляр и высокодоступный экземпляр
Хранилище дисков Azure (управляемые диски)			Включения	Умеренное увеличение затрат
Azure Elastic SAN			Передислокация	Умеренное увеличение затрат
Центры событий Azure: выделенный уровень			Всегда устойчива к зонам	Обязательные минимальные единицы емкости (ЦС)
Центры событий Azure: все остальные уровни			Всегда устойчива к зонам	N/A
Azure ExpressRoute			Модификация	Зависит от уровня
Файлы Azure			Включения	Умеренное увеличение затрат
Брандмауэр Azure			Модификация	Без влияния на затраты
Функции Azure			Передислокация	Минимально необходимый уровень и количество экземпляров
Azure HDInsight			Передислокация	Не влияет на затраты на одно и то же количество узлов
Центр Интернета вещей Azure			Устойчивость к зонам всегда	N/A
Azure Key Vault			Всегда устойчивый к зонам	N/A
Служба Azure Kubernetes (AKS)			Передислокация	Без влияния на затраты
Azure Load Balancer			Модификация	Без влияния на затраты
Azure Logic Apps — уровень потребления			Всегда устойчива к зонам	N/A
Azure Logic Apps — уровень "Стандартный"			Передислокация	Минимально необходимый уровень и количество экземпляров
Управляемая Grafana от Azure			Повторное развертывание	Умеренное увеличение затрат
Azure Monitor: Log Analytics			Всегда устойчива к зонам
Файлы Azure NetApp			Передислокация	Зависит от конфигурации репликации
Хранилище очередей Azure			Включения	Умеренное увеличение затрат
Сервисная шина Azure			Всегда устойчива к зонам	N/A
Azure Service Fabric			Передислокация	Не влияет на затраты на одно и то же количество виртуальных машин
Azure Site Recovery			Передислокация	Нет влияния на затраты для Site Recovery, умеренное увеличение затрат для хранилища реплик
База данных SQL Azure: уровень "Критически важный для бизнеса"			Включения	Без влияния на затраты
База данных SQL Azure: уровень общего назначения			Включения	Умеренное увеличение затрат
База данных SQL Azure: уровень гипермасштабирования			Передислокация	Минимальное количество реплик, необходимое
База данных SQL Azure: уровень "Премиум"			Включения	Без влияния на затраты
Управляемый экземпляр Azure SQL			Включения	Умеренное увеличение затрат
Хранилище таблиц Azure			Включения	Умеренное увеличение затрат
Масштабируемые наборы виртуальных машин Azure			Передислокация	Не влияет на затраты на одно и то же количество виртуальных машин
Виртуальные машины Azure			Передислокация	Не влияет на затраты на одно и то же количество виртуальных машин
Виртуальная сеть Azure			Всегда устойчива к зонам	N/A
Общедоступный IP-адрес			Всегда устойчивый к зонам	N/A

Связанные ресурсы

• Руководства по надежности Azure
• Службы Azure, поддерживающие зоны доступности
• Список регионов Azure