高性能软件定义存储的设计与实现思路

随着Big Data、 AI、IoT等业务的迅猛发展，传统的存储面临着越来越多的挑战。首先，横向扩展能力有待提升。近些年，需要IT基础设施进行处理和存储的数据量以指数级的速度增长。而传统存储的Scale-up的扩展能力越来越难以满足快速增长的数据的存储需求。其次，存储系统管理复杂。传统的SAN需要专门的FC传输协议，以及每个SAN厂商有自己独有的管理与运维方式，导致需要专门的存储运维人员。第三，无业务中断地运维能力弱。现在大量的应用要求7*24*365无中断的运行，几乎没有留给运维的时间窗口，因此需要存储系统具有业务无中断地运维能力。

因此，软件定义存储应运而生，很大程度上解决了传统存储的问题。同时，它还具有新的优势：1) 除了无缝地对接传统应用以外，软件定义存储更好地支持云原生应用；2）内建支持与私有云，公有云及混合云的对接。

目前在软件定义存储领域，Ceph在开源领域，以其统一的存储接口，无中心节点的架构收到广泛的欢迎，几乎成为事实上的标准。但很多公司由于各种各样的原因，会决定自行研发和实现一套存储系统，而性能，数据分布以及元数据管理是其中的核心问题。以下是笔者在这方面的一些思考和经验总结。

缩短I/O路径

一个典型的Ceph（采用FileStor为存储后端）的I/O路径如下：

用户请求->RBD->RADOS->TCP->OSD->本地文件系统->本地块设备

即使Ceph采用了BlueStor作为存储后端以后，也只是减少了本地文件系统这一路径，而直接从OSD到本地数据块。

那么，对一个追求极致性能的存储系统来说，可以考虑采用RDMA技术，把存储路径缩短为：用户请求->RDMA->存储守护进程->本地块设备。采用RDMA技术带来的额外好处是减少CPU的消耗

采用最终一致性

Ceph的目前是强一致性，这导致在默认三副本的情况下只有三个副本全部写完，写操作才完成。当然，这对于要求数据强一致性的场景下是必要的，但也牺牲了性能。但是强一致性带来两个负面影响：第一、只有三副本全部完成写操作的情况下，用户的写操作请求才被认为是完成。如果采用最终一致性的话，可以在只有一个副本完成写操作时，就认为用户的写操作完成，而不用等待三个副本写操作完成后才认为写操作完成，从而提高写操作的性能。第二，某些故障情况下写操作的时延上升。比如某一存储节点故障或者网络中断而Ceph-monitor还没有判断出该节点已经故障的情况下，写副本依然被发往该节点，只有发现副本的写操作失败（超过等待时间time-out值），副本写操作才会失败，重新选择新的副本节点。Ceph的这种机制会导致故障情况下某些写操作的时延大幅上升。

因此，由于需要对某些对强一致性要求没有那么高的业务，可以考虑采用最终一致性的方式，数据的一个副本写完后立刻返回，从而提高写操作的性能。

并发进行副本的写操作

Ceph在三副本的情况下的写操作顺序如下：1）客户端写数据对象到指定PG的主OSD；2）主OSD通过CRUSH map决定第二个和第三个副本的OSD；3）数据对象写入到第二个和第三个副本的OSD；4）等所有的副本写操作成功后，返回客户端，写操作成功。

Ceph现行的写操作的机制的问题是 上述两个花费时间的操作1）和3）是串行的。我们可以考虑在客户端发送写数据的请求时，SDS系统把数据转变为对象后，立刻决定三个副本对象的位置，并且同时写入三个副本。

可配置的数据分布

在软件定义存储或者分布式存储领域，关于数据分布，大致可以分为两类：1）使用一致性哈希算法或者类似算法来决定数据存储的物理位置。Ceph以及华为的FusionStorage采用该方式。2）由控制节点决定根据各节点的剩余容量，存储空间，网络速度，CPU等来决定数据的存储位置。Google的GFS和HDFS采用该方式。 Ceph采用的方式1），其优势是规则透明而且固定，进行自动的负载均衡，无需专门的维护，但其劣势是需要计算哈希值，并且在节点故障时需要考虑数据均衡，数据迁移等策略无法灵活配置。采用方式2）虽然需要专门的维护元数据，但好处是可以进行灵活的配置，并决定数据的物理位置，故障恢复时可以灵活指定迁移的目标节点等，防止数据风暴。

分散地元数据

在大规模的软件定义存储系统中，元数据服务器通常会成为瓶颈，因此总体的设计思路应该是尽量把各节点相关的数据下沉到各存储节点。一般的原则是，对于上层的整体逻辑架构，全局信息等由元数据服务器来维护，具体的每个存储节点中的数据的物理位置信息及状态等由各存储节点来保存，从而尽可能的减少元数据服务器的访问次数，降低元数据的工作负载。

设计与实现一个软件定义存储系统是一项复杂而耗时的任务，上述5个点只是存储系统核心方面的一部分。希望对各位有所有帮助和启发。