数字化转型之基础设施篇 | QingStor®️NeonSAN®️ 企业云存储实践

据 IDC 最新报告预测，2022 年中国 50% 以上的组织都将成为数字化坚定者，依靠新的商业模式、数字化产品与服务实现业务增长。

面对数字化转型的时代浪潮，青小云为大家准备了一份硬核大礼 —— 《数字化转型之路》，包含基础设施、业务架构、解决方案到行业实践、未来探索五个部分，该系列是对数字化转型理论与具体实践路径的系统梳理，希望帮助读者全面准确把握数字化转型发展趋势与前沿技术，促进企业与组织能够在变革的数字化世界中创造更大的价值，实现更强健的生命力。

今天与大家分享的是《数字化转型之路》中基础设施篇——利用 QingStor®️NeonSAN®️ 打造强劲的核心业务存储引擎。

以下是分享正文：

Neon 是一个惰性气体，它是化学元素周期表第十位，不燃烧、不助燃，不活跃，非常稳定。我们通过这个名字命名我们的存储，希望存储产品像惰性气体一样地稳定，因为稳定是存储最根本的要求。

为企业核心业务而生的 QingStor®️ NeonSAN®️

NeonSAN®️ 作为企业级软件定义的分布式块存储，它在青云经历了多年的研发迭代与广泛的用户验证。分布式存储是 QingCloud 云平台体系中的重要组成部分，很早就以云平台超融合的方式为客户提供服务。后面我们发现很多客户提出独立存储需求，我们把云平台的存储进行解耦，作为独立产品推出。

NeonSAN®️ 是青云全自研的一款软件定义分布式块存储产品，支持 HDD、SATA SSD、NVMe SSD 乃至 Intel Optane 等多种存储介质，并可选 10GbE 或新一代 25GbE 网络，通过不同的硬件组合，能够为不同应用场景下的不同存储性能需求提供灵活选择。也能根据应用特点融合部署在虚拟化环境（HCI），或者分离部署在 x86 服务器之上（Server SAN），Oracle RAC、SQL Server 等核心数据库集群、物理机高可用架构、容器持久化存储、大数据分析计算等应用场景都有相匹配的 NeonSAN®️ 产品。

NeonSAN®️ 主要由四个大的功能角色组成：

Zookeeper 用于集群管理，进行注册发现服务，新加入的 NeonSAN®️ 节点会自动注册到 Zookeeper；
管理组件用于 NeonSAN®️ 的控制节点，类似 SDS 中的控制平面（Control Plane），通过一主多从模式来实现高可用，当主控制节点不可用时，通过 Zookeeper 可以自动产生新的主控制节点；
元数据信息存放在 MySQL Plus 数据库中，MySQL Plus 是一个分布式数据库集群，可以分布到所有 NeonSAN®️ 之上，主控制节点可自动访问 MySQL Plus 以获取元数据信息；
Store Node 主要用于数据服务，类似 SDS 中的数据平面（Data Plane）。

NeonSAN®️ 通过多副本机制来保证数据的高可用，副本数量可以设置为一、二、三或更多（默认为三），接收到应用服务器的写请求之后，其在写入主副本的同时，Replicator 进程会同时将数据副本发送到其他 NeonSAN®️ 节点，当主副本与从副本的都写入成功之后，再返回应用服务器写入成功，这种机制保证了数据各副本之间的强一致性。

在全闪存阵列中，NeonSAN®️ 内部存储网络使用支持 RDMA 技术的新一代 25GbE 网络，利用 RDMA，数据本地写入与远程节点数据写入拥有几乎一致的响应时间，这可大幅降低 NeonSAN®️ 数据写入延迟。

除了数据存储的高可用之外，存储系统还需要关注存储网络的高可用。与传统 SAN 存储的双控制器或多控制器来实现高可用不同，NeonSAN®️ 的存储网络高可用是通过交换机和数据链路的冗余来实现高可用，如下图所示：

每个 NeonSAN®️ 节点都配备了 2 张双端口网卡，每个端口都连接到不同交换机上。其中互为冗余的两台前端交换机作为服务网络，即为前端应用服务器提供数据读取服务；两台支持 RDMA 技术的 25GbE 交换机作为数据网络，主要用于 NeonSAN®️ 的多副本写入等数据交换操作。

作为支撑企业关键应用的数据存储解决方案，NeonSAN®️ 在注重高可用性的同时，也致力于提供更高的性能。因此，在 NeonSAN®️ 开发过程中，简洁是第一原则，所有存储软件堆栈都以“简单”为第一优先级以充分发挥 NVMe SSD 的高性能优势。

除了对 IO 路径进行优化之外，NeonSAN®️ 还提供了诸多企业存储常用功能，比如标准 iSCSI 接口支持，和最新的 NVMe over Fabric 规范支持，以及多路径故障切换、无中断的数据恢复、迁移和容量均衡等功能。

NeonSAN®️ 通过多副本与多数据链路的机制达到数据存储与服务的高可用，利用 NVMe SSD+25GbE（RDMA）来提升存储性能，辅以“简洁”的存储软件堆栈最大限度发挥 NVMe SSD 的高性能优势，并支持多种企业关键应用常用功能来满足不同应用场景下的存储功能需求，这一系列特点已经让 NeonSAN®️ 具备了替代传统 SAN 存储的基础。

极致性能支撑核心业务数据库

E 企研究院根据企业关键应用的特点，使用 x86 服务器、Intel NVMe SSD 和 25GbE 构建了 Oracle RAC 数据库环境，用以评估 NeonSAN®️ 在 OLTP 中的性能表现。

测试分为两部分：

**第一部分是存储基准性能测试，**我们可以看到：随着 NeonSAN®️ 卷数量的增加，其性能线性增长，而平均响应时间的增长幅度并不明显。在单台客户端性能测试中，在配置 4 个 NeonSAN®️ 卷时，4K 随机读写和 8K 随机读性能均在 30 万 IOPS 左右，8K 随机写性能则能超过 25 万 IOPS，平均响应时间则均控制在 1ms 以内。

为什么选择测 4K 和 8K？

4K 是存储领域测试性能的事实标准， 8K 是数据库常用的块大小，8K 的性能可以从某一个方面反映出这个存储支持数据库的能力，性能越好，说明对数据库的支持越好。

**第二部分是 Oracle 场景测试，**我们可以看到：在配备 3 个 NeonSAN®️ 卷做 Oracle 数据库存储时，整个 Oracle RAC 环境就已经达到最高性能。即使受到 Oracle 数据库服务器计算性能的影响，在此 Oracle RAC 数据库环境中，也取得了超过 165 万 TPM 的性能，平均 TPS（Transactions Per Second，每秒事务处理数）接近 3 万，且完成每个事务处理的平均响应时间在 15ms 左右，能够支撑绝大多数的企业关键应用负载。

165 万 TPM 是一个什么样的水平？我们通过公开数据做了一个对比。

2018 年前 4 个月全国快递业务量累计完成 136.7 亿件，平均到每天的快递业务量约为 1.14 亿件，按 8 小时计算，相当于每分钟会产生 23.75 万件快递，相当于 23.75 万笔订单，每个订单背后按 5 个数据库操作计算（即 1 订单需要 5 数据库性能作为支撑），那么大约需要 120 万的数据库性能，即 120 万 TPM。

测试表明，NeonSAN®️ 具备高可用、可扩展性以及无锁定等特点，同时借助 NVMe SSD+25GbE 网络技术，能够提供极高的性能和极低的 I/O 响应时间，完全有能力满足企业关键应用负载提出的苛刻性能需求，助力企业向混合云迈进，为数字化转型奠定坚实基础。

NeonSAN®️ v2.2 版本新功能

NeonSAN®️ 在不断发布新的版本，做一些新特性的增强。上图左是我们现有的存储方案，采用共享存储的方式。底层是数据层一般会采用机械盘，如 SAS 或者 SATA，上层缓存层可能会使用 NVMe SSD、SATA SSD 等技术。作为总体空间对外提供服务，它的可用空间仅仅局限于数据层，缓存层只是做缓存，数据存在里面会不断地搬移到底层。

我们很多客户提出新的要求，他希望在不增加节点的情况下提供多维存储服务。比如在节点里，它要提供高性能存储服务支撑我的数据库，同时也要提供性能低一点，但容量比较大的服务，存一些比较大量的数据。新功能会自动帮用户做数据分布，对用户来说，只要把数据存在里面就可以了，设备会根据 IO 读取频率统计每个文件的使用情况，把热数据迁移到高性能资源池，把不常用的数据放在低性能资源池，可以拓宽用户的使用场景，降低用户的投入。

QoS 比较关键，青云是做公有云的，我们很多私有云场景里用户需要为多租户提供 QoS 服务，必须通过一些比较完善的技术确保我们存储能应对高并发的访问，基于能够针对 IOPS 和带宽做质量的控制，确保资源池的稳定和整个云平台的稳定。

前面提到我们的存储可以跟 VMWare vSphere 做对接，为 vSphere 提供存储能力。我们目前有两种方式：

第一种方式是计算存储分离的架构。VMWare 这边是 VMWare 的宿主机 EXSi，我们 NeonSAN®️ 创建 Volume 挂载到宿主机里，从 VMWare 创建 DataStore，它就像使用传统存储一样创建虚拟机和磁盘就可以了。

我们最近发布了另一个新方案，能够与 VMWare 宿主机采用融合部署的方式。它类似于 VSAN 的架构，在一个机器上装好 VMWare 操作系统，同时部署 NeonSAN®️ 软件，作为数据盘对 VMWare 提供服务，这类似于青云的计算存储融合架构，在同一个节点上同时提供计算服务和存储服务。

NeonSAN®️ 作为分布式块存储在存数据时要做切片，要把数据根据主副本和从副本存在不同的位置。主副本和从副本一般会存在不同的节点上，确保数据安全。

在融合部署时，可能会面临一个问题，虚拟机可能会在某一个计算节点上，但是它的盘的主副本可能在其他节点上。读的时候涉及跨网络的问题，为了解决对网络带宽的占用及提高融合架构下虚拟机的性能，我们提供了本地优先的方式，NeonSAN®️ 根据计算资源所在盘的位置把主副本跟它落在一起，读的时候不会涉及跨节点的数据访问。这样可以降低带宽，同时提高虚拟机的性能。

快照方面，以前的快照有一个快照空间，当我创建快照时把数据拷贝到快照空间里，在新的 IO 过来再写到原始数据里。

现在提供第二个方式，我们会创建一个区域——改动数据存放区，我们的快照创建时比较快，不需要做任何动作，当时的状态就保存在那里。当有新的 IO 过来时，把 IO 数据保存到改动数据区，及时记录下来，可以极大地提升创建快照效率。现在我们同时提供这两种方法，用户可以根据自己的业务场景、底层硬件配置选择采用哪种方式。

还有一个重要功能是数据恢复，主要用于应对某台 X86 宕机或者有盘掉电掉线的情况。

第一种方式是全量复制，假如原来有三个副本，当其中一个副本出现故障时，我们会从剩余的两个正常副本里把它复制一份出来，其他还是变成三副本。这对带宽和底层硬件要求比较高，适用于全闪场景。它在降级时少了一个副本，写的时候 IO 性能略有提升，但复制的压力会比较大。

**另一种方式是节点掉线后，不立刻做副本的复制，只记录变化的 IO，节点不会完全丢失，掉电重启上电后数据会回来。**这时候再把变化的 IO 写回之前的副本里，使之跟之前正常副本数据保持一致，可以实现三副本数据再次一致。主要适合于采用混合硬盘的场景，比如客户底层有很多机械盘，前端有 SSD 做缓存的场景，用户可以根据其实际需求选择不同的部署方式。

在灾备方面 NeonSAN®️ 也做了大量优化工作。以前灾备最小的颗粒度是 64G，只要这个 Shard 有变化，我们就需要把 64G 文件复制到远端。现在我们把独立颗粒度做了优化，最小可以是 64 兆，只需要把变化的数据以 64 兆为单位做复制，这样可以提升复制效率，降低对带宽的占用。

同时在备份方面也有增强，以前以 Block 的容量作为备份基准，当 Block 发生变化做备份时，如果选择增量备份，需要把整个 Block 进行拷贝。现在我们把对比颗粒度做得更细，最大不超过 1 兆。此时，做增量备份时，以兆为单位做数据复制，大幅提高备份的效率。

核心业务上云之最佳实践

接下来是两个客户案例：

第一个是金融行业的客户。

某国内保险集团（世界五百强企业）在 2015 年拿到互联网保险牌照，开始从事线上保险相关业务，并且开始建设自己的私有云，对核心业务进行分布式改造。

保单业务量 2016 年就出现 62 倍的增长，原有 Oracle 数据库一体机平台物理硬件资源趋于饱和，且该型号产品停产，不再支持扩容升级等服务。该集团在 2017 年下半年实现了核心关键业务向分布式云化架构的迁移，将线上业务数据库向 x86 平台迁移，使用全闪 NeonSAN®️ 集群作为 Oracle RAC 后端存储，采用三副本数据保护机制。如今，通过核心业务架构的改造，该集团数据库容量已经达到惊人的 30 多 TB，业务运行稳定、扩容极为便捷。

从用户的角度获得了几个好处在：

经过业务场景实测，基于 NeonSAN®️ 的复杂视图查询响应时间从 20 分钟以上缩小到 2 分钟，精算准备金复杂 SQL 执行效率从分钟级缩小到秒级，实现效率 100% 的提升，可确保所有类型的数据处理都能够实现卓越的性能。
现在是统一的 X86 硬件，不需要维护小机和 X86 两套架构，不需要传统 SAN 交换机，最大程度地简化了网络存储，显著降低部署和运维成本。
NeonSAN®️ 全分布式架构使存储扩容时间从几个月提升至几天，提升速度高达 10 倍，有效满足业务数据量激增的扩容需求。

第二个是零售行业的客户。

在互联网 + 的背景下，数字化已经成为新零售的核心驱动力。为了满足多变的客户需求、保持快速的产品和业务全流程创新，某零售集团大量的核心 ERP、Oracle RAC 业务需要从架构层进行重构，逐步实现向云化、移动化升级。该集团以超融合的方式在生产区部署了 8 节点 NeonSAN®️ 集群，在灾备区部署 3 节点的 NeonSAN®️ 存储，实现核心业务上云与应用级的云灾备。

客户收益主要体现在几个方面：