在业务安全中,不仅仅要考虑业务是否有被攻击的可能,同时也要考虑整个业务的稳定性,如果大家认为这是运维要考虑的事情安全不需要考虑就有些片面了,在整体架构中,安全协同运维做好架构方面的设计是十分必要的,人无完人,只有方方面面都考虑到才能保证业务的安全。
在我们的架构中核心是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
请登录后发表评论
注册