在当今快速发展的数字化时代，业务的连续性和稳定性已成为企业核心竞争力的重要组成部分。然而，由于各种原因，企业常常面临着数据丢失、系统瘫痪等潜在风险。因此，制定一套科学、高效的容灾方案至关重要。本文将围绕某全球领先的工业集团如何通过灵雀云企业级云原生平台ACP（以下简称ACP）实现高效的容灾方案展开深入探讨，旨在为您提供可借鉴的经验和启示。
Introduction
容灾概念说明
在系统高可用架构设计中，容灾能力的建设是不可或缺的。容灾设计要求系统对容灾事件具备快速响应能力，保障系统持续高可用。系统面对异常情况，如软件自身故障、外界环境影响（自然灾害）需具备快速恢复能力保障系统的持续高可用。
容灾的定义是指灾难发生时，通过采用一定的技术手段和措施，保证信息系统能够快速恢复正常的运行，从而减少业务中断和数据丢失所带来的损失。容灾不仅保护数据，更重要的是保证业务的连续性。容灾要求数据远程复制，保证容灾站点的数据尽可能与生产站点一致。
备份的定义是指将数据或系统备份到本地或远程存储设备中，以防止数据丢失或系统崩溃。
衡量灾难恢复能力的级别有两个重要的技术指标：RTO（恢复时间目标）和RPO（恢复点目标）。
RTO（恢复时间目标）是指在发生系统故障或灾难事件后，恢复业务运作所需的时间。也就是说，RTO是指从系统中断到恢复正常运作所需的最长时间。RTO的设定根据业务的需求和可接受的风险水平来确定。较短的RTO意味着业务中断的时间较短，需要更快地恢复业务运作。
RPO（恢复点目标）是指在系统故障或灾难事件发生前，系统数据的恢复点。也就是说，RPO是指在发生故障或灾难之前，数据备份的时间点。RPO的设定取决于业务对数据丢失的可接受程度。较小的RPO意味着数据丢失的时间较短，需要更频繁地备份数据。
容灾方案介绍
2021年，某全球领先的工业集团通过大量的调研和方案对比决定引入ACP作为其数字化转型的基座，以加速其数字化转型为目标，并确保业务连续性。为达到这个目标，该集团对灵雀云提出了严格的容灾需求，要求恢复时间目标（RTO）不超过2小时，恢复点目标（RPO）不超过1分钟。
ACP是基于云原生架构的全方位解决方案，提供了容器化、微服务、自动化运维等一系列功能。灵雀云与该集团紧密合作，深入了解其业务需求和技术挑战，为其量身定制了一套完整的云原生解决方案。
通过ACP，集团成功地将其传统应用迁移到了云原生环境，实现了应用的快速部署、弹性伸缩和自动化运维。同时，灵雀云还为集团提供了专业的培训和技术支持，确保其能够充分利用ACP平台的优势来提升业务价值。
在容灾方面，灵雀云利用先进的容器技术和自动化运维工具，为集团构建了一套高效的容灾体系。通过自动化备份和快速恢复机制，满足了RTO不超过2小时和RPO不超过1分钟的要求，确保了集团业务的连续性和稳定性。
1. 整体容灾方案介绍
图表 1 容灾方案总体架构
在制定企业整体容灾方案时，应考虑技术中台、应用数据、应用以及接入层的容灾需求。同时还需一套容灾切换管理平台，帮助企业对整个容灾过程的集中管理和控制，包括对数据、应用和接入层的自动化切换操作。
- 技术中台容灾
在遭遇火灾等灾难后，原有的技术中台可能无法继续提供正常服务，如应用的全生命周期管理、服务依赖的注册中心等。因此，容灾方案必须充分考虑中台服务的连续性和中台数据的冗余性。
理想的容灾方案应由供应商提供，解决主数据中心和备数据中心的数据同步问题、接入层切换问题。但项目中因某些特殊情况，技术中台需要在两个数据中心进行单元化部署，并对外提供两套访问地址。从用户角度来看，一套访问地址对应主数据中心，另一套对应备数据中心。
灵雀云提供ACP原生容灾能力，如数据同步、接入层切换等方案，能够满足各种容灾需求。
- 数据层容灾
业务运行过程中，数据的持久化至关重要。主要涉及三种类型的持久化需求：业务文件存储、中间件存储和数据库存储。
业务文件存储：
业务运行在Kubernetes（k8s）集群中，通过使用持久化卷（Persistent Volume，PV）和持久化卷申请（Persistent Volume Claim，PVC）K8s实现了对业务数据的持久化。该项目中，通过ACP创建的k8s集群，整合了集团之前采购的Netapp-ontap存储设备，通过CSI插件将k8s与Netapp-ontap存储设备集成。在需要持久化存储时，通过ACP创建PVC，k8s会自动在Netapp-ontap存储设备中创建存储卷，实现业务数据的持久化。值得注意的是，Netapp-ontap在主数据中心和备数据中心都有部署，并通过Snapmirror进行数据同步。在备数据中心，通过将pod与pvc关联，实现了文件的跨数据中心容灾。
图表 2 PVC容灾
中间件存储：
中间件的容灾基于中间自身方案。如Redis缓存系统，通过Redis-shake同步中间件做数据同步。
图表 3 redis容灾
Redis容灾方案操作步骤如下：
a) 在两个数据中心，部署相同版本的业务集群。
b) 分别在两个业务集群内，部署源端Redis哨兵架构实例与目标端Redis哨兵架构实例。
c) 在源端部署Redis-shake组件，用来支持数据传输，对于目标端来说，Redis-shake模拟了Redis的客户端进行写入操作。
在进行容灾切换时，为避免产生脏数据，需手动停止Redis-shake组件。这样可确保切换过程中的数据一致性，并防止因数据不同步而导致的潜在问题。
数据库存储：
该集团业务数据写入Oracle数据库中。Oracle提供Data Guard容灾方案，通过主库和备库来实现容灾。主库将redo log传递到备库上，备库对redo log进行应用，来保持与主库同步。
在进行容灾切换时，为避免产生脏数据，需手动停止数据同步操作，根据具体情况判断是否进行反向同步。这样可确保切换过程中的数据一致性，并防止因数据不同步而导致的潜在问题。
- 应用层容灾
应用容灾旨在为生产系统构建一套镜像的备份应用系统，确保在灾难发生时能迅速接管业务运行。为实现这一目标，业务需满足以下要求：
a) 应用需是无状态的，避免存储请求上下文信息。这使得任何用户的请求都能被任意实例处理，确保结果一致性。
b) 应用需通过域名提供服务，简化容灾切换过程，只需调整域名解析，无需改动应用本身。
c) 使用具备容灾功能的中间件，提升系统稳定性和可用性。
d) 应用对中间件和数据库的访问都需通过域名进行。这样在容灾切换时，只需调整域名解析，无需对应用进行改动，进一步增强容灾能力。
e) 应用与数据库、中间件的连接需支持断开自动重连功能。这样即使出现短暂的网络波动或容灾切换，应用仍能稳定运行。
应用镜像部署完成后，应用管理员需要确保两个生产环境中的部署版本一致，并保障其稳定性。日常需要对两个环境中的应用进行版本控制、巡检和功能验证，以确保没有差异。
- 接入层容灾
在业务部署中，客户访问业务分内网和外网两种场景。内网指客户在集团内网访问业务，外网指客户通过互联网访问业务。
图表 4 接入层容灾
在集团内部部署了DNS服务，所有服务器的DNS配置都指向该服务。业务提供的服务都通过域名对外展示。在内网环境中，域名解析到ACP的ALB，客户端通过DNS解析访问这些服务。流量会先被解析到ACP的ALB上，然后ALB会基于域名规则将流量转发给指定的服务。
在外网环境中，域名会解析到公网IP。在公网环境中，负载均衡器会将流量转发到内网的DMZ区。接着，经过防火墙和另一个负载均衡器的处理，流量会进一步被转发给ACP的ALB（Ingress Controller）。
当灾难发生时，接入层只需简单地进行域名解析切换，并等待域名生效，即可快速恢复服务。
- 容灾管理平台
在灾难发生时，需要进行一系列的切换操作，包括接入层域名解析切换、业务访问中间件和数据库域名解析切换，以及中间件和数据库的数据同步切换等。为了确保操作的准确性和效率，需要一个统一的管理平台来进行这些切换操作。这个管理平台可以将操作剧本化，将每一步的切换操作详细列出，以便在灾难发生时能够按照剧本一步步执行。
图表 5 切换剧本
2. 灾难恢复方案介绍
灾难事件的范畴很广，导致数据被破坏的时间包括自然灾害，硬件故障、人为操作失误、恶意攻击等。从数据保护的应对角度而言，硬件故障、软件故障为常见的主要原因，一般情况下，本地具备数据中心灾备能力，进行数据保护即可。自然灾害、人为误操作属于较低概率事件，但仅本地数据保护能力往往还不够，还需要异地远程灾备能力。与异地远程灾备相比，本地数据可以提供较好的RPO和RTO水平，而异地远程灾备能力建设一般用于应对如自然灾害、人为误操作这类小概率事件，恢复时间可以是分钟级别、小时级或几天级别。
集团为了确保业务的持续性和数据的安全性，采取了全面的容灾措施。在本地设立了容灾数据中心，旨在提供可靠的备份和故障转移能力。当主数据中心发生故障或灾难时，容灾数据中心能够迅速接管业务运行，确保服务的连续性。
此外，集团还在其他省份建立了灾难机房。这些机房经过特殊设计和配置，能够在灾难发生时提供额外的数据存储和计算能力。与容灾数据中心一样，灾难机房核心目的是确保业务的连续性和数据的安全性。
通过在本地和其他省份建立容灾数据中心和灾难机房，集团能够大大提高业务的可靠性和数据的完整性。这有助于减少因数据中心故障或灾难导致的数据丢失和服务中断的风险。
在制定企业灾难恢复方案时，需考虑技术中台灾难恢复、应用数据灾难恢复、应用灾难恢复。
- 技术中台灾难恢复
ACP平台以Kubernetes为开发框架，利用其原生扩展机制（如CRD、Controller、API Aggregation等）来开发产品功能。除了日志和监控组件数据，平台的其他数据都存储在etcd中。因此，备份etcd数据等同于备份整个平台数据。
在etcd节点上，可以设置定时任务来执行备份脚本，确保数据被定期备份到存储设备上。同时，使用备份工具将宁乡机房的数据备份至灾备机房，实现数据的异地保护。
当出现灾难或不可修复故障时，可以从存储中提取证书文件和etcd的快照文件。根据恢复手册来快速恢复集群的正常运行。
图表 6 ACP备份、集群备份
- 应用灾难恢复
灵雀云建议集团将业务核心系统部署在Kubernetes（K8s）集群上，以充分发挥其强大功能和灵活性。通过采用专业的灾难恢复工具，轻松实现将运行在K8s集群中的应用程序完整备份至高可用的对象存储中。这样，一旦发生灾难，集团可以迅速将数据恢复至任何K8s集群，确保业务连续性不受影响。
图表 7 应用容灾
此外，为了应对业务集群的异常情况，灵雀云建议集团定期进行ETCD的快照备份。这些快照可作为集群级别的灾难恢复参考，帮助集团快速恢复集群状态。而应用备份则更为细致，可以针对命名空间或特定应用程序进行备份和恢复，提供更精细的灾难恢复粒度。
- 数据灾难恢复
数据的灾难恢复涉及多个方面，包括数据库、中间件和文件存储等。为确保数据的完整性和可用性，灾难恢复方案通常分为两类。一类是直接备份整个磁盘，但这种方式可能导致服务无法正常启动。另一类是基于各产品原生能力进行备份，但不同产品的备份和恢复方案可能存在差异，增加了方案的复杂性。
考虑到项目中包含容灾管理平台，对于不同产品的备份和恢复方案的问题，可以将各种备份和恢复方案在容灾管理平台中脚本化。通过容灾管理平台进行统一管理，确保不同产品的备份和恢复操作都能按照标准化的流程进行，提高整个数据恢复过程的可靠性和效率。
容灾演练
容灾切换演练和灾难恢复演练是检验企业容灾方案实际效果的关键环节。通过模拟灾难场景，企业可以测试容灾切换和灾难恢复流程的可行性与有效性，及时发现潜在问题并采取改进措施，从而提升在真实灾难场景下的应对能力。为确保容灾方案的可靠性，集团每年至少进行一次容灾切换演练和灾难恢复演练，并选择核心业务进行验证。
容灾方案点评
该容灾方案在数据容灾、应用容灾和接入层容灾方面已经具备了一定的基础和框架，但仍然有待优化点：
1. 技术中台容灾优化
因项目特殊原因，技术中台是在两个数据中心进行单元化部署，对外提供两套访问地址，非产品最佳实践。ACP提供产品级容灾方案，对外以一个域名提供服务，公司自研acp-mirror组件，实现ACP产品级的数据同步。
图表 8 ACP容灾方案
2. 应用管理优化
当前容灾方案对应用管理员的部署和运维带来了极大的挑战。他们需要时刻关注两边部署的版本一致性、配置一致性以及业务可用性，这无疑增加了工作量和潜在的风险。为了减轻应用管理员的负担并提供更可靠的容灾方案，ACP引入了GitOps解决方案。
GitOps是一种基于Git的声明式管理方法，它允许开发人员使用Git作为配置仓库，并通过ACP平台DevOps持续集成/持续部署（CI/CD）流水线自动部署和管理应用程序。通过GitOps，应用管理员可以将应用程序的版本控制、配置管理和部署策略集中管理在Git仓库中。这使得应用管理员能够更加轻松地实现跨数据中心的版本控制、配置同步和自动化部署。
图表 9 ACP应用管理方案
ACP的GitOps解决方案提供了以下关键功能：
版本控制与同步：ACP的GitOps解决方案确保两个数据中心的应用程序版本一致。每当有代码更改或配置更新时，GitOps会自动触发CI/CD流水线，将更改同步到两个数据中心的部署环境中。
自动化部署：通过ACP平台DevOps持续集成/持续部署功能，可以自动化部署应用程序。应用管理员只需提交代码更改到Git仓库，ACP将自动执行构建、测试和部署流程，确保两个数据中心的部署环境保持同步。
配置管理：ACP的GitOps解决方案提供了一个集中式的配置管理机制。所有的配置文件和参数都存储在Git仓库中，确保两个数据中心的配置一致性。应用管理员可以通过简单的Git操作来管理和更新配置，避免了逐个手动配置的繁琐和潜在错误。
监控与告警：ACP的GitOps解决方案还集成了监控和告警功能。通过对两个数据中心的应用程序进行实时监控，及时发现潜在的问题或性能瓶颈。一旦发生异常情况，系统将自动触发告警通知应用管理员，以便及时采取措施解决问题。
通过引入ACP的GitOps解决方案，集团可以显著降低应用管理员的部署和运维成本，同时提高容灾方案的可靠性和可用性。
