写点什么

zookeeper 迁移实践

用户头像
小江
关注
发布于: 1 小时前
zookeeper迁移实践

背景

由于公司管理层决定要将云平台从阿里云切换成 AWS,所以部署在阿里云上的所有中间件服务都需要迁移,包括 kafka, zookeeper 等。由于 zookeeper 集群保存着重要的状态信息,而且迁移过程中极易出错,在此记录,方便有需要的读者参考。

迁移要求

对 zookeeper 集群的迁移,需要保证两点:

1)数据不能丢

2)服务不能中断

即对于业务方来说,迁移过程应该是尽量无感知的,不能影响到业务。

实施方案

zookeeper 集群的迁移,针对不同的 zk 部署版本,迁移过程也有所区别。如果 zk 版本 >= 3.5,那么 zk 集群支持动态配置,此时迁移过程会简单很多(参考 zookeeper 官网介绍https://zookeeper.apache.org/doc/r3.5.9/zookeeperReconfig.html


而对于 zk < 3.5 之前的版本,可以有两种解决方案:

(1)停机迁移

(2)平滑迁移


方案一 停机迁移

这个方案最简单,操作方便,先把旧节点上的 zk 进程停掉,然后将 zk 数据目录 copy 一份到新节点,然后启动新节点进程即可。但缺点是迁移期间无法继续提供服务,而且停机时间视数据目录大小 copy 耗时而定。因此该方案适用于非线上环境 zookeeper 集群迁移。

zookeeper停机迁移


方案二 平滑迁移

该方案的基本思路是先扩展 zookeeper 集群到新节点,然后下线旧节点,在整个迁移过程中 zk 集群可以持续提供服务。因此,平滑迁移可以保证服务不中断,适合线上环境执行,但缺点是操作复杂,容易出错。

zookeeper集群平滑迁移


具体迁移流程

由于我们目前部署的 zk 集群版本为 3.4.12,为了保证线上服务不中断,我们采用平滑迁移方案。

假定迁移前集群由 server1, server2, server3 组成,迁移后集群由 server4, server5, server6 组成。原有节点配置如下所示:

server.1=localhost:2881:3881server.2=localhost:2882:3882server.3=localhost:2883:3883
复制代码

迁移流程如下:

1)新增 ID 为 4,5,6 的节点(注意,新增节点 id 需要大于旧节点 id),并依次启动 server4, server5, server6,其中 server4 需要进行二次重启。

server4 的配置如下:

server.1=localhost:2881:3881server.2=localhost:2882:3882server.3=localhost:2883:3883server.4=localhost:2884:3884server.5=localhost:2885:3885 #需要在启动server6后进行第二次重启并打开剩余节点注释#server.6=localhost:2886:3886
复制代码

server5 的配置如下:

server.1=localhost:2881:3881server.2=localhost:2882:3882server.3=localhost:2883:3883server.4=localhost:2884:3884server.5=localhost:2885:3885 server.6=localhost:2886:3886
复制代码

server6 的配置如下:

server.1=localhost:2881:3881server.2=localhost:2882:3882server.3=localhost:2883:3883server.4=localhost:2884:3884server.5=localhost:2885:3885server.6=localhost:2886:3886
复制代码

即新增节点的启动顺序为 server4(列表中不包含 server6) -> server5 -> server6 -> 重启 server4(包含完整列表)。


2)对 1,2,3 节点的配置文件,分别补充新增节点列表,e.g.

server.1=localhost:2881:3881

server.2=localhost:2882:3882

server.3=localhost:2883:3883

server.4=localhost:2884:3884

server.5=localhost:2885:3885

server.6=localhost:2886:3886


3)对原节点 1,2,3 中的 follower 节点,分别进行重启

可以使用命令 echo mntr|nc localhost 2181 来查看当前集群节点的角色。

假设现在节点 2 是 leader,那么分别重启节点 1 和节点 3(此时除了节点 2,其余节点都能看到集群有 6 个 member)


4)对原节点 1,2,3 中的 leader 节点,进行重启

重启原 leader 节点之前,先确认 follower 节点已经同步完成 echo mntr|nc localhost 2181

zk_followers 5

zk_synced_followers 5

重启旧 leader 后,会选举出新的 leader(一般是 id 最大的节点),假设为节点 6。

至此,我们拥有了一个 6 个节点组成的新 zk 集群,其中 3 个旧节点,3 个新节点。


5)对外发布新节点 4,5,6 组成的连接串(即业务方将使用这个串进行新集群交互)

这一步很重要,它可以让业务方通过新地址串连接 zk 集群,方便我们后续下线旧节点。比如我们目前的集群有 6 个节点组成,但是我们对外发布 e.g. ip4:2181,ip5:2181,ip6:2181 的新节点连接串,这样业务方就不再感知旧节点,后续我们下线旧节点时就不会对业务方造成影响。


6)确认业务方替换完新连接串后(注意,因为新连接串只包含 4,5,6 节点,所以如果业务方替换完后,不会再有业务方机器连接旧节点):

A.先下线节点 1 (此时可用节点为 5 个,满足 6 个节点集群需要至少 4 个可用的要求),剩余两个可用的旧节点用来滚动替换,最终建成一个 3 个新节点的集群。


B.剩余 2,3,4,5,6 节点分别将节点 1 的配置从 zoo.cfg 中删除/注释,然后按先 follower,后 leader 的顺序重启各个节点,这样形成 5 个节点的 zk 集群。


C.对于 5 个节点的集群,可以容忍两个节点失效,因此,先下线旧节点 2,然后对于剩余的 3,4,5,6 节点分别将节点 2 的配置从 zoo.cfg 中删除/注释,然后按先 follower,后 leader 的顺序重启各个节点,这样形成 4 个节点的集群。


D.对于 4 个节点的集群,可以容忍一个节点失效,此时要注意不能直接下线节点 3,否则后续重启节点 4,5,6 时会造成集群不可用。因此对于剩余的 4,5,6 节点分别将节点 3 的配置从 zoo.cfg 中删除/注释,然后按先 follower,后 leader 的顺序重启各个节点,这样最终形成 3 个新节点的集群,此时下线最后一个旧节点 3。


7) done,此时最终形成节点 4,5,6 组成的新集群,数据跟旧集群一致。

注意事项

1.新增节点必须按照节点顺序依次启动,不能同时启动新增节点,关键因素就是先要保持原有的 leader 不变,不能因为新增节点导致重新选举。

这里我们要解释下为什么第一次启动节点 4 时配置列表中不能包含节点 6,假设我们包含节点 6,那么节点 4 看到集群包含 6 个节点,需要至少 4 个节点选择一致才能确定 leader 节点,而这时节点 1,2,3 会有一致选择,而节点 4,5,6 会有一致选择,都达不到确定 leader 节点的要求。


2.新增节点的 id 必须大于原有节点 id。这是因为 zookeeper 在两个节点之间建立连接时,只允许 id 较大的节点向 id 较小的节点发起连接,如果 id 较小的节点向 id 较大的节点发起连接,会被舍弃,如下图所示:

id较小的节点向id较大节点发起连接

假设新增节点 id 比原有节点 id 小,会出现什么情况呢?

答案就是会出现两个 leader,并且最后会导致数据不一致,如下图所示:

当前集群状态,出现两个leader


最后形成的leader为4,此时集群所存数据

而真实数据为原来 leader,节点 5 的数据为

/xiaojiang = 'born-in-beihai'

/cangcang = 'born-in-hangzhou'


造成这种状况的根本原因,在于重启原有 leader 节点前,现有集群节点没有全部处于 sync 状态。而新增较小的节点 id,使得在各个新增节点重启过程中出现较大 id 节点(原有节点)无法感知较小 id 节点加入集群的情况:

id较大节点无法感知较小id节点的加入

举个例子,原来有节点 4,5,6(leader 为 5),新增节点 1,2,3,那么启动完新增节点后,整个 zk 集群还是只有原来的 4,5,6 节点处于 sync 状态,此时节点 1,2,3 都处于寻找 leader 状态,并且都投票给节点 3(相同情况下,编号大的胜出)。那么当重启节点 4 后,节点 1,2,3,4 选出了节点 4 作为 leader(选票数超过 6 个节点的一半),而此时节点 5,6 仍然组成以 5 为 leader 的集群,这时两个集群都能提供服务,那么很明显数据将出现不一致。而后面继续重启节点 6 和节点 5 时,leader 仍为节点 4(仍然获得超过集群一半以上节点的支持),那么最后整个集群将以 leader(节点 4)的数据作为依据,因而先前在节点 5 作为 leader 期间变更的数据将丢失!!! 这无疑会是灾难性的后果。


3.在对外提供新集群连接串时,不要包含老节点地址。

业务方客户端在使用 zk 连接串时,都会随机挑一个地址进行尝试,如果无法连接则尝试下一个地址。因此我们只提供新地址组成的连接串,可以方便我们后续判断是否所有业务方都已使用新串进行连接。


4.在进行迁移的第 6 步进行滚动下线的 D 步骤时,要注意:不能先下线节点 3 然后再依次进行重启新节点。这是因为对于 4 个节点集群只能容忍一个节点失效,如果先下线节点 3,那么后续重启任何一个节点都将使得 zk 集群在重启期间不可用。


遇到的问题

1.zk server 上有保留着已建立连接的 established 信息(netstat -ntap),但是对应 server 却没有相应的连接。

这个问题比较诡异,不好排查,不影响操作流程。在 zookeeper 官网上找到一个原因可供参考:

Some broken network infrastructure may lose the FIN packet that is sent from closing client. These never closed client sockets cause OS resource leak.

解决方案:

官方文档有提到一个配置(clientTcpKeepAlive,3.6.1 开始支持)

Setting this to true sets the TCP keepAlive flag on the client sockets. Enabling this option terminates these zombie sockets by idle check.


2.迁移过程中 zk server 中可能会看到类似的日志:

Too many connections from /172.23.xxx.xxx - max is 60
复制代码

这个 warning 日志表示当前 server 接受的客户端连接数超过了默认给每个客户端 IP 使用的连接数,如果想调整这个参数,重新设置maxClientCnxns即可,e.g.

# set max client connects maxClientCnxns=300
复制代码

总结

3.5 版本前的 zk 迁移比较繁琐,容易出错,在迁移前也查阅了一些资料,但都没有详细的迁移步骤,在参考相关资料及自身搭建测试环境验证后,顺利完成了线上环境 zk 集群的迁移。为了避免后来人走弯路出错导致集群数据不一致或者服务中断,留下经过验证的一些迁移步骤,希望对大家有所帮助。

大家有更好的迁移计划也欢迎留言探讨~

发布于: 1 小时前阅读数: 2
用户头像

小江

关注

~做一个安静的码男子~ 2019.02.11 加入

软件工程师,目前在电商公司做研发效能平台,中间件维护开发相关工作

评论

发布
暂无评论
zookeeper迁移实践