本文来自微信公众号“twt企业IT社区”。
信创云环境下，面向企业级的国产数据库，在功能和性能方面能够替代传统国外数据库产品。为了减少架构调整带来的复杂工作性，沿用传统集中式部署架构，用较小的代价完成国产化替代是一种选择，需要国产数据库和集中式存储在信创云环境下进行适配。为了弥补信创云环境下技术栈性能较低的问题，采用分布式部署架构，需要国产分布式数据库和分布式存储在信创云环境下进行适配，达到从功能和性能方面都能达到传统国产成熟数据库产品的能力，这是议题设计的初衷。
张鹏 某金融科技公司高级技术主管：本议题由中国民生银行数据库架构孔再华、我本人发表针对议题下关键点的主张，几位专家的主张在某农商银行架构师胡海光、某金融公司架构师刘艳春及江西农信运维技术经理邓毓等多位专家的复议后，形成了一定的共识，希望可以对同行有一定的参考。
孔再华 中国民生银行数据库架构师：
金融企业愿意尝试数据库云化的技术背景主要有两方面：私有云环境基础架构已经趋于成熟，金融企业基本都实践了大规模的私有云环境建设和使用，并在无状态的应用部署中获得较高收益；大部分企业国产数据库选型基本完成，正处于迁移替代的进程中。
一、背景
目前金融行业信创工作的开展正如火如荼。其中包括信创云环境的建设和各种基础架构的信创产品替代。信创云环境需要使用国产的软硬件方案：国产服务器、国产OS、国产中间件、国产数据库、国产网络设备、国产存储设备等等。
国产数据库部署到信创云环境也是当前比较热门的课题。金融企业愿意尝试数据库云化的技术背景主要有两方面：私有云环境基础架构已经趋于成熟，金融企业基本都实践了大规模的私有云环境建设和使用，并在无状态的应用部署中获得较高收益；大部分企业国产数据库选型基本完成，正处于迁移替代的进程中。
在这个背景下，建设信创云环境是必要的，属于信创工作的一部分。数据库上云也是大势所趋，部分技术领先的金融头部企业已经大规模实践成功。我了解到当前已经有很多企业正在探索如何实现国产化数据库部署到信创云环境。
这两年我在行内设计和实践了国产数据库openGauss在基于鲲鹏ARM服务器的信创云环境下的部署方案。在这个过程中也不是一帆风顺，事实上充满了坎坷，尤其是在信创云环境下的存储选型和使用中，遇到了很多困难。
二、存算分离架构实践
数据库在信创云环境究竟使用什么存储才合适?这是我遇到的第一个问题。在所有的软硬件产品中，数据库是企业IT架构里最核心的组件。在金融企业IT架构演进中，最初数据库采用的是集中式存储，传统的IOE架构即便是到现在也还是主流。不过随着SSD、NVMe等高性能的存储技术发展，伴随着数据库分布式架构技术爆发，现代企业数据库趋于轻量化、简单化、单元化。面临稳定的集中式存储、流行的数据库本地盘方案和新兴的分布式存储选择，我需要从数据库高可用架构设计、性能、管理等多维度思考来设计最终的数据库云原生方案。
1.架构思考
数据库云原生方案里一个关键点是高可用设计。信创云环境一般采用比较流行的Kubernetes平台。云环境下数据库的高可用设计就是结合云环境的高可用能力和数据库自身的高可用技术。
云环境的高可用能力是业界比较认可的。尤其是无状态的应用大规模部署实践，其中高可用能力是企业最看好的特性。数据库部署到云环境后，要充分利用Kubernetes对于POD容器的自恢复能力。例如我在设计数据库云原生方案中，当数据库节点挂掉后，operator优先重启POD后恢复数据库服务。只有在POD重启无法恢复服务的情况下才触发数据库主从角色切换。
这里与底层存储相关的是存储CSI插件能否支持POD快速重启和漂移。尤其是POD跨节点漂移的过程中,存储插件需要做好源环境的存储设备清理和新环境的快速部署。这也是我遇到问题最多的地方。
我设计的数据库云原生方案支持采用任何类型的存储设备。当采用本地盘方案时，放弃了POD漂移等能力，因此主推存算分离方案。
2.性能实践
数据库在云环境适合采用什么存储的第二个关键点是性能。关于这一点真的是实践出真知。前面提到我设计的数据库云原生方案支持本地盘和各类存储，其实一开始是非常害怕数据库在云环境下的存储性能问题，才设计了本地盘方案。后来在全面测试了各类性能的存储和本地盘后，才开始主推分布式存储的方案。这里面涉及到数据库对于存储的使用特点和性能需求。
存储的性能可以考虑主要是两点：延时和吞吐量。在不同的压力背景下，存储的延时和吞吐量是有很大差异的。数据库的高并发和大查询就是两种完全不同的业务场景，对于存储的需求差异也很大。
重点阐述下数据库对于存储的使用细节。基本上所有的关系型数据库都采用了同样的文件设计：日志和数据。
a.数据文件：通常数据文件比较大，但是会有文件系统缓存或者是数据库内部的缓冲池。数据查询的时候会从存储读到缓存中，修改的时候会最先修改缓存数据，然后由异步的checkpoint检查点来刷盘。所以数据文件的读写更像是背景流量。
b.日志文件：日志文件一般较小，并且最大的特点是顺序写！虽然吞吐量小，但是延时要求高。因为日志文件是实时同步到磁盘的，写入事件直接影响当前的数据修改交易。
从数据库的基本设计来看，我们需要做的就是控制数据文件的读写背景流量，重保日志文件的响应时间。特别是在信创云环境下，多个数据库pod占用同样的存储设备，彼此是有影响的。
最初的本地盘方案很快到达了磁盘吞吐量瓶颈，再增压的情况下延时越来越糟糕，吞吐量也上不去，而采用分布式存储后解决了吞吐里的瓶颈。
分布式存储具备高扩展性、高可用性、高性能、低成本等主要特点。在低交易的情况下，分布式存储单独从IO延时看是比不上本地盘等存储介质的，但是当数据量交易量上来后，分布式存储反而更稳定。
这里还要提一下华为分布式存储的一个特性，是让我感到惊喜并且觉得非常适合数据库的。华为分布式存储设计了NVMe的缓冲层，当io量比较小的情况下会优先刷入缓冲层就返回，最后才异步刷到磁盘上。而比较大的IO会直接读取和写入磁盘。这简直就是为了数据库而量身定做的。因为数据库中比较大的io都是读取和写入数据文件，这个操作在数据库内就有缓冲池的设计，本身属于异步行为，不太影响交易。因此即便在分布式存储里直接存盘，也不会造成更大影响。而日志文件IO量小，时延要求高且稳定，正适合NVMe缓冲层。当在测试过程中发现分布式存储的性能居然比集中式存储采用SSD盘的效果还好后，经过理论分析得出了上述结论。因此更坚定了我使用分布式存储方案的决心。
三、数据库存储的生命周期管理
基于分布式存储的云原生数据库方案在实践过程中还是面临了比较多的问题。一方面数据库云原生方案技术正处于发展阶段，用户和厂商对于此类方案的实践经验和积累都还比较少。另一方面是分布式存储运用在云环境下的实践经验也非常少，基本也处于建设阶段。因此整个过程中遇到了很多坑，也正是这些坑让我们来全面思考一下，分布式存储在云环境需要具备哪些功能。从数据库的生命周期管理来浅谈下信创云环境下存储的管理。
1.创建分配
数据库作为有状态的应用，需要持久化的卷。当新建数据库容器的时候，需要定义使用的存储资源。云环境下存储CSI最基础的能力就是依据资源定义快速动态分配卷并挂载到对应的node节点上。
2.配额管理
前面提到数据库使用存储的过程中需要控制数据读写的背景流量来保障日志同步写的性能。而在容器云环境更是如此，不同数据库之间甚至还会互相影响。因此多租户配额管理也是存储CSI需要支持的能力。当前我还没有看到做的很好的案例。这里的配额管理是为租户设置容量和性能资源限制。
例如我部署一套非重要系统的数据库的时候，定义这个数据库使用的存储吞吐量不超过100GB/s.那么存储CSI会管理存储设备上的限额。
3.快速扩缩容
快速扩容是运行过程中最常见的管理措施。随着数据增长，数据库扩容也就是存储扩容在所难免。这个功能也算是存储CSI的基础能力，基本都做得比较好。但是缩容就普遍做不到。这也是存储设备今后需要加强的功能。
4.升级迁移
数据库使用过程中负载和数据量可能发生比较大的变化，因此原先的存储资源可能已经无法满足当前的数据库需求。另外一种情况是存储设备也面临更新换代。这种情况下是否可以尽量少的影响数据库使用，最好能够在线实现底层存储搬迁。
目前我就遇到了这种情况，因为存储设备不支持，最后只好通过上层数据库的迁移来实现，相对代价是比较大的。
5.删除销毁
当数据库下线后，对应的容器资源和存储资源都需要完全回收。因此存储CSI需要能够管理存储资源的删除和销毁，包括卸载卷，删除设备，删除卷等。这项基础功能也是目前大部分存储比较成熟的能力。
6.备份恢复
数据库的备份恢复通常都是采用数据库自身的工具方案。不过也有采用存储备份和恢复的方式。存储快照管理能力如果足够成熟，那么备份恢复速度的优势很大。
如果存储卷的备份恢复能够与数据库的扩缩容结合在一起，那么这种数据库云原生的方案将具备更高的可用性和可扩展性。
上述是从数据库的生命周期管理中摘取了对存储相关能力的需求，也是希望未来存储厂商优先考虑加强这方面能力。
四、基于集中式存储的云原生数据库技术验证测试
存算分离架构在存储层有集中式存储和分布式存储两种方案。集中式存储方案我们也做了测试，目标是验证Kube-ovn网络加华为集中式存储的方案是否可行，主要关注openGauss集群的部署和故障漂移情况。
测试环境采用鲲鹏ARM的服务器，采用麒麟V10操作系统，K8S版本是1.16，operator采用3分片部署，数据库容器介质采用是openGauss3.0.1版本。网络插件选用了Kube-ovn，存储插件使用的是华为存储CSI插件，底层接入华为集中式存储。
从测试结果来看，功能性需求完全满足设计目标。测试的结论主要有以下几点：
Kube-ovn网络插件支持固定IP的POD在不同node漂移、支持网络多平面，验证通过。
华为存储网络插件CSI支持POD在不同node漂移，满足数据库高可用性需求，验证通过。
openGauss集群的反亲和性验证通过，同一集群的POD会部署在不同的NODE上。
五、展望
在未来，我们会开展对于集中式存储、分布式存储、本地SSD的全面测试。未来可能采用差异化技术方案来应对不同的业务场景。进一步实现混合复杂融合部署，在保障性能的前提下，提升资源利用率。
目前云原生数据库在云环境大规模应用还处于创造实践阶段，肯定会遇到各种困难。但是只要更多的实践和困难解决，相信未来这种方案会很快成熟。为了加快这一进展，期望用户坚定数据库上云的决心，厂商加快产品在云环境能力的研发，让用户遇到的问题尽快得到解决。
张鹏某金融科技公司高级技术主管：
集中式数据库是企业的最初选择，它可以利用位于系统中心的服务器统一管理所有的共享资源，并处理来自用户的请求。
信创云，是在信息技术应用创新的背景下，以国产化的CPU、操作系统为底座的自主研发的云平台。该平台统筹利用计算、存储、网络、安全、应用支撑、信息资源等软硬件资源，发挥云计算虚拟化、高可靠性、高通用性、高可扩展性及快速、弹性、按需自助服务等特征，为用户提供可信的计算、网络和存储能力。全栈信创，就要基础平台侧（云平台底座），和应用侧（操作系统，数据库，中间件，应用软件）都是以国产化的CPU、操作系统为底座的自主研发的。下文主要讨论在信创云环境下，国产数据库的数据存储通常采用集中式和分布式两种部署架构的应用场景。
一、集中式数据库存储管理部署示例
GaussDB(for openGauss）是一款支持集中式部署方式的数据库，面向企业级支持主备部署的高可用关系型数据库。在主备部署架构中，业务数据存储在单个物理节点上，数据访问任务被推送到服务节点执行，通过服务器的高并发，实现对数据处理的快速响应。同时日志复制可以把数据复制到备机，提供数据的高可靠和读扩展。
openGauss支持主备部署，openGauss逻辑架构如图1所示。
图1 openGauss主备部署架构图
openGauss逻辑架构中：
OM：运维管理模块（Operation Manager），提供数据库日常运维、配置管理的管理接口、工具。
CM：集群管理模块（Cluster Manager）。管理和监控数据库系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行。
客户端驱动：客户端驱动（Client Driver），负责接收来自应用的访问请求，并向应用返回执行结果。客户端驱动负责与openGauss实例通信，发送应用的SQL命令，接收openGauss实例的执行结果。
openGauss（主备）：openGauss主备（Datanode），负责存储业务数据、执行数据查询任务以及向客户端返回执行结果。openGauss实例包含主、备两种类型，支持一主多备。建议将主、备openGauss实例分散部署在不同的物理节点中。
Storage：服务器的本地连接存储资源，持久化存储数据。
openGauss的数据库节点负责存储数据，其存储介质也是磁盘，数据库逻辑结构如图2所示。
图2 openGauss数据库逻辑架构图
Tablespace，即表空间，是一个目录，可以存在多个，里面存储的是它所包含的数据库的各种物理文件。每个表空间可以对应多个Database。
Database，即数据库，用于管理各类数据对象，各数据库间相互隔离。数据库管理的对象可分布在多个Tablespace上。
Datafile Segment，即数据文件，通常每张表只对应一个数据文件。如果某张表的数据大于1GB，则会分为多个数据文件存储。
Table，即表，每张表只能属于一个数据库，也只能对应到一个Tablespace。每张表对应的数据文件必须在同一个Tablespace中。
Block，即数据块，是数据库管理的基本单位，默认大小为8KB。
在信创云环境下部署方式，ECS弹性云主机作为计算节点，云存储提供块或者文件存储，挂载在ECS上，为数据库提供存储空间。
二、分布式数据库存储管理部署示例
云数据库GaussDB(for MySQL)是一款企业级高扩展高性能分布式数据库，完全兼容MySQL。基于华为最新一代DFV存储，采用计算存储分离架构，128TB的海量存储，故障秒级切换，既拥有商业数据库的高可用和性能，又具备开源低成本效益。
GaussDB（for MySQL）架构设计原则：
●采用云存储（DFV）作为快速，可扩展，可靠和共享数据库存储，不复制存储层中的已有功能，例如数据复制，跨可用区（AZ）可靠性，数据清理。
●单个数据库集群只需要一份足够可靠的数据库副本集。所有只读副本共享存储在云存储中，甚至跨AZ，数据库中没有逻辑复制。一写多读，没有独立的备用实例。主节点发生故障转移时，只读副本可以切换到接管主服务器。
●只有数据库日志是通过网络从数据库计算机节点写入DFV存储层，基于DFV存储层内的数据库日志重建数据面，以避免繁重的网络流量。
●基于跨DFV存储节点的切片策略对数据库进行分区，以支持大型数据库卷。单个DFV存储节点管理来自不同数据库集群实例的多个分片，实现存储容量和处理能力的无限扩展。
GaussDB(for MySQL)整体架构自上向下分为3大部分：SQL节点、存储抽象层SAL(Storage AbstractLayer)以及存储层(storage Nodes)，如图3所示。
图3 GaussDB(for MySQL)整体架构图
首先，SQL节点形成一个集群，包括一个主节点和多个只读副本（RO最多15个）。每个集群属于一个云租户，一个租户可以具有多个集群。SQL节点管理客户端连接，解析SQL请求，生成查询执行计划，执行查询以及管理事务隔离。
其次是存储抽象层SAL（Storage Abstraction Layer）：将原始数据库基于表文件的操作抽象为对应分布式存储，向下对接DFV，向上提供高效调度的数据库存储语义，是数据库高性能的核心。它是SQL节点和存储层之间的桥接器。如图4所示，SAL包括两个主要组件，SALSQL模块和DFV存储节点内部的Slice存储。
SAL SQL模块为SQL节点（主/只读副本）提供了SAL API，用以与底层存储系统进行交互。SAL SQL模块包含通用日志处理器CLP（Common Log Processor）、数据库分片管理器SM（Slice Manager）、页面读取器PR(Page Reader)以及与只读副本节点同步信息的工具程序。其中，CLP负责将数据库全局重做日志持久到DFV，解析日志并将其分发到相应的DFV分片，并生成同步消息（脏页、活动事务列表、分片持久LSN等）以供只读副本获取。CLP还需要处理数据库崩溃恢复，重新加载已提交的全局重做日志，并将其重新分配给所有相应的分片。SM维护分片策略以及页面映射信息，确定何时添加更多的分片以及哪些数据库页面应分配给哪个DFV切片等。页面读取器PR负责通过查找页面映射信息，将特定的页面读取请求路由到相应的切片管理器。另外，SAL SQL模块还为SQL节点与存储系统交互提供了其他一些接口，包括定期将日志清除信息（RecycleLSN）传递到数据库片等。
存储层(storage Nodes)，基于华为DFV存储，提供分布式、强一致和高性能的存储能力，此层来保障数据的可靠性以及横向扩展能力，保证数据的可靠性不低于99.999999999%。DFV(Data Functions Virtualization)是华为提供的一套通过存储和计算分离的方式，构建以数据为中心的全栈数据服务架构的解决方案。Slice Store是在DFV存储节点内部运行的插件模块，它需要与DFV存储框架一起使用，用以在相同DFV节点上管理多个数据库片，支持多租户资源共享，并将页面的多个版本提供给SQL节点。对于每个分片，Slice Store使用日志目录作为中心组件来管理重做日志和页面数据。Slice Store的主要职责是：接收分片重做日志，将其持久化并注册到日志目录中；接收页面阅读请求并构建特定版本的页面；垃圾回收和合并日志。
GaussDB（for MySQL）存储层建立在华为云存储DFV持久层之上，DFV持久层为上层SQL节点存储提供读写接口，提供跨地域3AZs之间的数据强一致性和可靠性保证。
GaussDB（for MySQL）使用两种模式实现write-optimized以及read-optimized，分别是Plog模式与iShard模式。Plog模式提供强一致性保证，而iShard模式实现最终的一致性。
其中，SQL节点使用Plog模式存储整个数据库的WAL重做日志，使用iShard模式对数据在多个存储节点之间进行分片和管理。Plog以SSD友好的追加写方式使事务提交更快。
iShard将redo以页面为单位进行聚合，管理数据分片，实现快速数据读取，并支持超大型数据库（128 TB）。存储层支持多个GaussDB（forMySQL）集群实例，单个存储节点支持多租户数据库分片。部署灵活，可以将Plog和iShard部署在单独的存储池中或共享同一存储池。
在这种体系架构下，整个数据库集群只需一份足够可靠的数据库副本集，就极大节约成本。同时，所有只读副本共享云存储中的数据，去除数据库层的复制逻辑。一写多读，没有独立的备用实例，当主节点发生故障，集群进行切换操作时，只读副本可以切换为主节点，接管集群服务。而且由于只有数据库日志通过网络从数据库计算节点写入DFV存储层，没有脏页、逻辑日志和双写的流量，节省了网络资源。
信创云环境下的典型应用部署场景，是读写分离场景。读写分离是指通过一个读写分离的连接地址实现读写请求的自动转发。创建数据库实例后，可以开通读写分离功能，通过GaussDB(for MySQL)的读写分离连接地址，写请求自动访问主节点，读请求按照读权重设置自动访问各个节点。目前支持创建4个代理实例，多个代理实例适用于有隔离需求的复杂业务，根据业务需要使用对应的连接地址连接到实例。开通读写分离时，需选择加入代理的节点（包括主节点和只读节点）。各业务可以通过代理实例的读写分离地址连接实例。且读请求会分别发往连接的代理实例。也可以对代理实例添加或移除节点。同一个节点（包括主节点和只读节点）可以同时被多个代理实例选择，并设置不同的读权重配比，如图5所示。读写模式的代理实例，可代理读、写请求，其中，写请求全部路由给主节点，读请求根据读权重配比分发到各个节点。只读模式的代理实例，只能代理读请求，读请求根据读权重配比分发到各个只读节点。不会分发到主节点，即使主节点被选为服务节点且已配置读权重，也不会生效。
图5 GaussDB（for MySQL）业务逻辑实例
开通读写分离功能的配置方法，主要通过开启数据库服务的页面去配置，如图6所示。
图6开筒数据库服务代理代理示例
代理实例名称：长度在4个到64个字符之间，必须以字母开头，区分大小写，可以包含字母、数字、中划线或下划线，不能包含其他特殊字符。
代理模式：支持读写模式和只读模式。
读写模式：所有写请求只发往主节点，所有读请求按照读权重配比分发到已选节点。主节点的读权重值默认为100。
只读模式：所有读请求按照读权重配比分发到已选只读节点，不会分发到主节点，即使主节点被选为服务节点且已配置读权重，也不会生效。只读模式仅支持读请求业务，写业务请求会有异常提示。该功能降低了主节点负载。在只读模式下，不支持DDL、DML操作和临时表操作。一致性级别：目前支持最终一致性和会话一致性。
最终一致性：开启数据库代理后，同一会话内，连续多次SELECT请求会根据权重配比，路由到不同的数据库节点，由于主节点与读节点之前存在复制时延，并且各个读节点的复制时延大小不一定完全相同，可能会导致每次SELECT请求得到的结果存在差异，因此默认情况下，数据库代理只能保证数据的最终一致。
会话一致性：由于最终一致性可能会导致多次SELECT请求的结果存在差异，数据库代理进一步提供了会话级别的数据一致性，保证了在同一会话内，每次SELECT请求都可以获取到上一次写入操作后，数据库的最新数据。数据库代理会记录每个数据节点的日志序号（Log Sequence Number，简称LSN），同时针对每一个会话也会维护对应的LSN，即Session LSN。当某个会话有数据更新操作执行完毕时，数据库代理会根据当时主节点的LSN来更新对应的Session LSN，后续有读请求来的时候，数据库代理会比较Session LSN以及各个数据节点的LSN，将请求发往LSN大于或等于Session LSN的数据节点，从而保证当前会话内，SELECT请求总能获取到上一次更新操作后的最新数据。如果需要减轻主节点压力，让尽量多的读请求路由到只读节点，您可以选择最终一致性。
路由模式：支持权重负载和负载均衡。
权重负载：根据您设置的读权重比例分发读请求。
负载均衡：根据数据库节点的活跃连接数情况进行读请求分发，将读请求分发到活跃连接数较少的节点上。
读写分离开通后，可以通过实例的“基本信息”页面查看每个代理实例关联的数据库节点。
三、写在最后
GaussDB（for MySQL）采用的新一代分布式存储系统DFV，节省了资源，极大提升了数据备份、恢复性能。它将特定计算任务（备份与恢复逻辑）下推到DFV，以便更高效，快速地实现备份、恢复，而上层计算节点专注于业务逻辑处理。在这种模式之下，客户可以通过本地访问数据并直接与第三方存储系统交互，达到高并发、高性能。另外，GaussDB（for MySQL）的共享存储架构将数据持久化放入新一代存储DFV中，充分保障数据强一致性和0丢失；针对硬件定制上层系统，利用RDMA网络、NVMe SSD等硬件优势，在这些关键技术上整合创新，使得数据库的性能有了质的飞跃。
同时GaussDB（for openGauss）在5.0.0中，传统的主备复制架构向资源池化架构演进，openGauss资源池化架构支持1主7备，主节点支持读写，备机横向扩展读能力，以满足现实世界典型负载性能要求。多节点数据实时一致的能力支持数据一致性敏感型应用负载从单个节点透明扩展到多个节点。去除传统主备日志复制开销，存储成本下降50%以上。基于高性能RDMA网络实现轻量级RPC框架，CPU资源开销显著降低，实现us级网络时延。SCM（基于持久化内存的SCM加速）多级缓存能力实现同等内存成本下性能提升30%。数据库的共享存储支持企业级存储和分布式存储。与传统建库相比，资源池化将目录分为三种类型，每实例独占且不共享、每实例独占且共享、所有实例共享。其中需要共享的目录均需存放到共享存储上，而不共享的目录存放在本地盘上。另外，备机建库只需要建隶属于自己的目录，不需要再次创建所有实例共享的目录结构。我们可以发现这种集中式和分布式混合的存储部署方式正在兴起。
结束语
国产数据库在功能和性能方面已经可以替代传统国外数据库产品，但实现国产化替代需要整体架构可靠、可用。尤其在一些关键核心应用场景下，需要灵活运用集中式和分布式存储的部署架构，实事求是地根据需求场景分析选择最适合的架构，稳健地实现国产化替代的目标。
