Путаться при попытке запустить процесс YARN и получать ошибки. Заглянув в раздел YARN пользовательского интерфейса ambari, вы увидите ... 
(обратите внимание, что там указано 60 ГБ). Тем не менее, при попытке запустить процесс YARN появляется сообщение об ошибке, указывающее на то, что доступно меньше ресурсов, чем указано в амбари, см. ...
➜ h2o-3.26.0.2-hdp3.1 hadoop jar h2odriver.jar -nodes 4 -mapperXmx 5g -output /home/ml1/hdfsOutputDir
Determining driver host interface for mapper->driver callback...
[Possible callback IP address: 192.168.122.1]
[Possible callback IP address: 172.18.4.49]
[Possible callback IP address: 127.0.0.1]
Using mapper->driver callback IP address and port: 172.18.4.49:46721
(You can override these with -driverif and -driverport/-driverportrange and/or specify external IP using -extdriverif.)
Memory Settings:
mapreduce.map.java.opts: -Xms5g -Xmx5g -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Dlog4j.defaultInitOverride=true
Extra memory percent: 10
mapreduce.map.memory.mb: 5632
Hive driver not present, not generating token.
19/08/07 12:37:19 INFO client.RMProxy: Connecting to ResourceManager at hw01.ucera.local/172.18.4.46:8050
19/08/07 12:37:19 INFO client.AHSProxy: Connecting to Application History server at hw02.ucera.local/172.18.4.47:10200
19/08/07 12:37:19 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding for path: /user/ml1/.staging/job_1565057088651_0007
19/08/07 12:37:21 INFO mapreduce.JobSubmitter: number of splits:4
19/08/07 12:37:21 INFO mapreduce.JobSubmitter: Submitting tokens for job: job_1565057088651_0007
19/08/07 12:37:21 INFO mapreduce.JobSubmitter: Executing with tokens: []
19/08/07 12:37:21 INFO conf.Configuration: found resource resource-types.xml at file:/etc/hadoop/3.1.0.0-78/0/resource-types.xml
19/08/07 12:37:21 INFO impl.YarnClientImpl: Submitted application application_1565057088651_0007
19/08/07 12:37:21 INFO mapreduce.Job: The url to track the job: http://HW01.ucera.local:8088/proxy/application_1565057088651_0007/
Job name 'H2O_80092' submitted
JobTracker job ID is 'job_1565057088651_0007'
For YARN users, logs command is 'yarn logs -applicationId application_1565057088651_0007'
Waiting for H2O cluster to come up...
19/08/07 12:37:38 INFO client.RMProxy: Connecting to ResourceManager at hw01.ucera.local/172.18.4.46:8050
19/08/07 12:37:38 INFO client.AHSProxy: Connecting to Application History server at hw02.ucera.local/172.18.4.47:10200
----- YARN cluster metrics -----
Number of YARN worker nodes: 4
----- Nodes -----
Node: http://HW03.ucera.local:8042 Rack: /default-rack, RUNNING, 1 containers used, 5.0 / 15.0 GB used, 1 / 3 vcores used
Node: http://HW04.ucera.local:8042 Rack: /default-rack, RUNNING, 0 containers used, 0.0 / 15.0 GB used, 0 / 3 vcores used
Node: http://hw05.ucera.local:8042 Rack: /default-rack, RUNNING, 0 containers used, 0.0 / 15.0 GB used, 0 / 3 vcores used
Node: http://HW02.ucera.local:8042 Rack: /default-rack, RUNNING, 0 containers used, 0.0 / 15.0 GB used, 0 / 3 vcores used
----- Queues -----
Queue name: default
Queue state: RUNNING
Current capacity: 0.08
Capacity: 1.00
Maximum capacity: 1.00
Application count: 1
----- Applications in this queue -----
Application ID: application_1565057088651_0007 (H2O_80092)
Started: ml1 (Wed Aug 07 12:37:21 HST 2019)
Application state: FINISHED
Tracking URL: http://HW01.ucera.local:8088/proxy/application_1565057088651_0007/
Queue name: default
Used/Reserved containers: 1 / 0
Needed/Used/Reserved memory: 5.0 GB / 5.0 GB / 0.0 GB
Needed/Used/Reserved vcores: 1 / 1 / 0
Queue 'default' approximate utilization: 5.0 / 60.0 GB used, 1 / 12 vcores used
----------------------------------------------------------------------
ERROR: Unable to start any H2O nodes; please contact your YARN administrator.
A common cause for this is the requested container size (5.5 GB)
exceeds the following YARN settings:
yarn.nodemanager.resource.memory-mb
yarn.scheduler.maximum-allocation-mb
----------------------------------------------------------------------
For YARN users, logs command is 'yarn logs -applicationId application_1565057088651_0007'
Обратите внимание
ОШИБКА: невозможно запустить какие-либо узлы H2O; обратитесь к администратору YARN.
Частая причина этого - запрошенный размер контейнера (5,5 ГБ) превышает следующие параметры YARN:
yarn.nodemanager.resource.memory-mb yarn.scheduler.maximum-allocation-mb
Тем не менее, у меня YARN настроен с
yarn.scheduler.maximum-allocation-vcores=3
yarn.nodemanager.resource.cpu-vcores=3
yarn.nodemanager.resource.memory-mb=15GB
yarn.scheduler.maximum-allocation-mb=15GB
и мы видим, что ограничения ресурсов контейнера и узла превышают запрошенный размер контейнера.
Попытка выполнить более крупный расчет с помощью примера mapreduce pi по умолчанию
[myuser@HW03 ~]$ yarn jar /usr/hdp/3.1.0.0-78/hadoop-mapreduce/hadoop-mapreduce-examples.jar pi 1000 1000
Number of Maps = 1000
Samples per Map = 1000
....
и проверив пользовательский интерфейс RM, я вижу, что, по крайней мере, в некоторых случаях возможно использовать все 60 ГБ ресурсов RM (обратите внимание на 61440 МБ в нижней части изображения) 
Итак, в этой проблеме есть кое-что, чего я не понимаю
# P10 #
# P11 #----- Узлы -----
Узел: http://HW03.ucera.local:8042 Стойка: / default-rack, РАБОТАЕТ, Использовано 1 контейнер, использовано 5,0 / 15,0 ГБ, использовано 1/3 виртуальных ядер
Узел: http://HW04.ucera.local:8042 Стойка: / default-rack, РАБОТАЕТ, Использовано 0 контейнеров, использовано 0,0 / 15,0 ГБ, использовано 0/3 виртуальных ядер
....
Почему перед ошибкой используется только один узел?
Из этих двух вещей кажется, что ни предел узла 15 ГБ, ни предел кластера 60 ГБ не превышены, так почему же возникают эти ошибки? Что в этой ситуации я неправильно понимаю? Что можно сделать, чтобы исправить (опять же, хотелось бы иметь возможность использовать все видимые 60 ГБ ресурсов YARN для работы без ошибок)? Любые предложения по отладке исправлений?
ОБНОВЛЕНИЕ:
Проблема, по-видимому, связана с Как правильно изменить uid для пользователя, созданного с помощью HDP / ambari? и тем фактом, что наличие пользователя существуют на узле a и имеют каталог hdfs://user/<username> с правильными разрешениями (как мне показалось на форуме Hortonworks post) недостаточно, чтобы быть признанным "существующим" в кластере.
Выполнение команды hadoop jar для другого пользователя (в данном случае пользователя hdfs, созданного Ambari), который существует на всех узлах кластера (даже несмотря на то, что Ambari создал этого пользователя с разными идентификаторами uid на узлах (IDK, если это проблема)) и имеет a hdfs://user/hdfs dir, обнаружил, что банка H2O работает, как ожидалось.
Изначально у меня создалось впечатление, что пользователям нужно было существовать только на той клиентской машине, которая использовалась, плюс необходимость в hdfs: // user / dir (см. https://community.cloudera.com/t5/Support-Questions/Adding-a-new-user-to-the-cluster/mp/130319/highlight/true#M93005). Одно касающееся / запутанное обстоятельство, которое произошло из-за этого, заключается в том, что Ambari, по-видимому, создал пользователя hdfs на различных узлах кластера с разными значениями uid и gid, например ...
[root@HW01 ~]# clush -ab id hdfs
---------------
HW[01-04] (4)
---------------
uid=1017(hdfs) gid=1005(hadoop) groups=1005(hadoop),1003(hdfs)
---------------
HW05
---------------
uid=1021(hdfs) gid=1006(hadoop) groups=1006(hadoop),1004(hdfs)
[root@HW01 ~]#
[root@HW01 ~]#
# wondering what else is using a uid 1021 across the nodes
[root@HW01 ~]# clush -ab id 1021
---------------
HW[01-04] (4)
---------------
uid=1021(hbase) gid=1005(hadoop) groups=1005(hadoop)
---------------
HW05
---------------
uid=1021(hdfs) gid=1006(hadoop) groups=1006(hadoop),1004(hdfs)
Это не похоже на то, как должно быть (только мое подозрение, потому что я работал с MapR (который требует, чтобы uid и gids были одинаковыми для всех узлов) и смотрел здесь: https://www.ibm.com/support/knowledgecenter/en/STXKQY_BDA_SHR/bl1adv_userandgrpid.htm Обратите внимание, что HW05 был добавленным позже узлом. Если в HDP это действительно нормально, я планирую просто добавить пользователя, с которым я на самом деле отступаю, чтобы использовать h2o на всех узлах с любыми произвольными значениями uid и gid. Есть мысли по этому поводу? Любые документы, подтверждающие, почему это правильно или неправильно, вы могли бы связать меня?
Рассмотрим это еще немного, прежде чем отправлять в качестве ответа. Я думаю, что в основном нужно будет найти немного больше разъяснений относительно того, когда HDP считает пользователя «существующим» в кластере.
