Надежность Функций Azure

Функции Azure — это служба вычислений на основе событий, которая выполняет небольшие блоки кода или functions без явной подготовки инфраструктуры или управления ими. Функции могут реагировать на такие события, как HTTP-запросы, таймеры, сообщения очереди и изменения в других службах Azure. Эта возможность делает функцию хорошо подходящей для обработки данных, системной интеграции и выполнения фоновых задач.

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

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

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

При развертывании функций важно ознакомиться с этими понятиями:

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

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

Это важно

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

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

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

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

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

Рассмотрим следующие рекомендации по обработке временных сбоев в функциональных приложениях:

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

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

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

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

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

Планы потребления не поддерживают зоны доступности. Если зональная избыточность является требованием для вашей рабочей нагрузки, следует рассмотреть использование планов Flex Consumption, Premium или Dedicated (Служба приложений Azure).

Планы потребления Flex поддерживают развертывания с избыточностью по зонам.

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

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

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

Схема, показывающая план функций с резервированием по зонам, который включает три экземпляра, распределенных по трем зонам, и учетную запись с ZRS.

План выделенного (App Service), поддерживает зонально-резервные развертывания. Если включена избыточность зон, платформа автоматически распределяет ваши экземпляры по всем зонам доступности в выбранном регионе. Вы настраиваете избыточность зоны в плане. Дополнительные сведения о том, как Служба приложений Azure обрабатывает отказоустойчивость зоны, см. в разделе Надежность в службе приложений.

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

Требования

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

Поддержка регионов: Вы можете развернуть зонально-избыточные планы Premium в следующих регионах.

Американский континент	Европа	Ближний Восток	Africa	Asia Pacific
Бразилия (Юг)	Центральная Франция	Israel Central	Север Южной Африки	Australia East
Canada Central	Западно-Центральная Германия	Qatar Central		Центральная Индия
Central US	Italy North	UAE North		Северный Китай 3
East US	North Europe			East Asia
Восток США 2	Norway East			Japan East
Южно-Центральная часть США	Центральная Швеция			Юго-Восточная Азия
Западная часть США 2	Switzerland North
Западная часть США 3	UK South
	West Europe

Операционные системы: Платформа поддерживает развертывание планов с зональной избыточностью для Windows и Linux.
Минимальное число экземпляров: Для планов уровня "Премиум" требуется не менее двух экземпляров, всегда готовых к работе, с зональной избыточностью.

Учетная запись хранения узла: Необходимо настроить учетную запись хранения узла приложения-функции по умолчанию для использования ZRS. Если вы используете учетную запись хранения хоста, которая не настроена для ZRS, ваше приложение может работать непредсказуемо в случае отказа зоны.

Учетная запись хранения контейнера развертывания: Если вы используете отдельную учетную запись хранения для контейнера развертывания приложения, также обновите ее, чтобы она была зонально-избыточной.

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

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

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

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

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

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

При выделении экземпляров в план Premium с зональной избыточностью используется балансировка зон "best-effort", которую предоставляют базовые наборы масштабирования виртуальных машин Azure. Azure рассматривает план уровня "Премиум" сбалансированным, если в каждой зоне такое же количество виртуальных машин (ВМ), как и в других зонах плана, плюс или минус одна ВМ.

Cost

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

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

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

Полные сведения о ценах см. в разделе "Цены на функции".

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

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

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

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

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

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

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

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

Операция между зонами: При настройке избыточности зоны в Функциях запросы автоматически распределяются по экземплярам в каждой зоне доступности. Запрос может перейти к любому экземпляру в любой зоне доступности.
Репликация данных между зонами: Функции — это служба вычислений без отслеживания состояния, поэтому нет данных для репликации между зонами. Платформа автоматически реплицирует конфигурацию между зонами.

Если учетная запись хранения хоста использует ZRS, служба хранилища Azure синхронно реплицирует данные между несколькими зонами доступности.

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

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

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

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

Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать Azure Работоспособность ресурсов для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах. Вы также можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

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

Если учетная запись хранилища узла использует ZRS, хранилище гарантирует отсутствие потери данных в случае отказа зоны.

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

Это важно

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

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

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

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

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

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

Служба «Функции» является однораионной. Если регион становится недоступным, ресурс "Функции" также недоступен.

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

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

Вы несете ответственность за:

Развертывание приложений-функций в нескольких регионах.
Управление распределением трафика между регионами.
Реализация механизмов отказоустойчивости.
Обеспечение согласованности данных между регионами (если применимо).
Мониторинг развертываний между регионами и управление ими.

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

Шаблон "Активный— активный" для функций триггера HTTP

В шаблоне "активный—активный" функции в обоих регионах активно выполняются и обрабатывают события либо в дублирующемся режиме, либо по очереди. Используйте шаблон active-active в сочетании с Azure Front Door для критически важных функций, запускаемых по HTTP, которые могут маршрутизировать HTTP-запросы и распределять их по принципу round-robin между функциями, выполняющимися в нескольких регионах. Azure Front Door также может периодически проверять работоспособность каждой конечной точки. Если функция в одном регионе перестает отвечать на проверки работоспособности, Azure Front Door удаляет ее из списка распределения и перенаправляет трафик только на оставшиеся работоспособные функции.

Диаграмма с примером архитектуры active-active. Azure Front Door маршрутизирует между функциональными приложениями в разных регионах, у каждого из которых есть собственная база данных.

Активный пассивный шаблон для функций триггеров, отличных от HTTP

Для функций, управляемых событиями, не активированных по протоколу HTTP (например, триггеров Служебная шина Azure и Центры событий Azure), используйте шаблон "активный-пассивный". В активно-пассивном шаблоне экземпляры функций выполняются в регионе, который получает события, а экземпляры в дополнительном регионе остаются бездействующими. Этот шаблон гарантирует, что только одна функция обрабатывает каждое сообщение, что помогает поддерживать согласованность данных. Он также предоставляет способ переключения на вторичный регион во время аварийных ситуаций, таких как сбой региона.

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

Рассмотрим пример топологии, которая использует триггер Центров событий Event Hubs, где пространство имен настроено для геоаварийного восстановления. В этом случае для активно-пассивного шаблона требуются следующие компоненты:

Пространства имен Event Hubs развернуты в основном и резервном регионах.
Включено гео-дизастерное восстановление для парного соединения основных и вторичных хабов событий. Эта конфигурация также создает псевдоним , который можно использовать для подключения к пространству имен Центров событий и переключения псевдонима с первичного на дополнительный, не изменяя сведения о подключении.
Приложения-функции, развернутые как в основном, так и во вторичном регионе. Приложение в дополнительном регионе остается неактивным, так как оно не получает сообщения.
Триггеры каждого приложения-функции используют direct (nonalias) строка подключения для соответствующего пространства имен Центров событий.
Издатели в пространстве имен Центров событий публикуют в строку подключения с псевдонимом.

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

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

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

Устойчивые функции

Сведения о восстановлении после нескольких региональных катастроф для Durable Functions см. в разделе Восстановление после катастроф и геораспределение в Durable Functions Azure.

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

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

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

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

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

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

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

Устойчивость к развертываниям приложений

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

Планы потребления Flex поддерживают стратегии обновления сайта, которые предоставляют несколько способов развертывания обновлений приложения. Эти стратегии включают последовательное обновление для развертываний без простоя.

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

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

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

Функции предоставляют отдельные соглашения об уровне обслуживания для плана потребления и для других типов планов.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-04-28