基于Ceph快照的异地灾备设计

作者：吴香伟 发表于 2017/02/06
版权声明：可以任意转载，转载时务必以超链接形式标明文章原始出处和作者信息以及版权声明

喜欢请点击右边打赏，谢谢支持！

---

引子

技术改变生活。
越来越方便的手机让大家能够更有效的利用碎片时间，我很享受在上下班的公交车上或在阳光明媚的花园里梳理思路，并写成文字上传到简书；要是搁在几年前的PC时代画风可能是坐在星巴克靠窗的桌子上边喝咖啡边敲键盘；如果时间再久远点，应该有间书房有张书桌，书桌边有个磨墨的小书童…

第一种情形跟后两种情形有着本质的区别。咖啡可能洒在键盘上烧坏主板，辛苦一下午写出的文字再也找不回来了；后院可能起火将写了两天的文字烧成灰烬，再也找不回来了。花园散步也可能摔一跤手机掉进水里开不了机，但不必担心因为我的文字早已经实时同步到了简书的服务器，并且不止保存了一份，并且不只保存在一个地区。所以不用担心跌倒，也不用担心地震，因为背后有异地灾备技术。

背景

这是去年初（2016年）为一紧急项目而设计，20K+代码量，陆陆续续花了大半年时间。异地灾备讲究两地三中心，两地指距离较远的两个地方，比如北京到上海一千多公里。三中心指3个数据中心，两个数据中心在同城，另一个在异地。同城两个数据中心间的数据采用同步方式，以IO为粒度。异地数据中心间一般采用异步复制。

Ceph社区有两种方法可以做站点间的数据复制：一种基于快照，主站点备份时为存储块打快照，将快照的差异部分发送到备站点重新生成新快照；另一种是当时社区正在开发的基于Rbd Journal的Rbd Mirror方案。

当时两种方案都有问题。Mirror方案正在开发不成熟，跟数据库配合也是个问题。快照已经很成熟，但有先天的缺陷：一方面打快照对原块的性能有很大影响，尤其是随机IO；另一方面，快照间的差异部分是在备份时计算出来的，因此很耗时，即使两个快照间没有差异也要花上很长一段时间来扫描差异部分。经过权衡，采用了第一种方案。现在社区还有个叫Ceph-backup的开源项目也是基于快照，不过与本方案相比要简陋很多。

总体架构

概念。
主站点，生产环境的数据中心；
备站点，备份环境的数据中心；
备份策略，确定备份的时间段、频率以及快照回收的频率；
备份任务，包括备份哪个存储块，由谁来备份。

网络结构。
主备站点间有独立的灾备网络，灾备网络为千兆带宽，延迟为33毫秒左右。站点内部除了灾