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

ошибки пула и узла в Azure Batch

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

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

Ошибки пула

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

Сведения об ошибке поставщика ретранслятора

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

Структура ошибки поставщика ретранслятора

Эти ошибки предоставляются в структурированном формате JSON, содержав следующие ключевые компоненты:

  • Код ошибки: тип ошибки, обнаруженной (например, AllocationFailed, BadRequest и т. д.).
  • Сообщение об ошибке: краткое описание ошибки
  • Json ошибки поставщика: подробное сообщение об ошибке, сформированное базовой службой Azure (например, VMSS).
  • Ошибка поставщика усечена: логическое значение, указывающее, усечено ли сообщение об ошибке поставщика из-за ограничений размера.

Примеры ошибок поставщика ретранслятора

Пример 1

Код ошибки:AllocationFailed
Сообщение об ошибке: не удалось выделить требуемое количество выделенных узлов
Ошибка поставщика JSON:

{
  "error": {
    "code": "BadRequest",
    "message": "The selected VM size 'STANDARD_A1_V2' cannot boot Hypervisor Generation '2'. If this was a Create operation, please ensure that the Hypervisor Generation of the Image matches the Hypervisor Generation of the selected VM Size. If this was an Update operation, please choose a Hypervisor Generation '2' VM Size."
  }
}

Ошибка поставщика JSON усечена: false

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

Пример 2

Код ошибки:AllocationFailed
Сообщение об ошибке: возникла внутренняя ошибка при изменении размера пула
Ошибка поставщика JSON:

{
  "error": {
    "code": "ScopeLocked",
    "message": "The scope '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/VirtualMachineScaleSets/<guid>-azurebatch-VMSS-D' cannot perform write operation because the following scope(s) are locked: '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/VirtualMachineScaleSets/<guid>-azurebatch-VMSS-D'. Please remove the lock and try again."
  }
}

Ошибка поставщика JSON усечённая: False

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

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

Время ожидания изменения размера или сбой

При создании нового пула или изменении размера существующего пула укажите целевое число узлов. Операция создания или изменения размера завершается немедленно, но фактическое выделение новых узлов или удаление существующих узлов может занять несколько минут. Вы можете указать время ожидания изменения размера в API Pool — Добавление или Pool — Изменение размера. Если Batch не может выделить целевое число узлов в течение тайм-аута изменения размера, пул переходит в устойчивое состояние и сообщает об ошибках изменения.

Свойство resizeError содержит ошибки, которые произошли для последней оценки.

К распространенным причинам ошибок изменения размера относятся следующие.

  • Время ожидания изменения размера слишком коротко. Обычно 15 минут по умолчанию достаточно, чтобы выделить или удалить узлы пула. Если вы выделяете большое количество узлов, например более 1000 узлов из образа Azure Marketplace или более 300 узлов из пользовательского образа виртуальной машины, можно задать время ожидания изменения размера до 30 минут.

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

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

  • Недостаточно ресурсов, когда пул находится в виртуальной сети. При создании пула в виртуальной сети можно создавать такие ресурсы, как подсистемы балансировки нагрузки, общедоступные IP-адреса и группы безопасности сети (NSG) в той же подписке, что и учетная запись пакетной службы. Убедитесь, что квоты для подписки достаточны для этих ресурсов.

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

Сбои автоматического масштабирования

Вы можете настроить Azure Batch для автоматического масштабирования числа узлов в пуле и задать параметры для формулы автоматического масштабирования пула. Затем пакетная служба использует формулу для периодического вычисления количества узлов в пуле и задания новых целевых номеров. Дополнительные сведения см. в статье "Создание автоматической формулы для масштабирования вычислительных узлов в пуле Batch."

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

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

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

Сведения обо всех оценках автоматически фиксируются в событии завершения изменения размера пула.

Неудачи при удалении пула

Чтобы удалить пул, содержащий узлы, Batch сначала удаляет узлы, что может занять несколько минут. Затем пакет удаляет сам объект пула.

Пакет устанавливает poolState на deleting во время процесса удаления. Вызывающее приложение может определить, занимает ли удаление пула слишком много времени, с помощью свойств state и stateTransitionTime.

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

  • Блокировки ресурсов могут быть помещены в ресурсы, созданные пакетной службой, или сетевые ресурсы, используемые пакетной службой.

  • Созданные ресурсы могут зависеть от ресурса, созданного пакетной службы. Например, при создании пула в виртуальной сети Batch создает группу безопасности сети, общедоступный IP-адрес и балансировщик нагрузки. Если вы используете эти ресурсы за пределами пула, вы не сможете удалить пул.

  • Поставщик Microsoft.Batch ресурсов может быть незарегистрирован из подписки, содержащей пул.

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

Ошибки узла

Даже если сервис Batch успешно выделяет узлы в пуле, различные проблемы могут привести к тому, что некоторые узлы неисправны и не могут обрабатывать задачи. Эти узлы по-прежнему несут расходы, поэтому важно обнаружить проблемы, чтобы избежать оплаты узлов, которые нельзя использовать. Знание распространенных ошибок узла и знание текущего состояния задания jobState полезно для устранения неполадок.

Сбои задачи запуска

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

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

Сбой задачи запуска также приводит к тому, что пакетная служба устанавливает computeNodeState в starttaskfailed, если waitForSuccess установлено в true.

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

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

Не удалось скачать пакет приложения

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

Если пакет приложения не удается скачать и распаковать, свойство computeNodeError сообщает об ошибке и задает состояние unusableузла.

Сбой при скачивании контейнера

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

Обновления ОС узла

Для пулов Windows enableAutomaticUpdates по умолчанию имеет значение true. Хотя рекомендуется разрешить автоматическое обновление, обновления могут прерывать ход выполнения задачи, особенно если задачи выполняются долго. Это значение можно задать равным false, если необходимо гарантировать, что обновление ОС не произойдет неожиданно.

Узел в непригодном состоянии

Пакет может задать computeNodeStateunusable по многим причинам. Вы не можете запланировать задачи на узел unusable, но за узел по-прежнему начисляется плата.

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

Другие причины для unusable узлов могут включать следующее:

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

Файлы журнала агента узла

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

Диск узла заполнен

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

  • Файлы пакета приложения
  • Файлы ресурсов задач
  • Файлы для конкретных приложений, скачиваемые в одну из папок Batch
  • Файлы Stdout и stderr для выполнения каждой задачи приложения
  • Выходные файлы конкретных приложений

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

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

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

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

При добавлении пула в портал Azure можно отобразить полный список размеров виртуальных машин, включая столбец размера диска ресурсов. В статьях, описывающих размеры виртуальных машин, есть таблицы с столбцом temp storage . Дополнительные сведения см. в статье Размеры виртуальных машин, оптимизированных для вычислений. В качестве примера таблицы размера см. Fsv2-series.

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

Если на временном или ОС диске заканчивается место, или оно почти закончилось, узел переходит в unusablecomputeNoteState, и ошибка узла сообщает, что диск заполнен.

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

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

Вы можете удалить старые завершенные задания или задачи, данные которых по-прежнему находится на узлах. Просмотрите коллекцию recentTasks в taskInformation на узле или используйте API File - List From Compute Node. При удалении задания удаляются все задачи в задании. Удаление задач в задании активирует удаление данных в каталогах задач на узлах и освобождает место. После освобождения достаточного места перезагрузите узел. Узел должен выйти из состояния unusable и снова войти в состояние idle.

Чтобы восстановить неиспользуемый узел в пулах VirtualMachineConfiguration, можно удалить узел из пула с помощью API "Удалить узлы". Затем вы можете снова увеличить пул, чтобы заменить плохой узел свежим.

Внимание

Reimage в настоящее время не поддерживается для пулов VirtualMachineConfiguration .

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

  • Last updated on