Spark1.0.0 Standalone HA的实现

Spark Standalone集群是Master-Slaves架构的集群模式，和大部分的Master-Slaves结构集群一样，存在着Master单点故障的问题。如何解决这个单点故障的问题，Spark提供了两种方案：

• 基于文件系统的单点恢复
• 基于zookeeper的Standby Masters

本文中的测试是在Spark1.0.0 Standalone 模式部署上进行。

1：基于文件系统的单点恢复

主要用于开发或测试环境下。当spark提供目录保存spark Application和worker的注册信息，并将他们的恢复状态写入该目录中，这时，一旦Master发生故障，就可以通过重新启动Master进程（sbin/start-master.sh），恢复已运行的spark Application和worker的注册信息。

基于文件系统的单点恢复，主要是在spark-env里对SPARK_DAEMON_JAVA_OPTS设置：

 参数 含义 spark.deploy.recoveryMode 设成FILESYSTEM ， 缺省值为NONE spark.deploy.recoveryDirectory  Spark 保存恢复状态的目录如果想从另外一台机器上恢复（比如原有的Master机器物理损害的情况下），可以考虑使用NFS的共享目录来保存Spark恢复状态。  

测试：

A：配置conf/spark-env.sh，然后保存并发放给各节点。

[hadoop@hadoop1 spark100]$ vi conf/spark-env.sh

[hadoop@hadoop1 spark100]$ cat conf/spark-env.sh

export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=FILESYSTEM -Dspark.deploy.recoveryDirectory=/app/hadoop/spark100/recovery"
export SPARK_MASTER_IP=hadoop1export SPARK_WORKER_CORES=1export SPARK_WORKER_INSTANCES=1export SPARK_MASTER_PORT=7077export SPARK_WORKER_MEMORY=1gexport MASTER=spark://${SPARK_MASTER_IP}:${SPARK_MASTER_PORT}

B：启动Spark Standalone集群。

C：启动一个spark-shell客户端并做部分操作后，然后用sbin/stop-master.sh杀死Master进程

D：过段时间后用sbin/start-master.sh启动master，观察客户端和监控，可以发现spark-shell可以使用杀死Master进程之前的变量。

 

2：基于zookeeper的Standby Masters

用于生产模式下。其基本原理，就是通过zookeeper来选举一个Master，其他的Master处于Standby状态。

• 将Standalone集群连接到同一个ZooKeeper实例并启动多个Master，利用zookeeper提供的选举和状态保存功能，可以使一个Master被选举，而其他Master处于Standby状态。如果现任Master死去，另一个Master会通过选举产生，并恢复到旧的Master状态，然后恢复调度。整个恢复过程（从原Master失去作用开始）可能要1-2分钟。注意，这种延迟只会影响新Application的调度，对于在故障期间已经运行的 application不会受到影响。
• 因为涉及到多个Master，所以对于应用程序的提交就有了一点变化，因为应用程序需要知道当前的Master的IP地址和端口。这种HA方案处理这种情况很简单，只需要在SparkContext指向一个Master列表就可以了，如spark://host1:port1,host2:port2,host3:port3，应用程序会轮询列表。
• 该HA方案使用起来很简单，首先启动一个ZooKeeper集群，然后在不同节点上启动Master，注意这些节点需要具有相同的zookeeper配置（ZooKeeper URL 和目录）。zookeeper配置参数有：

 参数 含义 spark.deploy.recoveryMode 设置成ZOOKEEPER，缺省值为 NONE spark.deploy.zookeeper.url ZooKeeper URL(如192.168.100.111:2181,192.168.100.112:2181...) spark.deploy.zookeeper.dir ZooKeeper 保存恢复状态的目录，缺省为 /spark

•    Master可以在任何时候添加或移除。如果发生故障切换，新的Master将联系所有以前注册的Application和Worker告知Master的改变。

测试：

zookeeper集群（hadoop1、hadoop2、hadoop2、hadoop4、hadoop5）

Master（hadoop1、hadoop2）

A：配置conf/spark-env.sh，然后保存并发放给各节点。

[hadoop@hadoop1 spark100]$ vi conf/spark-env.sh

[hadoop@hadoop1 spark100]$ cat conf/spark-env.sh

export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=hadoop1:2181,hadoop2:2181,hadoop3:2181,hadoop4:2181,hadoop5:2181 -Dspark.deploy.zookeeper.dir=/spark"export SPARK_WORKER_CORES=1export SPARK_WORKER_INSTANCES=1export SPARK_WORKER_MEMORY=1g

因为Master可以随意添加，所以就不将Master所定义在conf/spark-env.sh里了，而是直接在Application中定义。

B：启动zookeeper集群，关于zookeeper安装配置详见zookeeper3.4.5安装笔记。

C：启动Spark Standalone集群，并多启动一个节点的Master。

[hadoop@hadoop1 spark100]$ sbin/start-all.sh

[hadoop@hadoop2 spark100]$ sbin/start-master.sh

D：启动一个spark-shell客户端

[hadoop@hadoop2 spark100]$ MASTER=spark://hadoop1:7077,hadoop2:7077 bin/spark-shell

启动的时候使用了master列表，Application启动的时候会尝试连接所有的master

 

E：查看监控器，这是Active Master是hadoop1

 

F：用sbin/stop-master.sh杀死hadoop1的Master进程，这时saprk-shell花费了30秒左右的时候切换到hadoop2上的Master了。

 

G：查看监控器，这是Active Master是hadoop2。原来在运行的Application资源没发生变化，即不受故障的影响。