Надежность в службе пакетной обработки Azure

пакетная служба Azure запускает крупномасштабные параллельные и высокопроизводительные пакетные задания вычислений (HPC) в Azure. Пакетная служба создает пулы вычислительных узлов и управляет ими, устанавливает приложения, которые вы хотите запустить, и планирует выполнение заданий на узлах.

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

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

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

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

Логическая архитектура

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

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

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

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

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

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

Физическая архитектура

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

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

Режим выделения пула учетной записи Batch определяет, где Batch создает ресурсы, связанные с вычислительными ресурсами и виртуальными машинами:

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

Обязанности по физической архитектуре разделяются следующим образом:

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

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

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

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

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

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

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

Повторные попытки задачи и ограничения времени

Настройте maxTaskRetryCount для управления тем, сколько раз Batch повторно пытается выполнить задачу после завершения процесса задачи с ненулевым кодом выхода:

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

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

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

Временные ошибки в зависимостях задач

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

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

Повторные попытки запросов пакетного API

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

Используйте встроенную поддержку повторных попыток пакета SDK, если она доступна. Например, Azure.Compute.Batch client library for .NET предоставляет настройку поведения повторных попыток с помощью Azure.Core параметров повтора.

Если вы взаимодействуете непосредственно с API-интерфейсами пакетной службы из кода, подождите несколько секунд, прежде чем повторить попытку, используйте экспоненциальную задержку между повторными попытками со случайным разбросом (jitter), чтобы избежать синхронизированных повторных запросов, и учитывайте заголовок Retry-After, возвращаемый в ответах с ограничением скорости, таких как 429 Too Many Requests и 503 Service Unavailable.

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

Устойчивость к сбоям вычислительных узлов

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

Если сбой узла прерывает задачу, пакетная служба может повторить задачу на том же узле, если это возможно, до внутреннего ограничения. Если задача не может продолжаться на этом узле, Batch может повторно поставить ее в очередь для выполнения на другом доступном узле. Эти повторные попытки восстановления, управляемые службой , не зависят от maxTaskRetryCount и могут возникать даже при его значении 0.

процесс восстановления узлов, управляемых Microsoft

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

Изолировать узел: Пакетная служба обрабатывает узел как неработоспособный, задает узлу состояние unusable и останавливает планирование новых задач на нем.
Определите затронутые задачи: Batch определяет задачи, выполняемые на узле, в качестве кандидатов для перепланирования.
Повторная постановка подходящих задач в очередь: Если затронутая задача по-прежнему сохраняется в состоянии running, Batch может сбросить ее в active, чтобы планировщик смог назначить ее другому узлу. Пакет не сбрасывает и не повторно запускает задачу, уже сохраненную в состоянии completed.
Восстановление узла: Batch пытается восстановить узел до работоспособного состояния или заменить базовую виртуальную машину.

Восстановление не происходит мгновенно. Задача может оставаться в состоянии running, пока пакетная служба обнаруживает сбой узла и пытается перепланировать задачу. Если нет другого доступного вычислительного узла, задача может оставаться в этом состоянии, пока Batch не сможет перепланировать ее. Дополнительные сведения см. в разделе "Известные ограничения" для задач пакетной службы.

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

Ваши обязанности

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

Поддерживайте достаточную емкость: Если рабочая нагрузка должна продолжаться, пока узел недоступен, предусмотрите достаточное количество узлов, чтобы оставшиеся узлы могли выполнять переназначенные задачи. Без другого пригодного для использования узла прерванные задачи должны ждать.
Отслеживание доступной емкости: Отслеживайте общее количество узлов и их состояния, чтобы определить, когда в пуле больше не будет достаточно доступных узлов для вашей рабочей нагрузки. Такие состояния, как unusable, unknownstartTaskFailedи preempted указывают на снижение емкости. Дополнительные сведения см. в разделе "Мониторинг пакетных решений" подсчитывая задачи и узлы по состоянию.
Проверьте проблемные узлы: Если задачи неоднократно завершаются ошибкой, повторно ставятся в очередь или остаются в running состоянии после того, как назначенный узел становится неиспользуемым или покидает пул, используйте метаданные задачи, чтобы определить, связаны ли проблемы с определенным узлом.

Перед удалением проблемного узла отправьте журналы агента узла Batch и сохраните соответствующие журналы задач, так как удаление узла удаляет локальные файлы. Журналы агента узла могут помочь служба поддержки Майкрософт диагностировать проблемы пакетной службы или узла, а журналы задач, такие как stdout и stderr, могут помочь определить проблемы с приложением и конфигурацией. Дополнительные сведения см. в разделе Файлы журнала агента узла.
Защита хода выполнения задачи и данных: Проектируйте задачи так, чтобы они корректно переносили прерывание и повторное выполнение. Переместите контрольные точки, выходные данные и другие устойчивые данные с вычислительных узлов, так как их локальное хранилище является временным.

Дополнительные сведения см. Ошибки пула и узлов в пакетная служба Azure и обработке и обнаружении ошибок в пакетная служба Azure.

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

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

Пакетная служба поддерживает зоны доступности двумя основными способами:

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

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

На следующей схеме показан пример учетной записи Batch. У учетной записи есть один пул с узлами, распределенными по трем зонам доступности:

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

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

Requirements

Поддержка региона: Создайте пул в регионе Azure, поддерживающем зоны доступности.
Доступность SKU виртуальной машины: Выбранный номер SKU виртуальной машины должен быть доступен более чем в одной зоне в регионе. Используйте API списка SKU ресурсов для проверки locationInfo поля SKU виртуальной машины.
Доступ к подписке: Для режима распределения пула пользовательских подписок подписка не должна иметь ограничения на предложение зоны для выбранного SKU виртуальной машины. Проверьте ResourceSkuRestrictions в ответе API списка SKU ресурсов. Если ограничение существует, отправьте запрос на поддержку , чтобы запросить его удаление.
Взаимодействие между узлами: Пул не может использовать политику размещения зоны доступности, если связь между узлами включена с помощью SKU виртуальной машины с поддержкой InfiniBand.

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

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

Cost

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

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

Создайте новый пул с размещением зоны доступности: Чтобы создать пул с включенным размещением зоны доступности, см. статью Создание пула Batch в зонах доступности.
Измените размещение зоны доступности в существующем пуле: При создании пула необходимо выбрать размещение зоны доступности. Вы не можете изменить существующий пул для использования зон доступности.

Вы можете создать резервный пул и обновить каждое задание, чтобы использовать его, выполнив следующие действия:
1. Отключите задание: Используйте операцию Отключить задание и выберите, как пакетная служба обрабатывает задачи, выполняемые при отправке запроса:
  - Подождите: Пакетная служба останавливает запуск новых задач и позволяет уже выполняющимся задачам завершиться в существующем пуле. Задание остается в disabling состоянии до завершения выполнения задач.
  - Повторная постановка в очередь: Batch прерывает выполнение задач и возвращает их в очередь. Задачи могут выполняться снова после включения задачи.
  - Завершение: Пакетная служба прерывает выполнение задач и помечает их как завершенные с информацией о сбое, которая указывает на то, что они были принудительно завершены. Задачи не выполняются снова после включения задачи.
  Задачи, которые уже находятся в состоянии active, то есть поставлены в очередь, но не выполняются, остаются в очереди при каждом параметре.
  
  Подождите, пока задание не достигнет состояния disabled, прежде чем продолжить. На этом этапе задачи не выполняются, и Batch не будет планировать новые задачи.
2. Измените пул задания: Используйте операцию «Обновление задания», чтобы установить свойство задания poolInfo.poolId на резервный пул. Batch разрешает изменять это свойство, пока задание находится в состоянии disabled. Перед включением задания убедитесь, что пул замены существует и имеет пригодную для использования емкость. Если пул не существует, Batch принимает обновление, но не может планировать задачи до создания пула.
3. Включите задание: Используйте операцию Включить задание. Задание переходит из состояния enabling в состояние active. Затем пакет планирует задачи в очереди, включая задачи, возвращенные в очередь параметром Requeue, в замещающем пуле. Задачи, завершенные при применении в Batch параметра Wait, и задачи, завершенные с помощью параметра Terminate, не выполняются снова.

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

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

Если вы используете автомасштабирование: Ссылайтесь на $UsableNodeCount определяемую службой переменную в формуле автомасштабирования пула, чтобы определить, когда пригодная для использования емкость ниже базового уровня, который требуется вашей рабочей нагрузке. $UsableNodeCount — это переменная автомасштабирования Batch для пула, формула которой вычисляется, а не метрика Azure Monitor. Azure Monitor публикует метрики количества узлов Batch в области учетной записи Batch, и эти метрики не имеют измерения poolId.
Если вы управляете емкостью вручную: Используйте операцию List Pool Node Counts, чтобы получить количество выделенных и Spot-узлов в каждом состоянии для каждого пула. Операция не возвращает количество одного пригодного к использованию узла. Оцените состояния, пригодные для выполнения задач, такие как idle и unusable, в сравнении с недоступными или проблемными состояниями, такими как unknown, offline, startTaskFailed и running. Возвращаемые значения количества могут быть неактуальными, поэтому перечисляйте вычислительные узлы пула, если требуется точное количество.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Batch не гарантирует, что узлы перебалансируются равномерно между зонами доступности после восстановления. Размещение зоны по-прежнему выполняется по мере возможности.

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

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

Перезагрузите выбранные узлы.
Отключите планирование задач на выбранных узлах.
Удалите выбранные узлы из пула.

Если операция позволяет выбрать способ обработки выполняемых задач, выберите параметр Requeue, чтобы Batch могла планировать прерванные задачи на оставшихся узлах.

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

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

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

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

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

Пользовательские мультирегиональные решения для обеспечения устойчивости

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

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

В следующем списке приведены примеры обязанностей при разработке решения:

Развертывание: Заранее создайте учетные записи пакетной службы, пулы или определения развертывания пула, учетные записи хранения, сетевые ресурсы и другие зависимости в каждом регионе. Убедитесь, что каждый выбранный регион поддерживает функции Batch, размеры виртуальных машин и зависимые службы, необходимые рабочей нагрузке. Сохраняйте каждую учетную запись Azure Batch и ресурсы хранилища, используемые её задачами, в одном регионе, если это возможно, чтобы избежать ненужных задержек. Определите учетные записи Batch, пулы и вспомогательные ресурсы с помощью инфраструктуры в качестве кода, чтобы конфигурация была последовательно воспроизведена в разных регионах.
Квоты и емкость: Проверьте применимые квоты учетной записи Batch, подписки и семейства виртуальных машин в каждом регионе восстановления и запросите увеличение квот до сбоя при необходимости. Квота — это лимит, а не гарантия наличия ресурсов. Доступность виртуальных машин зависит от региона, семейства виртуальных машин и времени. Дополнительные сведения см. в разделе "Учетная запись Batch" и основные квоты.
Репликация данных: Обеспечьте доступность пакетов приложений, образов контейнеров, входных и справочных данных в каждом регионе восстановления. Пакетная обработка не реплицирует эти элементы для вас.
Репликация хранилища: Настройте избыточность хранилища и репликацию данных между регионами исходя из целевого показателя точки восстановления (RPO). Убедитесь, что реплицированные данные доступны из каждого региона восстановления. Параметры надежности хранилища см. Надежность в хранилище BLOB-объектов Azure.
Целевой регион: Если ваши приложения работают с вашей учетной записью Batch, создайте их таким образом, чтобы они могли выбрать другую учетную запись Batch и связанные с ней ресурсы хранения, не требуя развертывания кода.
Переключение при отказе: Batch не перемещает автоматически рабочую нагрузку в другой регион. Вы несете ответственность за обнаружение сбоя, определение того, как сбой влияет на рабочую нагрузку, остановку отправки в затронутую учетную запись Batch, перенаправление новой работы в учетную запись Batch в работоспособном регионе и решение о повторной отправке прерванных заданий. Результаты работы или задач, которые вы не реплицировали за пределами затронутого региона, могут быть недоступны или потеряны. Время восстановления зависит от модели развертывания, доступной емкости, репликации данных и автоматизации.
Восстановление региона: После восстановления доступности службы в затронутом регионе проверьте учетную запись пакетной службы, пулы, зависимости хранилища и состояние задания перед перенаправлением работы в этот регион. Устраните дубликаты или завершите частично выполненные задачи перед повторной отправкой. Batch не координирует этот процесс и не согласовывает состояние между региональными учетными записями.
Тестирование: Регулярно тестируйте полный региональный процесс восстановления в непроизводственной среде. Сымитируйте недоступность одного регионального развертывания, направьте отправку заданий в другую региональную учетную запись Batch, проверьте доступ к пакетам приложений и входным данным, выполните репрезентативные задания, соберите выходные данные и отработайте возврат восстановленного развертывания в эксплуатацию. Измеряйте результаты по целевому времени восстановления и целевой точке восстановления.

Резервное копирование и восстановление

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

Конфигурация пакетной службы: Определяйте учетные записи пакетной службы, пулы, задания и вспомогательные ресурсы с помощью инфраструктуры как кода, например Bicep, и определений заданий, управляемых версиями. Эти артефакты обеспечивают воспроизводимый способ повторного создания конфигурации в том же или другом регионе. Регулярно проверяйте, что определения могут развертывать пул и выполнять репрезентативное задание.
Метаданные пакета: Пакет хранит записи заданий и задач, пока не удалите связанное задание или задачу, но эти записи не являются резервной копией. Если необходимо сохранить эту историю, сохраните необходимые записи вне Batch.
Данные о вычислительных узлах: Вычислительные узлы являются временными, и их файловые системы не являются резервным или устойчивым хранилищем. Данные на узле теряются при повторном развертывании образа или выходе из пула. Пакетная служба также может удалять файлы задач после истечения срока хранения. Сохраните необходимые выходные данные и журналы диагностики в устойчивом хранилище до завершения задачи. Для длительных задач сохраняйте контрольные точки во время выполнения. Дополнительные сведения см. в разделах Сохранение выходных данных заданий и задач и Мониторинг пакетная служба Azure.
Данные в учетных записях автохранилища: Связанная учетная запись автохранилища может содержать пакеты приложений и файлы ресурсов задач. Помимо настройки избыточности, которая соответствует вашим целям восстановления, рассмотрите необходимость защиты этих данных от случайного удаления или повреждения. Дополнительные сведения см. в статье Резервное копирование и восстановление в Хранилище BLOB-объектов Azure.

Тестирование восстановления и возврата

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

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

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

Обслуживание узла: Azure использует такие методы обслуживания, как миграция в реальном времени, когда это возможно. Если для обслуживания требуется перезапустить или переместить вычислительный узел, выполнение задач может быть прервано, а Batch может перепланировать их. Сделайте задачи идемпотентными и сохраняйте контрольные точки и выходные данные в устойчивом хранилище.
Гостевая операционная система: Вы несете ответственность за поддержание гостевой операционной системы и агента узла Batch в актуальном состоянии. Поведение обновления операционной системы зависит от образа и конфигурации обновления. При соответствующей конфигурации автоматическое обновление образов ОС для пулов Batch может обновлять узлы пула без прерывания выполнения задач. Автоматическое обновление образа ОС не поддерживает каждый образ ОС Azure Batch.
Обновления агента узла: Автоматическое обновление образа ОС не обновляет агент узла Batch. Агенты пакетного узла не обновляются автоматически, если в пуле есть вычислительные узлы. Чтобы получить более новый агент узла, измените размер пула до нуля узлов и снова увеличите его или замените пул. Перед удалением узлов сохраните все необходимые выходные данные задачи и журналы диагностики. Дополнительные сведения см. в статье об обновлениях агента узла Batch.

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

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

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

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

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

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

Последнее обновление: 2026-10-12