面向全闪数据中心的“答案”

作者： XSKY 星辰天合 CTO 王豪迈

编辑：付秋伟

在数字化时代，企业追求的不仅仅是数据存储的速度和效率，还有对成本和能源的敏感把控。全闪数据中心顺应了这一趋势，因其固态存储解决方案相较传统硬盘在能源效率和总拥有成本（TCO）上的显著优势而脱颖而出。SSD 的能耗远低于传统硬盘，而在速度和响应时间上，它们提供了无与伦比的性能，这使得数据中心可以在更小的能耗预算下处理更多的数据，提升运营效率。

随着 SSD 技术的不断进步，价格也逐渐降低，使得全闪存储的成本逐步接近传统存储解决方案。更重要的是，全闪数据中心在扩展性和维护上的便捷性进一步降低了长期运维成本，加上其出色的能源效率，全闪数据中心成为了现代企业在数据存储上的首选。

正是基于这些技术和经济优势，全闪数据中心代表了未来数据存储的发展方向，成为了云计算、大数据分析和人工智能等高速增长领域的基石。随着全闪存储技术的成熟，数据中心架构正经历着一场深刻的变革，这不仅预示着性能的飞跃，更代表着对传统存储模式的根本挑战。我们如何在这波趋势中找到平衡点，实现高性能与成本效益的双赢，是一个行业共同关注的问题。

本文旨在深入探讨全闪数据中心的未来趋势，展示 XSKY 星辰天合如何通过星海架构引领行业变革。文章分为四部分，首先回顾 XSKY 星辰天合在分布式存储架构方面的演进和启示；其次，探讨硬件技术的发展如何推动全闪数据中心成为新趋势，以及带来的挑战；接着，深入分析面向未来的分布式全闪架构设计和解决问题的方案；最后，通过实际的应用场景验证新一代全闪架构的有效性。

回顾分布式架构的缓存技术演进

XSKY 自 2015 年创业以来，从早期的 V2 版本，经历 V3 的成长，直至最新发布的 V6，每一步都见证了技术的进步和不懈追求。在不同版本里，存储架构层、协议层、功能和对接应用生态都不断进步，而其中最重要的则是存储引擎的架构，它会具备更长的生命周期。

XSKY 从 2016 年正式发布基于 XStore 的 SDS V2 产品，XStore 在当时是业内少数的用户态缓存技术，提供本地 SSD 缓存来加速读写性能，其后 XSKY 陆续增加了大块 IO Bypass，可以自动识别大块 IO 直写 HDD。

在 2018 年，我们意识到本地 SSD 缓存固然简单，但是随着集群的长期运行，在 SSD 故障或者寿命到期后，SSD 对应的全量 HDD 数据都需要进行重构，大幅增加恢复时间，带来了更高的运维成本。同时，XStore 仅能够支持副本模式，而三副本的硬件成本相比使用 RAID 技术的集中性存储并没有显著的规模化优势。

因此，XSKY 设计了新一代全局缓存架构 XSpeed，并在 SDS V5 发布会亮相。

XSpeed 实现了集群中缓存介质的池化，可以整合全部缓存容量并以三副本冗余度提供高性能 IO 服务。整合后的全局缓存数据有更大的空间来进行回刷，在回刷过程中会使用 EC 纠删码技术和数据压缩功能，大幅提高集群的空间利用率。

新的架构变化，使得不管是 SSD 还是 HDD 故障，都可以只重构对应容量的数据，且 SSD 故障完全不会影响 HDD。

在 2021 年 V5 发布会后的 3 年时间里，大量的客户享受到了新架构带来的收益，得盘率提高 300% 以上，运维成本降低 94%。

从 XStore 到 XSpeed 的发展表明，在企业级存储系统中，存储软件架构是极其重要的。它可以决定系统的性能、TCO、扩展性和可靠性这些关键因素。

硬件技术的发展带来机会和挑战

在 XSpeed 发布之后的三年时间里面，硬件技术已经发生了非常大的变化。

在 2019 年，SATA/SAS SSD 还是主流，HDD 在持久化数据存储中正发挥着主要作用。PCIe 还停留在 3.0，存储 的 CPU 还是 8-12 Cores 为主，网络还是 10Ge。

但在短短几年内，技术的飞跃式进步已经颠覆了这一格局。特别是随着 AI 相关业务驱动，硬件平台迎来了大跃进。

不管是 x86 还是信创 CPU，单节点核数早已经跃升至 32 Cores，而今年的数据中心大赢家 GPU 也已经是主流算力，在网络上，基于以太网的存储网络已经 25Gb 起步，100Gb 也已经普遍使用。SSD 介质随着 PCIe 5.0 落地和颗粒层数工艺进步，拥有了更大的容量、更好的性能和更低的价格。

面对这些硬件技术变化和客户需求，我们开始思考如何设计面向全场景的分布式闪存存储系统，其中会有哪些新的挑战。

而随着 AI、大数据的发展，客户日益增长的存储需求中，一个突出的趋势是对高效存储解决方案的渴望。客户不仅需要通过分配更高性能的存储资源来处理更多任务，还追求更高的空间效率和完善的数据保护服务。

而现有的面向全场景的分布式闪存存储系统架构，很难完全满足需求：

• 可靠性较低：随着越来越低的性能延迟，应用实实在在享受到更好的存储性能所带来的好处，但更快的处理意味着对于存储可用性要求的提高。过去是 10 毫秒内的存储延迟，我们通常假设 10 秒内的节点故障规格可以接受，而在全闪化后，延迟降低到 100 微秒级别，之前秒级的异常规格就变得不可接受。但现有市场上分布式全闪产品中，仍然只提供长达数秒的故障切换指标。

• 性能服务水平不足：在不断迭代的 NVME SSD 和高速网络加持下，性能绝对值基本不再是挑战。反而是在规模化的全闪存里，在支持大规模高效写入数据和元数据更新情况下，长期的尾部延迟结果才能真正衡量存储性能服务水平。因为在堆砌大量 SSD 并基于高速网络后，SSD 的 GC （垃圾回收）以及网络偶发丢包等因素，导致的长尾延迟抖动，是应用性能体验的关键。因此，我们认为需要更关注 P99 延迟的稳定性，它才意味着真实的服务水平。

• 成本仍然过高：SSD 和 HDD 的成本剪刀差在过去 8 年没有发生根本性变化。用户仍然期望在数据量持续增长的背景下，能以适当的成本获得全闪存的巨大优势。如果在全闪存下，分布式存储还依赖三副本且不具备任何数据缩减能力，它并没有长期竞争力。

因此，如果在这三方面，我们如果不能很好去解决，只是有了一个高性能的分布式存储系统，是很难与集中式全闪相提并论，甚至在很多场景下，集中式全闪阵列借助 RAID 和压缩技术，会有更好的性价比。

因此，我们希望能够利用新的硬件变化来进一步推动分布式存储架构变革，来更好解决这些最新需求。而最好的办法，就是推出全新的架构来适应新时期的硬件和需求，也就是 XSKY 最新推出的“星海（XSEA，eXtreme Shared-Everything Architecture，极速全共享架构）”架构。

面向全闪数据中心的星海架构

星海架构是 XSKY 过去 8 年在存储技术领域，不断磨砺与创新的结果，它仍然采用软件定义的技术，以最新的标准存储协议和网络技术作为基础，并引入了三项技术创新点。

第一，星海架构采用了 Shared Everything （全共享）模型来实现全共享数据存储，使得每个节点都能直接访问所有 SSD，来提高了数据访问速度和灵活性；

其次，星海架构采用了单层闪存介质的设计，来专门面向 TLC NVMe SSD 进行优化，可以减少硬件配置复杂性；

第三，星海架构在 IO 路径中采用端到端的 NVMe 实现，不仅存储系统对外提供 NVMF 协议，内部复制网络和 IO 处理也同样采用 NVMF 技术，确保 IO 路径的高效处理。

Shared Everything 模型是新架构基石

在过去十年乃至更久的时间里，Shared Nothing 模型因其物理资源隔离的能力、易于扩展和管理的特点，在大规模存储解决方案中被广泛认可和应用。从超融合存储到分布式文件和对象存储，再到数据库、数仓系统等领域，都在使用 Shared Nothing 模型。

然而，随着 NVMe 规范标准化和 100Gb 以上高速网络的普及，远程访问 SSD 的性能已经可以媲美本地访问。Shared Nothing 模型过去基于网络性能瓶颈的假设其实已经不再适用。

在面对新的可靠性、性能服务水平和成本的挑战，我们看到 shared nothing 模型的局限性：

• 性能扩展性的局限性：在 Shared Nothing 架构中，每个节点独立处理数据，而随着节点增多，为了维持分布式事务的一致性，带来了额外的软件复杂性和 CPU 消耗，并可能导致写放大。这样的开销限制了扩容的收益，在全闪存系统里，这种瓶颈更为明显；

• 资源利用浪费：在 Shared Nothing 架构中，资源的独立性限制了灵活性，使得各节点资源无法统一利用。例如，在处理高负载时，每个节点必须配备足够的硬件资源，导致规划系统时需要进行提前预留，在大规模部署中，会造成更大的浪费。

• 服务质量：在 Shared Nothing 架构中，故障检测和响应机制常常缺乏业务层面的敏感度。一旦发生故障，节点间需要进行复杂的一致性协商，导致故障切换时间过长。在系统出现亚健康状况时，这种机制会更加脆弱，故障处理过程难以迅速有效地进行。

• 局部视角问题：Shared Nothing 架构将每个节点划分为独立的单元，这种划分会导致无法实施大比例的 EC 纠删码，数据恢复和后台 IO 操作也难以全局优化。结果是，这些操作可能占用过多带宽，影响正常的客户端 IO 请求，进而影响整体业务的稳定性。

为应对 Shared Nothing 模型的挑战，星海架构使用了 Shared Everything 的设计，借助最新硬件平台的支持，这一架构可以克服 Shared Nothing 限制，来显著提升性能、资源效率和整体服务质量。

从上图可知，BlockServer、FileServer 和 ChunkServer 作为一组无状态容器分布在多个服务器集群中，它们通过共享内存直接交互，无需通过网络。而 IOServer 会将所有 SSD 通过 NVMe-oF 协议暴露出物理卷，使得任意 ChunkServer 在启动时，都可以挂载集群里的所有 NVMe 卷。这意味着不管是块设备还是文件系统，都可以直接获得任意位置的 SSD 数据。

这样的架构设计在性能可扩展方面具有明显优势。

首先，随着集群的横向扩展，由于每个节点无需跟其他节点的服务进行通信，可以消除不必要的数据转发，实现了网络的线性扩展能力。

其次，存储容量和性能，可以与 CPU、内存资源解耦，为不同业务场景提供更高的灵活性和资源利用率。例如，在备份场景，可以使用较低的 CPU 和内存资源；在 OLTP 场景中，则可以部署更高频率的 CPU 以实现更低延迟的 IO 处理。

第三，Shared Everything 架构设计赋予了每个节点全局数据读写能力。这意味着，我们可以实施大比例的 EC 纠删码，如 20+4，大幅提升空间利用效率。也可以更好的进行全局流控、后台任务调度，并根据全局 SSD 的状态进行磨损均衡。

此外，在关键的可靠性方面，Shared Everything 架构显著提高了故障恢复能力。无论是节点、网络还是 SSD 故障，其他节点都能迅速接管，保证业务连续性。这是因为每个服务都可以访问到所有数据，而不用在故障时等待数据复制或状态同步。这样的设计可以在 100ms 内实现故障切换，为存储提供高可靠性保证。

面向 TLC SSD 优化，单层闪存介质设计

在定义存储池的构建方式时，星海架构挑战了传统的模式，该架构放弃了常规的缓存加数据盘的组合，转而采用了单层闪存介质构建，其背后是反映了 XSKY 对 SSD 技术和传输标准演进的深入理解。

从 PCIe 3.0 到 4.0，再到如今的 5.0，我们见证了 NVMe SSD 在带宽吞吐方面的巨大飞跃。这意味着，现在我们可以用更少的 PCIe 通道实现更高的数据传输速率，使得 TLC 型 NVMe SSD 持续具备最好的性价比。

因此，星海架构采用单层 TLC NVMe SSD 来构建存储池，简化集群的存储硬件结构。

在使用方式上，我们利用 Append Only 方式实现数据写入，减少了写放大现象。并通过精心设计的空间布局，在单个 SSD 上实现了缓存和持久存储的双重功能。这些技术使得在没有专用缓存介质情况下，确保足够的性能稳定性。

根据 XSKY 的评估，在常规的混合读写业务场景中，相比分层缓存方式，单层闪存可以显著降低介质成本 20%以上。

同时配合 Shared Everything 架构模型带来的全局 EC 和压缩功能，使得集群的得盘率超过了 100%。就如去年，著名的 HCI 存储软件 vSAN 8.0 发布，正式宣布其全闪架构从 OSA 演变为 ESA，而 ESA 架构的关键设计就是采用了 Single Tier。

最大化硬件卸载，端到端的 NVMe

在端到端 IO 路径上，星海架构采用了标准 NVMe over Fabric 协议进行构建。

过去，在存储系统中，SCSI 协议一直占据主导地位。然而，SCSI 在并发处理能力和协议效率上存在约束。相比之下，NVMe 协议以其更高的并发性和较低的协议开销脱颖而出，目前已得到主流操作系统内核的原生支持。

星海架构不仅在存储访问方面采用了 NVMe over Fabrics 协议，而且在存储内部网络中也全面实施了该协议。这意味着所有存储节点都可以通过 NVMe over Fabrics 高效地访问每一个 NVMe SSD，从而避免了存储协议转换所带来的额外开销。

在端到端的 NVMe I/O 路径上，也采用了高效的 Polling 模式处理每个 I/O 请求，并通过 NUMA 绑定优化了不同服务的内存访问效率。最后实现低至 100 微秒的端到端延迟。

此外，星海架构持续适应硬件技术的演进，通过与领先的智能网卡厂商合作，利用智能网卡来进行 NVMF 协议的硬件卸载，在存储设备上实现从计算节点到存储的高效数据传输。

3 个 100 的架构收益

通过 shared everything、单层闪存介质和端到端 NVMe，星海架构可以实现 3 个 100：

• 在 40%-60%负载下实现 100 微秒的超低延迟；

• 通过 EC 和数据压缩技术实现超过 100%的存储系统得盘率；

• 在面对慢盘、亚健康网络问题时，能在 100 毫秒内快速切换，以保证系统的稳定运行。

这 3 个 100 的实现，不仅是技术的飞跃，也直接回应了前文提出的的三大主要挑战。因此，星海架构能够实现更高的可靠性、更优异的性能服务水平，并有效控制成本。

成本优先架构，带来场景优势

基于星海架构，XSKY 已经发布了星飞软件和星飞 9000 一体机全闪存储，这也是业界首款采用全共享架构的分布式全闪主存储。

如上图左侧所示，当前数据中心存储结构通常由高性能 NVMe DAS、全闪存阵列、容量型存储及归档存储构成。在行业和用户共同的推动下，过去十年我们见证了容量型存储领域分布式架构的崛起，根据  IDC 报告，分布式架构的市场份额在容量型存储持续增长。

而星飞产品有更大的野心，希望能横跨 NVMe DAS、全闪阵列和容量型存储的使用场景，为了验证这一定位，我们精心设计了三个实际场景的测试项目，分别与合作伙伴和客户一同展现星海架构的领先性和创新成效：

• 第一个是面向 OLTP 数据库场景，与本地 NVMe DAS 对比测试

• 第二个是面向 OLAP 场景，与集中式全闪阵列对比测试

• 第三个是在公有云上与高性能网盘的对比测试

 NVMe DAS 对比测试

过去数年中，很多用户反馈随着 NVME SSD 价格下降，越来越多用户在高性能应用场景都选用本地 NVME SSD 提供存储能力，但随着 SSD 的规模化使用和老化，存储介质的运维实际上是很大挑战，硬件亚健康问题、SSD 容量和性能弹性需求都成为挑战。

XSKY 联合了 Intel Lab 做了面向数据库场景的本地 NVMESSD 与星飞产品的对比测试，从性能、TCO 方面进行评估。

根据英特尔中国区解决方案部技术总监高丰的介绍，经过双方联合测试，借助 QAT 加速数据压缩/解压缩的强大能力，与 NVMe DAS 配置相比，星飞 9000 获得相同延迟的同时，还可以实现更高的空间利用率，并大幅降低运维成本，提升业务连续性。

在测试中，采用了 OceanBase 数据库运行在计算节点上，占用 48C 和 192GB 内存。同时在计算节点上配备了两块  NVMe SSD，通过 RAID1 来提供本地盘。

而星飞存储系统运行在配置 16 块 1.92TB NVMe SSD 的三节点上，计算节点通过 2*100Gb 的网络访问存储。

三节点的星飞系统使用 EC 2+1 的冗余策略，启用了 QAT 压缩能力，并提供 NVMe over RDMA 协议的卷供 OceanBase 使用。

测试用例我们选择了 SysBench 中的 Point Select，ReadOnly，WriteOnly 和 ReadWrite 四种用例，针对每种用例，我们分别执行从 32 并发到 1024 并发的不同压力，主要关注 QPS 和 P95 延迟指标。

从下图中可以看到，橙色块是星飞系统的性能，另一个是本地 NVMe SSD 提供的性能。

从 32 到 1024 并发，星飞性能和本地 NVMe SSD 基本平分秋色，唯一的不足是在 1024 并发的情况下，星飞系统的延迟是本地 NVMe SSD 的 2 倍，后续我们会进一步探究问题原因。该结果也证明了星飞系统实际上已经达到了本地 NVMe SSD 的延迟水平，软件损耗非常低。

另一方面，在存储效率上，星飞通过 EC 加压缩的能力，在 1TB 的数据库空间里，实际只占用了  880GB 的容量，压缩比达到了 1.8，而使用 RAID 1 的本地 NVMe SSD，则占用了 2TB 的实际空间。相比而言，星飞系统只需要 44% 的本地 RAID1 方案的容量空间。再加上本地 NVMe SSD 的长期运维成本，星飞的图形化管理运维，以及闪存全局均衡，实际 TCO 下降到本地 NVMe SSD 的 30%。

集中式全闪对比测试

在银行业，数据库跑批是相当常见的一项业务。过去该业务一直运行在集中性存储厂商的全闪阵列上，江苏省农村信用社联合社（简称：江苏农信）也是如此。

随着业务规模的增加，集中全闪架构进一步制约了江苏农信云的弹性服务能力，因此江苏农信也开始考虑在分布式存储上进行数据库场景评估。

在面向 OLAP 数据库场景的集中式全闪对比场景中，XSKY 与江苏农信进行了联合测试。

对银行场景来说，高并发低延迟要求更严格，对账差 1 分钱都不会过夜，晚上跑批对账，做不到高性能低延迟，可能当天的账就无法按时对完，统计核算报表就没法出。因此，做完这些基准性能测试后，在星飞环境测试了一下跑批业务，数据库跑批业务主要有以下过程，分别是解压、数据入库、数据仓库转换和数据集市处理。从这里可以看到，星飞相比混闪集群的运行时间降低了 79 分钟，而相比  IBM FS9200 基本持平，在数据集市处理阶段阶段表现更好。

通过这次测试，江苏农信坚定了上云信心。过去受限于性能，集中存储承接数据库跑批业务，分布式主要面向非数据库库业务，通过本次测试，新架构的高得盘率使得江苏农信对全闪分布式数据中心有了更多的信心，未来考虑建设大规模全 NVME 星飞云存储，进一步提升云平台存储服务能力。测试结果也验证了星飞产品可以与集中全闪阵列做到相当的性能时延，且规模化闪存池化后提升资源利用率，降低成本。

公有云高速云盘对比测试

公有云高性能云盘，实际上早已已成为众多互联网业务架构中不可或缺的部分。这些云盘不仅提供了弹性的存储能力，还满足了业务对高性能的迫切需求。但有一个不争的事实是，越来越多的客户在关注多云化 IT 架构，特别是数据密集型业务的下云。

对于星飞而言，我们不仅希望能在云下提供高效存储能力，也希望在公有云上也能支持，给客户带来一致的存储体验。

我们与某互联网客户成立了联合项目组，针对星飞产品在公有云环境中的性能和成本效益，我们进行了一系列详尽的对比测试。

我们选择基于 AWS 云进行测试，使用了高性能的虚拟机配置作为客户端节点，启动了 3 个适合作为存储配置的虚拟机作为存储节点，该配置会挂载 4 个 7500GB 的本地 SSD，并部署了星飞系统，创建了 EC 4+2:1 的存储池并提供 12 个总可用容量为 116TB 的 NVMF 卷。具体配置在这里就不赘述了。

在每个客户端节点上利用 NVMe over TCP 方式挂载分别挂载了 4 卷。我们通过简单性能压测，基本看到，这样三节点星飞大约提供 615K IOPS 的读写 IOPS。

io2 是 AWS EBS 的高性能云盘，可以按需灵活提供 IOPS 和容量，其中容量价格为 0.125GB/月，每 IOPS 价格为 0.065。为了跟星飞提供的容量近似，我们创建了 16 个总容量为 116TB 的 io2 类型卷。

在性能基准测试中，基于同等容量的 16 个 LUN，我们主要关注单卷随机 4KB 延迟和集群整体延迟对比。

从性能对比中，可以看到在一致的 IOPS 性能下，AWS EBS io2 和星飞卷实现了同等数量级的延迟。另外由于星飞运行在 AWS 虚拟网络上，并使用 TCP/IP 协议通信，延迟高于云下的 RoCE/RDMA 网络，导致延迟高于 AWS EBS io2。针对该问题，后续计划支持公有云的 RDMA 网络方案，来显著降低延迟，接近或持平 AWS EBS 延迟。

在 TCO 对比环节，我们分别计算了 AWS 星飞系统和 AWS EBS io2 的购置成本。

星飞全闪总共提供 615K 的 IOPS，相比 EBS io2 预留 615K IOPS 的方案降低 87% 的成本。这个差距是巨大的。

我们都觉得这样的成本对比可能并不公平，因为星飞系统提供的性能 IOPS 超出了大多数工作负载所需，在公有云使用中，用户通常只会申请所需的 IOPS 来节约成本。因此我们将 AWS EBS io2 预留 IOPS 降低到 61K 来接近实际情况，但即使这样，依然能降低 62% 的 EBS 成本。

通过这次测试，我们看到星飞产品，不仅可以面向最新的硬件技术设计，也能够运行在公有云上，提供跟高性能云盘近似的性能。除了 AWS 外，后续星飞明年计划支持国内的 Top3 公有云平台。

这次测试我们达成了这些目的：

1.  首先，星飞可以提供一致的数据服务，帮助实现多云化的 IT 架构，统一管理和运维技能；

2.  其次，相比公有云网盘的可用性承诺，基于公有云的星飞产品可以提供更高的冗余度和可靠性保证；

3.  最后，利用低廉的快照成本和数据缩减能力，星飞产品至少可以降低 50% 以上的 TCO。

通过这些收益，我们认为星飞确实能够帮助用户一起实现云上云下，一致体验，成本节省一半。

面向未来全闪数据中心的架构答案

综上所述，无论从存储系统的架构演进，还是目前硬件产品的发展新趋势、市场和应用的需求，以及基于星海架构的星飞产品的验证结果而言，星海架构以及基于星海架构的全闪存储，是最值得考虑的选择。

作为行业的领先者，XSKY 致力于通过创新的星海架构，推动全闪数据中心技术的发展，满足日益增长的数据存储需求。