·2021-08-11 11:58

工程师·华为

MySQL存储计算分离创新方案实践

字数 5226阅读 1813评论 0赞 1

**导读** ：用 MySQL 等分布式数据库替代传统商业数据库，是近年最热门的话题之一，然而，替代的代价往往让企业难以接受。如何在实现数据库整体能力提升的同时，把数据库替换的代价降到最低呢？“存储和计算进一步分离”作为近年数据库分布式升级改造中的关键技术，让我们一起通过江苏电信的具体实践，去了解如何更好的利用这一技术。

# 一、  运营商核心 IT 系统互联网化成为行业共识

我是江苏电信企业信息化部 IT 架构师杨堃，计费和 CRM 两大系统是运营商的核心 IT 系统，由我所在部门企业信息化部负责运维。

随着移动互联网时代到来，越来越多的用户和业务模型，这都对 IT 系统提出了巨大的挑战。为了应对这些变化，提升电信的服务体验，中国电信在 2018 年对 IT 系统进行了架构重构，引入互联网化的 IT 架构，业务上实现中心化，微服务化，数据库分布式化，通过这些改造，系统的支撑能力有了极大提升，支撑了电信在移动互联网时代的业务**。** ****
![](/home/attachment/202108/11/1244863_162865407192979.png)
# 二、  数据库分布式改造面临三大挑战

借鉴互联网优秀实践，我们采用基于开源 MySQL 的分布式数据库和分库分表的方式替代核心业务的 Oracle 数据库，可靠性方面采用一主两从，增强型半同步复制的方式，来保障主从节点的强一致性。

![](/home/attachment/202108/11/1244863_162865399850165.png)
  
 一开始我们采用物理服务器的方式部署 MySQL 。为保证核心业务的稳定性，采用了 NVMe Flash 卡作为存储，配置两路 CPU 。然而，在实践过程中，我们发现这种服务器本地盘的部署方式带来了难以解决的问题：
 ## 1.  可靠性

因为承载的是核心业务，直接关系客户体验，因此我们对可靠性的要求非常高。而服务器的可靠性比较低，同时为了保证性能大量使用 NVMe Flash 卡，但服务器对它的使用没有优化，会因为频繁写入导致故障，使用年限越长同时出现大批量的故障增加，即使有多副本也无法保证不丢数据。

使用 NVMe Flash 卡是为了保证系统性能，但它不能做 RAID ，导致卡坏了或者服务器故障时间长一点，就需要全量恢复数据来重建副本。这需要备份恢复全量的数据，再用 Binlog 追日志，虽然一个实例只有 500G 到 1T 的数据，但因为 MySQL 的日志同步很慢， 500G 的数据经常要恢复 3 个小时，当业务压力大时，会导致很长时间都追不上。
![](/home/attachment/202108/11/1244863_162865405358635.png)
还有 MySQL 的增强型半同步在业务压力比较大时，比如做批量开户时有可能因为性能问题退化成异步同步，这时如果发生切换会导致数据丢失，对我们的运维是很大的挑战。

## 2.  资源分配

为了应对业务互联网化的挑战，我们借鉴互联网架构改造业务，期望能实现资源的快速发放和按需扩容。但我们发现使用服务器本地盘的方式，当计算或者存储单一资源耗尽需要扩容时，只能计算、存储绑定扩容，导致资源的浪费， CPU 资源利用率不到 15% ，如果无法实现弹性伸缩，按需扩容，那么我们花这么大代价做分布式化改造就没意义了。

## 3.  成本

我们发现替换 Oracle 后硬件投入不降反增，这由几方面原因造成：

首先为了保证性能，数据库分库分表后每个 MySQL 实例限制在 500G-1T 规模，这样一个 Oracle 数据库要拆分成几个甚至十几个数据库实例；

其次因为恢复从节点的时间太长，需要通过一主两从的方式保证可靠性，然而不管是主还是从节点，为了保证服务器的可靠性，我们要求一台服务器上最多部署 3 个实例。

同时由于无法按需扩容，我们要预留相对多的资源，以防业务高峰的带来突然增加的数据量，因为扩容不及时而导致系统奔溃。

在服务器本地盘存算一体的架构下，我们要保证系统的可靠性，一台服务器上部署实例比较少， CPU 利用率很低。利用率低也意味着更多的服务器投入，甚至机房供电都变得紧张。

因此我们决定探索从部署架构等方面进行优化的可能性。

# 三、  选择计算存储分离架构的主要考虑因素

## 1.  本地盘云架构部署能解决与不能解决的问题

我们首先想到的是用云的模式，对数据库，可以采用的方式是虚拟化和容器化。虚拟化技术成熟，可以作为当前选择，容器化性能损耗小，灵活度高，可作为未来方向进行评估。采用云架构部署和配置资源能解决快速部署，资源隔离，资源的按需发放等问题，业界也有很多用容器化来部署 MySQL 的实践。

但我们研究了一些企业使用容器化方案后发现，如果仍使用本地盘，仅做容器化并不能解决我们的根本问题。

首先，可靠性依然由服务器和本地盘决定，没有本质提升，更重要的是数据在本地盘上无法实现跨服务器的漂移，这使故障切换后恢复时间长的问题无法解决，我们还是不能放手增加服务器上的实例数量。

再有同样因为无法实现漂移，就无法实现资源的弹性扩缩容，这样在资源弹性分配和节省成本的优势就大打折扣。

## 2.  计算和存储分离的价值

我们的架构是借鉴互联网的，我们发现去 IOE 的阿里，以及京东也遇到了同样的问题，阿里在双 11 遇到了 MySQL 部署在本地盘无法弹性扩容的问题，京东则把可靠性、运维、扩容等问题总结为存储之殇。最终他们的解决方案都是采用计算、存储分离。
![](/home/attachment/202108/11/1244863_162865410550086.png)
阿里方案可以和分库分表结合，但封闭架构无法集成我们基于 MySQL 的开源数据库。
![](/home/attachment/202108/11/1244863_162865418236860.jpg)

京东的方案不需要改造数据库就可以实现，对我们来说，更具有参考性，通过 Kubernetes 实现了 CSI 插件对存储的调用，目前有状态的容器技术已经成熟，我们的问题能很好解决：

首先，可靠性上，存储是有冗余保护的，可靠性高于服务器；其次，容器与外置存储结合能实现跨物理机的漂移，故障恢复不需要全量恢复数据，故障降级时间大幅度缩减；同时，计算、存储解耦实现按需扩容，资源利用效率提升，整体成本下降 50% 。

## 3.  为什么选择全闪存存储

接下来就是存储分离后选择什么样的存储？存储的选型我们主要考虑几个方面：

**第一、综合性能上不能比原有方案差，存储不能成为性能瓶颈** 由于我们之前用的是 NVMe Flash 本地盘，因此在性能上考虑时延要小于 0.5ms ，同时峰值性能要求达到不低于 8000IOPS/TB 的性能密度。基于此考虑，企业级全闪存存储的低时延高性能密度的特性比较适合。

**第二、可靠性** 以我们的使用经验，核心业务数据库中选择有良好使用记录和服务支持能力的厂商的全闪存是更好的选择。全闪存的磨损均衡，反磨损均衡，全互连架构正好是解决 SSD 可靠性的关键能力。

**第三、扩展性** 在使用场景中考虑，因为交易型数据库为了保证核心数据库的可靠性和维护性，要划分更小的故障域，不管是计算、还是存储资源都可以按需分配，满足业务扩展需求，不会配置很大的资源池，但要有 “ 适度 ” 的灵活扩展能力。

# 四、  基于华为 OceanData MySQL 存算分离方案的实践

从上面的分析可以看出，没有最优的架构，只有更适合的架构，在核心业务数据库中，全闪存是更好的选择，当然前提是这个全闪存存储具有足够的可靠性，并融合了分布式的部分特征。最终我们选择华为 OceanData MySQL 存算分离方案展开我们的方案验证工作。

## 1.  要重点验证解决哪些问题

配置方案：存储采用了华为 OceanStor Dorado18500 ，网络采用了 25GE 以太网，确保性能。同时这个组网同时支持 ISCSI 和 NOF 组网，方便未来我们会升级到性能和稳定性更好的 NOF 组网。

前面已经提到，我们认为容器化是未来的方向，因此我们对容器化部署方案验证进行了详细设计和充分验证，以保障核心业务数据库的正常、稳定运行。容器场景下存储资源的编排发放，扩容等功能性验证；云虚拟机、本地虚拟机和容器的基准测试、性能、可靠性测试以及数据库部署实例密度测试。

**关于性能** ，通过测试我们得出两条结论：
![](/home/attachment/202108/11/1244863_162865415998833.png)
1 、同等 CPU 和内存资源消耗下，当配置相同数量的 MySQL 主从集群时， ISCSI 容器化部署的性能是本地虚拟机的 1.5 倍。

2 、相同 MySQL 参数下， NOF 容器化部署是 ISCSI 容器化部署的 1.5 倍，同时 CPU 使用率也提高了 1.5 倍，这也符合测试结果中体现的 TPMC 值与 CPU 使用率成正相关的关系。这个结果也反映出 NOF 组网相比于 ISCSI 组网，可以达到更高的性能上限。

这些结论加深我我们向容器化演进的信心。

**可靠性方面** ，我们考虑的是综合的可靠性，一方面容器提供了额外的可靠性保障，比如反亲和，另一方面我们重点测试了容器的漂移，对业务的感知和数据库实例重启是差不多的。这样在这个相当于重启的实例上做增量数据补从可以几分钟完成。原来一台服务器坏了，不管是在一台新的服务器上恢复，还是更换部件，再进行全量数据恢复和同步，都要半天甚至更长时间，现在几分钟就完成了，而且过程可以做到自动化。

## 2.  实践结果

从整体的效果来看是达到甚至超出预期的。各部件可靠性，尤其是存储可靠性有了比较大的提升，解决了 NVMe 盘 RAID 问题，还额外提供了亚健康监测，数据校验和 SSD 磨损均衡和反磨损均衡这些服务器上不太可能实现的能力。同时整体方案上我们看到故障恢复、降级时间，维护复杂度都有很大降低。也就是整体可靠性是远高于原有方案的。

存算分离后，所有的资源分配都可以是按量的，不会有 CPU 不够存储用不了或者反过来的情况，同时因为可以实现弹性扩容，一方面业务支撑能力增强了，另一方面也不用预留太多资源应付突发扩容的问题。在可靠性和运维能力提升的基础上，我们可以大胆地把每台服务器的实例数增加 2-3 倍。

同时因为我们的业务读写比比较低，所以在可靠性得到保障的情况下，可以从一主两从变为一主一从，一方面进一步节省资源，另一方面实例减少对运维也是有好处的，因为全面上云后我们的实例数会轻松达到上千个。

还有一个现在比较热的话题是碳排放。首先华为 OceanStor Dorado 全闪存存储的耗电本身就比较低，再加上节省了大量服务器，因此机房占地和耗电可以节省 50% 以上，不但保护了环境，还为以后的业务扩展增强了弹性。

## 3.  未来展望

我从事 IT 工作十几年，对于数据库，一直是两个思路来提升能力，一条是基于专业强大的基础设施的能力提升整体能力，另一条是通过对数据库和应用的架构改造和优化来支撑业务。随着网络技术和存储能力不断增强，我们基于网络和全闪存存储，通过存算分离架构，让基础设施来解决问题，后续我们仍然会考虑沿着这个思路进一步提升方案的能力，尤其是在成熟平台基础上做一些优化和集成，达到事半功倍的效果。对于存算分离后，对存储我们考虑的优化方向有：

在故障切换监测半同步状态，如果降级到异步了，就不做主从切换，等容器漂移完成后恢复服务，保证不丢数据。

进一步缩减数据副本，节省成本，因为数据库做了副本而存储再做冗余使冗余超过了可靠性的需要。目前 AWS ，阿里的云原生数据库都是共享一份存储的。

容器化的备份方案优化，比如使用存储快照等。

# 五、  总结

在 MySQL 分布式改造的探索和实践中，我们通过计算、存储分离架构，借助华为存储最终实现了计算、存储按需配置， CPU 利用率从 10% 提升至 30% ，存储利用率从 40% 提升至 70% ；主节点故障，业务重构时间从小时级缩短至分钟级；存算分离后， IO 路径变长，但新方案采用 RDMA 协议，远程内存访问，时延接近本地盘。

未来，我们也会在现有架构中继续探索，进一步提升 IT 基础设施的整体能力。

**文章著作者： 江苏电信企业信息化部 IT 规划总架构师 杨堃
**

华为 OceanData 存算分离

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

MySQL存储计算分离创新方案实践

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料