Приложенията на 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

В раздела Scheduler на YARN Web UI виждам приложението, стартирано на <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, другият) няма достатъчно ресурси за изпълнение на задачата:

„Задачата

Тук 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