分布式系统容灾部署方案

本文主要以OceanBase部署来说明分布式系统容灾部署方案

分布式系统提供持续可用的服务尤为重要。

好的分布式系统根据需求提供不同等级的的高可用与容灾级别。

而在分布式系统中，数据库系统又是最核心最关键的系统。

我们以数据库分布式系统为主，考虑其容灾部署方案。

数据库分布式系统容灾部署方案，首先需要满足足业务服务延时的需求，然后需要满足我们约定的容灾原则，再有就是灾部署需要较多物理资源，需要尽可能通过技术降低使用成本。

根据经验，容灾需要遵守以下原则：

1. RPO等于0，可以保证数据不丢

2. RTO为秒级，在发生故障后，恢复服务时间尽可能短

3. 分布式系统通过多副本提供高可用

4. 通过多数派一致性协议保证多副本数据一致性

根据以上容灾部署原则，我们讨论几种的容灾部署方案：

1. 同机房三副本

2. 同城三机房三副本

3. 两地三中心三副本

4. 两地三中心五副本

5. 三地三中心五副本

6. 三地五中心五副本

容灾部署中基本概念：

1. 地域：指数据中心所在的地理区域，通常按照数据中心所在的城市划分。例如，华北1（青岛）地域表示数据中心所在的城市是青岛。

2. 容灾部署方案中，机房与中心均指数据中心（IDC）。

3. 容灾部署方案中，Zone为一个逻辑概念，表示集群内逻辑划分的一组节点。如属于一个机架的一组节点，属于一个数据中心的一组节点。

考虑网络延时，以下为一组IDC间的网络延时：

1. 同城延时2ms

2. 相邻异地延时8ms

3. 远程异地延时30ms

可以看到相邻异地延时与远程异地延时都非常高，一个事务包含6~15条SQL语句，累计耗时非常高，所以一定要提前考虑好业务对服务延时的需求与业务SQL优化等问题。

同时为了降低成本，可以考虑

1. 部署日志副本替代全功能副本

2. 部署仲裁服务替代全功能副本

方案对比

容灾方案	网络延时	容灾级别	RPO	RTO	部署成本
同机房三副本	1ms	机器/机架	0	8s 内	1个IDC，6个节点
同城三机房三副本	2ms	机房	0	8s 内	3个IDC，6个节点
两地三中心三副本	2ms	机房	0	8s 内	2个城市，3个IDC，6个节点
两地三中心五副本	2ms	机房	0	8s 内	2个城市，3个IDC，10个节点
三地三中心五副本	8ms	地域	0	8s 内	3个城市，3个IDC，10个节点
三地五中心五副本	8ms	地域	0	8s 内	3个城市，5个IDC，10个节点

同机房三副本

这一方案可用于非生产环境，同时可以支持机架容灾级别。

1. 1个机房，3个Zone，3个副本

2. 业务容忍同机房数据同步延时

3. 部署

   1. 1个数据中心（机房）

   2. 3个Zone

   3. 2 * 3 = 6个节点

   4. 1个机房，按照机架部署3个Zone

4. 容灾

   1. 单节点故障，不丢数据，服务可用，服务延时不变

   2. 单Zone故障，不丢数据，服务可用，服务延时不变

5. 成本优化

同城三机房三副本

这一方案支持机房级容灾。

1. 1个城市，3个机房，3个Zone，3个副本

2. 业务容忍同城数据同步延时

3. 部署

   1. 3个数据中心（机房）

   2. 3个Zone

   3. 2 * 3 = 6个节点

   4. 同城3个机房，每个机房部署3个Zone

4. 容灾

   1. 单节点故障，不丢数据，服务可用，服务延时不变

   2. 单Zone故障，不丢数据，服务可用，服务延时不变

   3. 单机房故障，不丢数据，服务可用，服务延时不变

5. 成本优化

   1. 为了降低成本，第三机房部署仲裁服务（无需同步日志）。

两地三中心三副本

两地三中心是一类实现高可用和异地容灾的部署模式，这种模式也是监管机构对金融行业数据中心的基本要求。

相比传统金融业的两地三中心（一主一备，一冷备），提供RPO=0，RTO在8秒内。传统部署很难做到RPO=0，也很难在秒级内恢复服务。

1. 2个城市，3个机房，3个Zone，3个副本

2. 业务容忍同城数据同步延时

3. 部署

   1. 3个数据中心（机房）

   2. 3个Zone

   3. 2 * 3 = 6个节点

   4. 主城市2个机房，备城市1个机房，每个机房部署一个Zone

4. 容灾

   1. 单节点故障，不丢数据，服务可用，服务延时变大

   2. 主城市单机房故障，不丢数据，服务可用，服务延时变大

5. 成本优化

两地三中心五副本

这一方案是两地三中心三副本部署方案的进化，用于解决两地三中心三副本部署方案在多副本所在城市发生机房故障时引入的事务提交跨城市问题 。

这一方案可以在备城市建立备用集群，做到有损地域容灾。

1. 2个城市，3个机房，5个Zone，5个副本

2. 业务容忍同城数据同步延时

3. 部署

   1. 3个数据中心（机房）

   2. 5个Zone

   3. 2 * 5 = 10个节点

   4. 主城市2个机房，分别部署两个Zone，备城市部署一个Zone

4. 容灾

   1. 单节点故障，不丢数据，服务可用，服务延时不变

   2. 单Zone故障，不丢数据，服务可用，服务延时不变

   3. 两Zone故障，不丢数据，服务可用，服务延时变大，集群降级为3副本，服务延时不变

   4. 单机房故障，不丢数据，服务可用，服务延时变大，集群降级为3副本，服务延时不变

   5. 单地域故障，主地域故障，会丢数据，服务不可用；备地域故障，不丢数据，服务可用，服务延时不变

   6. 备用城市建设一个独立的 3 副本集群，做为一个备库，从主库 "异步同步" 到备库。一旦主城市遭遇灾难，备城市可以接管业务。（有损地域容灾）

5. 成本优化

   1. 为了降低成本，可以分别将 IDC1 和 IDC2 的各 1 个副本部署为日志副本。日志副本不提供服务，仅仅接受日志用于故障恢复，从而只需要存储并服务 3 份数据。

   2. 为降低成本，Region2可以只部署仲裁服务（无需同步日志）。

三地三中心五副本

两地三中心部署方案的问题在于不支持异地容灾。为了支持地域级无损容灾，至少需要 3 个地域.

1. 3个城市，3个机房，5个Zone，5个副本

2. 业务容忍异地数据同步延时

3. 部署

   1. 3个数据中心（机房）

   2. 5个Zone

   3. 2 * 5 = 10个节点

   4. 每个城市一个机房，相邻两个城市的机房分别署两个Zone，剩下一个城市的机房部署一个Zone

4. 容灾

   1. 单节点故障，不丢数据，服务可用，服务延时不变

   2. 单Zone故障，不丢数据，服务可用，服务延时不变

   3. 两Zone故障，不丢数据，服务可用，服务延时变大，集群降级为3副本，服务延时不变

   4. 单机房故障，不丢数据，服务可用，服务延时变大，集群降级为3副本，服务延时不变，此时跨地域容灾RPO不为0

   5. 单地域故障，不丢数据，服务可用，服务延时变大，集群降级为3副本，服务延时不变，此时跨地域容灾RPO不为0

5. 成本优化

   1. 为降低成本，Region3 可以只部署日志型副本（只有日志）。

三地五中心五副本

与三地三中心五副本相比，该部署方案进一步强化机房容灾能力。单机房故障不影响服务。

1. 3个城市，5个机房，5个Zone，5个副本

2. 业务容忍异地数据同步延时

3. 部署

   1. 5个数据中心（机房）

   2. 2 * 5 = 10个节点

   3. 两个相邻城市，每个城市部署两个机房，剩下一个城市部署一个机房，每个机房部署一个Zone

4. 容灾

   1. 单节点故障，不丢数据，服务可用，服务延时不变

   2. 单机房故障，不丢数据，服务可用，服务延时不变

   3. 两机房故障，不丢数据，服务可用，服务延时变大。集群降级为3副本，服务延时不变

   4. 单地域故障，不丢数据，服务可用，服务延时变大，集群降级为3副本，服务延时不变，此时跨地域容灾RPO不为0

5. 成本优化

   1. 为降低成本，Region3 可以只部署日志型副本（只有日志）。

   2. 为降低成本，Region3 部署仲裁服务以降低成本（无需同步日志）。

总结

分布式系统容灾部署需要考虑众多因素

1. 服务响应延迟要求

2. 服务容灾级别、RPO、RTO

3. 服务部署成本

权衡以上因素，选择合适的容灾部署方案。

考虑大部分应用需要做到机房级（IDC）容灾，同时要求服务响应较快，可以使用 两地三中心五副本 容灾部署方案。如果资源有限，应用可以容忍故障期间延时变大，可以采用 两地三中心三副本 容灾部署。

参考

1. ECS的服务地域

2. OceanBase 集群高可用方案简介

3. OceanBase 容灾部署方案