作者:庄宇
在设计系统架构时,我们必须假设任何组件和任何基础设施可能会在任何时间失效,例如:自然灾害,电力中断,网络中断,错误的系统变更等。为了应对挑战,我们必须设计合适的容灾架构。
本文介绍如何以 K8s 集群(包括:ACK 集群,他云集群和本地 IDC K8s 集群)为基础,结合阿里云云产品(网络,数据库,中间件,可观测),设计容灾架构,构建一个“韧性”系统。
容灾目标
Recovery time objective(RTO):
服务中断与服务恢复之间可接受的最大延迟时间。决定服务停机的可接受时长。
Recovery point objective(RPO):
自上一个数据恢复点以来可接受的最大时间量。决定可接受的数据丢失或重建。
对于 RTO 和 RPO,数值越低代表停机时间和数据丢失越少,但是越低的 RTO 和 RPO 会导致资源成本和运维复杂性越高。因此,您需要根据工作负载的重要性,指定适当的 RTO 和 RPO。
容灾策略
上图中,描述的常见的 3 种容灾策略:备份与恢复、主备、双活,不同的容灾策略对应了不同的收益和成本。您需要综合分析业务的重要性、风险、可投入的成本等,以选择适合的容灾策略。
备份与恢复(Backup-Restore)
在系统运行时,备份应用和数据,在灾难发生时,在另一个地点恢复应用和数据,并切换业务流量。由于数据无法实时备份,在恢复数据时会有一定的数据丢失,同时如果数据量较大,恢复数据时间可能较长。
主备(Active-Standby)
在主备模式中,主 Location 处理所有的业务流量,备用 location 可以启动较少的应用实例节省成本,并周期发送测试流量以验证系统有效性。在灾难发生时,做数据库主备切换,扩容应用实例数,并切换业务流量。
双活(Active-Active)
在双活模式中,2 个 Location 启动相同的应用实例数,同时处理业务流量。在灾难发生时,做数据库主备切换,并切换业务流量。
容灾范围
多可用区(Multi-AZ)
阿里云地域(Region) [ 11] 包含多个可用区(AZ),可用区(AZ)是电力和网络互相独立的物理区域,对停电,断网等局部中断的容灾场景,可以使用多个可用区(AZ)设计容灾策略。由于可用区间的网络延时较短,可以更容易实现数据部分的容灾方案,包括数据库、缓存和消息等。
多地域(Multi-Region)
为了应对更大范围的灾难故障事件,这些事件可能会影响同地域(Region)的多个可用区(AZ),您可以使用多个地域(Region)设计容灾策略。但由于地域间更大网络延时,容灾方案复杂度和实现成本较高。
在选择多可用区(AZ)或者多地域(Region)容灾方案时,需要重点考虑有状态应用和依赖的云产品(例如:数据库、缓存和消息)是否支持多地域或者多可用区容灾。
方案示例
备份与恢复(Backup & Restore)
公共云跨可用区和跨地域备份与恢复
- 通过 ACK One 备份中心 [3 ] ,可以备份 ACK 集群中的应用,包括无状态应用和有状态应用,对有状态应用,在备份应用 YAML 的同时可以备份相关 Storage 数据。
- ACK One 备份中心集成云产品云盘快照 [ 12] ,文件存储 NAS [13 ] ,对象存储 OSS [14 ] 和云备份 [15 ] ,分别支持应用 YAML,云盘 PV,文件系统 PV 的一键备份。
- 备份后,可以随时将应用和 Storage 数据,恢复到任意地域和可用区的 ACK 集群。
- 阿里云数据库服务的备份与恢复,可以参考相应数据产品的文档,例如:RDS MySQL 数据库备份恢复 [ 16] ,RDS 实例间数据迁移 [17 ] 。
混合云备份与恢复
- 通过 ACK One 注册集群 [ 4] ,可以将 IDC 自建或者非阿里云 K8s 集群,接入到阿里云 ACK 控制台。
- 接入 ACK One 注册集群后,通过 ACK One 备份中心,可以备份 IDC 自建和非阿里云 K8s 集群中的应用,包括无状态应用和有状态应用,对有状态应用,在备份应用 YAML 的同时可以备份相关 Storage 数据。
- 备份后,可以随时将应用(Deployment/Statefulset)和数据(PV/PVC),恢复到任意地域和可用区的 ACK 集群。
总结
备份恢复方案实施成本较低,但 RTO 和 RPO 相对较长,取决于数据量的大小和应用的复杂度。备份中心能够提供的全量备份+增量备份能力,减少 RTO 和 RPO 时间。
备份恢复作为容灾的兜底方案,重要性高,在系统运维的过程中,要保证备份的及时性和可恢复性。
另外,许多用户选择通过备份恢复功能实现应用的跨集群迁移,场景如下:
- 业务上云,将本地 IDC 集群中的应用,迁移到阿里云 ACK 集群中,参考 IDC 应用上云迁移 [ 18] 。
- 集群版本较老,版本升级有稳定性风险,可以先创建新版本集群,通过备份恢复将应用迁移到新版本集群运行,参考跨版本集群迁移 [ 19] 。
- 用户在收敛云账号或者组织调整时,需要跨账号集群接入 [ 20] 和跨集群迁移应用 [21 ] 。
多集群 Service
在应用迁移的过程中,由于应用的数量较多,需要分批迁移,同时应用间存在调用关系。此时,在网络打通的前提下,可以使用 ACK One 舰队多集群 Service [ 5] ,实现应用 Kubernetes Service 跨集群访问。如下图所示,ACK One 舰队多集群 Service,可以将 Cluster1 的 Applcation2 的 Kubernetes Service(包含 endpoints)注入到 Cluster2,Cluster2 上的 Application1 可以访问 Cluster1 上的 Application2。
在专线拉通的前提下,通过 ACK One 注册集群,IDC 和非阿里云的 K8s 集群也可以是用 ACK One 舰队多集群 Service。
单地域多可用区容灾
基于 DNS 流量分发
- 通过 ACK One GitOps 应用分发 [6 ] ,在 2 个 ACK 集群中部署应用,实现基于 Git 仓库的持续一致性部署。
- 通过全局流量管理(GTM) [22 ] 做 DNS 解析实现负载分发,并监控系统运行健康状态,自动触发容灾切换。
- 每个 AZ 内,通过 ACK Ingress [ 7] 实现 7 层流量管理。
- 备集群和主集群的应用版本相同,但备集群节点较少,应用副本较少,节省成本。
- 在主系统不可用时,全局流量管理(GTM)会将服务域名 DNS 解析到备用系统,完成主备切换。
- 由于流量的增长,备集群中 ACK HPA [8 ] 会扩容应用副本,进而触发 ACK Cluster Autocaler [9 ] 扩容集群节点。
- 阿里云中间件(消息,缓存)的跨可用区容灾,可参考相关文档,例如:云消息队列 RocketMQ 版实例规格 [ 23] ,云消息队列 Kafka 版实例规格 [ 24] ,云原生内存数据库 Tair 容灾方案 [ 25] 。
- 阿里云数据库服务的跨可用区容灾,可参考相关文档,例如:RDS MySQL 数据库搭建高可用架构 [ 26] 。
🔔 注意:
- 本方案基于 DNS 流量转发,由于 DNS 缓存,在灾难事件发生时,部分业务依然路由到主系统,造成一定的业务损失。
- 需要在 2 个集群中分别配置维护 7 层 ingress 规则,成本高。系统正常运行状态:
灾难事件发生,AZ 不可用时,系统主备切换,GTM 将流量切换到 AZ2,ACK Cluste2 的应用实例自动扩展,中间件和数据库多可用区高可用切换。
基于 ACK One 多集群网关
- 通过 ACK One GitOps 应用分发,在 2 个 ACK 集群中部署应用,实现基于 Git 仓库的持续一致性部署。
- 通过 ACK One 多集群网关 [ 10] ,定义标准 K8s Ingress 规则(YAML 格式),实现 7 层流量治理,实现流量的主备模式分发。多集群网关为跨可用区高可用。
- 备集群和主集群的应用版本相同,但备集群节点较少,应用副本较少,节省成本。可以发送特定 http header 的测试流量,多集群网关转发到备集群以验证工作状态。
- 在主系统不可用时,ACK One 多集群网关会自动将业务流量备用系统,完成主备切换。
- 由于流量的增长,备集群中 ACK HPA 会扩容应用副本,进而触发 ACK Cluster Autocaler 扩容集群节点。
- 阿里云数据库服务的跨可用区容灾,可参考相关文档,例如:RDS MySQL 数据库搭建高可用架构。
🔔 注意:
- 本方案为 HTTP 七层流量转发,配合 7 层健康检查,主备切换时相比 DNS 方案,大幅减低业务流量损失。
- 网关侧统一支持基于 Ingress 规则的流量治理,相比 DNS 方案,合并了四层负载均衡 SLB 和七层 Ingress 网关,降低系统复杂度和维护成本。
系统正常运行状态:
灾难事件发生,AZ 不可用时,系统主备切换,多集群网关(MSE 云原生网关)自动将流量切换到 AZ2 的 ACK Cluste2 中, 应用实例自动扩展。
跨可用区双活
以上 2 个方案以主备模式为例,描述了系统架构。同样的架构,基于 DNS 流量分发和 ACK One 多集群网关也支持双活场景,可以配置流量分发比例(例如:50% : 50%),支持自动 failover 切换。在双活的场景下,每个集群中的应用副本数,需要根据流量分发比例确定,集群中需要配置弹性伸缩,以支持流量切换情况下的流量增长。
总结
单地域多可用区方案实现的成本较低,可以利用云产品(包括:网关,容器,中间件,数据库)多可用区部署和多可用区高可用,快速实现容灾,对业务改造较小。但此方案仅可应对单个可用区的灾难和故障,无法应对地域级的灾难故障。
单地域云+IDC 容灾方案
方案架构与单地域多可用区容灾方案类似,要点如下:
- 云上 VPC 与 IDC 建立专线连接,打通管控与数据通道。
- 通过 ACK One 注册集群接入 IDC 集群,使用阿里云强大可观测和安全能力,统一管理 IDC 集群和 ACK 集群。
- 通过 ACK One GitOps 应用分发,在 2 个集群中部署应用,实现基于 Git 仓库的持续一致性部署。
基于 DNS 流量分发(单地域云上和云下双活)
基于 ACK One 多集群网关(单地域云上和云下双活)
多地域容灾
如果业务规模大重要性高,服务的用户数量多范围广,单地域的容灾方案就无法满足业务高可用要求,这时需要多地域容灾方案。在多个地域独立部署业务系统,保证每个地域的业务系统具有单独闭环提供完整的服务能力。
- 通过全局流量管理(GTM)实现用户就近接入相应地域。
- 通过 ACK One GitOps 应用分发,在 2 个 ACK 集群中部署应用,实现基于 Git 仓库的持续一致性部署。
- 缓存多地域高可用方案,可以参考阿里云产品相关文档,例如:Tair 全球多话 [ 27] 。
- 数据库跨地域高可用方案,可以参考阿里数据库云产品相关文档,例如:云原生数据库 PolarDB MySQL 全球数据库 [ 28] 。
- 地域内,可以采用单地域多可用区容灾方案。
单元化多活部署
区别与前一方案,多地域单元化多活部署,需要设计分片规则对应用和数据进行分片,使得单元提供面向部分数据分片的完整服务能力,实现业务安全故障隔离,水平扩展,服务庞大的用户群体。一般分为中心单元(拥有所有用户数据)和多个子单元(分片后详细数据)。此种方式需要业务系统支持,自定义分流规则,数据拆分,单元间配合等,复杂度高。
总结
各种灾难事件会影响您业务的可用性,通过使用阿里云的相关云产品的容灾能力,可以减轻或者消除这些影响。首先,需要了解业务可用性需求,从而选择一个适当的容灾策略,然后,使用阿里云相关云产品,包括:容器(容器服务 Kubernetes 版 ACK [ 1] 和分布式云容器平台 ACK One [ 2] )、消息、缓存、数据库等,设计容灾架构,快速达到您业务可用性要求的恢复时间目标 RTO 和恢复点目标 RPO。