集群有狀態(tài)重啟包括哪些內(nèi)容？

集群有狀態(tài)重啟包括RM Restart和NM Restart兩部分，ResourceManager（簡(jiǎn)稱RM）負(fù)責(zé)維護(hù)應(yīng)用級(jí)基礎(chǔ)信息與狀態(tài)，NodeManager（簡(jiǎn)稱NM）負(fù)責(zé)維護(hù)運(yùn)行時(shí)的Container信息與狀態(tài)，它們持續(xù)將相關(guān)狀態(tài)同步至外部存儲(chǔ)（Zookeeper、LevelDB和HDFS等），并在重啟后重新加載狀態(tài)自行恢復(fù)，保證集群升級(jí)或重啟后應(yīng)用自動(dòng)恢復(fù)，通常情況下可以做到應(yīng)用無(wú)感知。

如何啟用RM HA？

如何配置熱更新？

1. 開(kāi)啟關(guān)鍵配置。

   您可以在EMR控制臺(tái)YARN服務(wù)的配置頁(yè)簽，檢查或者配置以下參數(shù)。

   參數(shù)	描述	參數(shù)值（推薦）
   yarn.scheduler.configuration.store.class	使用的后備存儲(chǔ)的類型。例如，設(shè)置為fs，表示使用FileSystem類型存儲(chǔ)。	fs
   yarn.scheduler.configuration.max.version	保留歷史版本的最大數(shù)量，超出自動(dòng)清理。	100
   yarn.scheduler.configuration.fs.path	capacity-scheduler.xml文件存儲(chǔ)路徑。 不存在存儲(chǔ)路徑時(shí)，則自動(dòng)創(chuàng)建。不指定前綴時(shí)，則默認(rèn)defaultFs的相對(duì)路徑。	/yarn/<集群名>/scheduler/conf 重要 將<集群名>替換為集群名稱以便區(qū)分，可能有多個(gè)YARN集群對(duì)應(yīng)同一分布式存儲(chǔ)的情況。

2. 查看capacity-scheduler.xml配置。

   • 方式一（REST API）：http://<rm-address>/ws/v1/cluster/scheduler-conf。

   • 方式二（HDFS文件）：${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp>，其中后綴<timestamp>值最大的文件是最新的配置文件。

3. 更新配置。

   示例：更新一個(gè)配置項(xiàng)yarn.scheduler.capacity.maximum-am-resource-percent，并刪除配置項(xiàng)yarn.scheduler.capacity.xxx，刪除某配置項(xiàng)只需去掉其Value值。

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

如何處理Queue內(nèi)應(yīng)用分配不均？

如何查看隊(duì)列資源使用情況？

要查看隊(duì)列資源使用情況，您可以在YARN WebUI頁(yè)面查看Used Capacity參數(shù)。Used Capacity參數(shù)表示該隊(duì)列已使用的資源占該隊(duì)列整體資源的百分比，分別計(jì)算Memory和vCores占總體的比例，并選取最大值作為隊(duì)列整體資源使用的比例。具體查看操作如下：

1. 訪問(wèn)YARN UI，詳情請(qǐng)參見(jiàn)訪問(wèn)鏈接與端口。

2. 在All Applications頁(yè)面，單擊目標(biāo)作業(yè)的ID。

3. 單擊Queue行的隊(duì)列。

   在Application Queues區(qū)域，可以查看隊(duì)列資源使用情況。

   

YARN服務(wù)組件.out日志為何會(huì)大量堆積且無(wú)法自動(dòng)清理？

• 問(wèn)題原因：Hadoop組件部分依賴庫(kù)使用Java Logging APIs來(lái)生成日志記錄，不支持使用log4j配置的日志輪轉(zhuǎn)。目前這些daemon組件的stderr輸出被重定向到.out文件中，沒(méi)有自動(dòng)清理機(jī)制，長(zhǎng)時(shí)間積累可能導(dǎo)致數(shù)據(jù)盤(pán)存儲(chǔ)空間被占滿。

• 處理方法：可以使用head和tail命令結(jié)合日志中生成的時(shí)間戳信息，來(lái)判斷是否由于Java Logging APIs生成的日志導(dǎo)致存儲(chǔ)空間占用過(guò)大。通常情況下，這些依賴庫(kù)產(chǎn)生的都是INFO級(jí)別日志，不影響組件正常功能使用，但為了避免數(shù)據(jù)盤(pán)存儲(chǔ)空間被占用，可以采取修改配置的方式禁用此類日志的生成。

  例如，在優(yōu)化TimelineServer組件以關(guān)閉jersey依賴庫(kù)的日志生成時(shí)，操作步驟如下：

  1. 通過(guò)以下命令，監(jiān)控YARN日志路徑中與hadoop-timelineserver-相關(guān)的.out日志文件。DataLake集群的日志路徑為/var/log/emr/yarn/，Hadoop集群日志路徑為/mnt/disk1/log/hadoop-yarn。

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     觀察到輸出日志中包含由com.sun.jersey組件產(chǎn)生的記錄。

     

  2. 為了禁止組件輸出Jersey庫(kù)的INFO級(jí)別日志到.out 文件，創(chuàng)建并配置一個(gè)文件來(lái)關(guān)閉其日志生成。在運(yùn)行有TimelineServer組件的EMR節(jié)點(diǎn)上，可以通過(guò)執(zhí)行以下命令以root權(quán)限創(chuàng)建并編輯配置文件。

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

  3. 在EMR控制臺(tái)中YARN服務(wù)的配置頁(yè)面，查找YARN_TIMELINESERVER_OPTS參數(shù)（Hadoop集群為yarn_timelineserver_opts），并在此參數(shù)值后添加-Djava.util.logging.config.file=off-logging.properties，指定剛剛創(chuàng)建的配置文件位置。

     

  4. 保存上述配置更改后，重啟TimelineServer組件使新設(shè)置生效。持續(xù)觀察一段時(shí)間，如果TimelineServer組件正常啟動(dòng)，并且.out日志中不再出現(xiàn)任何與com.sun.jersey相關(guān)的日志信息，則說(shuō)明關(guān)閉jersey依賴庫(kù)日志的操作已成功完成。

如何檢查ResourceManager服務(wù)是否正常？

如何了解應(yīng)用運(yùn)行狀況？

應(yīng)用問(wèn)題排查流程

1. 檢查App狀態(tài)，通過(guò)App詳情頁(yè)或App REST API檢查App狀態(tài)。

   • 未找到App狀態(tài)，可能原因：

     • 客戶端向YARN提交之前失敗退出：客戶端組件問(wèn)題（檢查提交客戶端日志：BRS、flowagent等組件）。

     • 客戶端無(wú)法連接YARN RM：檢查連接RM地址是否正確、網(wǎng)絡(luò)是否存在問(wèn)題。如有網(wǎng)絡(luò)問(wèn)題，客戶端可能存在報(bào)錯(cuò)：com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed。

   • NEW_SAVING：該狀態(tài)處于Zookeeper State Store寫(xiě)入應(yīng)用信息階段。持續(xù)該狀態(tài)可能原因如下：

     • Zookeeper存在問(wèn)題，檢查Zookeeper服務(wù)是否正常。

     • Zookeeper讀寫(xiě)數(shù)據(jù)問(wèn)題，處理方法請(qǐng)參見(jiàn)RM處于Standby狀態(tài)，無(wú)法自動(dòng)恢復(fù)Active狀態(tài)，該如何處理？。

   • SUBMITTED：該狀態(tài)極少遇到，可能原因?yàn)镹ode Update請(qǐng)求太多造成Capacity Scheduler內(nèi)部搶鎖堵塞，通常發(fā)生在大規(guī)模集群，需優(yōu)化相關(guān)流程。相關(guān)案例，請(qǐng)參見(jiàn)YARN-9618。

   • ACCEPTED：檢查Diagnostics。請(qǐng)根據(jù)提示信息，選擇相應(yīng)的處理方式。

     • 報(bào)錯(cuò)提示Queue's AM resource limit exceeded。

       • 可能原因：Queue AM已使用資源和AM資源之和超出了Queue AM資源上限，UI條件為${Used Application Master Resources} + ${AM Resource Request} < ${Max Application Master Resources}。

       • 處理方法：上調(diào)該Queue的AM資源上限。例如，設(shè)置參數(shù)yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent為0.5。

     • 報(bào)錯(cuò)提示User's AM resource limit exceeded。

       • 可能原因：Queue user AM已使用資源和AM資源之和超出了Queue user AM資源上限。

       • 處理方法：提高user-limit比例。您可以修改參數(shù)yarn.scheduler.capacity.<queue-path>.user-limit-factor和yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent的參數(shù)值。

     • 報(bào)錯(cuò)提示AM container is launched, waiting for AM container to Register with RM。

       • 可能原因：AM已啟動(dòng)，內(nèi)部初始化未完成（例如，Zookeeper連接超時(shí)等）。

       • 處理方法：需要根據(jù)AM日志進(jìn)一步排查問(wèn)題。

     • 報(bào)錯(cuò)提示Application is Activated, waiting for resources to be assigned for AM。

       執(zhí)行步驟3，檢查AM資源分配為何未滿足。

   • RUNNING：執(zhí)行步驟2，檢查Container資源請(qǐng)求是否完成。

   • FAILED：檢查diagnostics。請(qǐng)根據(jù)提示信息，選擇相應(yīng)的處理方式。

     • 報(bào)錯(cuò)提示Maximum system application limit reached,cannot accept submission of application

       • 可能原因：集群內(nèi)運(yùn)行中的總應(yīng)用數(shù)超過(guò)上限（配置項(xiàng)：yarn.scheduler.capacity.maximum-applications，默認(rèn)值：10000）。

       • 處理方法：檢查JMX Metrics，確認(rèn)各隊(duì)列運(yùn)行的應(yīng)用數(shù)是否符合預(yù)期，找出并處理有大量重復(fù)提交的問(wèn)題應(yīng)用。如果應(yīng)用都正常，可以根據(jù)集群水位情況適當(dāng)調(diào)大上述配置。

     • 報(bào)錯(cuò)提示Application XXX submitted by user YYY to unknown queue: ZZZ

       • 可能原因：提交到不存在的queue。

       • 處理方法：提交到已存在的leaf queue。

     • 報(bào)錯(cuò)提示Application XXX submitted by user YYY to non-leaf queue: ZZZ

       • 可能原因：提交到parent queue。

       • 處理方法：提交到已存在的leaf queue。

     • 報(bào)錯(cuò)提示Queue XXX is STOPPED. Cannot accept submission of application: YYY

       • 可能原因：提交到STOPPED或DRAINING queue（已下線或正在下線的queue）。

       • 處理方法：提交到RUNNING queue（工作狀態(tài)正常的queue）。

     • 報(bào)錯(cuò)提示Queue XXX already has YYY applications, cannot accept submission of application: ZZZ

       • 可能原因：queue應(yīng)用數(shù)達(dá)到上限。

       • 處理方法：

         1. 檢查queue內(nèi)是否有大量重復(fù)提交的問(wèn)題應(yīng)用。

         2. 調(diào)整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications。

     • 報(bào)錯(cuò)提示Queue XXX already has YYY applications from user ZZZ cannot accept submission of application: AAA

       • 可能原因：user應(yīng)用數(shù)達(dá)到上限。

       • 處理方法：

         1. 檢查該user是否有大量重復(fù)提交的問(wèn)題應(yīng)用。

         2. 調(diào)整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications、yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent、yarn.scheduler.capacity.<queue-path>.user-limit-factor。

2. 確認(rèn)YARN資源分配還未完成。

   1. 在apps列表頁(yè)，單擊appID進(jìn)入AM頁(yè)面。

   2. 單擊下方列表的AM-ID，進(jìn)入AM-Attempt頁(yè)面。

   3. 查看Total Outstanding Resource Requests列表中是否有Pending資源（也可以通過(guò)PendingRequests REST API查詢）：

      • 沒(méi)有Pending資源：說(shuō)明YARN已分配完畢，退出該檢查流程，檢查AM情況。

      • 有Pending資源：說(shuō)明YARN資源分配未完成，繼續(xù)下一步檢查。

3. 資源限制檢查。

   檢查集群或Queue資源，查看資源信息，例如，Effective Max Resource和Used Resources。

   1. 檢查集群資源或所在Queue資源或其父Queue資源是否已用完。

   2. 檢查葉子隊(duì)列某維度資源是否接近或達(dá)到上限。

   3. 當(dāng)集群資源接近用滿時(shí)（例如85%以上），應(yīng)用的分配速度可能會(huì)變慢，因?yàn)榇蟛糠謾C(jī)器都沒(méi)有資源了，分配的機(jī)器沒(méi)有資源就會(huì)reserve，reserve到一定個(gè)數(shù)后分配就會(huì)變慢，另外也可能是由于內(nèi)存資源和CPU資源不成比例，例如，有的機(jī)器上內(nèi)存資源有空閑但CPU資源已經(jīng)用滿，有的機(jī)器上CPU資源有空閑但內(nèi)存已經(jīng)用滿。

4. 檢查是否存在Container資源分配成功但啟動(dòng)失敗的情況，YARN UI的App Attempt頁(yè)面可以看到已分配的Container數(shù)（間隔一小段時(shí)間觀察是否變化），如果有Container啟動(dòng)失敗，查看對(duì)應(yīng)的NM日志或Container日志進(jìn)一步排查失敗原因。

5. 動(dòng)態(tài)修改日志級(jí)別：在YARN UI的logLevel頁(yè)面（http://RM_IP:8088/logLevel），將org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity（CapacityScheduler調(diào)度邏輯所在的package）參數(shù)的日志級(jí)別改為DEBUG，如下圖所示。

   重要

   您需要在復(fù)現(xiàn)問(wèn)題的同時(shí)打開(kāi)，持續(xù)幾十秒（由于日志刷新的很快，無(wú)需持續(xù)太長(zhǎng)時(shí)間），日志級(jí)別改回INFO即可恢復(fù)。

單任務(wù)/容器（Container）最大可用資源由哪些配置項(xiàng)決定？

YARN配置修改未生效，如何處理？

• 可能原因

  • 非熱更新配置，配置關(guān)聯(lián)的組件未重啟。

  • 熱更新配置，配置生效所需的指定操作未執(zhí)行。

• 解決方案：請(qǐng)確保相關(guān)配置修改的后續(xù)操作正確執(zhí)行。

  配置集	配置類型	更新后續(xù)操作
  capacity-scheduler.xml fair-scheduler.xml	調(diào)度器配置。	熱更新配置，需要執(zhí)行RM組件的refresh_queues操作。
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	YARN組件運(yùn)行配置。	重啟配置關(guān)聯(lián)組件。例如： 修改配置yarn-env.sh中的YARN_RESOURCEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.resourcemanager.nodes.exclude-path等配置項(xiàng)后，需重啟RM。 修改配置yarn-env.sh中的YARN_NODEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.nodemanager.log-dirs等配置項(xiàng)后，需重啟NM。 修改配置mapred-env.sh中的MAPRED_HISTORYSERVER_OPTS、mapred-site.xml中的mapreduce.jobhistory.http.policys等配置項(xiàng)后，需重啟MRHistoryServer。

客戶端異常，提示Exception while invoking getClusterNodes of class ApplicationClientProtocolPBClientImpl over rm2 after 1 fail over attempts. Trying to fail over immediately

• 問(wèn)題現(xiàn)象：無(wú)法正常訪問(wèn)Active ResourceManager。ResourceManager日志異常，提示信息：WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33.**.**:53144 got version 6 expected version 9。

• 問(wèn)題原因：Hadoop版本太舊，導(dǎo)致客戶端RPC版本不兼容。

• 處理方法：使用匹配的Hadoop版本。

RM處于Standby狀態(tài)，無(wú)法自動(dòng)恢復(fù)Active狀態(tài)，該如何處理？

RM組件OOM如何處理？

為什么節(jié)點(diǎn)啟動(dòng)任務(wù)時(shí)Localize失敗或任務(wù)日志無(wú)法采集與刪除？

• 問(wèn)題現(xiàn)象：NM日志異常，提示java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider。

• 可能原因：HDFS配置異常。

• 處理方法：

  1. 以上是封裝后的異常，非根因，需要打開(kāi)DEBUG級(jí)別日志查看：

     • hadoop客戶端命令行環(huán)境（例如執(zhí)行hadoop fs -ls /命令），開(kāi)啟DEBUG調(diào)試信息。

       export HADOOP_LOGLEVEL=DEBUG

     • 有Log4j配置的運(yùn)行環(huán)境，Log4j末尾增加log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG。

  2. 以下示例的根因是用戶曾修改過(guò)NameServices配置，將emr-cluster修改為了hadoop-emr-cluster，但是擴(kuò)容節(jié)點(diǎn)時(shí)使用了修改前的配置。

  3. 在EMR控制臺(tái)HDFS服務(wù)的配置頁(yè)面，檢查各項(xiàng)配置是否正確。

資源本地化異常，該如何處理？

• 問(wèn)題現(xiàn)象：

  • Job AM Container啟動(dòng)失敗，異常信息如下。

    Failed job diagnostics信息為：Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted

  • 在資源本地化過(guò)程中（下載后解壓時(shí)）報(bào)錯(cuò)，NodeManager日志信息如下。

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)

• 問(wèn)題原因：壓縮包內(nèi)含有軟鏈接導(dǎo)致資源本地化異常。

• 處理方法：刪除該壓縮包內(nèi)包含的軟鏈接。

Container啟動(dòng)失敗或運(yùn)行異常，報(bào)錯(cuò)提示No space left on device，該如何處理？

節(jié)點(diǎn)NM服務(wù)或任務(wù)運(yùn)行時(shí)無(wú)法正常解析域名，該如何處理？

• 問(wèn)題現(xiàn)象：報(bào)錯(cuò)提示java.net.UnknownHostException: Invalid host name: local host is: (unknown)。

• 問(wèn)題原因及處理方法：

  • 查看是否正確配置了DNS服務(wù)器。

    通過(guò)以下命令，檢查配置信息。

    cat /etc/resolv.conf

  • 查看防火墻是否設(shè)置了53端口的相關(guān)規(guī)則。

    如果設(shè)置了，請(qǐng)關(guān)閉防火墻。

  • 查看是否開(kāi)啟了DNS的NSCD緩存服務(wù)。

    通過(guò)以下命令，檢查服務(wù)狀態(tài)。

    systemctl status nscd

    如果開(kāi)啟了DNS的NSCD緩存服務(wù)，可以執(zhí)行以下命令，停止緩存服務(wù)。

    systemctl stop nscd

NM組件OOM如何處理？

ECS實(shí)例重啟后NM啟動(dòng)失敗：cgroup目錄丟失，如何處理？

• 詳細(xì)異常信息：ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

• 原因：ECS異常重啟可能是ECS內(nèi)核缺陷（已知問(wèn)題版本：4.19.91 -21.2.al7.x86_64）導(dǎo)致的。重啟后CPU cgroup失效問(wèn)題，原因是重啟后cgroup的內(nèi)存數(shù)據(jù)會(huì)被銷毀掉。

• 解決方案：修改存量集群節(jié)點(diǎn)執(zhí)行和擴(kuò)容節(jié)點(diǎn)的引導(dǎo)腳本，在當(dāng)前環(huán)境中創(chuàng)建cgroup目錄并且用rc.local在以后ECS啟動(dòng)的時(shí)候創(chuàng)建目錄。

  # enable cgroups
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
  # enable cgroups after reboot
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  chmod +x /etc/rc.d/rc.local

修改NM resource配置，保存重啟后未生效，如何處理？

• 報(bào)錯(cuò)說(shuō)明：修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb參數(shù)，保存重啟NM后，NM資源數(shù)未修改。

• 問(wèn)題原因：由于機(jī)器組可能使用不同CPU內(nèi)存規(guī)格的實(shí)例，所以修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb參數(shù)，需要修改節(jié)點(diǎn)組維度的配置才能生效。

• 解決方案：在EMR控制臺(tái)，選擇節(jié)點(diǎn)組維度，選擇需要配置的NM所在節(jié)點(diǎn)組修改資源數(shù)的配置，具體操作請(qǐng)參見(jiàn)管理配置項(xiàng)。

節(jié)點(diǎn)出現(xiàn)Unhealthy問(wèn)題，如何處理？

• 原因：

  • 磁盤(pán)檢查發(fā)現(xiàn)異常：當(dāng)正常目錄數(shù)或總目錄數(shù)比率低于磁盤(pán)健康比例（yarn-site.xml配置項(xiàng)yarn.nodemanager.disk-health-checker.min-healthy-disks，默認(rèn)值：0.25）時(shí)，將節(jié)點(diǎn)標(biāo)記為UnHealthy。例如NM節(jié)點(diǎn)使用4塊磁盤(pán)，當(dāng)4塊磁盤(pán)上的目錄均不正常時(shí)節(jié)點(diǎn)才會(huì)標(biāo)記為UnHealthy，否則只在NM狀態(tài)報(bào)告中顯示local-dirs are bad或log-dirs are bad，參見(jiàn)節(jié)點(diǎn)磁盤(pán)問(wèn)題：local-dirs are bad/log-dirs are bad，如何處理？。

  • NM健康檢查腳本發(fā)現(xiàn)異常：該項(xiàng)檢查默認(rèn)未啟用，需要主動(dòng)配置健康檢查腳本（yarn-site.xml配置項(xiàng)yarn.nodemanager.health-checker.script.path）才能開(kāi)啟。

• 解決方案

  • 磁盤(pán)問(wèn)題，請(qǐng)參見(jiàn)節(jié)點(diǎn)磁盤(pán)問(wèn)題：local-dirs are bad/log-dirs are bad，如何處理？中的解決方案。

  • 健康檢查腳本問(wèn)題，請(qǐng)根據(jù)自定義腳本處理。

節(jié)點(diǎn)磁盤(pán)問(wèn)題：local-dirs are bad/log-dirs are bad，如何處理？

• 原因：磁盤(pán)檢查發(fā)現(xiàn)異常。該項(xiàng)檢查默認(rèn)開(kāi)啟，周期性檢查local-dirs（任務(wù)運(yùn)行緩存目錄，包括任務(wù)運(yùn)行依賴的各類文件、中間數(shù)據(jù)文件等）與log-dirs（任務(wù)運(yùn)行日志目錄，包含全部日志運(yùn)行）是否滿足以下條件，只要有一項(xiàng)不滿足就會(huì)被標(biāo)記為bad。

  • 可讀

  • 可寫(xiě)

  • 可執(zhí)行

  • 磁盤(pán)空間使用率是否低于配置閾值（yarn-site.xml配置項(xiàng)yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage，默認(rèn)：90%）

    磁盤(pán)剩余可用空間是否大于磁盤(pán)最小可用空間的配置值（yarn-site.xml配置項(xiàng)yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb，默認(rèn)：0）

• 解決方案

  • 一般都是磁盤(pán)空間不足引起，如果確認(rèn)存在下述場(chǎng)景之一，建議擴(kuò)容磁盤(pán)：

    • NM節(jié)點(diǎn)規(guī)格較大，可運(yùn)行任務(wù)數(shù)較多。

    • 磁盤(pán)空間相對(duì)較小。

    • 任務(wù)運(yùn)行所依賴的數(shù)據(jù)或文件較大。

    • 任務(wù)運(yùn)行產(chǎn)生的中間數(shù)據(jù)較多。

    • 任務(wù)日志相對(duì)較大（磁盤(pán)空間占比高）。

  • 檢查yarn-site.xml配置項(xiàng)yarn.nodemanager.localizer.cache.target-size-mb，如果相對(duì)磁盤(pán)比例過(guò)大會(huì)造成歷史任務(wù)緩存占用磁盤(pán)空間過(guò)多（超出配置值后才能自動(dòng)清理）。

  • 壞盤(pán)問(wèn)題，請(qǐng)參見(jiàn)自助壞盤(pán)維修流程更換集群損壞的本地盤(pán)。

報(bào)錯(cuò)提示User [dr.who] is not authorized to view the logs for application ***，該如何處理？

• 問(wèn)題現(xiàn)象：打開(kāi)日志頁(yè)面時(shí)，提示信息如下。

• 問(wèn)題原因：訪問(wèn)NodeManager Log頁(yè)面時(shí)會(huì)檢查ACL規(guī)則。如果啟用了ACL規(guī)則，遠(yuǎn)程用戶就要符合以下任一個(gè)條件：

  • 是admin用戶。

  • 是app owner。

  • 滿足app自定義ACL規(guī)則。

• 處理方法：檢查是否滿足以上條件中的任一條。

報(bào)錯(cuò)提示HTTP ERROR 401 Authentication required或HTTP ERROR 403 Unauthenticated users are not authorized to access this page，該如何處理？

• 問(wèn)題現(xiàn)象：訪問(wèn)UI或REST API時(shí)報(bào)錯(cuò)HTTP ERROR 401或HTTP ERROR 403。HTTP ERROR 401詳細(xì)信息如下圖。

  

• 問(wèn)題原因：YARN啟用了Simple認(rèn)證且不允許匿名訪問(wèn)，詳情請(qǐng)參見(jiàn)Authentication for Hadoop HTTP web-consoles。

• 處理方法：

  • 方式一：URL參數(shù)中顯示指定遠(yuǎn)程用戶，例如，user.name=***。

  • 方式二：您可以在E-MapReduce控制臺(tái)的HDFS服務(wù)的配置頁(yè)簽，在搜索區(qū)域搜索參數(shù)hadoop.http.authentication.simple.anonymous.allowed，修改其參數(shù)值為true允許匿名訪問(wèn)，參數(shù)含義請(qǐng)參見(jiàn)Authentication for Hadoop HTTP web-consoles。然后重啟服務(wù)，請(qǐng)參見(jiàn)重啟服務(wù)。

為什么TotalVcore顯示值不準(zhǔn)確？

在YARN UI右上方，Cluster或Metrics REST API結(jié)果中，TotalVcore顯示值不準(zhǔn)確。此問(wèn)題是由于社區(qū)2.9.2之前版本TotalVcore計(jì)算邏輯有問(wèn)題，詳情請(qǐng)參見(jiàn)https://issues.apache.org/jira/browse/YARN-8443。

EMR-3.37.x和EMR-5.3.x及后續(xù)版本已修復(fù)此問(wèn)題。

TEZ UI展示的應(yīng)用信息不全，該如何處理？

為什么YARN UI頁(yè)面有一個(gè)正在運(yùn)行的Spark Thrift JDBC/ODBC Server任務(wù)？

如果您在創(chuàng)建集群時(shí)選擇了Spark服務(wù)，集群會(huì)自動(dòng)啟動(dòng)一個(gè)默認(rèn)的Spark Thrift Server服務(wù)。該服務(wù)會(huì)占用一個(gè)YARN Driver的資源。在Spark Thrift Server中運(yùn)行的任務(wù)，默認(rèn)會(huì)通過(guò)該Driver向YARN申請(qǐng)所需的資源。

yarn.timeline-service.leveldb-timeline-store.path是否支持使用OSS地址？

yarn.timeline-service.leveldb-timeline-store.path參數(shù)不支持使用OSS地址。

如果您創(chuàng)建的是Hadoop集群，則yarn.timeline-service.leveldb-timeline-store.path的默認(rèn)值與hadoop.tmp.dir參數(shù)相同。請(qǐng)不要修改HDFS的hadoop.tmp.dir參數(shù)，因?yàn)檫@會(huì)影響yarn.timeline-service.leveldb-timeline-store.path的配置。

Timeline Server連接超時(shí)、CPU或Memory占用異常高問(wèn)題，該如何處理？

在Tez任務(wù)特別多的情況下，寫(xiě)入YARN的Timeline Server時(shí)，可能會(huì)出現(xiàn)連接超時(shí)的問(wèn)題。這是因?yàn)門(mén)imeline Server進(jìn)程占用大量CPU導(dǎo)致節(jié)點(diǎn)CPU使用率達(dá)到極限，進(jìn)而影響到了作業(yè)開(kāi)發(fā)和其他非核心業(yè)務(wù)（例如報(bào)表生成），所以臨時(shí)停止TimelineServer進(jìn)程來(lái)減輕節(jié)點(diǎn)的CPU負(fù)載。您可以通過(guò)修改以下配置項(xiàng)來(lái)解決此問(wèn)題。

在EMR控制臺(tái)修改Tez和YARN服務(wù)的相應(yīng)配置，新增或修改配置的具體操作，請(qǐng)參見(jiàn)管理配置項(xiàng)。

1. 在EMR控制臺(tái)Tez服務(wù)的配置頁(yè)面的tez-site.xml頁(yè)簽，新增參數(shù)為tez.yarn.ats.event.flush.timeout.millis，參數(shù)值為60000的配置項(xiàng)，該參數(shù)用來(lái)設(shè)置Tez任務(wù)將事件寫(xiě)入YARN的Timeline Server時(shí)的超時(shí)時(shí)間。

2. 在EMR控制臺(tái)YARN服務(wù)的配置頁(yè)面的yarn-site.xml頁(yè)簽，新增或修改以下配置項(xiàng)。修改完配置項(xiàng)后需要在YARN服務(wù)的狀態(tài)頁(yè)面重啟下TimelineServer。

   參數(shù)	參數(shù)值	說(shuō)明
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	用于指定YARN Timeline Server的事件存儲(chǔ)類。
   yarn.timeline-service.rolling-period	daily	用于設(shè)置YARN Timeline Server的事件滾動(dòng)周期
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4194304	用于設(shè)置YARN Timeline Server LevelDB存儲(chǔ)的讀取緩存大小。
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4194304	用于設(shè)置YARN Timeline Server LevelDB存儲(chǔ)的寫(xiě)入緩沖區(qū)大小。
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	用于設(shè)置YARN Timeline Server LevelDB存儲(chǔ)的最大打開(kāi)文件數(shù)。