首次揭秘，面向核心业务的全闪分布式存储架构设计与实践

当今是云计算、大数据的时代，企业业务持续增长需要存储系统的 IO 性能也持续增长。

机械盘本身的 IOPS 一直徘徊在数百的级别，为了提高传统存储的性能，有些存储厂商加了缓存层，然而目前应用正由单一走向多元化，导致 IO 特征无法预测，缓存也难以发挥作用。

机械盘依赖盘片的旋转和机械臂的移动进行 IO，目前转速基本达到物理极限，所以机械盘性能一直徘徊不前，无法满足企业核心业务对于存储性能的要求。SSD 作为一种全新的闪存介质开始进入企业的数据中心，并逐渐成为应用的主流。

企业对存储的要求是性能和容量要满足业务的需求，并且价格合适。

首先从容量上来看，目前主流的 SSD 单盘容量已经达到 8T，完全满足企业各类应用的需求。

其次从性能上来看，一块 NVMe SSD 的性能大概在 100 万 IOPS，相当于 5000 块 7.2k SATA HDD 的性能。在延迟上，一块 NVMe SSD 的延迟大概在 10 微秒，是机械盘的 200 分之一。

最后从单盘的价格来看，SSD 比机械盘要贵，但是从单个 IO 的成本来看，SSD 的性价比远远高于机械盘。最近英特尔推出了 96 层 QLC NAND 颗粒，正在研究 114 层的 NAND，随技术进步，SSD 性价比会进一步提高。

总之，全闪能够满足企业核心业务对存储的高 IOPS、低延迟的要求，并且可以降低 TCO，可以说企业核心存储选择全闪是大势所趋，所以厂商要面向全闪来设计存储系统。

如上图所示，目前业界基于全闪的存储方案主要有以下三种：

第一种是传统方式。

用 SSD 做缓存或者直接用 SSD 盘替换掉传统存储中的机械盘，这种方式无法发挥全闪的性能。

因为传统的存储诞生在机械盘的时代，是面向机械盘设计的。而当前 NVMe SSD 的性能已经达到 100 万 IOPS，与机械盘有了天壤之别。

传统存储受限于底层架构的设计，并没有针对全闪进行有效的软件改造或者优化，即使采用了全闪的配置，也无法发挥 NVMe SSD 的性能，传统存储方案已经不再适合承载高速闪存介质。

第二种是全闪阵列。

全闪阵列的性能相比传统方式有了很大提升，可以满足当前业务的要求。

全闪阵列通常采用专有的硬件，导致其成本高昂。另外一方面，传统阵列一般采用双控制器互为备份，纵向扩展无法提升性能，横向扩展受限于控制器的数量，一般情况下可以扩展到 8-16 个，导致其扩展性很差，灵活性也不够。

第三种是全闪分布式存储。

分布式存储是通过网络将存储节点联系在一起，以集群的形式提供服务。

首先，它采用通用的 X86 硬件，使硬件标准化，可以降低 TCO。

其次，扩展灵活。集群中每一个节点都具备存储和计算能力，随着节点的增加集群的容量和性能得到线性扩展。无中心设计使集群不易形成瓶颈节点，理论上可以无限扩展。

第三，针对 NVMe SSD 进行特殊的设计和优化，性能强劲。

另外，随着 25G、100G 网络的普及和 RDMA 网络低延迟的特性，使得分布式全闪的跨节点扩展不再是瓶颈。在全闪存和高速 RDMA 网络的加持下，分布式全闪架构已经成为企业核心业务的理想之选。

接下来介绍 QingStor NeonSAN，这是一款面向核心业务设计的全闪分布式块存储，由青云QingCloud 自主研发，打破了传统存储的容量与水平扩展的瓶颈，性能可以媲美全闪的中高端存储阵列。

NeonSAN 也是为云而生的分布式存储，原生适配虚拟化、大数据、容器等多种应用生态。

首先给大家讲讲 NeonSAN 名字的由来：名字的后半部分是 SAN，SAN 代表了产品的形态，Neon 是元素周期表里面氖的代号，是一种惰性气体，具有有极高的稳定性，所以 NeonSAN 的名字寓意着这是一款稳定的企业级存储产品。

NeonSAN 核心模块由数据层和控制层组成，此外包括前端接口与运维管理工具层。

NeonSAN 核心模块采用并行流水线技术，设计了全闪存储系统的资源调度系统、内存管理系统、元数据管理系统、RDMA 网络收发系统等，打造高可用、高可靠、高性能、扩展灵活的全闪分布式存储。

NeonSAN 提供 9 个 9 可靠性，单卷性能达到 10 万 IOPS，最小延迟小于 90 微秒。

在扩展方面，NeonSAN 可以扩至 1024 节点，并且容量和性能随节点的增加而线性增长。

NeonSAN 的基本架构是由 Zookeeper 服务、元数据服务、管理服务、存储服务和接入服务五部分构成。

Zookeeper 提供集群的发现服务；元数据服务用来记录集群中的元数据，如节点信息、SSD 的信息、卷信息等；管理服务提供集群的管理功能，如节点的上线、创建卷等。

数据存储服务用来给客户提供具体的 IO，它承载业务发来的 IO 请求，采用对等的设计，每个存储节点的地位是相等的，都可以提供 IO 服务。

对等设计可以保证集群的某一个节点发生故障时，其他节点能够接替故障节点继续服务，保证业务的连续性，同时为集群的容量和性能线性扩展提供基础。

接入服务，第一个模块是 QBD 内核驱动，在 Windows Server 和 Linux Server 上都有对应的版本，它可以让服务器以使用本地盘的方式使用 NeonSAN，上层业务不需要做任何改造就可以对接 NeonSAN，非常方便。

第二是模块是 QEMU，可以为虚机提供云硬盘。

第三是模块是通用的 iSCSI 接口，可以为 VMware 等虚拟化平台提供存储服务。

此外，NeonSAN 还提供高速的 NVMe-oF 接口以及 CSI 接口，为容器提供持久化的存储服务。

接下来谈谈 NeonSAN 的网络设计如何满足高可靠和高可用。

NeonSAN 的网络分为两部分：前端业务网络和后端互联网络，采用两个前端交换机和两个后端交换机，组建高可用网络。（交换机使用普通的以太网交换机就可以，不需要 FC 交换机这类昂贵的设备。）

每个 NenonSAN 节点配备双网卡，每张网卡有两个网口，分别连接到后端交换机和前端交换机，假如交换机 A 发生故障就会影响到 NeonSAN 1、2、3 节点的网卡 A，凡是通过这三个网卡进行交互的业务也会受到影响。

此时 NeonSAN 节点就会自动把网络流量切换到网卡 B 上，走交换机 B，保证整个集群网络的可用性。同理，当网卡发生故障时，整个网络仍然是高可用的。

NeonSAN 的数据可靠性及可用性是通过副本机制来实现的。

在 Linux 服务下看到块设备，或者在 Windows Server 下我们看到一张盘，对应到 NeonSAN 集群里，就会把这个盘切成一片片的 Shard。

如图所示，有红、黄、绿、紫这四个片，每一片都会有三副本，分别存放在不同的节点。任何一个节点上的数据损坏，都不会导致数据的丢失。可用性也是同样的，如果节点 1 不能提供服务，节点 2 或 3 可以继续提供服务，保证整个集群的可用性。

NeonSAN 的数据写入是三个副本同时写入，保证数据间的强一致性，数据的读取是从主副本读的。数据的副本可以按卷进行灵活的配置，在一个集群中既可以有单副本的卷，也可以有两副本的卷，还可以有三副本的卷。

NeonSAN 支持精简置备和全置备，一个集群可以同时存在精简置备的卷和全置备的卷。

我们通过一个例子看看 NeonSAN 强一致性写过程中的 IO 路径。

首先，客户端发 IO 给三副本的主副本节点，当主副本节点收到 IO 请求后会同时做两件事：一是把 IO 请求发给它本地的 SSD，同时也会把请求发给两个从副本，当两个从副本 IO 完成以及本地的 IO 也完成，就是三个 IO 同时完成后才会返回给客户端写成功，实现强一致三副本的写入。

NeonSAN 是一个面向全闪的分布式存储系统，针对全闪有哪些特殊的设计？

首先， NeonSAN 采用了极短 IO 路径，这是可以提供卓越性能的根本。

NeonSAN 只要 3 步就可以完成一个 IO，当客户端的 IO 发到存储节点后，存储软件做完处理后直接发给本地的 SSD。

业界其他的分布式存储中，却要经历很多步骤：先经过存储软件的处理，再发给本地文件系统，还要写日志，某些系统还需要再经过缓存，最后才能落到 SSD，这个 IO 路径是非常长的。（简单来说就是很慢）

NeonSAN 采用自研 SSD 管理模块，直接管理本地裸设备，不依赖本地的文件系统，不需要日志，也不需要 Cache，极大精简了 IO 路径，从而让延迟减少到最低，接近于 SSD 延迟的量级。

接下来讲讲 NeonSAN 并行流水线处理的设计。

传统机械盘只有 1 个队列，深度是 32，NVMe SSD 一般盘有 128 个队列，每个队列的深度是 128，还采用传统的软件设计，显然 NVMe 是处于饥饿的状态，无法发挥队列和深度优势。

NeonSAN 采用并行流水线，将 IO 进行拆分，拆分成接收、调度和落盘。

举个例子，在机械盘的年代超市只有 1 个收银台，只能排 1 队，但是到了 NVMe SSD 时代，超市有 128 个收银台，如果我们还排 1 队就对资源造成极大的浪费，所以需要采用多个 IO 队列并行 IO，充分发挥 NVMe SSD 本身的性能，提升 SSD 的使用率。

在微秒的 SSD 时代，操作系统逐渐暴露出一些问题，比如低效 CPU 核心调度和内存资源的竞争，以及调度时的切换等带来了巨大的延迟。

在高并发的压力下，多核心 CPU 的竞争与不合理的调度成为性能的瓶颈。NeonSAN 专门设计了资源调度引擎，避免由于调度问题和内存争抢问题带来的延迟开销。

首先，在网卡上我们分配专门的接收与解析 IO 流水线，针对 IO 调度流水线我们给它分配了独享的 CPU，避免调度流水线来回切换产生不必要的上下文开销，做到专门的 CPU 服务专门的流水线。

在内存方面，在系统软件启动时一次申请所需内存，根据不同流水线需求的多少按需分配给接收与解析 IO 调度、数据落盘等流水线，避免在 IO 过程中频繁申请与释放，带来的访问页表、内存锁等额外开销及内存碎片问题。

资源调度引擎保障了 NeonSAN 在获得高效 IO 的同时将延迟控制在很低的水平。

分布式存储是依赖于网络的，NeonSAN 采用高效的 RDMA 网络，将业务与数据网络分离，存储网络中的 IO 不会对业务网络造成压力，避免资源的竞争。

NeonSAN 采用端到端的RDMA网络设计，无论是存储内部节点之间还是存储服务和客户端之间都采用了 RDMA 网络。

RDMA 网络的内核旁路（kernel bypass）与零拷贝的特点让网络中的单个 IO 延迟变得非常低，基于异步的消息机制能让多个 IO 的并发显得效率更高。

上面介绍了 NeonSAN 的基本架构与面向全闪的特殊设计,接下来看看 NeonSAN 的真实性能表现。

从 E 企研究院的测试结果，可以看到：在两个客户端压力下，随着卷的增加，NeonSAN 集群提供的性能线性增长，延迟几乎不变。

以 4K 写为例，单个卷的 IOPS 是 13 万多，4 个卷的 IOPS 增加到 47 万，接近线性增长；单个卷的延迟是 0.943 毫秒，4 个卷的延迟基本没什么变化。

NeonSAN 提供了一个智能运维系统，可以通过可视化的图形界面实现存储集群的操作和配置，提供对业务资源的监控与审计等。

此外，NeonSAN 提供对闪存介质的监控，比如按预留空间、使用寿命等，可以提前预警，让用户制定合理的扩容规划。

NeonSAN 的数据均衡与恢复设计也非常有特点。大部分的存储系统一旦扩容就立刻开始数据的均衡，NeonSAN 扩容完成后，可以选择业务低峰期或者用户需要的任意时间点进行数据的均衡，也可以选择不均衡。

在某些场景下，数据的均衡的是没必要的，比如原来集群的容量用了 70% 或者 80%，新扩容的节点之后，业务的新 IO 就会落到新节点上，不需要再去搬迁原有节点上的数据。

某些分布式存储系统，当集群出现故障后，就会立刻开始进行数据恢复。如果此时恰好是业务的高峰期，数据的恢复势必会和正常的业务 IO 争抢资源。NeonSAN 对于数据恢复是可控的，用户可以选择在业务低峰期进行数据恢复。

NeonSAN 作为企业级的分布式块存储，应用场景比较广泛，除了上面提到的为 Oracle 等企业核心数据库提供共享存储之外，还可以为业界主流的虚拟化平台（VMware、OpenStack、Hyper-V等）提供数据盘，也就是云主机的云硬盘。

同时，NeonSAN 也可以用作物理机的数据盘，为大数据分析和计算提供大容量的存储，为容器应用提供持久化的存储。

接下来看一个金融用户的应用案例。

在采用分布式架构之前，用户采用 Oracle SuperCluster Solaris 平台，面临的问题是采购与维保费用昂贵，且扩容复杂，无法快速适应业务发展的需求。

于是客户把视角转到了基于 X86 计算与存储分离的架构，采用三节点全闪配置的 NeonSAN 作为存储节点，配置三副本用于 Oracle 数据库存储卷，提供较高层次的故障保护。

经过了近二年多时间的运行，NeonSAN 分布式存储方案的优势主要体现在以下几个方面：

首先，采用计算与存储分离的全分布式架构后，海量的数据压力分散到了多个并发存储节点，系统性能、吞吐量按照线性扩展。

其次，全闪的存储节点之间采用 RDMA 互联，性能提升 100% 以上，存储系统提供负载均衡机制，有效避免单点性能瓶颈。

由开放的 X86 平台取代了传统数据库一体机与与集中式存储设备，大幅缩短了存储系统的建设与扩容周期，有效满足业务数据量激增的扩容需求，同时大幅度节省采购、维护与运营成本。

NeonSAN 诞生在全闪的年代，是为全闪而生的分布式存储，提供高可靠、高可用，性能卓越的存储服务，其丰富的接口，可以承载数据库等传统应用，原生适配虚拟化、大数据、容器等多种应用生态，服务云时代高效的数据存储和管理，

NeonSAN 具备提供丰富的企业级特性，基于同步及异步的数据复制可以灵活构建各类灾备和双活解决方案。经过大量企业客户核心业务的长期验证，NeonSAN 是一款真正可以承载企业核心业务的全闪分布式存储。