大数据问题排查系列 - SPARK STANDALONE HA 模式的一个缺陷点与应对方案

前言

大家好，我是明哥！

作为当今离线批处理模式的扛把子，SPARK 在绝大多数公司的数据处理平台中都是不可或缺的。而在底层使用的具体资源管理器上，SPARK 支持四种模式：

• standalone
• yarn
• mesos
• kubernetes

四种模式的简单对比如下图：

以上四种模式中，mesos 在业界使用的最少，其次是 standalone 模式，再次是 yarn 模式。不过随着大数据与云计算日益融合的趋势，现在也有不少场景在使用 kubernetes 替代 yarn 和 standalone 模式。

关于大数据的发展趋势，尤其是大数据与云计算日益融合的趋势，大家可参考笔者以往两篇文章：

michaelli：从技术视角看大数据行业的发展趋势

本文讲述，spark standalone部署模式下，HA 高可用部署的一个缺陷点和对应的解决办法。

以下是正文。

SPARK STADNALONE HA 模式的确切含义是什么？

我们知道，spark 在 standalone 部署模式下，有多个 worker 节点负责具体任务的执行，spark 框架帮我们解决了作业底层各个 stage 以及各个 stage 中各个 task 任务执行失败时的容错，spark框架也帮我们解决了 各个 worker 节点宕机情况下的容错；但是整个 spark 集群是只有一个 master 节点负责接收用户提交的作业的，该 master 节点是有单点故障即 SPOF(single point of failure)的。

为了应对 master 节点的 spof, 我们可以做 master 节点的 HA 高可用：即部署多个 master 节点，并通过选举确保同一时间只有一个 active 的 master 对外提供服务，当该 active master 节点意外宕机时，原先 standby 的 master 节点会自动检测到这种异常情况并被选举成为新的 active master，从而对外提供服务（接受 worker 注册，接受作业提交）；同时原先已经注册到集群中的 workers，以及原先已经提交的作业，会自动注册到该新的 master 上，即不丢失状态。

如何配置和使用 STANDALONE HA 模式下的 SPARK 集群？

有两种方法，配置都很简单:

• 一是配置 spark-defaults.conf,示例如下：
  

• spark.master spark://node1:7077,node2:7077
• spark.deploy.recoveryMode ZOOKEEPER
• spark.deploy.zookeeper.url node1:2181,node2:2181,node3:2181
• spark.deploy.zookeeper.dir /spark24-ha

• 二是配置spark-env.sh，示例如下：

当然，客户端在使用 HA 模式的 SPARK STANDALONE 集群时，需要将 spark.master 配置为以下方式，才会轮询检查可用的 spark master:

• spark.master spark://node1:7077,node2:7077

问题现象 - SPARK STANDALONE HA 模式的一个缺陷

笔者在线上使用过程中，发现了 SPARK STANDALONE HA 模式的一个缺陷点，或者说做的不完善的地方： 某客户环境的 spark standalone 部署模式，通过 zk 配置了ha 高可用后，发现 active spark master 经常挂掉，且 standby spark master 经过选举成为 active spark master 后也经常挂掉。

经过 google 搜索，发现有一个相关的 jira 是关于这个的：

Bouncing Zookeeper node causes Active spark master to exit

问题原因

• Active 与 standby 的 spark master 在底层都会跟 zk 建立两个 session 链接， 一个是跟 zk leader node 的 session 链接，还有一个是跟任一 zk node 的 session 链接。
  
• 一旦 active spark master 底层跟 zk 的 session 链接断开，不管该 session 链接底层的 zk 是 leader 还是follower，原 active 状态的 spark master 的 leader 角色都会被剥夺，然后该 spark master 进程会自动退出。
  
• 同时原 standby 状态的 spark master 会成功切换为active状态，并自动接受已提交运行的application 的重新注册（当然，这些 application 需要配置多个 spark master 的轮询，如：spark://node1:7077,node2:7077）。
  
• 其实，以上现象说白了，是 active spark master 在因底层 zk 不稳定或其他原因造成 session 链接断开时，会被剥夺 leader 角色，这点没什么问题；但随后 spark 直接将被剥夺了 leader 角色的 master 进程直接退出了，这点就有点简单粗暴了。相关源码如下：
  

问题解决

可以从两个方面着手，解决该问题：

1. spark master 进程异常退出的根本原因是，底层的 zk 负载过大不稳定造成 spark 跟 zk 的 session 连接经常断开，（在 spark, kafka, 微服务等服务都使用同一个 zk 集群时，经常会出现该问题）。所以从根本上解决问题，需要从 zk 的稳定上做文章，可以配置 spark 单独使用一个独立的 zk 集群 （由于 spark 对 zk 的压力不大，对 zk 的性能要求也不是很高，所以该 zk 集群可以跟 spark 集群混部）；
   
2. active spark master 在因底层 zk session 链接断掉失去 leader 角色后会自动退出，所以为确保 HA 效果，我们可以再次启动该 spark master 服务，以确保集群中有至少两个 spark master。具体实现方式上，可以通过监控脚本或 haproxy 等工具，自动检测 spark master 进程并在该进程异常推出后，自动再次启动该进程 （其实底层只需执行 sh $SPARK_HOME/sbin/start-master.sh即可）
   

相关日志

当 zk 的 leader 节点重启时，原先 active 状态的 spark master 节点日志如下：

21/08/18 18:43:15 INFO zookeeper.ClientCnxn: Unable to read additional data from server sessionid 0x27a687ab09da9f8, likely server has closed socket, closing socket connection and attempting reconnect
21/08/18 18:43:15 INFO state.ConnectionStateManager: State change: SUSPENDED
21/08/18 18:43:15 INFO state.ConnectionStateManager: State change: SUSPENDED
21/08/18 18:43:15 INFO master.ZooKeeperLeaderElectionAgent: We have lost leadership
21/08/18 18:43:15 ERROR master.Master: Leadership has been revoked -- master shutting down.

当 zk 的 follower 节点重启时，原先 active 状态的 spark master 节点日志如下：

21/08/18 22:51:46 WARN zookeeper.ClientCnxn: Session 0x17b58dbaaf60171 for server node1/10.20.39.41:2181, unexpected error, closing socket connection and attempting reconnect
java.io.IOException: Connection reset by peer
        at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
        at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
        at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
        at sun.nio.ch.IOUtil.read(IOUtil.java:192)
        at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
        at org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:68)
        at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366)
        at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
21/08/18 22:51:46 INFO state.ConnectionStateManager: State change: SUSPENDED
21/08/18 22:51:46 INFO master.ZooKeeperLeaderElectionAgent: We have lost leadership
21/08/18 22:51:46 ERROR master.Master: Leadership has been revoked -- master shutting down.

当 zk 的 leader 节点重启时，原先 standby 状态的 spark master 节点日志如下:

21/08/18 18:43:18 INFO zookeeper.ClientCnxn: Socket connection established to node3/10.20.39.43:2181, initiating session
21/08/18 18:43:18 INFO zookeeper.ClientCnxn: Session establishment complete on server node3/10.20.39.43:2181, sessionid = 0x37a687ab25aa91d, negotiated timeout = 60000
21/08/18 18:43:18 INFO state.ConnectionStateManager: State change: RECONNECTED
21/08/18 18:44:18 INFO master.ZooKeeperLeaderElectionAgent: We have gained leadership
21/08/18 18:44:18 INFO master.Master: I have been elected leader! New state: RECOVERING
21/08/18 18:44:18 INFO master.Master: Trying to recover worker: worker-20210818182026-10.20.39.42-46483
21/08/18 18:44:18 INFO master.Master: Trying to recover worker: worker-20210818182026-10.20.39.43-37230
21/08/18 18:44:18 INFO client.TransportClientFactory: Successfully created connection to /10.20.39.42:46483 after 6 ms (0 ms spent in bootstraps)
21/08/18 18:44:18 INFO client.TransportClientFactory: Successfully created connection to /10.20.39.43:37230 after 6 ms (0 ms spent in bootstraps)
21/08/18 18:44:18 INFO master.Master: Worker has been re-registered: worker-20210818182026-10.20.39.42-46483
21/08/18 18:44:18 INFO master.Master: Worker has been re-registered: worker-20210818182026-10.20.39.43-37230
21/08/18 18:44:18 INFO master.Master: Recovery complete - resuming operations!