[设计]首次揭秘，面向核心业务的全闪分布式存储架构设计与实践( 四 ) |固态硬盘|云计算|大数据|

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

本文插图
分布式存储是依赖于网络的， NeonSAN 采用高效的 RDMA 网络，将业务与数据网络分离，存储网络中的 IO 不会对业务网络造成压力，避免资源的竞争。
NeonSAN 采用端到端的RDMA网络设计，无论是存储内部节点之间还是存储服务和客户端之间都采用了 RDMA 网络。
RDMA 网络的内核旁路（kernel bypass）与零拷贝的特点让网络中的单个 IO 延迟变得非常低，基于异步的消息机制能让多个 IO 的并发显得效率更高。
NeonSAN 分布式全闪跑分及场景实践
上面介绍了 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 分布式存储方案的优势主要体现在以下几个方面：