引導操作成功后節點供應器中的 EMR 從引導失敗

Question

我正在嘗試使用帶有 Spark 的 EMR 在 AWS 中啟動一個集群。 我有一個 bash 引導程序腳本來安裝一些 python 包、下載憑據並應用一些配置。 引導操作在 master 上成功，但在 slave 上失敗。 錯誤的唯一提示是“i-#####：無法啟動。引導操作 2 失敗，退出代碼為非零”。 緊接其前的消息是“i-#####：引導操作 1 已完成”。 （在這兩種情況下都是指從站的實例 ID。主站也報告引導操作 1 的成功）。

所以看起來在引導操作 2 中執行的最后一個命令有錯誤並導致引導腳本返回非零退出代碼。 但是，我只配置了一個 bootstrap action 。 非主節點是否有另一個自動運行的引導操作？

沒有任何日志顯示實際錯誤是什么。 我查看了 S3 上的引導程序日志（它不能可靠地顯示）並嘗試在啟動期間拖尾從站和主站上的 /var/log/bootstrap-actions/ 日志。

我很確定錯誤不在我的腳本中（每個開發人員都說過......）。 我能夠創建一個沒有引導的普通 EMR 集群，然后在等待后登錄並以用戶 hadoop 運行我的引導腳本，沒有錯誤。 我還查看了最后幾個命令（grep 和 echo）並驗證它們不會返回非零退出，也不會導致腳本返回非零退出代碼。

我認為問題一定出在一些神秘的第二次引導操作中。 是這種情況嗎？ 我如何確定錯誤？

更新我在啟動期間登錄到從節點。 我在/emr/instance-controller/lib/bootstrap-actions找到了引導/emr/instance-controller/lib/bootstrap-actions 。 只有 1 個子文件夾，它包含我的引導腳本。 然后我運行tail -f /emr/instance-controller/log/instance-controller.log 。 我驗證了我的腳本已啟動。 經過大約 15 個狀態檢查周期（15 分鍾）后，我看到

2017-06-02 13:44:30,173 INFO InstanceConfigurer: Script 1 - Execution succeeded

然后我看到另一個 AWS 腳本啟動，這似乎是失敗的腳本。

2017-06-02 13:44:30,181 INFO InstanceConfigurer: Running provision-node, with id 5aed1c54-4210-4387-944a-4fdbbce6dc8d
2017-06-02 13:44:30,188 INFO InstanceConfigurer: Script 5aed1c54-4210-4387-944a-4fdbbce6dc8d - Fetching file '/var/lib/aws/emr/provision-node'
2017-06-02 13:44:30,188 INFO InstanceConfigurer: Script 5aed1c54-4210-4387-944a-4fdbbce6dc8d - startExec '/var/lib/aws/emr/provision-node'
2017-06-02 13:44:30,189 INFO InstanceConfigurer: startExec '/var/lib/aws/emr/provision-node'
2017-06-02 13:44:30,190 INFO InstanceConfigurer: Script 5aed1c54-4210-4387-944a-4fdbbce6dc8d - Environment:
...
2017-06-02 13:44:54,201 INFO InstanceConfigurer: Output from command '/var/lib/aws/emr/provision-node':
stdout:
stderr:

2017-06-02 13:44:54,202 INFO InstanceConfigurer: Script 5aed1c54-4210-4387-944a-4fdbbce6dc8d - waitProcessCompletion ended with exit code 255 : /var/lib/aws/emr/provision-node
2017-06-02 13:44:54,202 INFO InstanceConfigurer: waitProcessCompletion ended with exit code 255 : /var/lib/aws/emr/provision-node
2017-06-02 13:44:54,203 INFO InstanceConfigurer: Script 5aed1c54-4210-4387-944a-4fdbbce6dc8d - total process run time: 24 seconds
2017-06-02 13:44:54,203 INFO InstanceConfigurer: total process run time: 24 seconds
2017-06-02 13:44:54,217 ERROR InstanceConfigurer: Script 5aed1c54-4210-4387-944a-4fdbbce6dc8d - Execution for /var/lib/aws/emr/provision-node failed with code '255'
2017-06-02 13:44:54,219 ERROR InstanceConfigurer: Startup failed with
aws157.instancecontroller.common.model.InstanceConfiguratorException: Source: PROVISION_NODE | ErrorCode: SCRIPT_EXECUTION_FAILED_CODE | Execution for /var/lib/aws/emr/provision-node failed with code '255'
    at aws157.instancecontroller.common.InstanceConfigurator.runScript(InstanceConfigurator.java:563)
    at aws157.instancecontroller.common.InstanceConfigurator.provisionNode(InstanceConfigurator.java:225)
    at aws157.instancecontroller.common.InstanceConfigurator.doDistributionConfigure(InstanceConfigurator.java:201)
    at aws157.instancecontroller.common.InstanceConfigurator.access$200(InstanceConfigurator.java:70)
    at aws157.instancecontroller.common.InstanceConfigurator$1.run(InstanceConfigurator.java:251)

我不熟悉那個/var/lib/aws/emr/provision-node腳本，但它的唯一內容是

#!/bin/bash
set -ex

sudo /usr/share/aws/emr/node-provisioner/bin/provision-node "$@"

查看/usr/share/aws/emr/node-provisioner/bin/provision-node ，我可以看到這個腳本做了很多工作來識別 $EMR_NODE_PROVISIONER_HOME 的路徑，然后從那里運行以下 Java 類

java -classpath '/usr/share/aws/emr/node-provisioner/lib/*' com.amazonaws.emr.node.provisioner.Program --phase hadoop _UUID_

我通過查看供應節點腳本的源代碼並獨立運行它來解決這個問題。 我無法實時捕獲日志或故障以查看出了什么問題。 當我單獨運行它時，出現以下異常。 但我認為這是因為我傳遞的是垃圾數據而不是 UUID（我不知道 UUID 來自哪里，並且在每個從站啟動時都不同）。

2017-06-02 14:55:13,593 ERROR main: Encountered a problem while provisioning
java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    at java.net.SocketInputStream.read(SocketInputStream.java:171)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
    at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
    at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1569)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
    at com.google.api.client.http.javanet.NetHttpResponse.<init>(NetHttpResponse.java:37)
    at com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:94)
    at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:972)
    at com.amazonaws.emr.node.provisioner.http.JsonHttpClient.doRequest(JsonHttpClient.java:49)
    at com.amazonaws.emr.node.provisioner.platform.EmrPlatformClient.getConfiguration(EmrPlatformClient.java:38)
    at com.amazonaws.emr.node.provisioner.platform.EmrPlatformClient.getConfiguration(EmrPlatformClient.java:31)
    at com.amazonaws.emr.node.provisioner.bigtop.config.PlatformContextProvider.provide(PlatformContextProvider.java:32)
    at com.amazonaws.emr.node.provisioner.phase.PhaseWorkflow.work(PhaseWorkflow.java:51)
    at com.amazonaws.emr.node.provisioner.phase.ProvisionHadoopPhase.perform(ProvisionHadoopPhase.java:21)
    at com.amazonaws.emr.node.provisioner.Program.main(Program.java:20)

所以我現在的問題是什么是 com.amazonaws.emr.node.provisioner.Program 以及它為什么失敗（或者我如何找出原因？）？

更新 2

我設法將 /usr/share/aws/emr/node-provisioner/bin/provision-node 的輸出一直拖到失敗，結果與我上面的獨立運行相同。

java -classpath '/usr/share/aws/emr/node-provisioner/lib/*' com.amazonaws.emr.node.provisioner.Program --phase hadoop
2017-06-02 17:05:37,869 ERROR main: Encountered a problem while provisioning
java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    at java.net.SocketInputStream.read(SocketInputStream.java:171)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
    at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
    at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1569)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
    at com.google.api.client.http.javanet.NetHttpResponse.<init>(NetHttpResponse.java:37)
    at com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:94)
    at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:972)
    at com.amazonaws.emr.node.provisioner.http.JsonHttpClient.doRequest(JsonHttpClient.java:49)
    at com.amazonaws.emr.node.provisioner.platform.EmrPlatformClient.getConfiguration(EmrPlatformClient.java:38)
    at com.amazonaws.emr.node.provisioner.platform.EmrPlatformClient.getConfiguration(EmrPlatformClient.java:31)
    at com.amazonaws.emr.node.provisioner.bigtop.config.PlatformContextProvider.provide(PlatformContextProvider.java:32)
    at com.amazonaws.emr.node.provisioner.phase.PhaseWorkflow.work(PhaseWorkflow.java:51)
    at com.amazonaws.emr.node.provisioner.phase.ProvisionHadoopPhase.perform(ProvisionHadoopPhase.java:21)
    at com.amazonaws.emr.node.provisioner.Program.main(Program.java:20)

我猜這可能是防火牆/安全組問題，但我使用的是 EMR 生成的默認安全組，因此我希望端口是開放的。 我正在 VPC 的私有子網中構建此集群，因此這可能是一個問題。 但是，當我在沒有引導的情況下構建集群時，我不會遇到此故障。 我的下一個調試步驟是構建一個沒有引導的 vanilla 集群，並觀察這個相同的命令。

更新 3 確認帶有 Spark 部署的 vanilla EMR 成功且沒有網絡更改。 /usr/share/aws/emr/node-provisioner/bin/provision-node 中沒有錯誤。 啟動 java 命令后，stderr 的下一行顯示平台配置參數的 JSON 轉儲。 但是，標准輸出顯示了從存儲庫 Bigtop 安裝的 yum 包。 我在腳本或 stderr 輸出（來自 set -xe）中沒有看到 yum 命令，所以我認為 yum 命令必須在該 Java 程序中。 不知道為什么他們在這里成功，但沒有引導行動。

我的私有 VPC 確實有一個帶有子網路由和防火牆規則的 S3 端點，允許訪問端點 plist。 我的引導腳本能夠使用 yum（不是來自 Bigtop 存儲庫）成功安裝軟件包，從 S3 復制文件，並從互聯網上的外部 git 存儲庫下載代碼。

Answer 1

我的引導腳本正在運行 yum 更新。 當我將其注釋掉時，我能夠通過配置節點腳本並最終使集群進入等待狀態。 其中一個更新肯定是造成了某種沖突或其他問題。 我不知道是哪一個。 現在，我將避免運行 yum update。

這是 yum 日志。 我猜它不是 R 或 mysql 包之一。 也許是 java、kernel、aws 或 util-linux？

Installed:
  kernel.x86_64 0:4.9.27-14.31.amzn1

Updated:
  R.x86_64 0:3.3.3-1.51.amzn1
  R-core.x86_64 0:3.3.3-1.51.amzn1
  R-core-devel.x86_64 0:3.3.3-1.51.amzn1
  R-devel.x86_64 0:3.3.3-1.51.amzn1
  R-java.x86_64 0:3.3.3-1.51.amzn1
  R-java-devel.x86_64 0:3.3.3-1.51.amzn1
  aws-amitools-ec2.noarch 0:1.5.13-0.2.amzn1
  aws-cli.noarch 0:1.11.83-1.46.amzn1
  java-1.8.0-openjdk.x86_64 1:1.8.0.131-2.b11.30.amzn1
  java-1.8.0-openjdk-devel.x86_64 1:1.8.0.131-2.b11.30.amzn1
  java-1.8.0-openjdk-headless.x86_64 1:1.8.0.131-2.b11.30.amzn1
  libRmath.x86_64 0:3.3.3-1.51.amzn1
  libRmath-devel.x86_64 0:3.3.3-1.51.amzn1
  libblkid.x86_64 0:2.23.2-33.28.amzn1
  libmount.x86_64 0:2.23.2-33.28.amzn1
  libuuid.x86_64 0:2.23.2-33.28.amzn1
  mysql-config.x86_64 0:5.5.56-1.17.amzn1
  mysql55.x86_64 0:5.5.56-1.17.amzn1
  mysql55-devel.x86_64 0:5.5.56-1.17.amzn1
  mysql55-libs.x86_64 0:5.5.56-1.17.amzn1
  ntp.x86_64 0:4.2.6p5-44.34.amzn1
  ntpdate.x86_64 0:4.2.6p5-44.34.amzn1
  python27-botocore.noarch 0:1.5.46-1.63.amzn1
  python27-jmespath.noarch 0:0.9.2-1.12.amzn1
  util-linux.x86_64 0:2.23.2-33.28.amzn1

歡迎進一步的見解。 否則，繼續實際運行我的代碼。

Answer 2

我自己遇到了這個問題，這就是我想出來的。 引導操作 2 指的是節點配置，由於在自定義引導操作 1 中執行錯誤而失敗。例如，在我的情況下，我正在安裝版本 X 的 MySQL 服務器，然后在節點配置期間，執行失敗，因為 yum 是嘗試安裝不同版本的 MySQL 服務器。 似乎沖突的 yum 更新是問題的主要來源之一。

消息非常不清楚，也沒有好的文檔。

如果遇到類似情況，請查看集群的所有日志。 就我而言，我在以下日志文​​件中發現了有問題的消息

s3://aws-logs-<account-id>-us-west-2/elasticmapreduce/<cluster-id>/node/<instance-id>/provision-node/apps-phase/0/93d592d9-d7e8-47a8-9972-05922c5a9885/stderr.gz

Answer 3

我的發現

在這里遇到同樣的問題后，我意識到你和我得到的錯誤實際上意味着引導操作失敗。 就我而言，所有節點都無法訪問 S3 文件，因為它們沒有正確的憑據。 此問題的日志記錄未明確記錄。 即使引導操作失敗，它仍然可以啟動主節點。

對於其他遇到類似問題的人，我建議將其用於調試：

1. 在 linux 終端中運行您的腳本。 （啟動一個 EC2 實例並嘗試它）您可能會意識到它失敗了。

2. 檢查您正在引導的所有內容的權限。 您是否有權訪問從中獲取此信息的 S3 存儲桶？ 位置是否正確？ 如果您使用的是 aws-cli 命令，您是否從 aws-cli 進行了 aws 配置，具有正確的（如果有）配置？

如果這對任何人有幫助，或者您有任何疑問，請告訴我！