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

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

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

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

Рекомендации по развертыванию в производственной среде

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

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

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

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

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

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

  Это важно

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

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

• Устойчивые функции: Устойчивые функции — это функции с отслеживанием состояния, включая длительные оркестрации и сущности с отслеживанием состояния.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования

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

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

  Американский континент	Европа	Ближний Восток	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.

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

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

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

Рекомендации

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

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

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

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

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

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

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

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

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

Cost

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Ожидаемая потеря данных: Считается, что сбои зоны не приводят к потере данных, так как Функции Azure — это бессостоячная служба.

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

  Для Durable Functions проверьте поставщика хранилища, чтобы определить, возможна ли потеря данных при отказе зоны.

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

• Перенаправка трафика: Функции Azure обнаруживают потерянные экземпляры из этой зоны и пытаются найти новые замещающие экземпляры. После нахождения замен Функции Azure распределяют трафик между новыми экземплярами по мере необходимости.

  Это важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Георепликация и геоизбыточное восстановление служебной шины Azure
• Георепликация и геоизбыточное восстановление Центров событий Azure

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

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

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

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

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

Сведения об аварийном восстановлении и геораспределении для Durable Functions см. в статье "Аварийное восстановление и геораспределение в Azure Durable Functions".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связанный контент

• Настройка зон доступности для Функций Azure
• Аварийное восстановление и геораспределение в Azure Durable Functions
• Создание Azure Front Door
• Особенности настройки отказоустойчивости Event Hubs
• Руководство центра архитектуры Azure по зонам доступности
• Надежность в Azure