Надежность в службе приложение Azure
В этой статье описывается поддержка надежности в службе приложение Azure и охватывает как внутрирегиональная устойчивость с зонами доступности, так и аварийное восстановление между регионами и непрерывность бизнес-процессов. Более подробный обзор принципов надежности в Azure см. в статье "Надежность Azure".
служба приложение Azure — это служба на основе HTTP для размещения веб-приложений, REST API и мобильных серверных серверов. Кроме того, в приложение добавляется мощность Microsoft Azure, например:
- Безопасность
- Балансировка нагрузки
- Автомасштабирование
- Автоматизированное управление
Чтобы узнать, как служба приложение Azure может повысить надежность и устойчивость рабочей нагрузки приложения, см. статью "Зачем использовать Служба приложений?"
Поддержка зоны доступности
Зоны доступности Azure — это по крайней мере три физически отдельные группы центров обработки данных в каждом регионе Azure. Центры обработки данных в каждой зоне оснащены независимой питанием, охлаждения и сетевой инфраструктурой. В случае сбоя локальной зоны зоны зоны создаются таким образом, чтобы при возникновении влияния одной зоны, региональных служб, емкости и высокой доступности поддерживались остальными двумя зонами.
Сбои могут варьироваться от сбоев программного обеспечения и оборудования до таких событий, как землетрясения, наводнения и пожары. Устойчивость к сбоям достигается с избыточностью и логической изоляцией служб Azure. Дополнительные сведения о зонах доступности в Azure см. в разделе "Регионы и зоны доступности".
Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматической репликацией между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см . в рекомендациях по использованию зональных зон и регионов.
приложение 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 во всех других зонах, используемых планом службы приложений.
Миграция зоны доступности
Невозможно перенести существующие экземпляры Служба приложений или ресурсы среды из поддержки недоступной зоны в поддержку зоны доступности. Чтобы получить поддержку зон доступности, необходимо создать ресурсы с включенными зонами доступности.
Цены
Для сред с несколькими клиентами с помощью планов Служба приложений Premium версии 2 или Premium версии 3 нет дополнительных затрат, связанных с включением зон доступности, если в вашем плане Служба приложений есть три или более экземпляров. Плата будет взиматься на основе номера SKU плана службы приложений, указанной емкости и всех экземпляров, для которых выполняется масштабирование, в зависимости от критериев автомасштабирования. Если включить зоны доступности, но указать для емкости значение меньше трех, платформа будет применять минимальное число экземпляров, равное трем, и взимать плату за эти три экземпляра. Среда службы приложений версии 3 имеет другую модель ценообразования для зон доступности. Сведения о ценах на Среда службы приложений версии 3 см. в разделе "Цены".
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с рекомендациями по разработке стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплицируют данные или не реплицируются из неудающегося региона для перекрестной репликации в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
В этом разделе рассматриваются некоторые распространенные стратегии для веб-приложений, развернутых в Служба приложений.
При создании веб-приложения в Служба приложений и выборе региона Azure во время создания ресурса это однорегионное приложение. Когда регион становится недоступным во время аварии, приложение также становится недоступным. Если вы создаете идентичное развертывание в дополнительном регионе Azure с помощью архитектуры географического региона с несколькими регионами, приложение становится менее подверженным аварии в одном регионе, что гарантирует непрерывность бизнес-процессов. Любая репликация данных в регионах позволяет восстановить последнее состояние приложения.
Для ИТ-специалистов планы непрерывности бизнес-процессов в значительной степени зависят от целевой цели времени восстановления (RTO) и целевой точки восстановления (RPO). Дополнительные сведения о RTO и RPO см. в целях восстановления.
Как правило, обслуживание SLA вокруг RTO нецелесообразно для региональных бедствий, и вы обычно разрабатываете стратегию аварийного восстановления вокруг RPO только (т. е. сосредоточиться на восстановлении данных и не на минимизации прерываний). Однако с помощью Azure это не только практическая, но и может быть простой для развертывания Служба приложений для автоматической геоотработки отказа. Это позволяет еще больше подтвердить аварию приложений, заботясь о RTO и RPO.
В зависимости от требуемых метрик RTO и RPO, для мультитенантных и Служба приложений Среда службы приложений часто используются три архитектуры аварийного восстановления. Каждая архитектура описана в следующей таблице:
| Метрика | Активный — активный | Активный-пассивный | Пассивный или холодный |
|---|---|---|---|
| RTO | Реальное время или секунды | Минуты | часов |
| RPO | Реальное время или секунды | Минуты | часов |
| Себестоимость | $$$ | $$ | $ |
| Сценарии | Критически важные приложения | Высокоприоритетные приложения | Приложения с низким приоритетом |
| Возможность обслуживания трафика пользователей в нескольких регионах | Да | Да/может быть | No |
| Развертывание кода | Предпочтительный конвейер CI/CD | Предпочтительный конвейер CI/CD | Резервное копирование и восстановление |
| Создание новых ресурсов Служба приложений во время простоя | Необязательное | Необязательное | Обязательное поле |
Примечание.
Приложение, скорее всего, зависит от других служб данных в Azure, таких как База данных SQL Azure и учетные записи служба хранилища Azure. Рекомендуется разработать стратегии аварийного восстановления для каждой из этих зависимых служб Azure. Сведения о База данных SQL см. в разделе "Активная георепликация" для База данных SQL Azure. Сведения о служба хранилища Azure см. в разделе служба хранилища Azure избыточности.
Аварийное восстановление в географическом регионе с несколькими регионами
Существует несколько способов репликации содержимого и конфигураций веб-приложений в регионах Azure в активно-активной или пассивной архитектуре, например с помощью резервного копирования и восстановления службы приложений. Однако резервное копирование и восстановление создают моментальные снимки на определенный момент времени и в конечном итоге приводят к проблемам с управлением версиями веб-приложений в разных регионах. См. следующую таблицу ниже, чтобы сравнить руководство по восстановлению спины и восстановления с руководством по восстановлению диастера.
Резервное копирование и восстановление и аварийное восстановление
| Платформа | Руководство по резервному копированию и восстановлению | Руководство по аварийному восстановлению |
|---|---|---|
| веб-приложения Служба приложений (Бесплатные и общие ценовые категории) |
Если у вас есть веб-приложения, развернутые на уровне "Бесплатный" или "Общий", требуется доступ к возможностям резервного копирования и восстановления для этих веб-приложений, масштабирование до уровня "Базовый" или "Выше". | Верните Служба приложений ресурсы в другой регион Azure во время региональной катастрофы. Начиная с 31 марта 2025 г. приложения Служба приложений не будут помещены в режим аварийного восстановления во время аварии в регионе Azure, как описано в статье о восстановлении после сбоя на уровне региона. Рекомендуется реализовать часто используемые методы аварийного восстановления для предотвращения простоя и потери данных во время региональной аварии. |
| веб-приложения Служба приложений (Ценовые категории "Базовый", "Стандартный" и "Премиум") |
В службе приложение Azure можно выполнять пользовательские резервные копии по запросу или использовать автоматические резервные копии. Вы можете восстановить резервную копию, перезаписав существующее приложение или выполнив восстановление в новом приложении или слоте. Дополнительные сведения см. в статье "Резервное копирование и восстановление приложения в службе приложение Azure". |
Текущее руководство по переносу ресурсов Служба приложений обратно в сеть в другом регионе Azure во время региональной аварии доступно при восстановлении после сбоя на уровне региона — приложение Azure служба. Начиная с 31 марта 2025 г. веб-приложения службы приложение Azure больше не будут помещены в режим аварийного восстановления во время аварии в регионе Azure, как описано в статье о восстановлении после сбоя на уровне региона. Мы рекомендуем реализовать часто используемые методы аварийного восстановления, чтобы предотвратить потерю функциональных возможностей или данных для веб-приложений в случае региональной аварии. |
| Среда службы приложений (V2 и V3) | В среде службы приложение Azure можно создавать пользовательские резервные копии по запросу или использовать автоматические резервные копии. Автоматическое резервное копирование можно восстановить в целевом приложении в том же Среда службы приложений, а не в другом Среда службы приложений. Пользовательские резервные копии можно восстановить в целевом приложении в другом Среда службы приложений (например, из версии 2 Среда службы приложений на Среда службы приложений версии 3). Резервные копии можно восстановить в целевом приложении той же платформы ОС, что и исходное приложение. Дополнительные сведения см. в статье "Резервное копирование и восстановление приложения в службе приложение Azure". |
Мы рекомендуем реализовать рекомендации по аварийному восстановлению для веб-приложений, развернутых в Среда службы приложений с помощью часто используемых методов аварийного восстановления. |
| Функции Azure. План ценовой категории "Выделенный" |
При запуске приложения-функции в плане выделенного (Служба приложений) необходимое содержимое приложения-функции поддерживается с помощью встроенного хранилища. В выделенном плане можно создавать пользовательские резервные копии по запросу или использовать автоматические резервные копии. Вы можете восстановить резервную копию, перезаписав существующее приложение или выполнив восстановление в новом приложении или слоте. Дополнительные сведения см. в статье "Резервное копирование и восстановление приложения в службе приложение Azure". Файлы Azure не используется выделенным планом, но если вы неправильно настроили приложение с подключением Файлы Azure, резервное копирование не поддерживается. |
Текущее руководство по переносу ресурсов приложения-функции в выделенный план обратно в сети в другом регионе Azure во время региональной аварии доступно при восстановлении после сбоя на уровне региона — приложение Azure службе. Начиная с 31 марта 2025 г. приложения Служба приложений не будут помещены в режим аварийного восстановления во время аварии в регионе Azure, как описано в статье о восстановлении после сбоя на уровне региона. Вместо этого следует планировать надежность в приложениях-функциях. Вы также можете ссылаться на часто используемые методы аварийного восстановления для приложений-функций в выделенном плане. |
| Функции Azure. Использование Flex, Планы потребления и уровня "Премиум" |
Приложения-функции, которые выполняются в плане потребления Flex, в плане потребления или в плане "Премиум" не могут использовать пользовательские или автоматические функции резервного копирования в Служба приложений. В этих динамических планах масштабирования содержимое приложения-функции сохраняется в служба хранилища Azure. Используйте параметры избыточности служба хранилища Azure, чтобы обеспечить соответствие учетной записи хранения целям доступности и устойчивости во время сбоя. Вы также можете скачать существующий проект приложения-функции в виде файла .zip из портал Azure. |
Мы настоятельно рекомендуем планировать надежность в приложениях-функциях. |
Чтобы избежать ограничений методов резервного копирования и восстановления, настройте конвейеры CI/CD для развертывания кода в обоих регионах Azure. Рассмотрите возможность использования Azure Pipelines или GitHub Actions. Дополнительные сведения см. в статье "Непрерывное развертывание в службе приложение Azure".
Обнаружение сбоев, уведомление и управление
Рекомендуется настроить мониторинг и оповещения для веб-приложений для своевременного уведомления во время аварии. Дополнительные сведения см. в разделе "Тесты доступности Application Insights".
Чтобы управлять ресурсами приложения в 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, реплицируйте настраиваемое резервное копирование (ZIP, XML-файлы и файлы журналов) из основного региона в дополнительное хранилище. Например:
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>'Вы можете использовать служба автоматизации Azure с runbook рабочего процесса PowerShell для запуска скрипта репликации по расписанию. Убедитесь, что расписание репликации соответствует аналогичному расписанию резервных копий веб-приложения.