Надежность в службе приложение Azure
В этой статье описывается поддержка надежности в службе приложение Azure и охватывает как внутрирегиональная устойчивость с зонами доступности, так и аварийное восстановление между регионами и непрерывность бизнес-процессов. Более подробный обзор принципов надежности в Azure см. в статье "Надежность Azure".
служба приложение Azure — это служба на основе HTTP для размещения веб-приложений, REST API и мобильных серверных серверов. Кроме того, в приложение добавляется мощность Microsoft Azure, например:
- Безопасность
- Балансировка нагрузки
- Автомасштабирование
- Автоматизированное управление
Чтобы узнать, как служба приложение Azure может повысить надежность и устойчивость рабочей нагрузки приложения, см. статью "Зачем использовать Служба приложений?"
Рекомендации по надежности
В этом разделе содержатся рекомендации по обеспечению устойчивости и доступности. Каждая рекомендация входит в одну из двух категорий:
Элементы работоспособности охватывают такие области, как элементы конфигурации и правильная функция основных компонентов, составляющих рабочую нагрузку Azure, такие как параметры конфигурации ресурсов Azure, зависимости от других служб и т. д.
Элементы риска охватывают такие области, как требования к доступности и восстановлению, тестирование, мониторинг, развертывание и другие элементы, которые, если остались неразрешенными, повышают вероятность проблем в среде.
Матрица приоритетов рекомендаций по надежности
Каждая рекомендация помечается в соответствии со следующей матрицей приоритетов:
| Изображения | Приоритет | Описание |
|---|---|---|
|
Высокая | Необходимо немедленное исправление. |
|
Средняя | Исправление в течение 3–6 месяцев. |
|
Низкая | Необходимо проверить. |
Сводка рекомендаций по надежности
Высокая доступность
ASP-1. Развертывание планов, избыточных между зонами Служба приложений
Чтобы повысить устойчивость и надежность критически важных для бизнеса рабочих нагрузок, рекомендуется развернуть новые Служба приложений Планы с избыточностью зоны. Выполните действия по повторному развертыванию в службе поддержки зоны доступности, настройте конвейеры для повторного развертывания WebApp в новом плане Служба приложений s, а затем используйте подход к развертыванию Blue-Green для отработки отказа на новый сайт.
Распространяя приложения в нескольких зонах доступности, вы можете обеспечить непрерывную работу даже в случае сбоя на уровне центра обработки данных. Дополнительные сведения о поддержке зон доступности в службе приложение Azure см. в разделе "Поддержка зоны доступности".
// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A
resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"
Устойчивость
ASP-2 . Использование плана Служба приложений, поддерживающего зоны доступности
Поддержка зоны доступности доступна только в определенных планах Служба приложений. Чтобы узнать, какой план требуется для использования зон доступности, см . предварительные требования для зоны доступности.
// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.
resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
tolower(sku_tier) !contains "premium" and
tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)
ASP-4. Создание отдельных планов Служба приложений для рабочей среды и тестирования
Чтобы повысить устойчивость и надежность критически важных для бизнеса рабочих нагрузок, необходимо перенести существующие планы Служба приложений и Среда службы приложений в поддержку зоны доступности. Распространяя приложения в нескольких зонах доступности, вы можете обеспечить непрерывную работу даже в случае сбоя на уровне центра обработки данных. Дополнительные сведения о поддержке зон доступности в службе приложение Azure см. в разделе "Поддержка зоны доступности".
Масштабируемость
ASP-3. Избегайте частого увеличения или уменьшения масштаба
Рекомендуется избежать частого увеличения или уменьшения масштаба экземпляров службы приложение Azure. Вместо этого выберите соответствующий уровень и размер экземпляра, которые могут обрабатывать типичную рабочую нагрузку, и масштабируйте экземпляры для изменения объема трафика. Масштабирование вверх или вниз может активировать перезапуск приложения, что может привести к сбоям службы.
ASP-5. Включение автоматического масштабирования или автоматического масштабирования, чтобы обеспечить доступность достаточных ресурсов для запросов на обслуживание
Рекомендуется включить автоматическое масштабирование или автоматическое масштабирование службы приложение Azure, чтобы обеспечить доступность достаточных ресурсов для обработки входящих запросов. Автомасштабирование — это масштабирование на основе правил, в то время как автоматическое масштабирование выполняет автоматическое масштабирование в зависимости от трафика HTTP. Дополнительные сведения см. в статье об автоматическом масштабировании в службе приложение Azure или начале работы с автомасштабированием в Azure.
// under-development
Поддержка зоны доступности
Зоны доступности Azure — это по крайней мере три физически отдельные группы центров обработки данных в каждом регионе Azure. Центры обработки данных в каждой зоне оснащены независимой питанием, охлаждения и сетевой инфраструктурой. В случае сбоя локальной зоны зоны зоны создаются таким образом, чтобы при возникновении влияния одной зоны, региональных служб, емкости и высокой доступности поддерживались остальными двумя зонами.
Сбои могут варьироваться от сбоев программного обеспечения и оборудования до таких событий, как землетрясения, наводнения и пожары. Устойчивость к сбоям достигается с избыточностью и логической изоляцией служб Azure. Дополнительные сведения о зонах доступности в Azure см. в разделе "Регионы и зоны доступности".
Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматическим реплика tion между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см. в Рекомендации использования зональных зон и регионов.
приложение Azure службу можно развернуть в зонах доступности (AZ), чтобы обеспечить устойчивость и надежность для критически важных для бизнеса рабочих нагрузок. Эта архитектура также называется избыточностью между зонами.
При настройке Служба приложений в качестве избыточной зоны платформа автоматически распределяет экземпляры плана обслуживания приложение Azure по трем зонам в выбранном регионе.
Распространение экземпляра с помощью развертывания, избыточного между зонами, определяется в следующих правилах, даже если приложение масштабируется и выходит:
- Минимальное число экземпляров плана Служба приложений составляет три.
- Если задана емкость больше, чем для трех зон, а число экземпляров можно разделить на три без остатка, экземпляры будут распределены по зонам равномерно.
- Все экземпляры, превышающие 3*N, распределяются по оставшимся одному или двум зонам.
Поддержка зоны доступности — это свойство плана Служба приложений. Служба приложений планы можно создавать в управляемой многотенантной среде или выделенной среде с помощью Среда службы приложений версии 3. Дополнительные сведения о Среда службы приложений версии 3 см. в Среда службы приложений обзоре версии 3.
Для Служба приложений, которые не настроены для избыточности между зонами, экземпляры виртуальных машин не являются устойчивыми к зонам и могут столкнуться с простоем во время простоя в любой зоне в этом регионе.
Сведения об архитектуре корпоративного развертывания см. в разделе "Высокий уровень доступности корпоративного развертывания" с помощью Среда службы приложений.
Необходимые компоненты
Текущие требования и ограничения для включения зон доступности:
Поддерживаются как Windows, так и Linux.
Зоны доступности поддерживаются только на более новых Служба приложений местах. Даже если вы используете один из поддерживаемых регионов, вы получите ошибку, если зоны доступности не поддерживаются для вашей группы ресурсов. Чтобы рабочие нагрузки приземлились на метку, поддерживающую зоны доступности, вам может потребоваться создать новую группу ресурсов, Служба приложений план и Служба приложений.
План Служба приложений должен быть одним из следующих планов, поддерживающих зоны доступности:
- В мультитенантной среде с помощью планов Служба приложений Premium версии 2 или Premium версии 3.
- В выделенной среде с помощью Среда службы приложений версии 3, которая используется с изолированными планами Служба приложений версии 2.
Для выделенных сред Среда службы приложений должен быть версии 3.
Внимание
Среда службы приложений версии 2 и версии 1 будут прекращены 31 августа 2024 года. Среда службы приложений версии 3 проще использовать и работать на более мощной инфраструктуре. Дополнительные сведения о Среда службы приложений версии 3 см. в Среда службы приложений обзоре. Если вы используете Среда службы приложений версии 2 или версии 1 и хотите обновить до версии 3, выполните действия, описанные в этой статье, чтобы перейти на новую версию.
Применяется минимальное количество экземпляров трех зон. Платформа будет применять это минимальное число в фоновом режиме, если вы укажете число экземпляров меньше трех.
Зоны доступности можно указать только при создании нового плана Служба приложений. Предварительно существующий план Служба приложений нельзя преобразовать в использование зон доступности.
Следующие регионы поддерживают службы приложение Azure, работающие в мультитенантных средах:
- Восточная Австралия
- Южная Бразилия
- Центральная Канада
- Центральная Индия
- Центральная часть США
- Восточная Азия
- Восточная часть США
- Восточная часть США 2
- Центральная Франция
- Центрально-Западная Германия
- Восточная Япония
- Республика Корея, центральный регион
- Северная Европа
- Восточная Норвегия;
- Центральная Польша
- Центральный Катар
- Северная часть ЮАР;
- Центрально-южная часть США
- Юго-Восточная Азия
- Центральная Швеция
- Северная Швейцария
- Северная часть ОАЭ;
- южная часть Соединенного Королевства
- Западная Европа
- западная часть США 2
- Западная часть США — 3
- Microsoft Azure, управляемый 21Vianet — Китай Северная 3
- Azure для государственных организаций - US Gov Вирджиния
Сведения о том, какие регионы поддерживают зоны доступности для Среда службы приложений версии 3, см. в разделе "Регионы".
Создание ресурса с включенной зоной доступности
Развертывание избыточного между зонами нескольких клиентов Служба приложений
Чтобы включить зоны доступности с помощью Azure CLI, включите --zone-redundant параметр при создании плана Служба приложений. Можно также включить параметр --number-of-workers, чтобы указать емкость. Если емкость не указана, для платформы будет по умолчанию задано значение 3. Значение емкости необходимо задать, исходя из требований рабочей нагрузки, но оно должно быть не менее 3. Общее правило выбора емкости заключается в обеспечении такого количества экземпляров для приложения, чтобы при потере одной зоны экземпляров оставалось достаточно емкости для обработки ожидаемой нагрузки.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Совет
Чтобы выбрать емкость экземпляра, можно использовать следующие вычисления:
Так как платформа распределяет виртуальные машины в трех зонах и необходимо учитывать сбой по крайней мере одной зоны, умножьте число экземпляров рабочей нагрузки на коэффициент зон/(зоны–1) или 3/2. Например, если типичная пиковая рабочая нагрузка требует наличия четырех экземпляров, следует подготовить шесть экземпляров: (2/3 * 6 экземпляров) = 4 экземпляра.
Развертывание избыточного между зонами Служба приложений с помощью выделенной среды
Сведения о создании Среда службы приложений версии 3 в плане изолированной версии 2 см. в статье "Создание Среда службы приложений".
Устранение неполадок
| Сообщение об ошибке | Description | Рекомендация |
|---|---|---|
| Избыточность зоны недоступна для группы ресурсов RG-NAME. Разверните план службы приложений ASP-NAME в новой группе ресурсов. | Зоны доступности поддерживаются только на более новых Служба приложений местах. Даже если вы используете один из поддерживаемых регионов, вы получите ошибку, если зоны доступности не поддерживаются для вашей группы ресурсов. | Чтобы рабочие нагрузки приземлились на метку, поддерживающую зоны доступности, создайте новую группу ресурсов, план Служба приложений и Служба приложений. |
Отказоустойчивость
Чтобы подготовиться к сбою зоны доступности, необходимо переоформить емкость службы, чтобы гарантировать, что решение может терпеть потерю емкости 1/3 и продолжать работать без снижения производительности во время сбоев на уровне зоны. Так как платформа распределяет виртуальные машины в трех зонах и необходимо учитывать сбой по крайней мере одной зоны, умножьте число экземпляров рабочей нагрузки на коэффициент зон/(зоны–1) или 3/2. Например, если типичная пиковая рабочая нагрузка требует наличия четырех экземпляров, следует подготовить шесть экземпляров: (2/3 * 6 экземпляров) = 4 экземпляра.
Взаимодействие с зонами вниз
Трафик направлен во все доступные экземпляры Службы приложений. При сбое зоны платформа Службы приложений обнаружит потерянные экземпляры и автоматически попытается найти новые экземпляры для замены и корректного распространения трафика. Если ваше автомасштабирование настроено и требует больше экземпляров, оно сделает соответствующий запрос в службе приложений. Обратите внимание, что поведение автомасштабирования не зависит от поведения платформы службы приложения и что спецификация числа экземпляров автомасштабирования необязательно будет кратна трем.
Примечание.
Нет никаких гарантий, что запросы на дополнительные экземпляры в сценарии зоны вниз будут успешными. Резервное заполнение потерянных экземпляров выполняется на основе лучших усилий. Рекомендуемое решение заключается в создании и настройке планов Служба приложений для учета потери зоны, как описано в следующем разделе.
Приложения, развернутые в плане Служба приложений с включенными зонами доступности, будут продолжать выполняться и обслуживать трафик, даже если другие зоны в том же регионе страдают от сбоя. Но сбой в других Зонах доступности может не повлиять и на действия, не относящиеся к среде выполнения, такие как масштабирование плана Службы приложений, а также создание, настройка и публикация приложений. Избыточность между зонами для планов службы приложений обеспечивает безотказную работу для развернутых приложений.
Платформа службы приложения использует зону наилучших усилий балансировки, предложенную набором масштабирования виртуальной машины Azure, когда распределяет экземпляры в план службы приложений избыточности между зонами. План службы приложений будет "сбалансирован", если в каждой зоне представлено одинаковое число виртуальных машин или если число виртуальных машин отличается на +/- 1 во всех других зонах, используемых планом службы приложений.
Миграция зоны доступности
Невозможно перенести существующие экземпляры Служба приложений или ресурсы среды из поддержки недоступной зоны в поддержку зоны доступности. Чтобы получить поддержку зон доступности, необходимо создать ресурсы с включенными зонами доступности.
Цены
Дополнительная плата за включение зон доступности не взимается. Цены для службы приложений с избыточностью между зонами аналогичны ценам на Службу приложений с одной зоной. Плата будет взиматься на основе номера SKU плана службы приложений, указанной емкости и всех экземпляров, для которых выполняется масштабирование, в зависимости от критериев автомасштабирования. Если включить зоны доступности, но указать для емкости значение меньше трех, платформа будет применять минимальное число экземпляров, равное трем, и взимать плату за эти три экземпляра. Сведения о ценах на Среда службы приложений версии 3 см. в разделе "Цены".
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с Рекомендации для разработки стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплика te данные или возвращаются из неудающегося региона, чтобы перекрестно реплика te в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
В этом разделе рассматриваются некоторые распространенные стратегии для веб-приложений, развернутых в Служба приложений.
При создании веб-приложения в Служба приложений и выборе региона Azure во время создания ресурса это однорегионное приложение. Когда регион становится недоступным во время аварии, приложение также становится недоступным. Если вы создаете идентичное развертывание в дополнительном регионе Azure с помощью архитектуры географического региона с несколькими регионами, приложение становится менее подверженным аварии в одном регионе, что гарантирует непрерывность бизнес-процессов. Любые данные реплика в регионах позволяют восстановить последнее состояние приложения.
Для ИТ-специалистов планы непрерывности бизнес-процессов в значительной степени зависят от целевой цели времени восстановления (RTO) и целевой точки восстановления (RPO). Дополнительные сведения о RTO и RPO см. в целях восстановления.
Как правило, обслуживание SLA вокруг RTO нецелесообразно для региональных бедствий, и вы обычно разрабатываете стратегию аварийного восстановления вокруг RPO только (т. е. сосредоточиться на восстановлении данных и не на минимизации прерываний). Однако с помощью Azure это не только практическая, но и может быть простой для развертывания Служба приложений для автоматической геоотработки отказа. Это позволяет еще больше подтвердить аварию приложений, заботясь о RTO и RPO.
В зависимости от требуемых метрик RTO и RPO, для мультитенантных и Служба приложений Среда службы приложений часто используются три архитектуры аварийного восстановления. Каждая архитектура описана в следующей таблице:
| Metric | Активный — активный | Активный-пассивный | Пассивный или холодный |
|---|---|---|---|
| RTO | Реальное время или секунды | Минуты | часов |
| RPO | Реальное время или секунды | Минуты | часов |
| Себестоимость | $$$ | $$ | $ |
| Сценарии | Критически важные приложения | Высокоприоритетные приложения | Приложения с низким приоритетом |
| Возможность обслуживания трафика пользователей в нескольких регионах | Да | Да/может быть | No |
| Развертывание кода | Предпочтительный конвейер CI/CD | Предпочтительный конвейер CI/CD | Резервное копирование и восстановление |
| Создание новых ресурсов Служба приложений во время простоя | Необязательное | Необязательное | Обязательное поле |
Примечание.
Приложение, скорее всего, зависит от других служб данных в Azure, таких как База данных SQL Azure и учетные записи служба хранилища Azure. Рекомендуется разработать стратегии аварийного восстановления для каждой из этих зависимых служб Azure. Сведения о База данных SQL см. в разделе "Активные геоза реплика" для База данных SQL Azure. Сведения о служба хранилища Azure см. в разделе служба хранилища Azure избыточности.
Аварийное восстановление в географическом регионе с несколькими регионами
Существует несколько способов реплика управлять контентом и конфигурацией веб-приложений в регионах Azure в архитектуре active-active или active-пассивной архитектуры, например с помощью резервного копирования и восстановления службы приложений. Однако резервное копирование и восстановление создают моментальные снимки на определенный момент времени и в конечном итоге приводят к проблемам с управлением версиями веб-приложений в разных регионах. См. следующую таблицу ниже, чтобы сравнить руководство по восстановлению спины и восстановления с руководством по восстановлению диастера.
Резервное копирование и восстановление и аварийное восстановление
| Платформа | Руководство по резервному копированию и восстановлению | Руководство по аварийному восстановлению |
|---|---|---|
| Веб-приложения службы приложений (Бесплатная и общая ценовая категория) |
Если у вас есть веб-приложения, развернутые на уровне "Бесплатный" или "Общий", требуется доступ к возможностям резервного копирования и восстановления для этих веб-приложений, масштабирование до уровня "Базовый" или "Выше". | Верните Служба приложений ресурсы в другой регион Azure во время региональной катастрофы. Начиная с 31 марта 2025 г. приложения Служба приложений не будут помещены в режим аварийного восстановления во время аварии в регионе Azure, как описано в статье о восстановлении после сбоя на уровне региона. Рекомендуется реализовать часто используемые методы аварийного восстановления для предотвращения простоя и потери данных во время региональной катастрофы. |
| Веб-приложения службы приложений (Ценовая категория "Базовый\Стандартный\Премиум") |
В службе приложение Azure можно выполнять пользовательские резервные копии по запросу или использовать автоматические резервные копии. Чтобы восстановить резервную копию, перезаписав существующее приложение, восстановите его в новом приложении или слоте. Дополнительные сведения см. в статье "Резервное копирование и восстановление приложения в службе приложение Azure". |
Текущее руководство по переносу ресурсов Служба приложений обратно в сеть в другом регионе Azure во время региональной аварии доступно при восстановлении после сбоя на уровне региона — приложение Azure служба. Начиная с 31 марта 2025 г. веб-приложения службы приложение Azure больше не будут помещены в режим аварийного восстановления во время аварии в регионе Azure, как описано в статье о восстановлении после сбоя на уровне региона. Мы рекомендуем реализовать часто используемые методы аварийного восстановления, чтобы предотвратить потерю функциональных возможностей или данных для веб-приложений в случае региональной аварии. |
| Среда службы приложений (V2 и V3) | В среде службы приложение Azure можно выполнять пользовательские резервные копии по запросу или использовать автоматические резервные копии. Автоматическое резервное копирование можно восстановить в целевом приложении в том же ASE, а не в другом ASE. Пользовательские резервные копии можно восстановить в целевом приложении в другом ASE (например, из ASE версии 2 до ASE версии 3). Резервные копии можно восстановить в целевое приложение той же платформы ОС, где находится исходное приложение. Дополнительные сведения см. в статье "Резервное копирование и восстановление приложения в службе приложение Azure". |
Мы рекомендуем реализовать рекомендации по аварийному восстановлению для веб-приложений, развернутых в Среда службы приложений с помощью часто используемых методов аварийного восстановления. |
| Функции Azure (выделенное) | В Функции Azure можно создавать пользовательские резервные копии по запросу или использовать автоматические резервные копии. Чтобы восстановить резервную копию, перезаписав существующее приложение, восстановите его в новом приложении или слоте. Дополнительные сведения см. в статье "Резервное копирование и восстановление приложения в службе приложение Azure". |
Текущее руководство по переносу ресурсов Функции Azure приложений (выделенных) в другой регион Azure во время региональной аварии доступно при восстановлении после сбоя на уровне региона — приложение Azure службе. Начиная с 31 марта 2025 г. приложения Служба приложений не будут помещены в режим аварийного восстановления во время аварии в регионе Azure, как описано в статье о восстановлении после сбоя на уровне региона. Вместо этого реализуйте Функции Azure геокадрового восстановления. Кроме того, вы также можете ссылаться на часто используемые методы аварийного восстановления для Функции Azure выделенных. |
| Функции Azure потребление и премиум | Функции Azure, развернутые в планах потребления и уровня "Премиум", не предоставляют доступ к пользовательским и автоматическим резервным копиям. Содержимое приложения-функции находится в учетной записи хранения Azure. Используйте параметры избыточности служба хранилища Azure, чтобы обеспечить соответствие учетной записи хранения целям доступности и устойчивости во время сбоя. Если вы создали функции с помощью редактора в портал Azure, вы также можете скачать существующий проект приложения-функции в виде файла .zip. |
Настоятельно рекомендуется реализовать Функции Azure геокадрового восстановления и надежности. |
Чтобы избежать ограничений методов резервного копирования и восстановления, настройте конвейеры CI/CD для развертывания кода в обоих регионах Azure. Рассмотрите возможность использования Azure Pipelines или GitHub Actions. Дополнительные сведения см. в статье "Непрерывное развертывание в службе приложение Azure".
Обнаружение сбоев, уведомление и управление
Рекомендуется настроить мониторинг и оповещения для веб-приложений для своевременного уведомления во время аварии. Дополнительные сведения см. в разделе "Тесты доступности приложений Аналитика".
Чтобы управлять ресурсами приложения в Azure, используйте механизм инфраструктуры как кода (IaC). В сложном развертывании в нескольких регионах управлять регионами независимо и поддерживать синхронизацию конфигурации между регионами в надежном режиме требует прогнозируемых, тестируемых и повторяемых процессов. Рассмотрим средство IaC, например шаблоны Azure Resource Manager или Terraform.
Настройка аварийного восстановления и обнаружения сбоев
Чтобы подготовиться к аварийному восстановлению в географическом регионе с несколькими регионами, можно использовать архитектуру active-active или active-пассивный.
Архитектура Active-Active
В архитектуре аварийного восстановления active идентичные веб-приложения развертываются в двух отдельных регионах, а Azure Front door используется для маршрутизации трафика в оба активных региона.
В этом примере архитектуры:
- Идентичные Служба приложений приложения развертываются в двух отдельных регионах, включая ценовую категорию и количество экземпляров.
- Общедоступный трафик непосредственно к приложениям Служба приложений блокируется.
- Azure Front Door используется для маршрутизации трафика в оба активных региона.
- Во время аварии один из регионов становится автономным, а Azure Front Door направляет трафик исключительно в регион, который остается в сети. RTO во время такой геоработки отказа почти нулю.
- Файлы приложений должны развертываться в обоих веб-приложениях с помощью решения CI/CD. Это гарантирует, что RPO практически равно нулю.
- Если приложение активно изменяет файловую систему, лучший способ свести к минимуму RPO — это только запись в подключенную общую папку служба хранилища Azure вместо записи непосредственно в общую папку веб-приложения /home content share. Затем используйте функции избыточности служба хранилища Azure (GZRS или GRS) для подключенной общей папки, которая имеет RPO около 15 минут.
Ниже приведены инструкции по созданию архитектуры active-active для веб-приложения в Служба приложений.
Создайте два плана Служба приложений в двух разных регионах Azure. Настройте два плана Служба приложений одинаково.
Создайте два экземпляра веб-приложения с одним в каждом плане Служба приложений.
Создайте профиль Azure Front Door с помощью:
- Конечная точка.
- Две группы источников, каждая из которых имеет приоритет 1. Равный приоритет сообщает Azure Front Door маршрутизировать трафик в оба региона одинаково (таким образом активный— активный).
- Маршрут.
Ограничить сетевой трафик веб-приложениями только из экземпляра Azure Front Door.
Настройте и настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.
Разверните код в обоих веб-приложениях с непрерывным развертыванием.
Руководство. Создание высокодоступного приложения с несколькими регионами в службе приложение Azure показывает, как настроить архитектуру с активным пассивным доступом. Те же действия с минимальными изменениями (задайте приоритет "1" для обоих источников в группе источников в Azure Front Door) предоставляют архитектуру active-active.
Архитектура "Активный-пассивный"
В этом подходе аварийного восстановления идентичные веб-приложения развертываются в двух отдельных регионах, а Azure Front door используется для маршрутизации трафика только в один регион (активный регион).
В этом примере архитектуры:
Идентичные Служба приложений приложения развертываются в двух отдельных регионах.
Общедоступный трафик непосредственно к приложениям Служба приложений блокируется.
Azure Front Door используется для маршрутизации трафика в основной регион.
Чтобы сэкономить затраты, вторичный Служба приложений план настроен на меньшее количество экземпляров и (или) находится в более низкой ценовой категории. Существует три возможных подхода:
Предпочтительный план вторичного Служба приложений имеет ту же ценовую категорию, что и основной, с тем же количеством экземпляров или меньше. Этот подход обеспечивает четность как в функциях, так и в размерах виртуальных машин для двух планов Служба приложений. RTO во время геоработки отказа зависит только от времени масштабирования экземпляров.
Менее предпочтительный план вторичного Служба приложений имеет тот же тип ценовой категории (например, PremiumV3), но меньший размер виртуальной машины с меньшими экземплярами. Например, основной регион может находиться на уровне P3V3, а дополнительный регион находится на уровне P1V3. Этот подход по-прежнему обеспечивает четность функций для двух планов Служба приложений, но отсутствие четности размера может потребовать ручного масштабирования, когда дополнительный регион становится активным регионом. RTO во время геоработки отказа зависит от времени масштабирования и масштабирования экземпляров.
Наименее предпочтительный план вторичного Служба приложений имеет другую ценовую категорию, чем первичные и меньшие экземпляры. Например, основной регион может находиться на уровне P3V3, а дополнительный регион находится на уровне S1. Убедитесь, что дополнительный Служба приложений план имеет все функции, необходимые приложению для выполнения. Различия в доступности функций между двумя могут привести к задержкам в восстановлении веб-приложения. RTO во время геоработки отказа зависит от времени масштабирования и масштабирования экземпляров.
Автомасштабирование настраивается в дополнительном регионе в случае, если активный регион становится неактивным. Рекомендуется использовать аналогичные правила автомасштабирования как в активных, так и пассивных регионах.
Во время аварии основной регион становится неактивным, а дополнительный регион начинает получать трафик и становится активным регионом.
После того как дополнительный регион станет активным, сетевая нагрузка активирует предварительно настроенные правила автомасштабирования для горизонтального масштабирования дополнительного веб-приложения.
Возможно, вам потребуется увеличить ценовую категорию для дополнительного региона вручную, если она еще не имеет необходимых функций для запуска в качестве активного региона. Например, для автомасштабирования требуется уровень "Стандартный" или более высокий.
Когда основной регион снова активен, Azure Front Door автоматически направляет трафик обратно в него, а архитектура возвращается к активно-пассивному, как и раньше.
Файлы приложений должны развертываться в обоих веб-приложениях с помощью решения CI/CD. Это гарантирует, что RPO практически равно нулю.
Если приложение активно изменяет файловую систему, лучший способ свести к минимуму RPO — это только запись в подключенную общую папку служба хранилища Azure вместо записи непосредственно в общую папку веб-приложения /home content share. Затем используйте функции избыточности служба хранилища Azure (GZRS или GRS) для подключенной общей папки, которая имеет RPO около 15 минут.
Ниже приведены шаги по созданию активно-пассивной архитектуры для веб-приложения в Служба приложений.
- Создайте два плана Служба приложений в двух разных регионах Azure. Дополнительный план Служба приложений может быть подготовлен с помощью одного из подходов, упоминание ранее.
- Настройте правила автомасштабирования для дополнительного плана Служба приложений, чтобы оно масштабируется до того же числа экземпляров, что и основной регион, когда основной регион становится неактивным.
- Создайте два экземпляра веб-приложения с одним в каждом плане Служба приложений.
- Создайте профиль Azure Front Door с помощью:
- Конечная точка.
- Группа источников с приоритетом 1 для основного региона.
- Вторая группа источников с приоритетом 2 для дополнительного региона. Разница в приоритете указывает Azure Front Door предпочитать основной регион, когда он находится в сети (таким образом активный-пассивный).
- Маршрут.
- Ограничить сетевой трафик веб-приложениями только из экземпляра Azure Front Door.
- Настройте и настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.
- Разверните код в обоих веб-приложениях с непрерывным развертыванием.
Руководство. Создание высокодоступного приложения с несколькими регионами в службе приложение Azure показывает, как настроить архитектуру с активным пассивным доступом.
Архитектура пассивного холода
Используйте пассивно-холодную архитектуру для создания и поддержания регулярных резервных копий веб-приложений в учетной записи служба хранилища Azure, расположенной в другом регионе.
В этом примере архитектуры:
Одно веб-приложение развертывается в одном регионе.
Веб-приложение регулярно выполняет резервное копирование в учетную запись служба хранилища Azure в том же регионе.
Межрегионное реплика от конфигурации избыточности данных в учетной записи хранения Azure зависит от конфигурации избыточности данных. Если это возможно, необходимо задать учетную запись служба хранилища Azure как GZRS. GZRS обеспечивает синхронную избыточность зоны в пределах региона и асинхронную в дополнительном регионе. Если GZRS недоступна, настройте учетную запись как GRS. Как GZRS, так и GRS имеют RPO около 15 минут.
Чтобы обеспечить получение резервных копий при недоступности основного региона учетной записи хранения, включите доступ только для чтения к дополнительному региону (что делает учетную запись хранения RA-GZRS или RA-GRS соответственно). Дополнительные сведения о проектировании приложений для использования геоизбыточности см. в статье "Использование геоизбыточности" для разработки высокодоступных приложений.
Во время аварии в регионе веб-приложения необходимо вручную развернуть все необходимые Служба приложений зависимые ресурсы с помощью резервных копий из учетной записи служба хранилища Azure, скорее всего, из дополнительного региона с доступом на чтение. RTO может быть в часах или днях.
Чтобы свести к минимуму RTO, настоятельно рекомендуется создать полный сборник схем, в которых описаны все шаги, необходимые для восстановления резервного копирования веб-приложения в другом регионе Azure.
Ниже приведены инструкции по созданию пассивного холодного региона для веб-приложения в Служба приложений.
Создайте учетную запись хранения Azure в том же регионе, что и веб-приложение. Выберите уровень производительности "Стандартный" и выберите избыточность в качестве геоизбыточного хранилища (GRS) или геоизбыточного хранилища (GZRS).
Включите RA-GRS или RA-GZRS (доступ на чтение для дополнительного региона).
Настройте настраиваемое резервное копирование для веб-приложения. Вы можете задать расписание для резервных копий веб-приложения, например почасово.
Убедитесь, что файлы резервного копирования веб-приложения можно получить вторичную область учетной записи хранения.
Совет
Помимо Azure Front Door, Azure предоставляет другие варианты балансировки нагрузки, такие как Диспетчер трафика Azure. Сравнение различных параметров см. в разделе "Параметры балансировки нагрузки" в Центре архитектуры Azure.
Аварийное восстановление в географическом регионе с одним регионом
Если в регионе веб-приложения нет хранилища GZRS или GRS или если вы находитесь в регионе Azure, который не является одной из региональных пар, вам потребуется использовать хранилище, избыточное между зонами (ZRS) или локально избыточное хранилище (LRS), чтобы создать аналогичную архитектуру. Например, можно вручную создать дополнительный регион для учетной записи хранения следующим образом:
Ниже приведены инструкции по созданию пассивного холодного региона без GRS и GZRS:
Создайте учетную запись хранения Azure в том же регионе веб-приложения. Выберите уровень производительности "Стандартный" и выберите избыточность как хранилище, избыточное между зонами (ZRS).
Настройте настраиваемое резервное копирование для веб-приложения. Вы можете задать расписание для резервных копий веб-приложения, например почасово.
Убедитесь, что файлы резервного копирования веб-приложения можно получить вторичную область учетной записи хранения.
Создайте вторую учетную запись хранения Azure в другом регионе. Выберите уровень производительности "Стандартный" и выберите избыточность как локально избыточное хранилище (LRS).
С помощью средства, например AzCopy, реплика te custom backup (ZIP, XML и log files) из основного региона в дополнительное хранилище. Например:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'С помощью модуля Runbook рабочего процесса PowerShell можно использовать служба автоматизации Azure для запуска скрипта реплика tion по расписанию. Убедитесь, что расписание реплика tion следует аналогичному расписанию резервных копий веб-приложения.