Docker 1.12 ：认识 Swarm 模式下的节点崩溃处理

上周小编为大家推荐了《Docker 1.12：用 Swarm 模式创建 Swarm 集群》，本周我们将深入为大家解读 1.12 版本 Docker Swarm 模式下的节点崩溃处理。欢迎大家在评论中踊跃推荐 Docker 技术文章，通过审核后的文章会由 DaoCloud 为大家带来独家翻译。

在上一次班加罗尔 Docker Meetup 中，许多人对Docker引擎 1.12 版 Swarm 模式下的“应用预期状态调和”和“节点管理”功能怀有很大的好奇。我发现，展示环节中大家提出最多的问题，都是关于新 Docker Swarm 模式下的节点崩溃处理，尤其是 RAFT 一致性算法中主节点崩溃后如何处理。在这篇博客里，我会专门针对 RAFT 一致性算法，谈一谈“主节点崩溃”的问题。我们将看到 Swarmkit（Swarm 模式的主要技术实现）是如何使用 RAFT 一致性算法，确保没有单点故障，从而在分布式系统中实现高效率决策的。

在上一篇博客中，我们深入了解了 Swarm 模式的执行机制，并谈到了管理节点和工作节点之间的通信问题。运行 Swarmkit 的主机可以被整合到一起，创建一个 Swarm ，彼此协同处理任务。每一台新加入的主机，都变成一个 Swarm 节点。这个节点要么是工作节点，要么是管理节点。工作节点负责执行任务，而管理节点从用户那里获得任务说明，负责整合现有的集群，达到理想状态。

管理节点会保障集群内部环境状态的强一致性，以及基于 Raft 协议实现状态备份，另外通过内存读写保障速度，使集群可以在对崩溃保持较高容错率的同时，做出快速的决策部署。通过 API / CLI 命令，节点角色（工作节点或者管理节点）可以互相切换。换言之，如果某个主节点或者工作节点崩溃了，Swarmkit 会把它的任务（也就是容器）重新部署到其他节点上去。

快速概览一下 Raft 一致性算法

让我们来了解一下 Raft 一致性算法究竟是个什么。一个 Raft 集群包括了若干个服务器，数目通常是五个，这样系统就能承受两次崩溃。在给定的任意时间点上，每个服务器都处在以下三种状态的一种：指挥者、跟随者，或候选者。在一般操作中，一定会有一个指挥者，剩下的服务器都是跟随者。跟随者是被动的：它们自己不提交任何需求，仅仅响应指挥者和候选者提出的需求。指挥者处理所有的客户端需求（如果客户端向跟随者发送了需求，跟随者会把它转交给指挥者）。至于第三种状态——候选者——则是用来选举一个新的指挥者。 Raft 用一种心跳机制来触发指挥者选举。当服务器启动时，它们先从跟随者做起，并会在接收到指挥者或候选者发送的有效 RPC 协议（远程过程调用协议）之前，一直执行跟随者的工作。指挥者定时向全体跟随者发送心跳信息，以保持它们的授权。如果一个跟随者超过一定时间没有接收到心跳信息（这段时间称为“选举超时”），它就会假设指挥者已经失效，然后启动选举，来选择一个新的指挥者。要了解 Raft 的执行机制，我推荐阅读一篇文章，以下是链接：https://github.com/hashicorp/raft 。

请注意，要实现一致性，管理节点的数量必须时刻为奇数（1、3、5、7等）。如果你只有两个管理节点，万一其中一个崩溃了，就会导致无法取得一致的状况出现。理由是——超过 50% 的管理节点在实际运用 Raft 一致性算法前，都需要得到另一方的“同意”。

谈谈管理节点崩溃

在这里，我用谷歌云引擎上已有的 Swarm 模式集群，来展示一下主节点崩溃的情景。如下所示，我用5个节点组了一个 Swarm 模式集群，在 1.12.0-rc4 的 Docker 测试版本上安装运行。

5 个节点中，Swarm 模式集群已经把服务复制到其中 3 个节点——测试 – 主节点 1 ，测试-节点 2 和测试 – 节点 1 —— 上运行。让我们用 docker-machine 命令（我一直以来的最爱）来给通过ssh连接到测试 – 主节点 1 ，并按照之前演示过的，把工作节点（测试 – 节点 1 和测试 – 节点 2 ）提升为管理节点。

从此，工作节点就被正确升格为管理节点，并显示为“Reachable”。

“$docker ps”命令显示，有一个任务（容器）已经在主节点上运行。请记住，“$docker ps”必须在专用的节点上手动执行，才能知道哪个本地容器正在特定节点上运行。

下图描述了容器（或者任务）的详细清单，它们分布在整个 Swarm 集群上。

让我们来搞垮管理节点“测试-主节点 1”（方式随意，可以不彻底地关停之，也可以按如下所示，通过可用的 GCE 功能停止内存块）。管理节点（测试-主节点 1）已经不能使用了。如果你尝试通过ssh协议连接测试 – 节点2，并检查集群是否启动和运行，你会发现节点崩溃已经被处理好了，理想状态调试也已经开始。现在任务（或者容器）的 3 个复制件已经在测试 – 节点 1 ，测试 – 节点 2 和测试 – 节点 3 上运行了。

要执行 Raft 一致性算法，我推荐最少都要用到 1、3、5、7 等奇数个管理节点。当然最佳的策略是设置 5个管理节点，如果设置7个管理节点有可能会导致性能表现上的瓶颈，因为要在管理节点之间维持住相互协议，不发生错乱，就必然会在沟通上造成额外的花销。

技术直播预告

第三期用容器创造新世界

作为「容器改变世界」系列讲座的最终章，我们将迎来本系列的高潮，开叔会向我们展示一个怎样的新世界呢？大家敬请期待！