0

我想知道在使用 bdutil 工具部署 Spark 集群时是否有人可以帮助我解决这个问题。当核心总数增加（> = 1024）时，它一直失败，原因如下：

  1. 某些机器永远无法 sshable，例如“Tue Dec 8 13:45:14 PST 2015: 'hadoop-w-5' not yet sshable (255); sleep"

  2. 一些节点在部署 Spark 工作节点时失败并出现“Exited 100”错误，例如“Tue Dec 8 15:28:31 PST 2015: Exited 100: gcloud --project=cs-bwamem --quiet --verbosity=info compute ssh hadoop-w-6 --command=sudo su -l -c "cd ${PWD} && ./deploy-core-setup.sh" 2>>deploy-core-setup_deploy.stderr 1>>deploy-core-setup_deploy .stdout --ssh-flag=-tt --ssh-flag=-oServerAliveInterval=60 --ssh-flag=-oServerAliveCountMax=3 --ssh-flag=-oConnectTimeout=30 --zone=us-central1-f"

在日志文件中，它说：

hadoop-w-40: ==> 部署核心-setup_deploy.stderr <==

hadoop-w-40：dpkg-query：未安装包“openjdk-7-jdk”，没有可用信息

hadoop-w-40：使用 dpkg --info (= dpkg-deb --info) 检查存档文件，

hadoop-w-40: 和 dpkg --contents (= dpkg-deb --contents) 列出它们的内容。

hadoop-w-40：无法获取http://httpredir.debian.org/debian/pool/main/x/xml-core/xml-core_0.13+nmu2_all.deb 从服务器读取错误。远端关闭连接[IP：128.31.0.66 80]

hadoop-w-40：E：无法获取一些档案，也许运行 apt-get update 或尝试使用--fix-missing？

我试过16核128节点、32核64节点、32核32节点和其他1024核以上的配置，但是上面的原因1或2都会出现。

我还尝试修改 ssh-flag 以将 ConnectTimeout 更改为 1200 秒，并更改 bdutil_env.sh 以将轮询间隔设置为 30 秒、60 秒……，它们都不起作用。总会有一些节点失败。

这是我使用的配置之一：

时间 ./bdutil \ --bucket $BUCKET \ --force \ --machine_type n1-highmem-32 \ --master_machine_type n1-highmem-32 \ --num_workers 64 \ --project $PROJECT \ --upload_files ${JAR_FILE } \ --env_var_files hadoop2_env.sh,extensions/spark/spark_env.sh \ deploy

4

1 回答 1

0

总结从单独的电子邮件讨论中得出的一些信息，随着 IP 映射的变化和不同的 debian 镜像被分配，apt-get install在 bdutil 部署期间并发调用可能会导致某些不平衡的服务器过载或触发 DDOS 保护偶尔会出现问题导致部署失败。这些确实往往是暂时的，目前看来我可以在区域中部署大型集群，us-east1-c并且us-east1-d再次成功。

您可以采取一些选项来减少 debian 镜像上的负载：

  1. 设置MAX_CONCURRENT_ASYNC_PROCESSES为比默认的 150 inside 小得多的值bdutil_env.sh，比如10一次只部署 10 个；这将使部署花费更长的时间，但会减轻负载，就像您刚刚进行了几次背靠背 10 节点部署一样。
  2. 如果 VM 已成功创建但部署步骤失败，则无需重试整个删除/部署周期，您可以尝试./bdutil <all your flags> run_command -t all -- 'rm -rf /home/hadoop'然后./bdutil <all your flags> run_command_steps运行整个部署尝试。
  3. 使用resize_env.sh增量构建集群；最初设置--num_workers 10并部署您的集群，然后编辑resize_env.sh设置NEW_NUM_WORKERS=20并运行./bdutil <all your flags> -e extensions/google/experimental/resize_env.sh deploy，它只会部署新的工作人员 10-20 而不会触及前 10 个工作人员。然后您只需重复，NEW_NUM_WORKERS每次添加另外 10 个工作人员。如果调整大小尝试失败，您只需./bdutil <all your flags> -e extensions/google/experimental/resize_env.sh delete删除那些额外的工作人员，而不会影响您已经成功部署的工作人员。

最后，如果您正在寻找更具可重复性和优化的部署，您应该考虑使用Google Cloud Dataproc，它允许您使用标准gcloudCLI 来部署集群、提交作业以及进一步管理/删除集群，而无需记住您的 bdutil 标志或跟踪您在客户端计算机上拥有的集群。您可以通过 SSH 连接到 Dataproc 集群并使用它们与 bdutil 集群基本相同，但有一些细微差别，例如 DataprocDEFAULT_FS是 HDFS，因此您使用的任何 GCS 路径都应完全指定完整gs://bucket/object名称。

于 2015-12-10T02:51:50.997 回答