1. Spark HA高可用部署
Spark Standalone集群时Master-Slaves架构的集群模式,和大部分的Master-Slaves结果集群一样,存在着Master单点故障的问题。如何解决这个单点故障的问题,Spark提供了两种方案:
1.1 基于文件系统的单点恢复(Single-Node Recovery with Local File System)
- 主要用于开发或测试环境。
- 当spark提供目录保存**spark Application和worker的注册信息,**并将它们的恢复状态写入该目录中,这时,一旦Master发生故障,就可以通过重新启动Master进程(sbin/start-master.sh),恢复已运行的spark Application和worker的注册信息。
1.2 基于ZK的Standby Masters(Standby Masters with Zookeeper)
- 用于生成模式,
- 基本原理是通过zk来选举一个Master,其他Master处于Standby状态。
- 将spark集群连接到同一个zk实例并启动多个Master,利用zk提供的选举和状态保存功能,可以使一个Master被选举成活着的Master,而其他Master处于Standby状态。
- 如果现任Master死去,另一个Master会通过选举产生,并恢复到旧的Master状态,然后恢复调度。
- 整个恢复过程可能要1-2分钟。
2. 基于Zookeeper的Spark HA高可用集群部署
该HA方案使用起来简单,首先需要搭建一个Zookeeper集群,然后启动Zookeeper集群,最后再不同阶段上启动Master。具体配置如下:
vim spark-env.sh
注释掉export SPARK_MASTER_HOST=node01
- 在spark-env.sh添加Spark_DAEMON_JAVA_OPTS,内容如下:
export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER-Dspark.deploy.zookeeper.url=node01:2181,node02:2181,node03:2181-Dspark.deploy.zookeeper.dir=/spark"
- 参数说明
- spark.deploy.recoveryMode:恢复模式(Master重新启动的模式)
有三种:(1)ZooKeeper (2) FileSystem (3)NONE - spark.deploy.zookeeper.url:ZooKeeper的Server地址
- spark.deploy.zookeeper.dir:保存集群元数据信息的文件、目录。
包括Worker,Driver和Application。
- spark.deploy.recoveryMode:恢复模式(Master重新启动的模式)
- 注意:
在普通模式下启动spark集群,只需要在主机上面执行start-all.sh 就可以了。
在高可用模式下启动spark集群,先需要在任意一台节点上启动start-all.sh命令。然后在另外一台节点上单独启动master。命令start-master.sh。
3. 如何恢复上一次活着Master挂掉之前的状态&在Master的恢复阶段对任务的影响
(1)如何恢复到上一次活着master挂掉之前的状态:
- 在高可用模式下,整个spark集群就有很多个master,其中只有一个master被zk选举成活着的master,其他的多个master都处于standby,同时把整个spark集群的元数据信息通过zk中节点进行保存。
- 后期如果活着的master挂掉。首先zk会感知到活着的master挂掉,下面开始在多个处于standby中的master进行选举,再次产生一个活着的master,这个活着的master会读取保存在zk节点中的spark集群元数据信息,恢复到上一次master的状态。
- 整个过程在恢复的时候经历过了很多个不同的阶段,每个阶段都需要一定时间,最终恢复到上个活着的master的转态,整个恢复过程一般需要1-2分钟。
(2)在master的恢复阶段对任务的影响 - 针对于正在运行的任务,由于它已经分配到了资源,它是不受任何影响.
- 受影响的就是在当前这个挂掉的阶段,后面提交的新的任务,由于没有活着的master分配资源,该任务是无法运行。