当前位置:   article > 正文

2024年Linux最新ZooKeeper运维——集群动态迁移与扩缩容(不停机+不丢失)

2024年Linux最新ZooKeeper运维——集群动态迁移与扩缩容(不停机+不丢失)

server.5的zoo.cfg配置

peerType=observer

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.4 = 127.0.0.1:2691:3791

server.5 = 127.0.0.1:2692:3792:observer

server.6 = 127.0.0.1:2693:3793

server.6的zoo.cfg配置

peerType=observer

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.4 = 127.0.0.1:2691:3791

server.5 = 127.0.0.1:2692:3792

server.6 = 127.0.0.1:2693:3793:observer

server.4server.5server.6分别启动,数据就可以从源集群同步到目的集群了,即使现在源集群有写操作,也可以实时同步。

  • 如下是server.4作为源集群的Observer启动时的日志:

  • server.4刚启动时,是一个LOOKING状态,就是在找Leader

  • 找到Leader以后,就变成了OBSERVING状态。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hXDEN6rq-1632664267904)(C:\我的坚果云\mymd\image\zk_observer1.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t7sErJxi-1632664267907)(C:\我的坚果云\mymd\image\zk_observer2.png)]

2、切换客户端zk地址

虽然server.4server.5server.6都是Observer,但是也可以对外提供服务。此时可以将连接目的集群的客户端,如qconf_agentkafka中的zk地址修改为目的集群的。

3、修改目的集群配置

先将目的集群的配置observer相关的配置去掉,都修改为如下配置:

server.4 = 127.0.0.1:2691:3791

server.5 = 127.0.0.1:2692:3792

server.6 = 127.0.0.1:2693:3793

4、依次重启目的集群

目的集群的配置修改好了,还没有重启,此时依然是作为Observer在对外提供服务。

现在依次重启server.4server.5server.5成为目的集群的Leader,此时已经完全和源集群分离,立刻重启server.6server.6作为Follower加入目的集群。

但是在目的集群重启Leader选举时,可能存在短暂的数据不一致,因为可能在server.5重启触发Leader选举时,server.6可能接收到写请求,依然转发给源Leader,所以server.6甚至是整个目的集群都尽快完成重启。

到这里基本就完成了集群的不停机动态迁移,观察一段时间目的集群的服务状态,如果正常,就可以把源集群停掉了。

这过程一旦出现问题,比如目的集群重启失败,立刻回滚第二步,然后查看目的集群的启动日志。

三、zk集群动态扩容


zk集群的扩容,对读请求来说是可以提升性能,但是对于写请求就未必是好事了,因为所有的写请求都需要Leader统一协调处理(两阶段提交),所以服务节点多了反而会降低写性能。

zk集群的扩容可以有两种形式,一种是扩容节点以Observer附庸在源集群上,另一种就是正常意义上扩容,给源集群加Follower节点。

依然用一台服务器搭建的伪集群演示。

1、Observer扩容

Observer方式扩容,不参与源集群的投票和过半机制,依然可以一起加入到zk地址中对外提供服务,有如下几个优点:

  • 提升源集群的读性能,对写性能影响很小。

  • 可以将Observer部署在异地机房,读请求就近发送,降低延迟。

但是多多少少对写操作有一定影响,即Observer所在服务,处于无监管状态,无法确保数据都同步了,可能因为网络原因一些请求被丢弃等,需要对Observer进行监控。如果Observer部署在异地,写同步的延迟可能也会增加。

Observer扩容还有一个缺点,就是源集群的稳定性没有提高。

假设扩容的Observer服务为server.4,只需要在其zoo.cfg中如下配置即可:

server.4的zoo.cfg配置

peerType=observer

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.4 = 127.0.0.1:2691:3791:observer

2、Follower扩容

Follower扩容建议扩容服务节点数为偶数个,这样和源集群加起来就是奇数个。

在不停机,只有Leader重选时不能正常对外提供服务外,集群一直处于正常状态,照这个要求,试了多种场景,好像只有一种方式:新节点作为Follower加入源集群。

假设,源集群为3个服务节点,Leader为server.1,现在扩容为5个,扩容节点为server.7server.8。源集群初始配置为:

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

(1)修改扩容节点配置

修改server.7server.8zoo.cfg为如下所示:

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.7 = 127.0.0.1:2697:3797

server.8 = 127.0.0.1:2698:3798

(2)启动扩容节点

server.7server.8依次启动后,首先处于投票选举的状态(LOOKING),交换选票,收到源集群 FollowerLeader 的选票后,统计选票,如果某个节点拥有超半数的选票,且有Leader,则扩容节点设置自己的状态为FollowerFOLLOWING),并退出选举。这样扩容节点就和源集群建立了连接。

但是源集群保持独立,新节点故障与否不影响源集群过半机制判断。

(3)修改客户端zk地址

修改连接源集群的客户端的zk地址为加上server.7server.8共5个ipport

(4)修改源集群的配置

依次修改源集群的zoo.cfg,加上server.7server.8

(5)重启源集群

依次重启源集群,但是需要注意源集群的Leader最后重启,如server.1是Leader,就先重启server.2,再重启server.3,此时源集群处于不可用和扩容之后的新集群处于Leader选举的状态,此时会有短暂不能正常对外提供服务。

最后重启server.1。扩容完毕。

需要注意:扩容之后的集群的Leader变了,可能为扩容节点中的一个。

(6)人为脑裂

需要强调一下,如果扩容的节点数超过了源集群的节点个数,可能人为造成脑裂。

如3个扩容为7个,需要扩容4个节点,使用如上方式扩容时,就可能出现问题。扩容节点依次重启时,处于投票选举状态,交换选票,收到源集群 FollowerLeader 的选票后,统计选票,源集群有3个节点投给了某个节点,但是扩容之后的节点个数为7,3没有超过7的半数,所以扩容节点不会设置自己的状态为FollowerFOLLOWING),一直处于投票选举状态。

需要强调两点:

  • 处于投票状态的服务节点接收到其他节点的选票时,会根据选票信息中发送者状态来区分统计,FollowerLeader 发送的一起统计,同处于投票状态(LOOKING)的节点一起统计。

  • 统计选票时,如果是FollowerLeader 发来的选票,说明此时集群中已经有Leader了,但是还是先判断票数是否过半,然后再判断集群中是否有Leader

当4个扩容节点都重启后,4个扩容节点交换选票,可以再选一个Leader出来,此时就存在两个Leader,互不干扰。源集群没有重启过还是认为自己是3个节点的,而扩容之后的集群,认为自己是7个节点,但是只有4个正常节点,挂一个就会死。

脑裂出现了,可能会出现数据不一致问题。

正常情况下,ZooKeeper不会因为网络分区出现脑裂问题。

四、zk集群动态缩容


因为扩容有两种方式,对应的缩容也有两种应对措施:

  • 缩减掉Observer很简单,基本不会影响源集群。

  • 缩减Follower,就稍微复杂些。

以源集群5个节点缩减为3个为例,源集群配置为:

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.7 = 127.0.0.1:2697:3797

server.8 = 127.0.0.1:2698:3798

为了做好运维面试路上的助攻手,特整理了上百道 【运维技术栈面试题集锦】 ,让你面试不慌心不跳,高薪offer怀里抱!

这次整理的面试题,小到shell、MySQL,大到K8s等云原生技术栈,不仅适合运维新人入行面试需要,还适用于想提升进阶跳槽加薪的运维朋友。

本份面试集锦涵盖了

  • 174 道运维工程师面试题
  • 128道k8s面试题
  • 108道shell脚本面试题
  • 200道Linux面试题
  • 51道docker面试题
  • 35道Jenkis面试题
  • 78道MongoDB面试题
  • 17道ansible面试题
  • 60道dubbo面试题
  • 53道kafka面试
  • 18道mysql面试题
  • 40道nginx面试题
  • 77道redis面试题
  • 28道zookeeper

总计 1000+ 道面试题, 内容 又全含金量又高

  • 174道运维工程师面试题

1、什么是运维?

2、在工作中,运维人员经常需要跟运营人员打交道,请问运营人员是做什么工作的?

3、现在给你三百台服务器,你怎么对他们进行管理?

4、简述raid0 raid1raid5二种工作模式的工作原理及特点

5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?

6、Squid、Varinsh和Nginx有什么区别,工作中你怎么选择?

7、Tomcat和Resin有什么区别,工作中你怎么选择?

8、什么是中间件?什么是jdk?

9、讲述一下Tomcat8005、8009、8080三个端口的含义?

10、什么叫CDN?

11、什么叫网站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题,mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以点击这里获取!

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题,mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以点击这里获取!

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Cpp五条/article/detail/681042
推荐阅读
相关标签
  

闽ICP备14008679号