高可用模式

发布于 2015-12-05 11:02:09 | 691 次阅读 | 评论: 0 | 来源: 网络整理

如果Mesos master节点失效，那么现有的而任务仍然可以继续执行，但是新的资源就无法被分配而导致新的任务无法启动。为了减少这种情况发生的可能性，Mesos设计了高可用的模式，即使用多个master节点，并选取其中一个作为活动的master（成为leader或者leading master），其他的master节点则作为备用来避免leader的崩溃。正果过程同，msos通过使用 Apache ZooKeeper 协调选举和通过master,slave和调度驱动检测leader master节点的健康程度。详见leader选举过程

Note: 本文假设你知道如何 使用启动、运行和使用ZooKeeper运作。ZooKeeper的客户端库内建于标准的Mesos构建。

用法

让Mesos变成高可用模式：

1. 确认集群中 ZooKeeper 已经开启且在运行中。

2. 提供znode路径给在所有的Master、slave、应用框架调度器，设置如下：

   • 运行mesos-master程序时，附加 --zk参数，比如 `--zk=zk://host1:port1,host2:port2,.../path'

   • 运行mesos-slave程序时，附加参数 --master=zk://host1:port1,host2:port2,.../path

   • 运行应用框架调度器时，在最后两步附加 --zk参数。如[应用开发向导]( http://mesos.apache.org/documentation/latest/app-framework-development-guide/)中所述，SchedulerDriver必须和该路径绑定。

这样，Mesos的所有Master节点和Slave节点都将通过ZooKeeper来找出哪一个master节点是当前的leading master。除此之外，就是通常的leading master和slave之间通信了。

查看Scheduler API 了解如何处理leader的变更。

组件失联的处理

当ZooKeeper的监控下中有网络连接中发生了组件（master，slave或scheduler driver）失联的情况时，该组件的主检测程序将发出一个超时事件来告诉所有组件：目前没有了leading master。（注意：当有部分失联时，master节点仍会和slave节点、调度器等保持通信，反之亦然）。下面是失联后组件的状况：

• 失联的Slave节点将无法知道谁是leading Master，所以会无视所有从leader master节点发来的消息来避免执行非leader的master节点发送的命令。当slave节点重新连接到ZooKeeper上时，Zookeeper会告知其谁是现任leader。slave节点根据该信息，停止忽略leader master发来的信息。

• 失联后，master节点将进入无leader状态，无论该master节点失联前是否是leader。

  • 当leader从ZooKeeper失联时，将中断所有处理进程。user/developer/administrator会新开一个master实例当备份去尝试重新连接ZooKeeper。 Note: 很多生产环境部署的Mesos集群都会使用进程监控（如systemd和supervisord）来在进程崩溃时自动重启Mesos master节点

  • 或者，在master备份还没重新连接上ZooKeeper的时候，可能ZooKeeper已经新选了leader。
• 调度器失联则只会收到一个消息：它们和leader失联了。

当Slave节点失联时：

• Leader master对slave节点的 可用性检查会失败。

• Leader master将标记该Slave节点为失效状态，并把其未完成的工作标记为丢失状态。应用框架开发向导对这些任务的状态有详细说明。

• 被标记为非活动状态的slave节点，将无法完成重新注册，并会被随后通知关闭。

实现细节

Mesos实现了对ZooKeeper选择leader抽象化的两个层次，一个在src/zookeeper，另一个在src/master (具体细节可查询 contender|detector.hpp|cpp)

• 底层的LeaderContender和LeaderDetector 实现了一个松散的通用ZooKeeper选举算法。详见recipe （master小组节点小于3时的无群处理方法）。

• 高一层的MasterContender和MasterDetector包装了ZooKeeper的contender和detector的抽象层，来和ZooKeeper进行数据交互。

• 每个Mesos master节点都同时使用了一个contender和detector，用于选自己为leader或者发现现任leader。单独的detector是必须的，因为需要将从浏览器发来的请求访问任何一个没选成的leader的master节点上的Web界面时，需要将该请求重定向到现任leader master几点上。其他的Mesos部件（比如slave和scheduler）也都使用detector来找到现任leader master，并与其建立连接。

• leader候选组的概念通过Group对象实现。通过队列和错误重试的方式，处理ZooKeeper候选者的注册、注销和监控的流程。在过程中，它会监控Zookeeper会话的事件：

  • 连接
  • 重连
  • 会话过期失效
  • Znode的创建、删除、更新
• 超时：在和ZooKeeper失联一段时间后，系统会主动将会话设为过期超时的状态。详见MASTER_CONTENDER_ZK_SESSION_TIMEOUT 和 MASTER_DETECTOR_ZK_SESSION_TIMEOUT。这是因为ZooKeeper的客户端的库函数只能通过重连来提示会话过期。这些超时设定可在网络设定部分查看。