业务稳定性迁移实验

在业务安全中，不仅仅要考虑业务是否有被攻击的可能，同时也要考虑整个业务的稳定性，如果大家认为这是运维要考虑的事情安全不需要考虑就有些片面了，在整体架构中，安全协同运维做好架构方面的设计是十分必要的，人无完人，只有方方面面都考虑到才能保证业务的安全。

在我们的架构中核心是zookeeper，在我前期的文章中也有关于我们业务架构的描述，不熟悉的朋友可以翻一翻，今天想讲的是zookeeper的平滑故障迁移，这实际上应该是故障应急演练，当然认为这是运维工作的可以跳过。

什么是zookeeper：

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

zookeeper的原理：

ZooKeeper是以Fast Paxos算法为基础的，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader (领导者)，只有leader才能提交proposer，具体算法可见Fast Paxos。因此，要想弄懂ZooKeeper首先得对Fast Paxos有所了解。

zookeeper的基本运行流程：

1、选举Leader。
2、同步数据。
3、选举Leader过程中算法有很多，但要达到的选举标准是一致的。
4、Leader要具有最高的执行ID，类似root权限。
5、集群中大多数的机器得到响应并接受选出的Leader。

实验理论

3台zookeeper形成稳定的集群，当其中一台发生故障时，另外两台接替故障的一台继续工作，当follower出现问题时，leader不会发生变化，此时将迁移的对象接入，由于持续工作的两台配置文件没有变更，所以迁移的对象无法接入，处于notrunning状态，改变配置重启follower节点，停止被迁移的zookeeper将迁移对象接入，此时应是被迁移对象与leader形成一个集群正常工作，改变第三个节点的配置文件形成迁移后的3节点集群

实验环境

4台zookeeper

IP：

172.31.253.111
172.31.253.112
172.31.253.113
172.31.253.115

实验步骤

1.配置zookeeper（112，113，115为一个集群，目前集群为原始集群，即为无故障集群，集群上放test作为数据标识）

112配置文件：zoo.cfg

Myid:1

113配置文件：zoo.cfg

Myid:2

115配置文件：zoo.cfg

Myid:3

启动集群，查看集群状态

112follower：

113follower：

115leader：

115是leader，保留115，从follower开始模拟112发生故障，替换112->111

4.替换

111配置文件：

Myid:1

启动111并查看状态

此时的集群状态：

111：not running（对状态有质疑的请往上翻看实验理论）
112：follower
113：follower
115：leader

查看数据：

存在测试数据test（标识数据）

将113的配置文件变更

停掉112重启并查看状态

此时集群状态：

111：follower
113：follower
115：leader

查看数据：

将115配置文件变更后重启

数据依旧存在并且完成zookeeper的故障机替换

注：在启动113时如果没有停掉112，会导致115,112为一个集群，111,113为一个集群，出现两个leader，数据在两个集群中同时存在，数据虽然不受影响，但集群会有瞬时的中断，在此过程中会造成数据丢失的风险，所以一定注意要将替换下的zookeeper停掉！

*本文原创作者：煜阳yuyang ，本文属于FreeBuf原创奖励计划，未经许可禁止转载