search

lihongzheshuai / lihongzheshuai.github.io

onecoder's blog.
https://onecoder-blog.vercel.app
MIT License
6 stars 2 forks source link

Spring Hadoop Yarn HA问题调研 #20

Open lihongzheshuai opened 7 years ago

lihongzheshuai commented 7 years ago

http://www.coderli.com/spring-hadoop-yarn-ha/

zhuweimin1975 commented 6 years ago

博主 你好，我测试了你在github上面提交的补丁，https://github.com/spring-projects/spring-hadoop/pull/238 RM完全没问题，AppMaster不能自动恢复，测试方法如下： １、找到ApplicationMaster的所在服务器和PID [root@testhost1 ~]# ps -ef|grep Appmaster yarn 3495 3493 0 Dec21 ? 00:00:00 /bin/bash -c /usr/java/latest/bin/java -Xms512m -Xmx512m -Dspring.config.location=servers.yml -jar spring-cloud-deployer-yarn-appdeployerappmaster-1.2.2.RELEASE.jar --spring.cloud.deployer.yarn.appmaster.artifact=/dataflow//artifacts/cache/ 1>/yarn/container-logs/application_1513855083662_0002/container_e33_1513855083662_0002_01_000001/Appmaster.stdout 2>/yarn/container-logs/application_1513855083662_0002/container_e33_1513855083662_0002_01_000001/Appmaster.stderr

2、杀掉这个进程 [root@testhost1 ~]# kill -9 3495 [root@testhost1 ~]# ps -ef|grep Appmaster root 28566 28118 0 10:43 pts/2 00:00:00 grep --color=auto Appmaster

３、Yarn的管理画面确认JOB的状态` Yarn: Failed

不知道是不是我的设定有问题，请指教。 hadoop: fsUri: hdfs://nameservice1 resourceManagerHost: yarnRM resourceManagerPort: 8032 config: dfs.ha.automatic-failover.enabled: True dfs.nameservices: nameservice1 dfs.client.failover.proxy.provider.nameservice1: org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider dfs.ha.namenodes.nameservice1: namenode45,namenode53 dfs.namenode.rpc-address.nameservice1.namenode45: testhost1.euler:8020 dfs.namenode.rpc-address.nameservice1.namenode53: testhost2.euler:8020 yarn.resourcemanager.ha.enabled: true yarn.resourcemanager.ha.rm-ids: rm39,rm80 yarn.resourcemanager.cluster-id: yarnRM yarn.resourcemanager.address.rm39: testhost1.euler:8032 yarn.resourcemanager.scheduler.address.rm39: testhost1.euler:8030 yarn.resourcemanager.admin.address.rm39: testhost1.euler:8033 yarn.resourcemanager.webapp.address.rm39: testhost1.euler:8088 yarn.resourcemanager.resource-tracker.address.rm39: testhost1.euler:8031 yarn.resourcemanager.address.rm80: testhost2.euler:8032 yarn.resourcemanager.scheduler.address.rm80: testhost2.euler:8030 yarn.resourcemanager.admin.address.rm80: testhost2.euler:8033 yarn.resourcemanager.webapp.address.rm80: testhost2.euler:8088 yarn.resourcemanager.resource-tracker.address.rm80: testhost2.euler:8031 yarn.resourcemanager.zk-address: testhost1.euler:2181,testhost2.euler:2181,testhost3.euler:2181 yarn.resourcemanager.recovery.enabled: true

zhuweimin1975 commented 6 years ago

同样的环境中用hadoop的例子PI做同样的测试，JOB继续执行，自动在生成新的ApplicationMaster Container

ApplicationMasters Attempt Number Start Time Node Logs 1 Wed Jan 10 16:45:23 +0900 2018 testhost2.euler:8042 logs 2 Wed Jan 10 16:46:04 +0900 2018 testhost3.euler:8042 logs

感觉补丁可能还有需要修改的地方。

lihongzheshuai commented 6 years ago

@zhuweimin1975 感谢你的测试。你说的没错。我们当时关注的场景也不是你测试的场景。我们关注的是，当RM挂掉的时候，我们系统能继续运行，由于系统依赖spring-hadoop，所以就修改了spring-hadoop的相关逻辑，满足了我们的场景。。至于你直接kill掉am的场景，好像没有处理这个场景。而且，对于spring-hadoop，我觉得封装有些过度，还丢失了很多HA特性。官方原生的挺好。再次感谢你提供的测试结果：）

zhuweimin1975 commented 6 years ago

@lihongzheshuai 谢谢你的回复，如你所说AM进程挂掉的可能性确实很小，但我想AM所在的节点宕机的可能性是有的。因为我们使用https://cloud.spring.io/spring-cloud-dataflow-server-yarn/ 跑永不停止的实时处理程序，JOB需要一直在运行，一旦AM挂掉，希望能自动恢复，如果不能实现自动恢复就得考虑自动再提交JOB的机制。

lihongzheshuai commented 6 years ago

@zhuweimin1975 你说的可能是有的，dataflow应该是xd的升级版本，底层机制是差不多的。不知道现在发展到什么样子了。恩，如果AM所在的节点挂了，好像是没有自动恢复的。需要重新提交。至少我当时遇到的情况是这样。我们处理的是AM没挂，RM挂了，AM重新注册的部分。这是我们遇到最多的情况。重新提交AM，感觉应该是YARN处理的事情，不知道原生有没有这部分机制。