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

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

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

В этой статье описываются примеры сценариев настройки аварийного восстановления и геораспространения с помощью функции устойчивых функций Azure.

Предыстория

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

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

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

Общие рекомендации

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

• В этой статье предполагается, что вы используете поставщик службы хранилища Azure по умолчанию для хранения состояния среды выполнения устойчивых функций. Вы также можете настроить альтернативные поставщики хранилища, которые хранят состояние в другом месте, например в базе данных SQL Server. Для альтернативных поставщиков хранилища могут потребоваться различные стратегии аварийного восстановления и геораспространителя. Дополнительные сведения см. в разделе поставщиков хранилища устойчивых функций.
• Предлагаемая активная и пассивной конфигурация гарантирует, что клиент всегда может активировать новые оркестрации через HTTP. Однако если два приложения-функции совместно используют один и тот же концентратор задач в хранилище, некоторые фоновые транзакции хранилища можно распределять между приложениями. В результате этого распределения эта конфигурация может привести к добавленным затратам на исходящий трафик для дополнительного приложения-функции.
• Базовая учетная запись хранения и концентратор задач создаются в основном регионе. Приложения-функции используют эту учетную запись хранения и концентратор задач.
• Все приложения-функции, которые избыточно развернуты, должны совместно использовать одни и те же ключи доступа к функциям при активации через HTTP. Среда выполнения Функций Azure предоставляет API управления , который можно использовать для программного добавления, удаления и обновления ключей функций. Вы также можете управлять ключами с помощью API Azure Resource Manager.

Сценарий 1. Балансировка нагрузки вычислений с общим хранилищем

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

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

Существует несколько преимуществ для использования этого сценария развертывания:

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

Рекомендации по сценарию

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

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

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

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

• Этот сценарий зависит от диспетчера трафика. Клиентское приложение может занять некоторое время, прежде чем снова запросить адрес приложения-функции из диспетчера трафика. Дополнительные сведения см. в статье о работе диспетчера трафика.

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

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

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

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

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

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

Этот подход добавляет улучшения в предыдущий сценарий:

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

Рекомендации по сценарию

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

Сценарий 3. Балансировка нагрузки вычислений с общими GRS

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

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

• Геоизбыточное хранилище (GRS) и GRS (RA-GRS) обеспечивает максимальную доступность для учетной записи хранения.
• Если в службе хранилища Azure произошел региональный сбой, можно вручную инициировать отработку отказа на вторичную реплику. В чрезвычайных обстоятельствах, когда регион теряется из-за аварии, корпорация Майкрософт может инициировать региональную отработку отказа. В этом случае вам не нужно предпринимать никаких действий.
• Когда происходит отработка отказа, состояние устойчивых функций сохраняется до последней репликации учетной записи хранения. Репликация обычно выполняется каждые несколько минут.

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

Рекомендации по сценарию

• Отработка отказа на реплику может занять некоторое время. До завершения отработки отказа и обновления записей DNS службы хранилища Azure приложение-функция продолжает оставаться недоступным.
• Существует повышенная стоимость использования геореплицированных учетных записей хранения.
• Репликация GRS копирует данные асинхронно. Некоторые из последних транзакций могут быть потеряны из-за задержки процесса репликации.
• Как описано в первом сценарии, рекомендуется использовать приложения-функции, развернутые в этой стратегии, версию 2.3.0 или более позднюю версию расширения Устойчивых функций.

Следующий шаг