引言

保险企业在数据库与存储的信创建设过程当中，如何设计存储架构是个令人徘徊的问题，也一直是IT界经常要讨论的问题。有的观点认为信创数据库通常对存储资源的形态没有特殊要求，实则不然，一切需要回归实事求是。数据库存储架构的设计，既要需要满足特定业务需求场景的存储资源需求，又要支撑业务稳定、保障数据安全，还要整体TCO最优。本文从业务场景适用性及软硬件TCO维度展开具体分析。

一、保险行业数据处理业务场景特征

保险行业的业务系统会因业务渠道、服务对象、处理逻辑等因素的差异呈现出不同的数据处理需求，对于支撑这些业务系统的数据库基础架构工作模式也会呈现为混合负载模式。以保险行业为例，业务系统主要包含以下几类：

1、业务管理类

该类系统是保险行业的核心类系统，主要用于实时处理保险业务，包含产品、保单、理赔等相应业务。主要目的在于完成保险业务，提高处理效率，保障客户感受。那么后台数据处理也会呈现重逻辑计算轻数据存取的特点，而且并发量级较高，对数据的完整性及安全性都有较强要求。

2、客户关系类

该类系统主要是帮助保险公司进行客户画像、行为分析、需求分析、客户维护等业务处理。时效性低于业务类，但是会对客户的历史数据以及其他数据进行大量的存取、处理以及分析。那么后台数据处理也会呈现出大量数据的存取操作以及批量计算的特点。

3、其他类

其他类包含风险管理类、财务管理类、资管类以及决策支持类等。可以看出它们根据其所属专业领域、使用部门、使用目的等诸多不同因素呈现出不同的数据访问特点，同样后台的数据处理也会呈现出不同的计算和存储比例特点。

综上，金融行业IT的整体数据处理业务是一个混合负载业务，其对计算资源和存储资源的利用比例以及要求不能完全用一个标准来衡量。

二、计算与存储的耦合性

要搞清楚不同架构在TCO以及业务场景适用性方面的优略，首先需要搞清楚哪些架构是属于计算与存储强耦合的架构，哪些是解耦的架构。通常我们认为数据库信创建设过程当中利用本地存储属于计算和存储强耦合的架构，利用共享存储的模式属于计算和存储解耦的架构。如图2.1&2.2所示：

本地存储架构的CPU不仅需要承担数据库的计算任务，还需要承担本地存储资源的存储任务。共享架构下的服务器仅承担数据库的计算任务，数据落盘的存储任务由存储设备的CPU来承担。

三、本地存储架构

3.1 本地存储的TCO和场景限制

为什么通常认为本地存储架构会节省成本？

本地存储架构，因无需采购共享存储设备，所以从直观理解来看，建设成本肯定会低于共享存储数据库架构。这个观点显然是从个体单元出发来考虑问题的，如果所有的数据库业务都可以按照以下的负载特点来运行的话，我们来看它的成本变化趋势。

（1）对数据库主机的CPU P99 负载，一般要求不超过40%。在20%~25%为合理区间；
（2）对数据库主机的本地存储使用，因为存储一体的扩容复杂度，时效低，一般建议整机不超过80%，单个实例不超过70%。 因此整体存储使用率保持55%~65% 合理区间；
（3）数据库主机使用本地存储，在存算一体情况下，CPU和存储必须按照套餐规格分配。

接下来我们来看对于企业来讲，多套数据业务规模化发展后的趋势。

我们以32C(物理核), 20T 存储主机为例。可以按照1C : 350GB 套餐规格分配。 理想情况下，最大可以分配 48C:16.8T存储， CPU超分系数1.5，存储不超分。并达到CPU (20%~25%), 存储（55%~65%） 的期望负载。

显而易见, 如果所有业务系统的数据库都能满足以上负载特点，保持一致性的发展状况，那么企业就可以节省采购专门存储设备的成本了，包含设备以及运维等方面。

但是，企业数据业务是不是能保持如此一致的发展趋势呢？

金融企业的数据业务有很多种类，以保险为例：有支持前端的出单业务，有支持售后的理赔业务，也有支持客户管理的数据分析类业务，每一种业务的数据访问、数据量级、并发数量都是不同的，这必然导致数据库系统的计算任务和存储任务的负载比例是有差异的。例如：聚焦于客户画像的分析类业务必然是重存储轻计算的特征，聚焦于客户支持的核算、出单、理赔类业务必然是重计算轻存储的特征。

因此，强耦合的架构有适合的业务场景和业务架构，但不适合所有的金融企业的数据业务场景，我们需要具体问题具体分析。

3.2 本地存储的问题

（一）、数据安全和一致性

1、主机级故障时的RPO问题
主备机共享存储架构下，当主机故障时可切换存储，可保证RPO=0。 但当主机故障时候，本地盘可能发生数据未写入、未同步到从库情况，无法确保RPO=0 。

当然，如果业务没有强要求的话，可以通过以下几种方式解决：

• 数据不重要，应用系统接受数据丢失。
• 应用系统能识别数据丢失，并有快速补数方法和措施。
• 采用强一致同步模式, 事务在确保从库写入之后才返回，确保RPO=0。但应用需接受性能延迟。在网络状况正常情况下，单次数据库操作从毫秒级到10毫秒级。
• 采用原生分布式数据库, 在底层自动实现多数节点同步。

2、脑裂和双主问题
主备架构采用了一份共享存储，或者挂载主机上或挂在备机上，不会发生主备两个主机同时写入的情况。在此主备机共享存储架构下，主机级故障优先进行存储切换。不涉及脑裂和双主问题。只有在机房级故障， 需要进行同城切换的时候，才可能会涉及到双主故障。并进行相应的防范和处理。但对本地存储的主从架构，即使在主机层面的故障，也必须要对脑裂以及双主情况判断、防范和处理，避免双主情况的发生。 一旦进行了自动切换，也要有机制在数据层面进行检查和复核。

（二）、容量天花板

本地存储容量有上限，一但达到上限，只能采用更大容量的机型，并且要做数据迁移，整个变更周期需要几小时甚至几天。 所以使用本地存储模式，要严格管控数据库的大小，容量限高。并容忍有较高存储预留阀值，和因此造成的一定程度浪费。 一旦容量有超过限高的趋势，就要进行拆分。有2种情况：

• 如果应用采用分库分表架构，则可增加节点，并只需要迁移部分数据。
• 如果应用没有采用分库分表架构，那需要进行拆库，应用重构。或者迁移更大容量主机。

例如：对容量要求限制

**共享主机数据库要求控制1TB以下，分配存储不超过3TB
独占主机数据库要求控制在5TB以下，分配存储不超过8TB**

另一方面，这个限制又可能随机型变化而动态变化。对应用，数据库，主机三方面都增加管理复杂度。

（三）、CPU与存储套餐分配的长锥效应

存算一体架构下，需要按照CPU和存储套餐规格分配。所以在资源分配上，CPU 和存储容量会有“长锥效应”，即需要按就大原则来分配。因此要求应用系统与数据库设计需要保持较高的统一性，尽量保障CPU和存储资源使用均衡。如CPU负载太高，而存储容量小，可增加优化业务，把负载变平滑；或者增加缓存，优化业务逻辑，减少数据库负载。如果CPU使用低，而存储容量太大，是否可进行数据归档，进行压缩。或者因业务行为的资源不均衡，确实无法与规格套餐匹配。 那就只能按照就高原则分配，接受相关资源的总体成本增加。

（四）、存算一体架构的几个运维陷阱

1、可扩展性
对于业务活动，业务负载有明显上升的预期，到达一定程度之后，应用和数据库服务器的压力都会上升，当现有服务器处理能力不足时，应用和数据库服务器的计算资源都可能需要扩展。在存算一体架构下，当前主机若无法满足，则需要对数据库进行迁移，因为是本地存储架构，需要进行数据全量初始化和同步，然后变更切换。整个过程可能需要1~2天。并要保持反向同步，以便在活动结束后回切。而在主备共享存储模式下，可以采用先切备机，或者采用跨集群迁移方式迁移到CPU资源更多集群，而无须进行数据库同步。

2、缩容操作
文件系统一旦容量撑大，较难进行缩容操作。 一个大库进行了数据清理或者归档，降低了使用率。但还需要复杂的变更，如新搭建从库，并进行切换。才能回收掉分配存储。

共享存储虽也不提供缩容功能，但因采用Thin Provisioning，可按实际使用收费，不会对用户成本造成影响， 用户一般不关心缩容操作。

3、可维护性
主机过保维护，也需要先进行数据同步，然后安排变更切换。 人力、网络流量、时效都会增加。本地存储无法采用基于快照的方式进行备份。只能使用工具备份，对于超过2T以上库，备份可能需要几天。 而采用基于共享存储的快照备份，同样大小的库可在30分钟内完成。 同样，基于快照的备份集可以很快被恢复。

四、共享存储架构

4.1 TCO对比分析

我们采用的信创数据库是集中式数据库，分别按照本地存储3副本架构，以及共享存储主备架构（SAN存储）对比来进行测算。具体架构详见图3.1&3.2，测算过程中，以下述三点为前提条件：

• 本测算中，所有CPU核数均指物理核；
• 本模型均以共享主机评估， 数据库独占主机受具体情况偏差太大，暂不作为参考；
• 本测算中，统一考虑32C，20T机型。
  
  图4.1 本地存储主从架构（3副本）

（一）、通用成本因子

（二）、本地存储成本因子

（三）、共享存储（SAN）成本因子

（四）、评估项及公式
首先，计算两种架构下的主机需求数量：

1、本地存储架构总主机数

备注：本地存储架构因存储按需分配后，无法“共享”，不能超分，因此以存储为主要计算因素。

接下来，计算两种架构下的全年成本：

如果本地存储的平均CPU P99负载为10%， 而共享存储在存储分离情况，平均CPU P99负载为20%， 则年总成本比较示意图如下（ 具体根据实际情况计算 ） ：

• 而如果本地存储的平均CPU P99负载为20%， 则本地存储年总成本与共享存储接近（ 具体根据实际情况计算 ）
  
  注：横轴为实际使用存储总量， 单位TB，纵轴为年总成本，单位为(万元)
• 在1000TB实际使用存储用量情况下，我们以每CPU P99 与实际存储容量比(GB) 1:800, 共享存储架构数据库主机平均CPU P99为20% 来进行比较。可以看到只有当本地存储数据库主机平均CPU P99 达到20%以上，则逐渐体现成本优势。
  
• 如果是在100TB实际使用存储情况下，当本地存储数据库主机平均CPU P99 达到18%以上，逐渐体现成本优势。
  

总结来看，只有应用系统的CPU P99与实际使用存储容量保持相对均衡的水平，才可以显示本地存储架构的TCO优势。但是大多数企业，尤其是金融行业的数据库系统根据业务场景不同会呈现出不同的特征，这将导致计算与存储的负载比例不可能完全保持同样的平衡区间。综合需要做业务改造、机房改造等成本，那么，从TCO角度来看，强耦的本地存储架构在TCO方面并不占优。

4.2 业务场景契合度

（一）、通用指标对比分析

以上，是我们从规模、IT组织模式、资源分配、负载特征等几个指标来分析本地存储的耦合架构和共享存储的解耦架构各自适应的通用场景。前文分析过，金融行业IT的整体数据处理业务是一个混合负载业务，其对计算资源和存储资源的利用比例以及要求不能用一个标准来衡量。同时，数据的量级也属于中高甚至海量级规模。并且金融企业的IT管理相对比较细分，开发和基础运维各司其职。从这几个特点上来看，它更适合存算分离的解耦架构，也就是共享存储的架构。

4.3 基于SAN共享存储架构实现数据库信创实践

（一）、数据库基础架构
整体架构为PostgreSQL 高可用架构模式，采用“PaceMaker & 共享存储”组合完成数据库系统架构整体设计，共享存储采用华为OceanStor Dorado产品。具体如图4.3。

如架构所示，数据库层面通过Pacemaker实现数据库节点之间的故障切换。存储采用华为OceanStor Dorado全闪共享存储，一方面通过共享存储本身的计算以及存储资源体系支撑本地数据库节点的共享访问，另外一方面，通过SAN共享存储本身的容灾及备份功能实现数据底层的数据保护功能。

（二）、实现价值
技术上充分满足企业混合负载业务场景特性，实现如下价值：

1、满足信创国产化建设要求，打造自主、安全、可控的数据存储平台。
2、实现计算存储分离，利用业务系统数据分布空间和业务处理时间的整体均衡分布特性实现计算资源和存储资源的充分利用。
3、主从读写分离架构，支持超大规模并发订单和支付交易系统。
4、原生分区表支持丰富的分区策略，海量数据无需分库分表。
5、计算集群与存储集群分离，实现存储层和计算层的灵活弹性扩容。

TCO方面，通过与本地存储架构的对比测算，实现整体成本优势。

总结

企业在信创建设过程当中，由于分布式技术的应用，越来越多的技术和架构可以选择。无论是追求新技术的引入还是要增强自身架构的自主可控安全性，都无可厚非。但终究需要选择适合自己的技术架构才是硬道理。何为适合？还是要回到整体TCO的考量和业务场景的契合度上来。望本文能成一砖，引发更多优秀的思路和见解共勉。

课题协作：
陈萍春 某保险企业 存储架构师
王志猛 某保险企业 系统架构师
曹志勇 某保险企业 系统架构师
梁净净 某保险企业 数据库管理员
课题审核：
杨光-某保险企业-数据库架构师