CloudBees CI使用Velero进行灾备(DR)概念验证

企业灾难可能是技术、自然或人为层面的。自然灾害包括洪水、龙卷风、飓风、滑坡、地震和海啸。人为和技术灾难涉及的面较广，包括危险物质泄漏、电力或基础设施故障、化学和生物武器威胁、网络攻击、恐怖主义行为、爆炸和内乱。这些都有可能造成企业IT系统的关闭，以及阻碍企业的整体运营。

对于企业来说，停机时间和技术中断就像一个恐怖故事，所以，您需要一个灾难恢复 (DR) 计划。

阅读本文，您将了解现代云平台上，CloudBees CI实施此类灾难恢复计划的效果。

立即联系CloudBees授权合作伙伴——龙智，获得更多关于CloudBees的咨询、试用、服务等信息。

生产环境中部署的关键业务功能，必须有灾备计划，以便在系统意外崩溃时，可以将业务迁移到本地区的其它机房甚至其它地区。

这就是CloudBees决定进行概念验证的原因，能够了解在现代云平台上，为 CloudBees CI实施此类灾难恢复计划的效果如何。

CloudBees专注于以下几种场景: CloudBees CI在Elastic Kubernetes Service (EKS)中运行，对于$JENKINS_HOME卷使用Elastic Block Store (EBS)，并由Route 53管理域。它演示了使用常用的OSS Velero项目作为备份系统，对元数据使用简单存储服务(S3)，并使用EBS快照来存储主要数据。

为什么CloudBees要选择这一场景？因为采用Kubernetes能使我们关注应用程序本身，而不是基础设施。当在Kubernetes上使用类似Velero的工具时，不仅会备份和恢复数据卷，而且还会备份和恢复所有元数据。这意味着我们可以通过一些简单、可移植的命令来运行主要的操作。

除了Velero，我还能使用其他工具吗？是的，当然可以。这篇文章中展示的概念可以用其他开源或商业的备份工具来实现，不管是在Kubernetes上还是其他地方，只要它们能够跨区域同步数据。例如，Google Cloud (GCP) 正在为Google Kubernetes Engine (GKE)提供一个原生的集成备份系统。

能剧透一下结果吗？能，但继续阅读，您能收获更多有趣的信息和背景。CloudBees进行了测试，测试规模约100个在用的托管控制器，能够达成RPO（Recovery Point Objective）和RTO（Recovery Time Objective）目标。更具体地说，CloudBees可以在每15分钟安排一次备份的基础上实现较低的RPO，而RTO则在同一范围内。

CloudBees CI的灾难恢复要求

一般来说，CloudBees CI的跨区灾难恢复有以下几个要求：

1. 文件系统数据，例如$JENKINS_HOME卷，必须在灾难发生之前复制到备用区。因为灾难发生后，恢复数据为时已晚。
2. 元数据，例如进程列表、网络配置或不在$JENKINS_HOME中的任何内容，也必须提前复制。应该假定主要区域是完全不可访问的。
3. 管理员必须有一种简单的、大部分是自动化的方式来触发切换（failover）。(当在主区域检测到问题时，不需要自动触发切换。)
4. 一旦恢复到备用区域，CloudBees CI必须在没有任何严重错误(例如：文件写入不一致等)的情况下启动。
5. 故障转移过程必须包括将CloudBees CI的DNS条目切换到新的物理位置，以便任何浏览器书签、webhook或类似组件都可像恢复之前那样继续工作。
6. 恢复时间目标(RTO)由管理员确定，但通常是一个小时或是更少的时间。这意味着故障转移过程需要在几分钟内完成，CloudBees CI应该很快启动并运行，随即准备执行构建。
7. 恢复点目标(RPO)可能较长，大约为一天，但也可能与RTO相当。因此，只有少数最新的构建或配置更改可能会丢失。
8. 管理员应该清楚地知道恢复的系统实际上是从备份中恢复的，并有机会检查可能因故障转移而中断的任何构建。

备注：

• 由于Jenkins架构，UI将会有一段时间无法访问，任何传入的webhook也会丢失。但是，监听hook的系统，如Multibranch项目，应该配置为偶尔轮询作为备用。
• 预计可能已经因为故障转移而中断的构建，不会自动恢复或重新启动，也不去尝试保存工作区的内容或节点的实时进程状态。