Standalone下Spark配置HA(High Availablity)

Standalone下Spark配置HA(High Availablity)

http://spark.apache.org/docs/1.6.3/spark-standalone.html#high-availability

在默认情况下，Standalone的集群调度对Worker具有容错性，因为当Worker节点崩溃后可以将Application移动到其他可用节点。但是调度程序依靠Master进行调度决策，这意味着会出现单点故障(single point of failure)，如果Master崩溃，则不能创建新的Application。为了避免这种情况，有两个高可用性的方案，详述如下：

1. 使用ZooKeeper进行热备

概述

利用ZooKeeper提供leader选举和一些状态存储，您可以在连接到同一ZooKeeper群集中启动多个Masters。一个将被选为“leader”，其他人将保持standby模式。如果当前leader死亡，将选出另一个leader，恢复旧leader的状态，然后恢复调度。整个恢复过程（从第一个leader被关闭时起）应该需要1到2分钟。请注意，此延迟仅影响计划新Application的创建，在Master故障转移期间已运行的任务不受影响。

配置

需要在spark-env.sh中配置SPARK_DAEMON_JAVA_OPTS

配置项	说明
spark.deploy.recoveryMode	设置为ZOOKEEPER去启动热备模式(默认: NONE).
spark.deploy.zookeeper.url	ZooKeeper集群URL (e.g., 192.168.1.100:2181,192.168.1.101:2181).
spark.deploy.zookeeper.dir	ZooKeeper中的存储目录(默认: /spark).

例如： export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode="ZOOKEEPER" -Dspark.deploy.zookeeper.url=hh1:2181,hh2:2181,hh3:2181

注意： 如果没有正确配置使用ZooKeeper，那么Master将不能检测到彼此，将导致每个Master都是leader。这将导致一个不健康的集群状态（所有的Master都是独立的调度）

说明

启动ZooKeeper集群后，使用HA将非常简单。只需使用相同的ZooKeeper配置（ZooKeeper URL和目录）在不同节点上启动多个Master进程，当然可以随时添加和删除Master。

为了调度新Application或添加Worker到群集，他们需要知道当前leader的IP地址。这可以通过简单地传入您曾经传入一个Masters列表来完成。例如，您可以启动指向spark://host1:port1,host2:port2的SparkContext。这会使得SparkContext尝试向两个Master注册，如果host1发生故障，这个配置仍然是正确的，因为找到了新的leader host2。

向注册Master与正常操作之间存在重要区别。Application或Worker需要能够找到当前的leader Master进行注册。一旦成功注册，它就存储在ZooKeeper中了。如果发生故障转移，新leader将联系所有先前注册的Application和Worker，告知他们Master的变化，因此他们甚至不需要知道新的Master在启动时是否存在。由于这个属性，我们可以随时创建新的Master，唯一需要担心的是新Application和Worker可以找到它以便注册。

2. 使用本地文件系统进行单点恢复

概述

在生产环境下，使用ZooKeeper是实现HA的最好方式。但是当Master挂掉后，你只是想重新启动Master，FILESYSTEM 模式就可以搞定。当Application和Worker进行注册时，将这些状态信息写入指定的本地文件系统目录中，以便在重启Master时恢复这些状态信息。

配置

需要在spark-env.sh中配置 SPARK_DAEMON_JAVA_OPTS

配置项	说明
spark.deploy.recoveryMode	设置为ZOOKEEPER去启动单节点恢复模式（默认为None）
spark.deploy.recoveryDirectory	指定存储状态信息的目录

说明

此解决方案可以与monit等进程监视器/管理器一起使用，也可以只是通过重新启动来进行手动恢复。

虽然文件系统恢复似乎比完全不进行任何恢复要好，但这种模式对于某些开发或实验可能不是最理想的。通过stop-master.sh杀掉Master并不会清除其恢复状态，因此无论何时启动新主服务器，它都将进入恢复模式。如果需要等待所有先前注册的Workers/客户端连接超时，这可能会使启动时间增加最多1分钟。

虽然它没有得到官方支持，但您可以挂载一个NFS目录作为恢复目录。如果原先的Master完全死亡，则可以在另一个节点上启动Master，这将正确恢复所有先前注册的Worker/Application（相当于ZooKeeper恢复）。然而，新的Application必须能够找到新的Master才能进行注册。