我想知道是否有人可以在使用bdutil工具部署spark集群时帮助我解决这个问题。 当核心总数增加（> = 1024）时，它总是失败，原因如下：
有些机器永远不会被淘汰，比如“2015年12月8日太平洋标准时间2015年12月14日14：''hadoop-w-5'还没有sshable（255）;睡觉”
某些节点在部署spark worker节点时出现“Exited 100”错误，例如“2015年12月8日15:28:31太平洋标准时间：退出100：gcloud --project = cs-bwamem --quiet - -verbosity = info compute ssh hadoop-w-6 --command = sudo su -l -c“cd $ {PWD}＆amp;＆amp; ./deploy-core-setup.sh“2＆gt;＆gt; deploy-core-setup_deploy.stderr 1＆gt;＆gt; 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：==＆gt; deploy-core-setup_deploy.stderr＆lt; ==
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更改为1200s，并更改bdutil_env.sh以将轮询间隔设置为30s，60s，......，它们都不起作用。总会有一些节点失败。
以下是我使用的配置之一：
时间./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 \ 部署
答案 0 :(得分：0)
总结一下单独的电子邮件讨论中提供的一些信息，随着IP映射的更改和不同的debian镜像的分配，在bdutil部署期间对apt-get install的并发调用可能会偶尔出现问题。使一些不平衡的服务器过载或触发DDOS保护，导致部署失败。这些确实是短暂的，目前看来我可以再次成功地在us-east1-c和us-east1-d等区域部署大型群集。
您可以采取一些方法来减少debian镜像的负载：
MAX_CONCURRENT_ASYNC_PROCESSES设置为比bdutil_env.sh内的默认值小得多的值，例如10，以便一次只部署10个;这将使部署时间更长，但会减轻负载，就好像您只是进行了几次背对背的10节点部署一样。./bdutil <all your flags> run_command -t all -- 'rm -rf /home/hadoop'后跟./bdutil <all your flags> run_command_steps来完成整个部署尝试，而不需要重试整个删除/部署周期--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.然后你再重复一遍，每次增加另外10名工人到NEW_NUM_WORKERS。如果调整大小尝试失败，您只需./bdutil <all your flags> -e extensions/google/experimental/resize_env.sh delete只删除那些额外的工作人员，而不会影响已成功部署的工作人员。最后，如果您正在寻找更具可重复性和优化的部署，则应考虑使用Google Cloud Dataproc，这样您就可以使用标准gcloud CLI来deploy cluster，{{3} }，以及submit jobs，无需记住您的bdutil标志或跟踪您在客户端计算机上拥有的群集。您可以SSH到Dataproc集群并使用它们与bdutil集群基本相同，但有一些细微差别，例如Dataproc DEFAULT_FS是HDFS，因此您使用的任何GCS路径都应该完全指定完整的gs://bucket/object名称。