企业劫难可能是技术、天然或人为层面的。自然灾害包含洪水、龙卷风、飓风、滑坡、地震和海啸。人为和技术劫难波及的面较广，包含危险物质透露、电力或基础设施故障、化学和生物武器威逼、网络攻击、恐怖主义行为、爆炸和外患。这些都有可能造成企业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