Лучшие практики для Azure Batch

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

Пулы

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

Настройка пулов и присвоение им имен

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

• classic или simplified режим связи с узлом: пулы можно настроить в одном из двух режимов связи узла, классических или упрощенных. В классической модели связи между узлами служба пакетной обработки инициирует обмен данными с вычислительными узлами, а вычислительным узлам также необходима связь со службой хранилища Azure. В упрощенной модели взаимодействия вычислительные узлы инициируют связь со службой пакетной обработки. В связи с уменьшенным объемом необходимых входящих и исходящих подключений и отсутствием необходимости в исходящем доступе к Azure Storage для базовой работы, рекомендуется использовать упрощенную модель связи узлов. Для некоторых будущих улучшений пакетной службы также потребуется упрощенная модель взаимодействия узлов. Классическая модель связи с узлами будет прекращена 31 марта 2026 г.

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

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

• Изображения с датами окончания срока действия (EOL): настоятельно рекомендуется избежать изображений с датами окончания срока действия пакетной поддержки (EOL). Даты прекращения поддержки можно узнать с помощью ListSupportedImages API, PowerShell или Azure CLI. Вы несете ответственность за периодическое обновление информации о датах окончания срока службы (EOL), которые относятся к вашим пулам, и за перенос рабочих нагрузок до наступления этой даты. Если вы используете пользовательский образ с определенным (указанным) агентом узла, проследите за соблюдением дат окончания срока поддержки пакетной службы для образа, для которого ваш пользовательский образ является производным или согласованным. Изображение без указанной batchSupportEndOfLife даты указывает, что такая дата еще не определена пакетной службой. Отсутствие даты не означает, что соответствующий образ будет поддерживаться на неопределенный срок. Дата EOL может быть добавлена или обновлена в будущем в любое время.

• Номера SKU виртуальных машин с датами окончания срока действия (EOL): как и в случае с образами виртуальных машин, номера SKU или семействами виртуальных машин также могут достичь окончания срока действия пакетной поддержки (EOL). Даты прекращения поддержки можно узнать с помощью ListSupportedVirtualMachineSkus API, PowerShell или Azure CLI. Запланируйте миграцию рабочей нагрузки на номер SKU виртуальной машины, отличный от EOL, создав новый пул с соответствующим поддерживаемым номером SKU виртуальной машины. Отсутствие связанной batchSupportEndOfLife даты для SKU виртуальной машины не указывает, что конкретный номер SKU виртуальной машины будет поддерживаться на неопределенный срок. Дата EOL может быть добавлена или обновлена в будущем в любое время.

• Уникальные имена ресурсов: Ресурсы пакетной службы (задания, пулы и т. д.) часто появляются и исчезают со временем. Например, вы можете создать пул в понедельник, удалить его во вторник, а затем создать аналогичный пул в четверг. Каждому новому создаваемому ресурсу следует присваивать уникальное имя, которое раньше не использовалось. Вы можете создать уникальность с помощью GUID (в качестве всего имени ресурса или в составе) или путем внедрения даты и времени создания ресурса в имя ресурса. Batch поддерживает атрибут DisplayName, который позволяет присвоить ресурсу более читаемое имя, даже если его фактический идентификатор не является удобным для восприятия. Использование уникальных имен упрощает выявление действий, выполненных определенным ресурсом, в журналах и метриках. Это также устраняет неоднозначность, если когда-либо придется подавать обращение в службу поддержки по ресурсу.

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

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

Безопасность пула

Граница изоляции

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

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

Обновления агента узла пакетной обработки

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

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

Обновления операционной системы

Рекомендуется, чтобы образ виртуальной машины, выбранный для пула Batch, был обновлен с помощью последних обновлений безопасности, предоставленных издателем. Некоторые образы могут выполнять автоматические обновления пакетов при загрузке (или вскоре после этого), что может препятствовать определенным действиям, инициируемым пользователем, таким как получение обновлений репозитория пакетов (например, apt update) или установку пакетов во время таких действий, как StartTask.

Рекомендуется включить автоматическое обновление ОС для пулов пакетной службы, что позволяет базовой инфраструктуре Azure координировать обновления в пуле. Этот параметр можно настроить так, чтобы не нарушать выполнение задач. Автоматическое обновление ОС не поддерживает все операционные системы, которые поддерживаются Batch. Дополнительные сведения см. в матрице поддержки автоматического обновления ОС для масштабируемых наборов виртуальных машин. Для операционных систем Windows убедитесь, что вы не активируете свойство virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates при использовании автоматического обновления ОС в пакетном пуле.

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

Время существования пула и выставление счетов

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

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

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

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

Сбои выделения пулов

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

Незапланированный простой

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

Пулы пользовательских образов

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

Сторонние образы

Пулы можно создавать с помощью сторонних образов, опубликованных в Azure Marketplace. При использовании пакетных учетных записей в режиме пользовательской подписки может появиться сообщение об ошибке "Allocation failed due to marketplace purchase eligibility check" (Сбой выделения из-за проверки допустимости покупки Marketplace) при создании пула с использованием определенных сторонних образов. Чтобы устранить эту ошибку, примите условия, заданные издателем образа. Для этого можно использовать Azure PowerShell или Azure CLI.

Пулы контейнеров

При создании пула Batch с виртуальной сетью могут возникать побочные эффекты взаимодействия между указанной виртуальной сетью и стандартным мостом Docker. По умолчанию Docker создаст сетевой мост со спецификацией подсети 172.17.0.0/16. Убедитесь, что между сетевым мостом Docker и виртуальной сетью нет конфликтующих диапазонов IP-адресов.

Docker Hub ограничивает количество вытягивания изображений. Убедитесь, что рабочая нагрузка не превышает опубликованные ограничения скорости для образов на основе Docker Hub. Рекомендуется использовать Реестр контейнеров Azure напрямую или использовать кэш артефактов в ACR.

Зависимость от региона Azure

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

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

Работы

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

Меньше заданий, больше задач

Использовать задание для выполнения одной задачи — неэффективно. Например, эффективнее использовать одно задание, содержащее 1000 задач, а не создание 100 заданий, содержащих 10 задач. Если вы использовали 1000 заданий, каждое из которых содержит одну задачу, это был бы наименее эффективный, наименее быстрый и самый дорогой подход.

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

Срок выполнения задания

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

Работа не переходит автоматически в состояние завершения, если не будет явно завершена. Это действие можно активировать автоматически с помощью свойства onAllTasksComplete или maxWallClockTime.

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

Удаляйте задания, если они больше не нужны, даже если они завершены. Хотя завершенные задания не учитываются в счет активной квоты заданий, полезно периодически удалять их. Например, перечисление заданий будет более эффективным, если общее количество заданий меньше (даже если к запросу применяются правильные фильтры).

Задачи

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

Сохранение данных задачи

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

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

Управление временем существования задачи

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

Удаление задач выполняет две задачи:

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

Отправка большого числа задач в составе коллекции

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

Задавайте адекватное максимальное число задач на узле

Система пакетной обработки поддерживает выполнение большего количества задач на узлах, чем количество ядер у узла. Вам следует убедиться, что ваши задачи соответствуют размерам узлов в вашем пуле. Например, может возникнуть снижение производительности при планировании восьми задач, каждая из которых потребляет 25 % загрузки ЦП, на одном узле (в пуле с taskSlotsPerNode = 8).

Проектирование для повторных попыток и повторного выполнения

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

Иногда задача может быть повторно выполнена внутренне из-за сбоя на вычислительном узле, например неспособности обновить внутреннее состояние или сбоя узла во время выполнения задачи. Задача будет повторно выполняться на том же вычислительном узле, если это возможно, до достижения внутреннего лимита попыток, прежде чем отказаться от задачи и передать её для повторного планирования в службу Batch, возможно, на другом вычислительном узле.

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

Создание устойчивых задач

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

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

Избегайте короткого времени выполнения

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

Используйте pool scope для кратких задач на узлах Windows

При планировании задачи на узлах Batch можно выбрать, следует ли запускать ее с областью задачи или областью пула. Если задача будет выполняться только в течение короткого времени, область задач может быть неэффективной из-за ресурсов, необходимых для создания учетной записи автопользователя для этой задачи. Рекомендуется задать область пула для этих задач для повышения эффективности. Дополнительные сведения см. в разделе «Запуск задачи в качестве автопользователя в пределах пула».

Узлы

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

Запуск задач: время существования идемпотентности

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

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

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

Изолированные узлы

Рассмотрите возможность использования изолированных размеров виртуальных машин для рабочих нагрузок с необходимостью соответствия нормативным требованиям. Поддерживаемые изолированные размеры в режиме конфигурации виртуальной машины: Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5, Standard_GS5 и Standard_E64i_v3. Дополнительные сведения о размерах изолированных виртуальных машин см. в статье Изоляция виртуальных машин в Azure.

Избегайте создания соединений каталогов в Windows

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

Временные диски и AZ_BATCH_NODE_ROOT_DIR

Batch-сервис использует временные диски виртуальной машины для типов виртуальных машин, совместимых с Batch, чтобы хранить метаданные, связанные с выполнением задач, и артефакты выполнения задач на этом временном диске. Примерами этих временных точек подключения диска или каталогов являются: /mnt/batch, /mnt/resource/batchи D:\batch\tasks. Замена, повторное подключение, перенаправление или создание символических ссылок для этих точек монтирования и каталогов, или для любого из родительских каталогов, не поддерживается и может привести к нестабильности. Если требуется больше места на диске, рассмотрите возможность использования размера виртуальной машины или семейства с временным дисковом пространством, которое соответствует вашим требованиям или присоединение дисков данных. Дополнительные сведения см. в следующем разделе о присоединении и подготовке дисков данных для вычислительных узлов.

Подключение и подготовка дисков данных

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

Подготовка дисков данных в Batch пулах Linux

Диски данных Azure в Linux представлены как блочные устройства и назначают типичный sd[X] идентификатор. Не следует полагаться на статические sd[X] назначения, так как эти метки динамически назначаются во время загрузки и не гарантируют согласованность между первой и любой последующей загрузкой. Необходимо идентифицировать подключенные диски с помощью сопоставлений, представленных в /dev/disk/azure/scsi1/. Например, если вы указали LUN 0 для диска данных в API AddPool, этот диск будет отображаться как /dev/disk/azure/scsi1/lun0. Например, если бы вы перечислили этот каталог, вы можете увидеть следующее:

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

Нет необходимости переводить ссылку обратно к сопоставлению sd[X] в скрипте подготовки, вместо этого обратитесь непосредственно к устройству. В этом примере данное устройство будет /dev/disk/azure/scsi1/lun0. Вы можете предоставить этот идентификатор непосредственно fdisk, mkfs, и любым другим инструментам, необходимым для вашего рабочего процесса. Также, можно использовать lsblk с blkid для сопоставления UUID для диска.

Дополнительные сведения о дисках данных Azure в Linux, включая альтернативные методы поиска дисков данных и /etc/fstab параметров, см. в этой статье. Убедитесь, что нет зависимостей или рас, как описано в примечании подсказки, прежде чем продвигать метод в рабочую среду.

Подготовка дисков данных в пулах пакетных заданий Windows

Диски данных Azure, подключенные к вычислительным узлам Пакетной службы Windows, отображаются без секционирования и неформатированы. Необходимо перечислить диски с RAW секциями для действий в рамках начальной задачи. Эти сведения можно получить с помощью командлета Get-Disk PowerShell. Например, можно увидеть следующее:

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

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

Дополнительные сведения о дисках данных Azure в Windows, включая примеры сценариев PowerShell, см. в этой статье. Убедитесь, что все примеры скриптов проверены на идемпотентность перед внедрением в производственную среду.

Сбор журналов агента пакетной обработки

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

API пакетной обработки

Сбои тайм-аута

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

Подключение

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

Группы безопасности сети (NSG) и определяемые пользователем маршруты (UDR)

При подготовке пулов Batch в виртуальной сети убедитесь, что вы внимательно следите за рекомендациями по использованию тега сервиса BatchNodeManagement.region, а также за портами, протоколами и направлением правила. Использование тега службы настоятельно рекомендуется; Не используйте базовые IP-адреса пакетной службы, так как они могут изменяться с течением времени. Использование IP-адресов пакетной службы напрямую может привести к нестабильной работе, перерывам или простоям пулов пакетной службы.

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

Почтение к DNS

Убедитесь, что ваши системы учитывают срок жизни (TTL) DNS для URL-адреса учетной записи Batch. Кроме того, убедитесь, что клиенты пакетной службы и другие механизмы подключения к пакетной службе не используют IP-адреса.

Все HTTP-запросы с кодами состояния уровня 5xx, а также заголовок Connection: close в ответе требует корректировки поведения клиента пакетной службы. Клиент пакетной службы должен соблюдать рекомендацию, закрыв существующее подключение, выполнив повторное разрешение DNS для URL-адреса службы учетной записи пакетной службы и отправив последующие запросы через новое подключение.

Автоматический повтор попыток запросов

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

Статические общедоступные IP-адреса

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

Базовые зависимости узла пакетной службы

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

Ресурсы, созданные системой

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

Виндоус:

• Пользователь с именем PoolNonAdmin.
• Группа пользователей с именем WATaskCommon.

Линукс:

• Пользователь с именем _azbatch.

Очистка файлов

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

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

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

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