ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

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

2021-03-22 11:51:42  阅读:160  来源: 互联网

标签:bin -- 备份 集群 etcd 容灾 backup


 康凯 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.


本灾备方案的优点

  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平台上持续运行,备份状态良好,后续还需要继续观察。


标签:bin,--,备份,集群,etcd,容灾,backup
来源: https://blog.51cto.com/15127564/2668168

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有