Надежность в Azure Среда службы приложений

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

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

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

Замечание

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

Среда обеспечивает следующие ключевые преимущества надежности:

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

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

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

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

Обзор архитектуры надежности

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

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

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

Чтобы использовать среду Среда службы приложений, ваши планы должны быть на уровне ценовой категории Isolated версии 2. Этот уровень поддерживает зональную избыточность и масштабируемые критически важные для бизнеса приложения.

Служба приложений предоставляет следующие функции избыточности:

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

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

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

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

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

Устойчивость к временным сбоям

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

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

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

  • Разверните несколько экземпляров в вашем плане. Служба приложений выполняет автоматические обновления и другие формы обслуживания в экземплярах вашего плана. Если экземпляр становится неработоспособным, служба может автоматически заменить этот экземпляр новым здоровым экземпляром. В процессе замены может быть короткий период, когда предыдущий экземпляр недоступен, и новый экземпляр не готов обслуживать трафик. Чтобы устранить эти последствия, разверните несколько экземпляров плана службы приложений.

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

  • Избегайте увеличения или уменьшения масштаба. Эти операции изменяют ЦП, память и другие ресурсы, назначенные каждому экземпляру, и они могут активировать перезапуск приложения. Вместо этого выберите уровень и размер экземпляра, которые соответствуют вашим требованиям к производительности при обычной загрузке. Для масштабирования вширь и вглубь динамически добавляйте и удаляйте экземпляры, чтобы обрабатывать изменения в объёмах трафика.

Устойчивость к сбоям зоны доступности

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

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

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

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

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

Требования

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

  • Region support: Чтобы узнать, какие регионы поддерживают зоны доступности для Среда службы приложений версии 3, см. статью Regions.

  • Тип плана: Используйте изолированные типы планов версии 2.

  • Минимальное количество экземпляров: Разверните как минимум два экземпляра в плане, чтобы он был избыточным по зонам.

    Незональные планы в вашей среде можно развернуть на одном экземпляре.

  • Единица масштабирования: Ваша среда должна быть развернута в единице масштабирования, поддерживающей зоны доступности. Вы не управляете единицей масштабирования, которую использует ваша среда. Вместо этого, при создании среды App Service, эта среда распределяется по масштабируемому блоку в зависимости от группы ресурсов среды. Чтобы определить, поддерживает ли единица масштабирования для Среда службы приложений зональную избыточность, проверьте поддержку зональной избыточности для Среда службы приложений.

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

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

Распределение экземпляров между зонами

При создании плана службы приложений (App Service plan) с избыточностью между зонами, Azure распределяет экземпляры плана по зонам доступности в данном регионе. Это распределение гарантирует, что ваши приложения остаются доступными, даже если одна зона испытывает сбой.

Распределение экземпляров в развертывании с избыточностью между зонами следует определенным правилам. Эти правила также применяются при масштабировании приложения как внутрь, так и наружу:

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

  • Максимальное количество зон доступности, поддерживаемых планом: Azure определяет количество зон доступности, которые может использовать ваш план, это называется maximumNumberOfZones. Чтобы просмотреть количество зон доступности, которые может использовать конкретный план, см. раздел "Проверка поддержки избыточности зоны" для плана службы приложений.

    Замечание

    Количество зон доступности, доступных вашему плану (maximumNumberOfZones), зависит от единицы масштабирования и региона. Зонально-избыточное развертывание всегда использует как минимум две зоны доступности и может использовать больше, в зависимости от ваших требований к масштабированию. Независимо от количества зон, зонально-избыточное развертывание обеспечивает устойчивость к сбою одной зоны и предлагает такое же соглашение об уровне обслуживания (SLA).

  • Распределение экземпляров: Если включена избыточность зоны, Azure автоматически распределяет экземпляры плана по нескольким зонам доступности. Распределение основано на следующих правилах:

    • Если число экземпляров превышает maximumNumberOfZones и делится без остатка, то Azure распределяет экземпляры равномерно между зонами.

    • Если количество экземпляров не разделяется равномерно, Azure распределяет оставшиеся экземпляры по оставшимся зонам.

    • Когда платформа службы приложений выделяет экземпляры для зоны-резервного плана службы приложений, она использует балансировку зоны на основе принципа наилучшего соответствия, которую предоставляют базовые масштабируемые наборы виртуальных машин Azure. План считается сбалансированным, если каждая зона имеет одинаковое количество виртуальных машин или если количество виртуальных машин в одной из зон отличается от количества в других зонах на один экземпляр. Дополнительные сведения см. в разделе "Балансировка зоны".

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

Соображения

  • Поведение вне времени выполнения: Сбой зоны доступности может повлиять на некоторые аспекты службы приложений, даже если приложение продолжает обслуживать трафик. К ним относятся масштабирование плана службы приложений, создание приложений, конфигурация приложений и публикация приложений.

  • Обновления платформы: При включении зональной избыточности в плане службы App Service также повышается надежность во время обновлений платформы. Дополнительные сведения см. в разделе "Устойчивость к обслуживанию службы".

Себестоимость

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

Если включить зоны доступности и указать вместимость менее двух, платформа устанавливает минимальное количество экземпляров равное двум. Платформа взымает плату за эти два случая.

Это важно

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

Плата зависит от SKU плана службы приложений, указанной емкости и всех экземпляров, масштабируемых на основе критериев автомасштабирования. Дополнительные сведения см. в статье Цены на Служба приложений Azure в Linux и Цены на Служба приложений Azure в Windows.

Настройка поддержки зоны доступности

Сведения о создании, включении или отключении новых планов службы приложений, избыточных между зонами и новых планах службы приложений, избыточных между зонами, см. в разделе Среда службы приложений Настройка сред службы приложений и изолированных планов службы приложений версии 2 для избыточности между зонами.

Замечание

Изменение статуса отказоустойчивости зоны в Среда службы приложений занимает от 12 до 24 часов. Во время процесса обновления не возникают проблемы со временем простоя или производительностью.

Планирование ресурсов и управление ими

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

Поведение, когда все зоны работоспособны

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

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

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

Поведение во время сбоя зоны

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

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

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

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

    Если автомасштабирование настроено и определяет, что требуется больше экземпляров, он запрашивает экземпляры из службы приложений. Поведение автомасштабирования работает независимо от поведения платформы службы приложений. Поэтому спецификация количества экземпляров не обязательно должна быть кратной двум. Дополнительные сведения см. в разделе "Масштабирование приложения" в службе приложений и обзор автомасштабирования.

    Это важно

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

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

Восстановление зоны

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

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

Служба приложений — это однорегиональная служба. Если регион становится недоступным, среда и ее планы и приложения также становятся недоступными.

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

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

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

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

Резервное копирование и восстановление

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

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

Это важно

Начиная с 31 марта 2028 года, в пользовательских резервных копиях Служба приложений Azure больше не будет поддерживаться резервное копирование связанных баз данных. См. Устаревание резервных копий связанных баз данных для получения дополнительной информации.

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

Устойчивость к обслуживанию служб

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

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

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

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

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе соглашения об уровнях обслуживания (SLA) для онлайн-сервисов.

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