Рекомендации для пакетной службы Azure

  • Статья

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

Совет

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

Пулы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работы

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

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

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

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

Время существования задания

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

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

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

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

Задачи

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

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

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

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

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

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

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

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

Примечание.

Для выполнения задач, отправленных в пакетную службу, вызов API DeleteTask занимает до 10 минут. Прежде чем он вступит в силу, другие задачи могут быть не запланированы. Это связано с тем, что планировщик пакетной службы по-прежнему пытается запланировать только что удаленные задачи. Если вы хотите удалить одну задачу вскоре после отправки, завершите задачу вместо этого (так как запрос на завершение задачи вступит в силу немедленно). А затем удалите задачу через 10 минут.

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование области пула для кратковременных задач на узлах Windows

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

Узлы

Вычислительный узел — это виртуальная машина 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

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

присоединением и подготовкой дисков данных;

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

Совет

При подключении диска данных в Linux при вложении точки подключения диска в точки временного подключения Azure, например /mnt или /mnt/resource, следует соблюдать осторожность, чтобы не были введены зависимости. Например, если эти подключения автоматически выполняются операционной системой, может возникнуть гонка между временным диском и подключенными дисками данных под родительским элементом. Необходимо выполнить действия, чтобы обеспечить применение соответствующих зависимостей доступными средствами, такими как systemd или отложить подключение диска данных к начальной задаче в рамках скрипта подготовки диска данных idempotent.

Подготовка дисков данных в пулах пакетной службы 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, см. в этой статье. Убедитесь, что все примеры скриптов проверяются на идемпотентность перед повышением уровня использования в рабочей среде.

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

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

Управление обновлениями ОС

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

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

API пакетной службы

Сбои времени ожидания

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

Подключение

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

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

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

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

Учет DNS

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

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

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

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

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

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

Проверка подключения с помощью конфигурации облачных служб

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

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

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

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

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

Windows:

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

Linux:

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

Совет

Именование этих пользователей или групп — артефакты реализации и могут изменяться в любое время.

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

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

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

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