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

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

谈谈管理节点崩溃

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

2

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

3

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

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

4

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

5

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

6

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

技术直播预告

 第三期   用容器创造新世界

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

Leave a Reply

Your email address will not be published. Required fields are marked *