Приложения YARN не могут запускаться при указании меток узлов YARN

Я пытаюсь использовать метки узлов YARN, чтобы пометить рабочие узлы, но когда я запускаю приложения в YARN (Spark или простое приложение YARN), эти приложения не запускаются.

  • со Spark при указании --conf spark.yarn.am.nodeLabelExpression="my-label" задание не может быть запущено (заблокировано Submitted application [...], подробности см. ниже).

  • с приложением YARN (например, distributedshell) при указании -node_label_expression my-label приложение не может запуститься ни

Вот тесты, которые я сделал до сих пор.

Настройка этикеток узлов YARN

Я использую Google Dataproc для запуска своего кластера (пример: 4 рабочих, 2 на вытесняемые узлы). Моя цель - заставить любой мастер приложения YARN работать на невытесняемом узле, иначе узел может быть отключен в любое время, что приведет к серьезному сбою приложения.

Я создаю кластер, используя свойства YARN (--properties), чтобы включить метки узлов:

gcloud dataproc clusters create \
    my-dataproc-cluster \
    --project [PROJECT_ID] \
    --zone [ZONE] \
    --master-machine-type n1-standard-1 \
    --master-boot-disk-size 10 \
    --num-workers 2 \
    --worker-machine-type n1-standard-1 \
    --worker-boot-disk-size 10 \
    --num-preemptible-workers 2 \
    --properties 'yarn:yarn.node-labels.enabled=true,yarn:yarn.node-labels.fs-store.root-dir=/system/yarn/node-labels'

Версии упакованных Hadoop и Spark:

  • Версия Hadoop: 2.8.2
  • Версия Spark: 2.2.0

После этого я создаю метку (my-label) и обновляю два невытесняемых воркера с этой меткой:

yarn rmadmin -addToClusterNodeLabels "my-label(exclusive=false)"
yarn rmadmin -replaceLabelsOnNode "\
    [WORKER_0_NAME].c.[PROJECT_ID].internal=my-label \
    [WORKER_1_NAME].c.[PROJECT_ID].internal=my-label"

Я вижу созданный ярлык в YARN Web UI:

Этикетка создана на ПРЯЖЕ

Искра

Когда я запускаю простой пример (SparkPi) без указания информации о метках узлов:

spark-submit \
  --class org.apache.spark.examples.SparkPi \
  --master yarn \
  --deploy-mode client \
  /usr/lib/spark/examples/jars/spark-examples.jar \
  10

На вкладке «Планировщик» в веб-интерфейсе YARN я вижу приложение, запущенное <DEFAULT_PARTITION>.root.default.

Но когда я запускаю задание, указав spark.yarn.am.nodeLabelExpression, чтобы установить местоположение мастера приложения Spark:

spark-submit \
    --class org.apache.spark.examples.SparkPi \
    --master yarn \
    --deploy-mode client \
    --conf spark.yarn.am.nodeLabelExpression="my-label" \
    /usr/lib/spark/examples/jars/spark-examples.jar \
    10

Работа не запущена. В веб-интерфейсе YARN я вижу:

  • YarnApplicationState: ACCEPTED: waiting for AM container to be allocated, launched and register with RM.
  • Диагностика: Application is Activated, waiting for resources to be assigned for AM. Details : AM Partition = my-label ; Partition Resource = <memory:6144, vCores:2> ; Queue's Absolute capacity = 0.0 % ; Queue's Absolute used capacity = 0.0 % ; Queue's Absolute max capacity = 0.0 % ;

Я подозреваю, что очередь, относящаяся к разделу меток (не <DEFAULT_PARTITION, другой), не имеет достаточных ресурсов для выполнения задания:

Работа в Spark принята

Здесь Used Application Master Resources это <memory:1024, vCores:1>, а Max Application Master Resources это <memory:0, vCores:0>. Это объясняет, почему приложение не запускается, но я не могу понять, как это изменить.

Я пытался обновить разные параметры, но безуспешно:

yarn.scheduler.capacity.root.default.accessible-node-labels=my-label

Или увеличивая эти свойства:

yarn.scheduler.capacity.root.default.accessible-node-labels.my-label.capacity
yarn.scheduler.capacity.root.default.accessible-node-labels.my-label.maximum-capacity
yarn.scheduler.capacity.root.default.accessible-node-labels.my-label.maximum-am-resource-percent
yarn.scheduler.capacity.root.default.accessible-node-labels.my-label.user-limit-factor
yarn.scheduler.capacity.root.default.accessible-node-labels.my-label.minimum-user-limit-percent

без успеха тоже.

ПРЯЖА Применение

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

hadoop jar \
    /usr/lib/hadoop-yarn/hadoop-yarn-applications-distributedshell.jar \
    -shell_command "echo ok" \
    -jar /usr/lib/hadoop-yarn/hadoop-yarn-applications-distributedshell.jar \
    -queue default \
    -node_label_expression my-label

Приложение не запускается, и логи повторяются:

INFO distributedshell.Client: Got application report from ASM for, appId=6, clientToAMToken=null, appDiagnostics= Application is Activated, waiting for resources to be assigned for AM. Details : AM Partition = my-label ; Partition Resource = <memory:6144, vCores:2> ; Queue's Absolute capacity = 0.0 % ; Queue's Absolute used capacity = 0.0 % ; Queue's Absolute max capacity = 0.0 % ; , appMasterHost=N/A, appQueue=default, appMasterRpcPort=-1, appStartTime=1520354045946, yarnAppState=ACCEPTED, distributedFinalState=UNDEFINED, [...]

Если я не укажу -node_label_expression my-label, приложение запустится <DEFAULT_PARTITION>.root.default и завершится успешно.

Вопросов

  • Я что-то не так делаю с этикетками? Однако я следовал официальной документации и это руководство
  • Это конкретная проблема, связанная с Dataproc? Поскольку предыдущие руководства, похоже, работают в других средах
  • Может мне нужно создать конкретную очередь и связать ее с моим лейблом? Но так как я запускаю «одноразовый» кластер для выполнения одного задания Spark, мне не нужны определенные очереди, выполнение заданий в корневом каталоге по умолчанию не является проблемой для моего варианта использования.

Спасибо за помощь


person norbjd    schedule 07.03.2018    source источник
comment
Привет! Поддержка GCP здесь. Я думаю, что после воспроизведения вашей проблемы, возможно, стоит сообщить о ней в общедоступном трекере проблем, чтобы его можно было лучше там отследить. Таким образом, вы сможете предоставить дополнительную информацию, которая может потребоваться для устранения проблемы. Благодаря имеющейся у нас информации мы не смогли определить основную причину проблемы, с которой вы столкнулись, поэтому, возможно, у нас есть лучший шанс отследить ее в PIT. Если вы это сделаете, не стесняйтесь опубликовать это в качестве ответа, чтобы сообщество знало об этом.   -  person dsesto    schedule 12.03.2018
comment
Здравствуйте, мы только что создали проблему, как вы рекомендовали. Итак, насколько я понимаю, проблема, которую мы получили, связана с Dataproc, а не с YARN, верно?   -  person norbjd    schedule 13.03.2018
comment
Спасибо за это. На данный момент мы не знаем, откуда взялась проблема, но я надеюсь, что мы сможем получить больше информации, когда продолжим расследование. Не стесняйтесь размещать ссылку на PIT, чтобы сообщество также могло отслеживать ее решение.   -  person dsesto    schedule 14.03.2018


Ответы (1)


Инженер Google ответил нам (по частной проблеме, которую мы подняли, не в PIT), и дал нам решение, указав сценарий инициализации для создания кластера Dataproc. Я не думаю, что проблема исходит от Dataproc, это просто конфигурация YARN. Сценарий устанавливает следующие свойства в capacity-scheduler.xml сразу после создания метки узла (my-label):

<property>
  <name>yarn.scheduler.capacity.root.accessible-node-labels</name>
  <value>my-label</value>
</property>
<property>
  <name>yarn.scheduler.capacity.root.accessible-node-labels.my-label.capacity</name>
  <value>100</value>
</property>
<property>
  <name>yarn.scheduler.capacity.root.default.accessible-node-labels</name>
  <value>my-label</value>
</property>
<property>
  <name>yarn.scheduler.capacity.root.default.accessible-node-labels.my-label.capacity</name>
  <value>100</value>
</property>

Из комментария, сопровождающего сценарий, это «устанавливает accessible-node-labels как на root (корневая очередь), и root.default (фактически запускаются приложения очереди по умолчанию)». Часть root.default - это то, чего не хватало в моих тестах. Емкость для обоих установлена ​​на 100.

Затем необходимо перезапустить YARN (systemctl restart hadoop-yarn-resourcemanager.service) для проверки изменений.

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

Надеюсь, что это поможет людям, имеющим такие же или похожие проблемы.

person norbjd    schedule 07.04.2018