Надежность в Функции Azure
В этой статье описывается поддержка надежности в Функции Azure и охватывает как внутрирегиональная устойчивость с зонами доступности, так и восстановлением между регионами и непрерывностью бизнес-процессов. Более подробный обзор принципов надежности в Azure см. в статье "Надежность Azure".
Поддержка зоны доступности для Функции Azure доступна в планах Premium (Elastic Premium) и Выделенных (Служба приложений). В данной статье основное внимание уделяется поддержке избыточности между зонами для планов категории "Премиум". Сведения о избыточности зон в выделенных планах см. в разделе "Миграция Служба приложений в поддержку зоны доступности".
Поддержка зоны доступности
Зоны доступности Azure — это по крайней мере три физически отдельные группы центров обработки данных в каждом регионе Azure. Центры обработки данных в каждой зоне оснащены независимой питанием, охлаждения и сетевой инфраструктурой. В случае сбоя локальной зоны зоны зоны создаются таким образом, чтобы при возникновении влияния одной зоны, региональных служб, емкости и высокой доступности поддерживались остальными двумя зонами.
Сбои могут варьироваться от сбоев программного обеспечения и оборудования до таких событий, как землетрясения, наводнения и пожары. Устойчивость к сбоям достигается с избыточностью и логической изоляцией служб Azure. Дополнительные сведения о зонах доступности в Azure см. в разделе "Регионы и зоны доступности".
Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматическим реплика tion между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см. в Рекомендации использования зональных зон и регионов.
Функции Azure поддерживает избыточное между зонами развертывание.
При настройке функций в качестве избыточной зоны платформа автоматически распределяет экземпляры приложения-функции по трем зонам в выбранном регионе.
Распространение экземпляра с помощью развертывания, избыточного между зонами, определяется в следующих правилах, даже если приложение масштабируется и выходит:
- Минимальное число экземпляров приложения-функции — три.
- При указании емкости, превышающей три, экземпляры распределяются равномерно, только если емкость составляет несколько 3.
- Для значения емкости более 3*N дополнительные экземпляры распределяются по оставшимся одному или двум зонам.
Внимание
Функции Azure могут выполняться на платформе Службы приложений Azure. На платформе Служба приложений планы, в которых размещаются приложения-функции плана Premium, называются планами Elastic Premium с именами SKU, такими как EP1. Если вы решили запустить приложение-функцию в плане Premium, обязательно создайте план с именем SKU, начинающимся с E, например EP1. Служба приложений имена SKU плана, начинающиеся с "P", например P1V2 (небольшой план premium V2), фактически являютсяВыделенные планы размещения. Так как они относятся к разряду планов с выделенным размещением, а не эластичными категории "Премиум", планы с названиями ценовых категорий, начинающимися с буквы "P", не будут динамически масштабироваться, что может привести к увеличению затрат.
Доступность в регионах
Планы premium, избыточные между зонами, доступны в следующих регионах:
| Северная и Южная Америка | Европа | Ближний Восток | Африка | Азиатско-Тихоокеанский регион |
|---|---|---|---|---|
| Brazil South | Центральная Франция | Израиль, центральный регион | Северная часть ЮАР | Восточная Австралия |
| Центральная Канада | Центрально-Западная Германия | Центральный Катар | Центральная Индия | |
| Центральная часть США | Северная Италия | Северная часть ОАЭ; | Северный Китай 3 | |
| Восточная часть США | Северная Европа | Восточная Азия | ||
| восточная часть США 2 | Восточная Норвегия; | Восточная Япония | ||
| Центрально-южная часть США | Центральная Швеция | Юго-Восточная Азия | ||
| западная часть США 2 | Северная Швейцария | |||
| Западная часть США — 3 | южная часть Соединенного Королевства | |||
| Западная Европа |
Необходимые компоненты
Поддержка зоны доступности является свойством плана "Премиум". Текущие требования и ограничения для включения зон доступности:
- Вы можете включить зоны доступности только при создании плана "Премиум" для приложения-функции. Вы не можете преобразовать существующий план "Премиум" для использования зон доступности.
- Для учетной записи хранения приложения-функции необходимо использовать учетную запись хранения с избыточностью между зонами (ZRS). Если вы используете другую учетную запись хранения, функции могут отображать непредвиденное поведение во время зонального сбоя.
- Поддерживаются как Windows, так и Linux.
- Должны размещаться в плане "Эластичный премиум" или плане размещения "Выделенный". Сведения об использовании избыточности между зонами с планом "Выделенный" см. в статье Миграция Службы приложений для включения поддержки зон доступности.
- Поддержка зон доступности сейчас недоступна для приложений-функций в планах Потребление.
- Приложения-функции в плане "Премиум" должны иметь не менее трех постоянно готовых экземпляров.
- Платформа применяет это минимальное количество за кулисами, если указать число экземпляров меньше трех.
- Если вы не используете план "Премиум" или единицу масштабирования с поддержкой зон доступности, находитесь в неподдерживаемом регионе или не знаете, что нужно делать, см. руководство по миграции.
Цены
Дополнительные затраты, связанные с включением зон доступности, не требуются. Цены на план, избыточный между зонами, Служба приложений уровня "Премиум" совпадают с одним планом уровня "Премиум". Для каждого используемого плана Служба приложений взимается плата на основе выбранного номера SKU, указанной емкости и всех экземпляров, масштабируемых на основе критериев автомасштабирования. Если вы включите зоны доступности, но укажите емкость менее трех для плана Служба приложений, платформа применяет минимальное число экземпляров для этого плана Служба приложений и взимается плата за эти три экземпляра.
Создание плана и приложения-функции, избыточного между зонами, и приложения-функции
Сейчас есть два способа развертывания плана "Премиум" с избыточностью между зонами и приложения-функции. Необходимо использовать портал Azure или шаблон ARM.
Откройте портал Azure и перейдите на страницу Создать приложение-функцию. Сведения о создании приложения-функции на портале можно найти здесь.
На странице Основные сведения заполните поля для приложения-функции. Обратите особое внимание на поля в следующей таблице (также выделенные на снимке экрана ниже), которые имеют особые требования к избыточности между зонами.
Параметр Предлагаемое значение Примечания об избыточности между зонами Регион Предпочтительный регион Подписка, в которой создается приложение-функция. Вам нужно выбрать регион с поддержкой зон доступности в списке выше. 
На странице Размещение заполните поля для плана размещения приложения-функции. Обратите особое внимание на поля в следующей таблице (также выделенные на снимке экрана ниже), которые имеют особые требования к избыточности между зонами.
Параметр Предлагаемое значение Примечания об избыточности между зонами Учетная запись хранения Учетная запись хранения с избыточностью между зонами Как упоминание выше в разделе предварительных требований, настоятельно рекомендуется использовать учетную запись хранения, избыточной по зонам, для приложения-функции, избыточного между зонами. Тип плана Функции уровня "Премиум" В данной статье описано, как создавать приложение с избыточностью между зонами в плане "Премиум". Избыточность между зонами в настоящее время недоступна в планах категории "Потребление". Сведения о избыточности между зонами в планах службы приложений приведены в этой статье. Избыточность между зонами Включен Это поле заполняется флажком, определяющим, является ли приложение приложением с избыточностью между зонами. Вы не сможете выбрать Enabled, если вы не выбрали регион, поддерживающий избыточность между зонами, как упоминалось на шаге 2.
Далее процесс создания приложения-функции выполняется как обычно. На остальных этапах процесса создания поля, влияющие на избыточность между зонами, отсутствуют.
После создания и развертывания плана с избыточностью между зонами все приложения-функции, размещенные в новом плане, считаются избыточными между зонами.
Миграция зоны доступности
В настоящее время приложения-функции Azure не поддерживают миграцию существующих экземпляров приложений-функций. Сведения о переносе общедоступного мультитенантного плана Premium из зоны доступности в поддержку зоны доступности см. в статье "Миграция Служба приложений в поддержку зоны доступности".
Взаимодействие с зонами вниз
Все доступные экземпляры приложений-функций, избыточных между зонами, включены и обрабатывают события. При понижении зоны функции обнаруживают потерянные экземпляры и автоматически пытается найти новые экземпляры замены при необходимости. Поведение эластичного масштабирования по-прежнему применяется. Но в сценарии отключения зоны нет гарантии, что запросы на получение дополнительных экземпляров могут быть выполнены успешно, так как обратное заполнение потерянных экземпляров происходит по мере возможности. Приложения, развернутые в зоне доступности с поддержкой плана Premium, продолжают работать, даже если другие зоны в том же регионе страдают от сбоя. Но, возможно, что сбой в других зонах доступности по-прежнему может влиять на поведение, не относящееся к среде выполнения. Такое поведение может включать масштабирование плана "Премиум", а также создание, настройку и публикацию приложений. Избыточность между зонами для планов "Премиум" гарантирует только безотказную работу для развернутых приложений.
Когда Функции выделяют экземпляры плану "Премиум" с избыточностью между зонами, используется максимальная балансировка зоны, предлагаемая базовыми Масштабируемыми наборами виртуальных машин Azure. План "Премиум" считается сбалансированным, если каждая зона имеет одинаковое число виртуальных машин (±1 виртуальная машина) во всех остальных зонах, используемых планом "Премиум".
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с Рекомендации для разработки стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплика te данные или возвращаются из неудающегося региона, чтобы перекрестно реплика te в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
В этом разделе описаны некоторые стратегии, которые можно использовать для развертывания функций для обеспечения аварийного восстановления.
Аварийное восстановление в нескольких регионах
Так как нет встроенной избыточности, функции выполняются в приложении-функции в определенном регионе Azure. Чтобы избежать потери выполнения во время простоя, можно избыточно развернуть одни и те же функции в приложениях-функциях в нескольких регионах. Дополнительные сведения о развертываниях с несколькими регионами см. в руководстве по Веб-приложению с высоким уровнем доступности в нескольких регионах.
При выполнении одного и того же кода функции в нескольких регионах существует два шаблона, которые следует учитывать, активные и активные пассивные.
Шаблон "Активный— активный" для функций триггера HTTP
При использовании шаблона "активный— активный" функции в обоих регионах активно выполняются и обрабатывают события либо в повторяющемся режиме, либо в повороте. Рекомендуется использовать шаблон "активный— активный" в сочетании с Azure Front Door для критически важных функций, активированных HTTP, которые могут направлять и циклически переборы HTTP-запросов между функциями, выполняющимися в нескольких регионах. Front door также может периодически проверка работоспособности каждой конечной точки. Когда функция в одном регионе перестает отвечать на проверка работоспособности, Azure Front Door принимает ее из поворота и перенаправит трафик только в оставшиеся работоспособные функции.
Внимание
Хотя настоятельно рекомендуется использовать шаблон "активный-пассивный" для функций триггеров, отличных от HTTPS. Вы можете создавать развертывания active-active для функций, не активированных по протоколу HTTP. Однако необходимо учитывать, как два региона будут взаимодействовать друг с другом. Если вы развернули одно и то же приложение-функцию в двух регионах и каждое из них активирует одну и ту же очередь служебной шины Microsoft Azure, они будут действовать как конкурирующие потребители, потому что приходится удалять сообщения из этой очереди. Хотя это означает, что каждое сообщение обрабатывается только одним из экземпляров, это также означает, что на одном служебная шина экземпляре по-прежнему существует одна точка сбоя.
Вместо этого можно развернуть две очереди служебной шины: с одной в основном регионе и одной в дополнительном регионе. В этом случае можно иметь два приложения-функции, каждый из которых указывает на очередь служебной шины, активную в своем регионе. Проблема с этой топологией заключается в том, как сообщения очереди распределяются между двумя регионами. Часто это означает, что каждый издатель пытается опубликовать сообщение в обоих регионах и каждое сообщение обрабатывается обоими активными приложениями-функциями. Это создает желаемый шаблон "активный — активный", но создает трудности, связанные с дублированием вычислений, моментом и способом консолидации данных.
Активный пассивный шаблон для функций триггеров, отличных от HTTPS
Рекомендуется использовать активный пассивный шаблон для функций, управляемых событиями, не запускаемых по протоколу HTTP, таких как служебная шина и триггерные функции Центров событий.
Чтобы создать избыточность для функций триггеров, отличных от HTTP, используйте шаблон "активный-пассивный". С активным пассивным шаблоном функции выполняются активно в регионе, принимающем события; в то время как те же функции во втором регионе остаются бездействуными. Шаблон "активный- пассивный" позволяет обрабатывать каждое сообщение только одной функцией, предоставляя механизм отработки отказа в дополнительный регион в результате аварии. Приложения-функции работают с поведением отработки отказа партнерских служб, таких как геовосстановление Служебной шины Azure и геовосстановление Центров событий Azure.
Рассмотрим пример топологии с помощью триггера Центра событий Azure. В этом случае для шаблона "Активный и пассивный" требуются следующие компоненты:
- Центры событий Azure развернуты как в основном, так и в дополнительном регионе.
- Геокатастасизм включен для связывания первичных и вторичных центров событий. При этом также создается псевдоним, который можно использовать для подключения к концентраторам событий и переключения с первичного на вторичный, не изменяя сведений о соединении.
- Приложения-функции развертываются как в основном, так и в дополнительном регионе (отказа), при этом приложение в дополнительном регионе по сути простаивает, так как сообщения не отправляются туда.
- Приложения-функции активируются по строке непосредственного подключения (не псевдонима) для соответствующего концентратора событий.
- Издатели для концентратора событий должны публиковать, используя строку подключения псевдонима.
До отработки отказа издатели, отправляющие на общий псевдоним, будут маршрутизироваться к основному концентратору событий. Основное приложение-функция прослушивает только основной концентратор событий. Вторичное приложение-функция будет пассивным и бездействующим. После запуска отработки отказа издатели, отправляющие в общий псевдоним, теперь будут маршрутизироваться к дополнительному концентратору событий. Теперь приложение-функция-получатель становится активным и запускается автоматически. Эффективную отработку отказа в дополнительный регион можно проводить исключительно от концентратора событий, при этом функции становятся активными только тогда, когда активен соответствующий концентратор событий.
Дополнительные сведения и рекомендации по отработке отказа с помощью Служебной шины и Концентраторов событий.