Поделиться через


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

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

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

План размещения Уровень поддержки Дополнительные сведения...
План потребления Flex Генеральная Ассамблея Выберите Flex Consumption в верхней части этой статьи.
План Elastic Premium Генеральная Ассамблея Выберите "Премиум" в верхней части этой статьи.
План категории "Выделенный" (Служба приложений) Генеральная Ассамблея См. статью "Надежность" в Службе приложений Azure.
План потребления n/a Не поддерживается планом потребления.

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

Функции Azure поддерживает избыточное между зонами развертывание.

Поддержка зон доступности

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

Если избыточность зоны включена в рамках плана 'Flex Consumption', распределение экземпляров определяется согласно следующим правилам:

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

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

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

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

Внимание

Функции Azure могут выполняться на платформе Службы приложений Azure. На платформе службы приложений планы, которые размещают приложения-функции плана Premium, называются планами Elastic Premium с именами SKU, такими как EP1. Если вы решили запустить приложение-функцию в плане Premium, обязательно создайте план с именем SKU, начинающимся с E, например EP1. Имена SKU планов службы приложений, которые начинаются с P, например P1V2 (план "Премиум V2 Малый"), являются выделенными планами размещения. Так как они выделены, а не Elastic Premium, планы с именами SKU, начиная с P динамического масштабирования и могут увеличить затраты.

Доступность в регионах

В настоящее время не все регионы поддерживают резервирование зон для планов Flex Consumption. Azure CLI можно использовать для просмотра регионов, которые поддерживают его:

  1. Если это еще не сделано, установите и войдите в Azure с помощью Azure CLI:

    az login
    

    Команда az login входит в вашу учетную запись Azure.

  2. Используйте эту az functionapp list-flexconsumption-locations команду с параметром --zone-redundant=true, чтобы вернуть список регионов, которые в настоящее время поддерживают зонально избыточные планы гибкого потребления.

    az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table
    

При создании приложения Flex Consumption на портале Zone redundancy Azure раздел страницы "Основы " включен, когда выбранный регион поддерживает его.

В следующих регионах доступны зонально избыточные тарифы Premium:

Северная и Южная Америка Европа Ближний Восток Африка Азиатско-Тихоокеанский регион
Бразилия (Юг) Центральная Франция Израиль, центральный регион Северная часть ЮАР Восточная Австралия
Центральная Канада Центрально-Западная Германия Центральный Катар Центральная Индия
Центральная часть США Северная Италия Северная часть ОАЭ; Северный Китай 3
Восточная часть США Северная Европа Восточная Азия
восточная часть США 2 Восточная Норвегия; Восточная Япония
Центрально-южная часть США Центральная Швеция Юго-Восточная Азия
западная часть США 2 Северная Швейцария
Западная часть США — 3 южная часть Соединенного Королевства
Западная Европа

Необходимые компоненты

Поддержка зоны доступности (availability zone) — это свойство плана Flex Consumption. Ниже приведены рекомендации по использованию зон доступности.

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

  • Включить зоны доступности в плане можно только при создании приложения. Вы не можете преобразовать существующий план "Премиум" для использования зон доступности.
  • Для учетной записи хранения по умолчанию вашего приложения-функции необходимо использовать учетную запись хранения с зональной избыточностью (ZRS). Если вы используете другую учетную запись хранения, приложение может вести себя неожиданно во время зонального сбоя.
  • Поддерживаются как Windows, так и Linux.
  • Приложения-функции, размещенные в плане Premium, должны иметь не менее двух постоянно готовых экземпляров.
  • Платформа автоматически обеспечивает это минимальное количество экземпляров, если вы указываете число экземпляров меньше двух.
  • Если вы не используете план "Премиум" или единицу масштабирования с поддержкой зон доступности, находитесь в неподдерживаемом регионе или не знаете, что нужно делать, см. руководство по миграции.

Цены

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

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

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

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

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

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

  2. В портал Azure перейдите на страницу создания приложения-функции. Дополнительные сведения о создании приложения-функции на портале см. в статье "Создание приложения-функции".

  3. Выберите Flex Consumption и нажмите кнопку "Выбрать ".

  4. На странице "Создание приложения-функции (потребление Flex)" на вкладке "Основы" введите параметры для вашего приложения-функции. Обратите особое внимание на параметры в следующей таблице (также выделены на следующем снимке экрана), которые имеют конкретные требования к избыточности зоны.

    Параметр Предлагаемое значение Заметки о избыточности зоны
    Регион Предпочитаемый регион Регион, в котором создается план потребления Flex. Необходимо выбрать регион, поддерживающий зоны доступности. См. список доступности региона.
    Избыточность зоны Включен Этот параметр указывает, является ли приложение избыточным по зонам. Вы можете выбрать Enabled только после того, как выбрали регион, который поддерживает зональную избыточность.

    Снимок экрана: вкладка

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

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

После создания и развертывания резервного плана между зонами, приложение Flex Consumption, размещенное на вашем новом плане, считается резервным между зонами.

Обновление плана потребления Flex для избыточности между зонами

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

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

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

  1. Ознакомьтесь с рекомендациями по хранению.
  2. Создайте или определите зонально избыточную учетную запись хранения, которая будет учетной записью хранилища по умолчанию для размещения приложения.
  3. Обновите настройки приложения, связанные с хранилищем, например AzureWebJobsStorage, чтобы ссылаться на зонально-избыточную учетную запись хранения. См. статью "Работа с параметрами приложения".
  4. Обновите учетную запись хранения развертывания для приложения. Эта учетная запись может быть той же самой, что и учетная запись хранения, связанная с приложением, или отличаться от нее. См. раздел "Настройка параметров развертывания".

После обновления учетных записей хранилищ, используемых вашим приложением, вы можете обновить план Flex Consumption для обеспечения зональной избыточности, используя шаблоны Bicep или ARM. В настоящее время портал Azure не поддерживает внесение обновлений по зональной избыточности в план.

  1. На портале Azure найдите и выберите приложение-функцию для обновления.

  2. В разделе "Параметры" выберите "Масштаб и параллелизм".

  3. На вкладке "Избыточность зоны " установите флажок "Добавить избыточность зоны ", чтобы включить эту функцию. Если этот флажок уже установлен, этот флажок можно снять, чтобы отключить эту функцию.

  4. Нажмите кнопку "Сохранить", чтобы зафиксировать изменения и перезапустить приложение.

Снимок экрана: вкладка

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

  1. В портал Azure перейдите на страницу создания приложения-функции. Дополнительные сведения о создании приложения-функции на портале см. в статье "Создание приложения-функции".

  2. Выберите "Функции "Премиум" и нажмите кнопку "Выбрать ".

  3. На странице "Создание приложения-функции "Премиум" на вкладке "Основные сведения" введите параметры приложения-функции. Обратите особое внимание на параметры в следующей таблице (также выделены на следующем снимке экрана), которые имеют конкретные требования к избыточности зоны.

    Параметр Предлагаемое значение Заметки о избыточности зоны
    Регион Предпочитаемый регион Регион, в котором создается план Elastic Premium. Необходимо выбрать регион, поддерживающий зоны доступности. См. список доступности региона.
    Тарифный план Один из планов Elastic Premium. Дополнительные сведения см. в разделе "Доступные номера SKU экземпляра". В этой статье описывается, как создать избыточное между зонами приложение в плане Premium. Избыточность между зонами в настоящее время недоступна в планах категории "Потребление". Сведения о избыточности зон в планах Служба приложений см. в разделе "Надежность" в службе приложение Azure.
    Избыточность зоны Включен Этот параметр указывает, является ли приложение избыточным по зонам. Вы не сможете выбрать Enabled , если вы не выбрали регион, поддерживающий избыточность зоны, как описано ранее.

    Снимок экрана: вкладка

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

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

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

Миграция зоны доступности

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

Взаимодействие с зонами вниз

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

  • Масштабирование
  • Создание приложения
  • Изменения конфигурации
  • Развертывания

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

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

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

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

Аварийное восстановление между регионами и непрерывность бизнес-процессов

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

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

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

Сведения о аварийном восстановлении для Устойчивые функции см. в статье "Аварийное восстановление" и геораспространителя в Azure Устойчивые функции.

Аварийное восстановление в нескольких регионах

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

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

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

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

Архитектура для Azure Front Door и Функции Azure

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

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

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

Рассмотрим пример топологии с помощью триггера Центра событий Azure. В этом случае для шаблона "Активный и пассивный" требуются следующие компоненты:

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

Пример архитектуры

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

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

Шаблон "активно-активный" для функций триггеров, не основанных на протоколе HTTPS

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

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

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