最佳实践4 | SequoiaDB巨杉数据库两地三中心部署

 01 前言

 

在上一篇文章中，我们分享了利用巨杉数据库SequoiaDB，实现系统同城双中心容灾的最佳实践。巨杉数据库提供了存算分离、多副本、强一致的特性，解决了如双中心双活流量分发、透明故障切换等问题，构建了同城跨区域数据保护的能力。

但是，同城双中心架构的局限性也是显而易见的，因为它无法防范城市级的不可抗力故障，如地震、火山、海啸等自然灾害等。从监管的角度考虑，随着业务等级的提升，对容灾部署模式提出了更高了要求，这就出现了两地三中心的部署模式。

在本文中，我们将和大家一起来了解，如何利用金融级数据库SequoiaDB的多副本、高可用能力，构建两地三中心系统，从而为数据库系统的容灾建设，提供一些新的思路，并提供最佳实践指导建议。

 

02 背景

 

2.1 两地三中心技术

当自然灾害等不可抗力故障发生时，同一个城市的基础设施同时遭到破坏，主、备中心均丧失了业务连续性和数据保护的能力。为了达到这样的防范能力，就需要在同城双中心的基础上，加一个异地灾备中心，增加整个系统的高可用性和灾难恢复能力，避免主备站点同时不可用造成的业务大面积瘫痪，及数据的灾难性破坏。

2.2 巨杉金融级分布式数据库SequoiaDB简介

SequoiaDB 巨杉数据库是一款原生分布式数据库，具有存算分离、多模、多副本高可用等技术特性，已经帮助超过 50 家银行机构、上百家金融级用户，来承载高并发联机交易、数据中台、内容管理等多种类型的业务场景，取代了传统架构的数据库。

众多客户，选择巨杉数据库的两地三中心架构，实现业务的跨站点、跨区域容灾，进一步提升了业务系统在灾难场景下的业务连续性和数据保护能力。

 

03 SequoiaDB 技术架构

 

SequoiaDB部署示意如图1（以3台服务器为例）。

图1

 

SequoiaDB分布式架构示意如图2。

图2 

 

从部署示意图及架构图中可以看出，巨杉数据库主要由计算实例、协调节点、编目节点、数据节点四个组件构成。

• 计算实例：负责接收应用端的访问请求，并将其转换成巨杉数据库特有的语法协议。计算实例支持多种引擎，如SQL引擎、JSON引擎、对象存储/文件系统引擎等。

• 协调节点：负责执行计划的生成，及访问请求的路由和转发。将执行分解成独立的计算单元，下发到数据节点进行存取和运算，并将结果返回计算实例。

• 编目节点：负责维护集群的元数据，如拓扑结构、安全策略、表与集合定义以及分区规则等。

• 数据节点：以数据组为单位提供数据的存储和访问，数据组内实现副本化，主节点可读写，备节点可读。如果某个主节点发生故障，则通过RAFT协议选举出新的主节点。

关于巨杉数据库技术架构的详细解析，请参考《金融级数据库巨杉SequoiaDB技术架构讲解》(http://doc.sequoiadb.com/cn/sequoiadb-cat_id-1558957225-edition_id-500)和《巨杉数据库高可用原理详解》。

 

04 SequoiaDB两地三中心部署最佳实践

 

4.1 部署概述

在本文中，我们用SequoiaDB部署了一套数据库集群，用来承载典型的OLTP系统。上层应用采用微服务架构，应用和数据库都采用两地三中心的集群部署形式。

相较于同城双中心的部署方式，两地三中心在容灾层面更具优势。三个数据中心（主中心、同城灾备中心和异地灾备中心）中，任意一个完全瘫痪，无需人工干预即可完成透明故障转移，数据库可正常运行，应用做到了无感知。

即使发生城市级的严重灾难，也可在短暂的人为介入（执行Split操作，1分钟内）后，快速完成故障切换，使得业务的连续性、数据可靠性都得到极大地保证。按照本文的最佳实践部署后，系统的RPO/RTO可达到如下水平： 

 

4.2 部署规划

数据中心规划：

网络规划：

 

4.3 架构设计

该架构为巨杉数据库典型的两地三中心部署方案。其中同城双中心各两个副本，异地灾备中心一个副本，构成一个高可用的五副本集群，主节点可读写，备节点只读。

整个数据库由datagroup[1-10]这10个数据组构成。datagroup [1,2,3,4,5]的主节点位于sdb01，datagroup[6,7,8,9,10]的主节点位于sdb02。这样一来，sdb01、sdb02就可以同时提供读写访问能力，sdb03、sdb04、sdb05可提供只读访问。架构如下图3所示：

图3 高可用五副本集群

 

图例：

 

设计要点：

• 每个中心，必须要具备业务接管能力，所以配置一组协调节点；

• 主中心，必须具备数据的读写访问能力，所以配置全量的主节点，以及一组编目节点；

• 备中心，提供只读访问能力，一旦将来主中心发生故障，也必须具备读写能力，所以配置一组全量的备节点（切换后即成为主节点），以及一组编目节点；

数据库关键配置项：

1、ReplSize设置为3，是指当发生写操作时，主节点写入后，还必须保证至少2个备节点完成数据同步，才返回结果（主中心备节点、同城灾备中心的备节点优先同步），并能够避免同城到异地中心的网络出现延时而影响主节点写入性能。

2、通过weight为数据组内的各节点（副本）指定权重，目的是：正常情况下，应用连接生产站点的主节点。当主中心发生故障时，主节点不可用，通过选举，使同城备中心的节点优先成为主节点，提供读写访问；若同城主、备中心同时发生故障，则异地灾备中心接管（需要手动执行Split操作），对外提供读写访问。

Note：

•  ReplSize：SequoiaDB的ReplSize参数，用来控制写操作发生时，必须具备什么样的数据一致性同步条件，才向客户端返回写入结果。 

-1，写请求同步到该数据组所有活跃节点后，写操作才返回；

 0，请求同步到该数据组所有节点后，写操作才返回；

 N，写请求同步到该数据组其它节点后，必须确保至少有N个节点数据一致，写操作才返回。N的取值范围[1-7]。

•  weight：节点选举权重值。通过改参数，来设置选举过程中各节点的优先级。取值范围[1~100]，默认值为10。 

•  archivecompresson： 开启归档日志压缩特性，从而节省本地空间。

 

4.4 故障场景模拟

发生故障后，数据库后台发生一系列动作，来完成故障转移。数据库集群要能够接管业务，有三个必要条件：

1. 集群中至少有1个协调节点，对应用提供访问；

2. 集群中至少有1个主编目节点，提供元数据的读写；

3. 集群中有1套完整的数据库的全量主节点，处于存活状态，数据可读可写。 

Note： 

选举和仲裁机制： 

•  主节点故障后，需要一个机制来选择新的主节点。每个数据组内所有的副本节点定期向组内其它成员发送含自身状态的心跳信息，当主节点宕机后，所有的备节点间会进行投票，选取最具资格的备节点即当选新的主节点。组内必须拥有超过半数以上的节点参与投票，否则为了避免“脑裂”发生而无法进行选举。 

•  任何时刻组内成员必须超过半数，否则当前的主节点会自动降级为备节点，同时断开当前节点的所有用户连接。

 

4.4.1 主中心单点故障

同城主中心单点故障的示意图如图4。

图4  主中心单点故障示意

 

故障转移过程：

当主中心sdb01发生故障，此时sdb01上datagroup[1-5]的主节点将不能进行写入操作。此时发起选举，根据优先级设置，主中心sdb02上datagroup[1-5]的备节点，将成为主节点。选举结束后，集群立即恢复正常，无需人工干预。

 

4.4.2 同城备中心单点故障

同城备中心单点故障的示意图如图5。

图5  同城备中心单点故障示意

 

故障转移过程：

当同城备中心sdb03发生单点故障，由于其上没有数据主节点，因此数据库集群仍正常提供读写服务，业务不受影响。待故障恢复后，快速完成数据同步，节点即可修复。

 

4.4.3 主中心整体故障

同城主中心整体故障的示意图如图6。

图6  主中心整体故障示意

 

故障转移过程：

当主中心sdb01、sdb02同时故障，意味着数据主节点均不能读写。此时发起选举，根据优先级设置，备中心sdb03上datagroup[1-5]的备节点，sdb04上datagroup[6-10]的备节点，将成为主节点。选举结束后，集群恢复正常，无需人工干预。

 

4.4.4 同城备中心整体故障

同城备中心整体故障的示意图如图7。

图7  同城备中心整体故障示意

 

故障转移过程：

同城备中心整体发生故障，由于其上没有主数据节点，数据库集群仍可正常提供读写，业务不受影响。待故障恢复后，快速完成数据同步，则节点即可修复。

 

4.4.5 主中心、同城备中心整体故障

主中心、同城备中心整体故障的示意图如图8。

图8 主中心、同城备中心整体故障示意

 

故障转移过程：

当主中心、同城备中心（sdb01/sdb02/sdb03/sdb04）同时不可用，就需要由异地灾备中心来承载业务访问。例如发生城市级的不可抗力故障时，就属于这种情况。

这里需要用到Split工具进行人为处理，把异地灾备中心分裂出去，使之成为一个独立的单副本集群，从而提供读写访问。

待故障恢复后，可通过Merge工具，将原有节点重新合并到集群，使集群拓扑恢复到初始状态。

分裂集群的耗时比较短，一般在1分钟内便能完成。

Note： 

集群分裂：按照RAFT协议，必须确保半数以上节点存活，集群才处于可用状态。在两地三中心5副本模式下，当同城主、备站点均发生故障时，5副本中的4个已经不可用，集群仅剩余1个副本，不能对外提供服务。

 

4.4.6 跨城网络故障

同城备中心整体故障的示意图如图9。

图9  跨城网络故障示意

 

故障转移过程：

当同城、灾备中心之间的网络出现故障，导致站点间无法进行通信时，应用程序可以继续访问本地四副本集群，业务没有任何影响，无需人为干预。

待网络故障修复后，完成异地灾备中心节点的数据同步即可。

 

 

05 总结

 

在本文中，我们介绍了巨杉数据库 SequoiaDB 的两地三中心部署最佳实践，包括技术原理、部署规划、架构设计等方面，也对各类故障、灾难场景的切换原理和过程做了讲述。

通过本文，我们希望能够提供一些业务系统容灾建设方面的新思路、实践参考，从而助力行业客户，进一步提升业务连续性管理水平，加速实现从同城灾备，到全面支持同城、异地多活的业务连续性模式的转型。

最后，提出几个问题，供大家思考：

• 随着数据量的持续增长，如何解决SequoiaDB数据库的扩容问题？

• 为了应对更严苛的业务连续性、数据保护要求，巨杉SequoiaDB数据库能否实现三地五中心架构？

• 在多中心的架构下，能否使各个站点、各个数据中心同时提供读写访问，实现多活？

这些问题，我们将在陆续推出的最佳实践系列中，和大家一起展开探讨，敬请期待！

转载：https://blog.csdn.net/SequoiaDB_Official/article/details/111385999