一种etcd容灾备份的设计与实现

康凯 360云计算

女主宣言

该文章主要还是围绕hulk虚拟化团队的stark平台展开的，stark平台是基于k8s + docker实现的，而etcd作为k8s的k-v数据存储方案，在我们的平台中起着非常重要的作用，一旦etcd出现数据丢失，整个k8s调度系统直接瘫痪，所以etcd的容灾备份显得格外重要。最后也希望该文章的etcd备份设计方案能给大家一点启发。

PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！

背景描述

当技术人员说起docker的时候，都会为他的优雅所折服。但是大部分人却不知道docker作为容器技术范例背后的技术实现。本篇我们会一起探索拥有大量活跃开发者的Docker容器集群管理系统kubernetes的关键组件-etcd，在我们线上的使用和相关实践。

etcd 是一个高可用的分布式k/v存储系统,作为一个受到ZooKeeper与doozer启发而催生的项目，除了拥有与之类似的功能外，更专注于简单、安全、快速和可信。

作为kubernetes的数据库，etcd存储了k8s自身的信息、各种业务容器信息和flannel网络配置信息供各节点协调，官方也支持数据的简单备份操作，但是在极端环境下的灾难恢复方面并没有很完备的方案，于是我们就从etcd集群常用的API入手，搭建了一套高可用的etcd灾备方案

方案设计

在集群健康的情况下，etcd集群中只存在一个leader，且从leader中落盘的数据是最新的，我们定时拿到tar包并将其推送到存储中间件中，再由存储中间件将备份数据推送到其他机房，整套系统保留最近两天的数据。

etcd灾备方案不分主次机器，整个集群同时对外提供服务，当一方出现故障时才会将备份操作自动切换到另一台机器。

为了避免出现上一份数据还未传输完成，下一次备份操作已经开始的情况，我们加上了文件锁：

*/5 * * * * flock -xn /root/etcd_DR/bin/../conf/mytest.lock -c 'python /root/etcd_DR/bin/rsync_remote_backup.py --hostlist /root/etcd_DR/bin/../conf/hostlist.cnf >> /root/etcd_DR/bin/../log/testlo

官方也提供了简单备份的方法：

[root@k0149v bin]# etcdctl backup --helpNAME: etcdctl backup - backup an etcd directoryUSAGE:

etcdctl backup [command options]

OPTIONS: --data-dir Path to the etcd data dir --wal-dir Path to the etcd wal dir --backup-dir Path to the backup dir --backup-wal-dir Path to the backup wal dir

整个系统代码的树形结构如下：

[root@k0149v ~]# tree etcd_DR/etcd_DR/├── bin│ ├── etcd│ ├── init│ └── rsync_remote_backup.py├── changelist├── conf│ ├── hostlist.cnf│ ├── members│ ├── mytest.lock│ └── option.spt├── etcd_DR.sh├── log│ ├── etcdlog_-t_start_2016-08-30_12:31:00.log│ └── testlog├── README└── status.log3 directories, 13 files

/bin/init 是环境初始化脚本，在crontab调用 rsync_remote_backup.py 之前进行环境初始化的操作;
etcd_DR.sh 调用/bin/etcd, 对crontab进行增删改操作，启动/停止系统的运行；
/bin/rsync_remote_backup.py 是整套系统的核心，检查判断当前机器的健康度并通过etcdctl的backup接口打包数据推送到存储中间件上，为了节省存储空间，只保留最近三天的数据。
status.log 是一个状态查看器，其中状态值代表了各种系统状态，方便后期查错，比如：ONGOING=2; STOP=3; INTERACTION=7.

本灾备方案的优点

切换成功率高：灾备系统的核心部件部署在etcd集群的每一个节点上，不存在灾备切换时起不来的情况。
切换时间快：由于切换的时候，就是新leader产生的时候，毫秒级别的切换时间。
数据实时性高：备份数据的实时性可以与集群数据达到同步。
数据丢失率低：可以保证主系统中只要有存活的节点，灾备系统都可以正常获取到数据。

本灾备方案的缺点

传输过程中使用的flock文件锁可能出现死锁的现象
实时同步对网络环境要求比较高，这个不用过于担心，目前我司的网络环境完全符合要求。

小结

集群故障完全不能使用时如何恢复

这种情况下就只能重建集群了，将最新的备份数据恢复到新的集群的任意一个节点上，使用 --force-new-cluster 参数启动etcd服务。这个参数会重置集群ID和集群的所有成员信息，然后手动添加其他节点即可

备份时怎么解决数据冲突的问题

给备份文件打包时加上时间戳，同时注明打包位置以便故障排查，打包数据类似下面：

-rw-r--r--. 1 root root 315075 Aug 30 17:15 2016-August-30_17-15-01_k0608v.add.bjyt.qihoo.net.tar.gz

该方案现在已经在stark平台上持续运行，备份状态良好，后续还需要继续观察。

小结

更多相关文章

随机推荐