首页 / 更多教程 / 一种etcd容灾备份的设计与实现

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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了一种etcd容灾备份的设计与实现，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3702字，纯文字阅读大概需要6分钟。

内容图文

 康凯 360云计算

一种etcd容灾备份的设计与实现 - 文章图片一种etcd容灾备份的设计与实现 - 文章图片

女主宣言


该文章主要还是围绕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容灾备份的设计与实现 - 文章图片

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.


本灾备方案的优点

  1. 切换成功率高：灾备系统的核心部件部署在etcd集群的每一个节点上，不存在灾备切换时起不来的情况。

  2. 切换时间快：由于切换的时候，就是新leader产生的时候，毫秒级别的切换时间。

  3. 数据实时性高：备份数据的实时性可以与集群数据达到同步。

  4. 数据丢失率低：可以保证主系统中只要有存活的节点，灾备系统都可以正常获取到数据。


本灾备方案的缺点

  • 传输过程中使用的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平台上持续运行，备份状态良好，后续还需要继续观察。


内容总结

以上是互联网集市为您收集整理的一种etcd容灾备份的设计与实现全部内容，希望文章能够帮你解决一种etcd容灾备份的设计与实现所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/1030571.html

来源：【匿名】