Проблема:
При попытке работы с HDFS-пространством (например, создание директории) сервис не может определить "namespace", который формируется из имени кластера:
TASK [filesystem : Create directory hdfs:///user/yarn if needed] ***************
fatal: [node-2.corp.rtest]: FAILED! => {"changed": true, "cmd": ["hdfs", "dfs", "-mkdir", "-p", "hdfs:///user/yarn"], "delta": "0:00:00.960121", "end": "2022-12-07 14:32:41.903722", "msg": "non-zero return code", "rc": 1, "start": "2022-12-07 14:32:40.943601", "stderr": "mkdir: Incomplete HDFS URI, no host: hdfs://name_underscore-1", "stderr_lines": ["mkdir: Incomplete HDFS URI, no host: hdfs://name_underscore-1"], "stdout": "", "stdout_lines": []}Проявляется при установке YARN в режиме HA. Керберизация не влияет.
Решение:
Не использовать никаких спец. символов, пробелов и нижних подчёркиваний
Проблема:
Велика вероятность того, что при установке RTCM у клиентов уже будет задана своя структура OU в AD, в которой могут присутствовать пробелы в названиях OU:
Решение:
В таком случае при указании адреса ldap-подключения необходимо экранировать OU кавычками, указанным ниже способом:
OU="Cluster Manager",OU=Services,OU="Perfect Company",DC=CORP,DC=RTEST
Если графики не показывает в rtcm:
• Проверяем, что в Prometheus всё зелёное;
• Проверяем, что есть ssh с контейнера rtcm на rtcm-bridge;
• в ./rtcm/rtcm_conf/rtcm.properties, проверить, что стоит правильный порт: rtcm.prometheus.port=:9090;
• Перезагружаем контейнер: docker rtcm restart.
Бывает, что совсем не помогает, можно попробовать разобрать контейнеры (данные CM сохранятся):
docker-compose -p rtcm down
Забэкапить /var/lib/docker/volumes/rtcm_config/_data/
Почистить её и запусти опять через проект
docker-compose -p rtcm up В логе rtcm:
Caused by: java.net.ConnectException: Connection refused (Connection refused)
Caused by: org.postgresql.util.PSQLException: Connection to localhost:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.1) Проверить сетевую доступность до PostgreSQL (до контейнера или отдельной postgresql, в зависимости от сценария использования)
| № | Описание проблемы | Способ решения |
| 1 | Не запускается rtcm, в логах docker logs rtcm: Caused by: java.net.UnknownHostException: postgres Если в docker-compose закомментировать postgres volume, то всё запускается нормально |
Смотрим включен ли Selinux (если Enforcing, значит включен) getenforce Альтернативный вариант при просмотре файлов, на конце прав видна точка: drwx------. ls -la Посмотрим права Selinux, если в них тип=usr_t, то значит мы на верном пути ls -Z Лечение. Вариант №1 (через docker-compose) Добавить буковку z к volume: volumes: - ./postgres_data:/var/lib/postgresql/data:z затем разрушить контейнеры и поднять снова docker-compose down docker-compose -p rtcm up -d Лечение. Вариант №2 (через изменение прав в selinux) Удалим директорию (внимание, если ранее rtcm работал, то сделать бэкап этой директории), создадим новую [опциональный backup] cp ./postgresdata <some_dir> docker-compose down rm postgres_data -R mkdir postgres_data chcon -u system_u postgres_data -R chcon -r object_r postgres_data -R chcon -t container_file_t postgres_data -R docker-compose -p rtcm up -d |
| № | Описание проблемы | Способ решения |
| 1 |
6/12/13 20:19:39 INFO ipc.Client: Retrying connect to server: hostname/ip:port. Already tried 2 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=3, sleepTime=1000 MILLISECONDS)
|
Если делать graceful рестарт ярна, то он не отпускает старые yarn-менеджеры пока на них не отработают таски, при этом новые джобы могут на них попадать. Тут может случится затык, что новые джобы не могут достучаться и будут висеть 30 минут пока не умрут. Как только все отомрет использующее старые контейнеры до рестарта, то все нормализуется. Как вариант решения - килл всех текущих джобов или рестарт resource-manager'а на неймноде. |
| 2 |
Зависание job reduce -> copy Симптомы: кластер слабо реагирует, джобы весят, вплоть до дедлока. reduce -> copy, average speed (0.00 mb/s). |
Как правило причина в дисках. Надо смотреть диски по нодам. Можно попробовать вычислить ноду по отсылке в редюсере в мап-контейнере, который меделенно отдавал. Если таких контейнров много, то это оно.
|
| 3 | Зависание джобов на этапе шедуллинга Долго висит в статусе ACCEPTED |
Скорее всего resource manager пошел в зависшую ноду и она не отдает ответ об аллокации контейнера. Еще один симтом: в маппере/редюсере ошибка "Timed out after 600 secs Container released on a *lost* node", значит именно эта нода зависла. |
| 4 | Exceeded MAX_FAILED_UNIQUE_FETCHES; bailing-out. Error: org.apache.hadoop.mapreduce.task.reduce.Shuffle$Shuffle Error: error in shuffle in fetcher#2 at org.apache.hadoop.mapreduce.task.reduce.Shuffle.run(Shuffle.java:134) at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:376) at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:163) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.apache.hadoop.security.UserGroupInformation.doAs (UserGroupInformation.java:1671) at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:158) Caused by: java.io.IOException: Exceeded MAX_FAILED_UNIQUE_FETCHES; bailing-out. |
При данной ошибке не видно ноду, с которой fetcher не смог забрать результаты. Найти нужные ноды можно следующим способом: hadoop fs -cat webhdfs://namenode_fqdn/var/log/hadoop-yarn/apps/mail/logs /application_ID/* > /tmp/application_ID Ошибка проявляется во время graceful рестарта ярна. Ярн сразу не отдает старый инстанс ярна и он еще используется, но потом завершается. Видимо в этот промежуток нарушается связь между контейнерами и выдает эту самую ошибку bailing-out. |
| 5 |
Проблема с диском на одной из нод 13:13:22,332 FATAL [IPC Server handler 1 on 36863] org.apache.hadoop.mapred. TaskAttemptListenerImpl: Task: attempt_1467282885944_447475_m_001113_1 - exited : java.io.IOException: Spill failed |
Смотреть мониторинг по участвующим в джобе нодам. |
| 6 |
Битые блоки в HDFS. При этом в логах можно найти следующие предупреждения (грепать паттерн "Failed to connect"): 2016-10-05 12:13:05,808 WARN [fetcher#3] org.apache.hadoop.mapreduce.task.reduce.Fetcher: Failed to connect to FQDN:PORT with 20 map outputs java.io.IOException: Got invalid response code 401 from http://FQDN:PORT/mapOutput? job=job_1467282885944_475266&reduce=6&map=attempt_1467282885944_475266_m_000071_0, Или ошибки, говорящие о том, что узлы не могут установить соединение друг с другом (грепать паттерн "ERROR"): 2016-10-05 12:09:32,078 ERROR [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm. RMContainerAllocator: Container complete event for unknown container id container_1467282885944_475266_01_002029 Или вот такие, более явные - Connection Refused (грепать паттерн "FATAL"): 2016-10-03 18:32:15,054 FATAL [IPC Server handler 19 on 53888] org.apache.hadoop.mapred. TaskAttemptListenerImpl: Task: attempt_1467282885944_467710_m_000143_0 - exited : java.lang.RuntimeException: java.io.IOException: java.net.ConnectException: Connection refused И, наконец, сами ошибки HDFS (они проявились через несколько дней, после появления ошибок с подключением между узлами): 2016-10-03 19:39:58,118 FATAL [IPC Server handler 5 on 33631] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Task: attempt_1467282885944_467896_r_000005_0 - exited : org.apache.hadoop.ipc.RemoteException(org.apache. hadoop.hdfs.server.namenode.LeaseExpiredException): No lease on PATH/_temporary /1/_temporary/attempt_1467282885944_467896_r_000005_0/part-00005 (inode 440196493): File does not exist. Holder DFSClient_attempt_1467282885944_467896_r_000005_0_1977697967_1 does not have any open files. at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkLease(FSNamesystem.java:3602) File does not exist. |
Как лечить: 1. Проверить диски на нодах (и вывести проблемные диски из-под YARN) 2. Проверить HDFS. su hdfs hdfs fsck / -files -list-corruptfileblocks |
| 7 |
Падение NodeManager Caused by: org.apache.hadoop.ipc.RemoteException(java.lang.NullPointerException): java.lang.NullPointerException ... Halting due to Out Of Memory Error... Halting due to Out Of Memory Error... |
Это значит, что NodeManager'у не хватает памяти. Как лечить: Идем в yarn-env.sh на каждой машине кластера. Находим там JAVA_HEAP_MAX=-Xmx<XXX>m, YARN_HEAPSIZE=<XXX>, где XXX - объем памяти в mb, выдеяемые jav'е в NodeManager на данный момент. Заменяем на JAVA_HEAP_MAX=-Xmx<YYY>m, YARN_HEAPSIZE=<YYY>, где YYY - объем памяти в mb, которые хотим дать jav'е в NodeManager. Рестартим YARN. |
| 8 |
Переполнение диска 2016-12-29 13:41:23,213 WARN [CommitterEvent Processor #3] org.apache.hadoop.mapreduce.lib.output. FileOutputCommitter: Could not delete hdfs://FQDN_NN/PATH/empty /_temporary/1/_temporary/attempt_1479403045764_220619_m_000040_1 |
Возникает при физической нехватки места на дисках при записи промежуточных результатов MapReduce в диск. Чаще всего связано с забитостью места в кластере. Troubleshooting: 1. Нехватка места 2. Много данных генерит джоб |
| 9 |
Если имеется много мелких файлов и distcp копирует крайне медленно, можно изменить стратегию копирования и количество splits/chunks. При ошибке: |
hadoop distcp -D ipc.client.fallback-to-simple-auth-allowed=true -D distcp.dynamic.recordsPerChunk=50 -D distcp.dynamic.max.chunks.tolerable=10000 -skipcrccheck -update -m 600 -bandwidth 8192 -strategy dynamic URI_SCR URI_DST |
| 10 | hadoop-client при работе с hdfs падает с ошибкой недостатка heap | export HADOOP_CLIENT_OPTS="-Xms4096m -Xmx4096m" |
| 11 | Процедура устранения ошибочного удаления чего-то на hdfs | 1) сейфмод без промедлений 2) стоп неймнод 3) бэкап меты везде, где можно Далее: 1) ищем последний edits_in_progress 2) конвертим в xml hdfs oev -i edits_inprogress_0000000000000001689 -o edits_inprogress_0000000000000001689.xml 3) находим OPERATION с командой на удаление пути 4) удаляем эту операцию и конвертим xml в бинарный edit и заменяем его в папке с метой (по-хорошему его надо заложить и на других неймноды - тут не уверен) hdfs oev -i edits_inprogress_0000000000000001689.xml -o edits_inprogress_0000000000000001689 -p binary 5) запускаем recover |
| 12 | java.sql.SQLException: Access denied for user 'hive'@'hadoop-m2' (using password: YES) | mysql -u root -p -hlocalhost Enter password: mysql> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'%' IDENTIFIED BY 'password'; mysql> FLUSH PRIVILEGES; |
| 13 |
Ошибка при запуске таски в yarn, зависает в статусе NEW_SAVING. Свитчовер RM. Ошибка в RM: INFO org.apache.zookeeper.ClientCnxn: Session establishment complete on server hadoop-m3.rtk/10.42.12.227:2181, sessionid = 0x1836a5253b0006f, negotiated timeout = 10000 Ошибка в zookeeper: WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x837fb9b9854d35 due to java.io.IOException: Len error 1158341 |
Выставить значение jute.maxbuffer в конфиге /etc/zookeeper/conf/zookeeper-env.sh. По умолчанию 1мб. export SERVER_JVMFLAGS="$SERVER_JVMFLAGS -Dcom.sun.management.jmxremote.port=9982 -Djute.maxbuffer=2000000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false" |
| № | Описание проблемы | Способ решения |
|---|---|---|
| 1 |
| № | Описание проблемы | Способ решения |
|---|---|---|
| 1 |
| № | Описание проблемы | Способ решения |
|---|---|---|
| 1 |
| № | Описание проблемы | Способ решения |
|---|---|---|
| 1 | INFO org.apache.hadoop.service.AbstractService: Service ResourceManager failed in state STARTED; cause: java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap') java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap') FATAL org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Error starting ResourceManager java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap') |
| № | Описание проблемы | Способ решния |
|---|---|---|
| 1 |
| № | Описание проблемы | Способ решния |
|---|---|---|
| 1 | ERROR org.apache.hadoop.yarn.server.applicationhistoryservice.ApplicationHistoryServer: Error starting ApplicationHistoryServer java.lang.NoClassDefFoundError: javax/activation/DataSource |
| № | Описание проблемы | Способ решния |
|---|---|---|
| 1 |
| № | Описание проблемы | Способ решния |
|---|---|---|
| 1 |