共计 6424 个字符，预计需要花费 17 分钟才能阅读完成。
企业劫难可能是技术、天然或人为层面的。自然灾害包含洪水、龙卷风、飓风、滑坡、地震和海啸。人为和技术劫难波及的面较广，包含危险物质透露、电力或基础设施故障、化学和生物武器威逼、网络攻击、恐怖主义行为、爆炸和外患。这些都有可能造成企业 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 的跨区劫难复原有以下几个要求：
- 文件系统数据，例如 $JENKINS_HOME 卷，必须在劫难产生之前复制到备用区。因为劫难产生后，复原数据为时已晚。
- 元数据，例如过程列表、网络配置或不在 $JENKINS_HOME 中的任何内容，也必须提前复制。应该假设次要区域是齐全不可拜访的。
- 管理员必须有一种简略的、大部分是自动化的形式来触发切换（failover）。(当在主区域检测到问题时，不须要主动触发切换。)
- 一旦复原到备用区域，CloudBees CI 必须在没有任何严重错误 (例如：文件写入不统一等) 的状况下启动。
- 故障转移过程必须包含将 CloudBees CI 的 DNS 条目切换到新的物理地位，以便任何浏览器书签、webhook 或相似组件都可像复原之前那样持续工作。
- 复原工夫指标 (RTO) 由管理员确定，但通常是一个小时或是更少的工夫。这意味着故障转移过程须要在几分钟内实现，CloudBees CI 应该很快启动并运行，随即筹备执行构建。
- 复原点指标 (RPO) 可能较长，大概为一天，但也可能与 RTO 相当。因而，只有多数最新的构建或配置更改可能会失落。
- 管理员应该分明地晓得复原的零碎实际上是从备份中复原的，并有机会查看可能因故障转移而中断的任何构建。
备注：
- 因为 Jenkins 架构，UI 将会有一段时间无法访问，任何传入的 webhook 也会失落。然而，监听 hook 的零碎，如 Multibranch 我的项目，应该配置为偶然轮询作为备用。
- 预计可能曾经因为故障转移而中断的构建，不会主动复原或重新启动，也不去尝试保留工作区的内容或节点的实时过程状态。
CloudBees CI 中的劫难复原反对
CloudBees CI 与 DR 兼容，包含跨区域。从技术角度来看，它波及到以下次要组成部分：
- Jenkins 外围和插件通常将配置和运行时的状态，都保留在文件系统层次结构中。因而，简略地将 $JENKINS_HOME 卷复制到新地位就足以进行备份。在可行的状况下，元数据文件都是主动编写的，并且尽所有致力容忍失落、截断或损坏的文件，但出于平安起因，也有一些例外。
- 流水线插件的设计目标是容许构建版本在控制器重启时运行。同样的机制也实用于备份和复原或劫难复原场景中的输出等步骤，这些步骤不需节点参加就会暂停。当构建在节点块内的节点上运行，并且因为区域中断或更常见的问题而销毁或失落节点时，以后构建不可能在新的节点上重试这一阶段。然而，这种状况至多能够记录在构建日志和元数据中，并能够从头开始重新启动构建。
- CloudBees CI 蕴含专有的性能，可检测复原场景，向管理员显示专门的告诉，并列举可能或必定受到影响的构建版本。
2022 年 4 月公布的 CloudBees CI 2.332.2.6 版本中有一些性能改良。咱们会持续汲取客户的意见，并作出适当的改良。
Kubernetes 上的 CloudBees CI 还受害于 Kubernetes 管制立体的弱小容器治理。除了作为 StatefulSet 运行的经营核心 (operations center) 和托管控制器 (managed controllers) 之外，控制器还应用 Jenkins Kubernetes 插件在一次性节点上安顿构建，无需显式治理基础设施。假如备份区域的集群有足够的容量，那么一旦托管控制器再次启动，复原后的装置就能够运行新的构建。备份不须要蕴含 Pod，因为操作核心或治理控制器 Pod 会主动从新创立。代理 Pod 无奈从备份中复原。
出于 DR 目标，CloudBees CI 还反对托管控制器休眠。如果在最初一次备份时，托管控制器中只有一部分实际上在运行，那么复原之后也同样如此。交付给复原集群的 SCM webhook 能够像平常一样“唤醒”休眠的托管控制器并触发构建。
CloudBees CI 还提供了配置即代码 (CasC) 性能。齐全转换为 CasC 的装置可能不须要传统备份来实现劫难复原；复原操作可简略地包含在新集群中运行 CasC 疏导脚本。然而，如果您须要保留长期数据（例如构建历史记录），那么出于 DR 目标，可能仍须要从备份执行文件系统级复原。
在 AWS 上应用 Velero
Velero 包含一个实用于 AWS 的规范插件，专门基于 S3 元数据存储和 EBS 快照。不过此插件目前暂不提供跨区域反对。
作为这个概念验证的示例，咱们为这个 Velero 插件开发了自定义补丁，它实现了跨区 EBS 快照复制。为放弃较低的 RPO，咱们还为 Velero 核开发了自定义补丁，以并行化卷快照操作。能够将备份复原到主区域或 failover 区域，并在复原时主动抉择适当的快照。
重要提醒：
这些补丁应该被认为是 实验性的且无奈反对。他们目前的模式不被上游 Velero 我的项目承受。对 Velero 的广泛跨地区反对正在探讨中，因为它可能是基于新的基础架构。
此外，咱们还为 CloudBees CI 开发了简略的 Velero 插件，该插件并非针对 AWS。它在每个 StatefulSet 中将以后复原的标识符记录为环境变量，这样应用 Restart Aborted Builds 插件的托管控制器就会收到对于从备份中复原的警报。
演示
代码
有配套的存储库和公布版，可演示本篇文章的内容，并对其进行更具体的扩大。
- 存储库: https://github.com/cloudbees-…
- 公布: cbci-velero-eks
留神：这里介绍的架构和代码旨在进行概念验证，并没有制订对于如何在生产环境中部署 CloudBees CI 的规范。
架构
下图展现了为运行演示而部署的所有 AWS 组件。
△ 图 1：演示架构图 概述
流程
构建阶段
△ 图 2：演示架构图 偏重构建阶段
构建劫难复原演示的自动化脚本实现所有步骤后，将在原始 (东) 和故障转移 (西) 区域创立以下元素:
- 在 EKS 上运行的 Kubernetes 集群
△ 图 3：次要 (东) 区域和故障转移 (西) 区域的 Kubernetes context 元素，通过 K9s 工具查看
- 部署在 Nginx 入口控制器和 Velero 图表 k8s 资源部署，以及 k8s Metrics 服务器组件
△ 图 4：运行演示设置后，故障转移区可用的 Kubernetes 正本集，通过 K9s 工具查看
除了跨区域的通用元素之外，原始区域将用于现代化云平台的 CloudBees CI 部署，包含一个经营核心和一组通过 Helm 和 CasC 配置的托管控制器。
△ 图 5：在 MC_COUNT 设置为 5 的状况下运行演示设置后可立刻从主区域取得 Kubernetes Statefulset，通过 K9s 工具查看
在提到的区域外，在全局级别上，创立了以下元素：
- 在 AWS Route 53 内的一条 A 记录，指向主区域的入口控制器的 AWS ELB alias。
△ 图 6：运行演示设置后，来自 Route 53 的 AWS A 记录指向主 AWS ELB alias，通过 AWS 控制台查看
- 全局 S3 bucket ((连贯到西部区)，存储 Velero 备份，Velero 调度程序是在部署 CloudBees CI 图之后立刻创立的。
△ 图 7：运行演示设置后，全局 AWS S3 Bucket 可用，通过 AWS 控制台查看
最初，为主区域 (Primary Region) 除 pods 和事件外的所有 K8s 对象创立 Velero 备份打算。它将安顿以下事件：
- Velero 命名空间备份
- CloudBees CI 命名空间备份
- 存储在 s3 Bucket 中每个 PV 的 EBS 快照
- 将 EBS 快照复制到故障转移区域
留神：如不心愿应用打算备份，也能够应用 backup.sh 脚本启动备份
CI 工作负载模仿
此时，能够依据您的 DR 测试要求扩大集群节点组，更新 cbci-eks-dr-demo/infra/cluster.yaml 上定义的初始 desiredCapacity。
一旦节点胜利扩大，就可通过运行 reload-cbci 脚本来模仿 CI 工作负载，它将触发每个托管控制器中托管的 3 个流水线。值得注意的是，在运行加载命令之前，应该调整 MC_COUNTto 的新值，以适应节点组的新大小)。
△ 图 8：Jenkins pipeline 工作通过其中一个 controller 运行, 从 CloudBees CI 控制器仪表盘查看
△ 图 9：来自节点的 Kubernetes Pods，上述 Jenkins pipeline 工作, 通过 K9s 工具查看
劫难复原故障转移
△ 图 10：演示架构图, 偏重故障转移阶段
在转移到故障转移局部前，务必确保 Velero 备份失常: 查看是否是“已实现”的非过期备份，且没有谬误或正告。
△ 图 11：可用 velero 备份的描述性列表, 偏重故障转移阶段，从终端查看
而后，可执行 CloudBees CI 平台到故障转移区域的复原，从最新的衰弱备份中传输蕴含利用配置和构建信息的所有 K8s 资源。Velero 此前启动了名称空间复原。
务必留神，主区域中的运行流水线会在复原操作之后立刻在故障转移区域中复原。
另请查阅 CloudBees 检查点性能对于这类场景的全副劣势。
△ 图 12：故障转移区域中的运行流水线, 从 CloudBees CI 控制器仪表盘查看
为了验证复原是否胜利，请转到复原后的托管控制器的托管 Jenkins 仪表板，从 Restart Aborted Builds 插件的治理监视器能够看到这样的音讯:This controller is new restore from backup。
△ 图 13：来自 Restore Build Plugin 的音讯, 通过 CloudBees CI Controller > Manage Jenkins 查看
此外，Velero 复原操作可通过其 CLI 形容，以查看其状态。
△ 图 14：残缺形容由 Velero 备份执行的复原 从终端查看
DNS 开关
CloudBees 利用将可从故障转移区域拜访，因为有一个 DNS 开关从东部的 ELB alias 到西部。
△ 图 15：演示架构图 重点关注 DNS 替换阶段
可从 Route 53 Hosted Zone 进行验证。
图片
△ 图 16: 运行 DNS 开关后，来自 Route 53 的 AWS A 记录指向故障切换 AWS ELB alias , 从 AWS 控制台查看
测试和后果
整体而言，Velero 补丁曾经测试到大概 100 个被动治理控制器的规模。休眠治理控制器对备份工夫的影响很小，因为 EBS 卷快照以及跨区域快照复制都是增量的。在正当的负载条件下，备份只需几分钟就能实现，因而，基于每 15 分钟调度一次的备份，可实现较低的 RPO。因为 Kubernetes 元数据的重建是相当快的，因而在同一区域的 RTO 也是可能实现的。从 EBS 快照创立的卷是提早加载的，因而操作核心和托管控制器的启动工夫比通常要慢，但依然能够承受。
理论后果取决于许多因素，备份性能次要取决于批改的 512 KiB 块的数量。能够批改大量或大型文件的托管控制器 (例如通过运行许多并发构建、应用大型日志文件，或将构建工件存储在 $JENKINS_HOME(基于 s3 的工件存储合适于这个工作) 施加了最大的负载，因而须要工夫。从 EBS 快照创立的卷是提早加载的，因而操作核心和托管控制器的启动工夫比通常要慢，但依然能够承受。
考量
如果你想尝试一下实验性的 Velero 插件补丁，请留神有一些限度:
- 它只反对单个可用分区 (AZ) 中的卷，即便可将 EKS 配置为应用 EBS 跨区的几个 AZ 运行有状态的工作负载。然而，无状态的 pods(如节点)能够运行在另一个 AZ 的节点池中。
- 它只反对一个故障转移区域，不实现元数据复制。元数据只发送到故障转移区域中的 S3，因而如果故障转移区域产生故障，从主区域中的备份进行复原将无奈工作。
还要留神，AWS 弹性文件系统 (EFS) 有一个十分不同的快照和复制架构，不在这个插件治理范畴内(打补丁或其余形式)。
与劫难复原相干的 AWS 计费老本可能会有所不同，因而请确保监控每个“服务”的每日、每周或每月的老本应用图表。预计与计算 (EC2) 老本相比，EBS 快照的跨区域复制不会显著减少每月费用。放弃 EBS 快照，即便在一个区域内也会产生显著的老本，但依然可能比计算成本低得多。但这对于日常备份是必要的。
从头开始创立 EKS 集群十分耗时，大概须要 27 分钟，这就无奈优化 RTO。此外，这很容易出错。因而，理智的做法是在故障转移区域保留一个空集群—只有一个管制立体和 Velero 服务处于活动状态，费用为每天 5 美元。扩大节点池的速度要快得多，且看起来十分牢靠，因而在复原过程中按需进行扩大是正当的。这节俭了老本，只会减少几分钟的 RTO。应用 Amazon EC2 Spot 实例也能够大大节俭计算成本。
致谢
感激 Steve Boardwell 所做的评论和演示测试，用以验证其穿插兼容性。
本文由 Jesse Glick(继续集成首席软件工程师)和 Carlos Rodriguez Lopez (CloudBees DevOps 参谋)撰写。Jesse 多年来始终在开发 Jenkins 的外围和插件。他与 Kohsuke 共同开发了流水线零碎的外围基础设施。Carlos 是一位推崇 DevOps 文化的自动化参谋。他在 Java Web 和数据管理与剖析以及在云中运行 CI/CD 流水线方面有丰盛的造诣。
文章起源：https://www.cloudbees.com/blo…
如需理解更多对于 CI/CD 等流水线等信息，或想收费试用 Cloudbees，请立刻分割 Cloudbees 受权合作伙伴——龙智：
电话：400-775-5506
邮箱：marketing@shdsd.com
