运营商BSS核心业务MySQL存算分离创新实践

【作者】杨堃，江苏电信企业信息化部IT规划总架构师

用MySQL等分布式数据库替代传统商业数据库，是近年最热门的话题之一，然而，替代的代价往往让企业难以接受。如何在实现数据库整体能力提升的同时，把数据库替换的代价降到最低呢？“存储和计算进一步分离”是近年数据库分布式升级改造中的热门话题，存算分离到底有什么魅力？让我们跟着江苏电信的具体实践一起去一探究竟。

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

随着移动互联网时代到来，越来越多的用户和业务模型，这都对IT系统提出了巨大的挑战。为了应对这些变化，提升电信的服务体验，中国电信在2018年对IT系统进行了架构重构，引入互联网化的IT架构，业务上实现中心化，微服务化，数据库分布式化，通过这些改造，系统的支撑能力有了极大提升，支撑了电信在移动互联网时代的业务。

二、数据库分布式改造面临三大挑战

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

一开始我们采用物理服务器的方式部署MySQL。为保证核心业务的稳定性，采用了NVMe Flash卡作为存储，配置两路CPU。然而，在实践过程中，我们发现这种服务器本地盘的部署方式带来了难以解决的问题：

1.可靠性

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

使用NVMe Flash卡是为了保证系统性能，但它不能做RAID，导致卡坏了或者服务器故障时间长一点，就需要全量恢复数据来重建副本。这需要备份恢复全量的数据，再用Binlog追日志，虽然一个实例只有500G到1T的数据，但因为MySQL的日志同步很慢，500G的数据经常要恢复3个小时，当业务压力大时，会导致很长时间都追不上。

还有MySQL的增强型半同步在业务压力比较大时，比如做批量开户时有可能因为性能问题退化成异步同步，这时如果发生切换会导致数据丢失，对我们的运维是很大的挑战。

2.资源分配

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

3.成本

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

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

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

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

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

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

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

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

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

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

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

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

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

我们的架构是借鉴互联网的，我们发现去IOE的阿里，以及京东也遇到了同样的问题，阿里在双11遇到了MySQL部署在本地盘无法弹性扩容的问题，京东则把可靠性、运维、扩容等问题总结为存储之殇。最终他们的解决方案都是采用计算、存储分离。

阿里方案可以和分库分表结合，但封闭架构无法集成我们基于MySQL的开源数据库。

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

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

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

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

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

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

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

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

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

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

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

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

关于性能，通过测试我们得出两条结论：

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基础设施的整体能力。

未经允许不得转载：DOIT » 运营商BSS核心业务MySQL存算分离创新实践