业务稳定性迁移实验 – 作者:煜阳yuyang

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

在我们的架构中核心是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原创奖励计划,未经许可禁止转载

来源:freebuf.com 2020-03-02 12:30:40 by: 煜阳yuyang

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论