随着IOT、大数据、移动互联等应用的暴涨，产生的数据也越来越多，整个存储市场总量也逐年增长，预计到2021年分布式存储会占到整个存储市场的50%，到2027年，分布式存储会占到整个市场的70%。Ceph则是典型的分布式存储软件的代表。

杉岩数据作为一家软件定义存储商，软件的发展与硬件的结合密必不可分，与华为共建ARM生态是杉岩发展的关键着力点。目前，杉岩数据的对象存储MOS和块存储USP已完成在鲲鹏平台的适配工作，且可进行商用。

以下是杉岩数据云存储高级研发工程师刘亮奇在华为开发者大会中关于Ceph开发和应用方面的经验分享。

Ceph是什么？

在用户层面，Ceph对外提供的三个服务：

1、Block storage即（RDB块存储接口）：如同一个没有格式化的U盘，在第一次接入个人PC时，windows操作系统会弹出一个格式化的请求界面供用户选择参数，如比较重要的文件系统选项，有NTFS、exFAT等文件系统以供选择，格式化完成后的U盘才能进行创建目录、拷贝文件等操作；形象一点的概括：整个块设备可以看成一栋大楼的框架，在进入大楼工作生活前，需要对这栋大楼进行装修，即格式化。而大楼不可能只有一个人，所以需要物业进行管理，物业可以比作一个文件系统。

2、Object storage即（RADOS GW对象存储）：对象存储在大家的生活中也是接触较多的，例如我们平常使用的云盘；或者我们使用的智能手机都有云备份功能，都是基于对象存储的一种业务表现。所以对象存储是为了解决信息化时代海量不规则文件的存储问题。就如世界上没有两片相同的叶子，每个人都会产生不同的信息，如何解决这些独一无二数据的存储，对象存储就是提供了一种解决方法。

3、Flie system文件系统：把Ceph提供文件系统服务，类比成购买个人电脑的过程，DIY用户可能会买各种硬件、零件组装起来装上操作系统之后才能使用，而电脑商家还会提供一个已经预装好windows系统的整机供用户选择，用户购买之后接通电源开机后可直接使用。Ceph提供的文件系统服务也就类似于这样的一个整机，用户只需将对应的目录挂载到本地即可进行工作。

RGW：对象存储接口，使用这个接口服务需要配合一些客户端软件；当然了,手机上的云备份功能是因为手机操作系统已经内置了APP进行支撑，所以不需要再额外安装软件。

RBD：块存储接口，如果使用的是Linux系统，可以使用内核模块krbd直接在本地直接生成一个块设备供用户使用。针对Windows系统，则可以通过iSCSI协议，虚拟一块硬盘来供用户使用。

RADOS：再往下是整个Ceph集群的统一抽象层RADOS，即抽象的对象存储集群。它是上面的所有接口数据经过处理后都会以对象的形式保存在集群当中。同时RADOS还确保这些接口数据在整个集群中的一致性，而LIBRADOS，主要是访问RADOS层的接口库。

接下来是Ceph集群中一些比较重要的组件，如mgr，mirror等，这些组分布在集群中的各个服务器上，未在上图中体现。下面简略说明各个组件的职能：

MON：即monitor，可以认为是集群的大脑，负责集群状态的维护和元数据的管理。
MDS：元数据服务，它是为Ceph FS接口服务提供文件层次结构检索和元数据管理的，如果不需要Ceph FS服务，可以选择不部署该组件。
OSD：对象存储设备，这是整个集群中用户数据主要承载的终端设备，用户所有的数据读写请求基本上最终由OSD来负责执行。所以OSD的性能决定了整个上层业务的表现。OSD一般会绑定一个较大的存储空间，例如一块硬盘或一个硬盘分区；而OSD管理存储空间的本地存储接口主要有File Store和Blue Store。当然File Store还需要借助本地文件系统（比如XFS）来管理存储空间。而Blue Store则可以直接接管裸设备，这样就可以减少它的IO路径，以提高性能。

总体来看，Ceph是一个统一的分布式存储系统。它的设计目标是较好的性能，可靠性和可扩展性。这是因为从Ceph的架构来看，没有专门的缓存层，所以在性能表现并不是很理想。社区也针对这个问题一直在推动分级缓存(tier)功能，但这个功能还没有达到可生产的阶段;所以目前比较通用的做法就是在操作系统层面来缓存Ceph数据；如内核的通用块层使用dm-cache、bcache、enhanceIO等开源软件，在操作系统层面将数据缓存在一个较高速的设备(如SSD)，以此提高Ceph的性能。

Ceph现有架构与业务存在哪些问题？

1、Ceph数据与内核缓存的割裂问题。以BlueStore为例，它将OSD的元数据保存在RockDB中，RockDB又是运行在一个简化的文件系统(Blue FS)之上的，此时可以认为Blue FS的IO就是OSD的元数据，但对于内核缓存来说，它是无法感知OSD下发的数据是有元数据和业务数据之分的。

2、内核缓存无法区分OSD业务的热点数据和冷数据，比如用户配置比较典型的三副本存储策略，此时只有主副本数据才会为客户端提供读写服务，而从副本则直接不用缓存即可，但是内核层缓存是没法区分这种差异的。如果使用的是DM Cache，还会在内存中分配一个空间来缓存部分数据，这无还疑会浪费内存资源。

总体来说，内核缓存存在浪费Cache空间，还有Cache命中率不高，频繁刷新缓存导致缓存设备寿命缩短等缺陷。

有何解决方案？

在BlueStore下发IO的地方增加一个适配层，用来标记下发IO的类型，在内核缓存入口处增加一个适配层，用来捕捉OSD的IO类型，最后在内核缓存处理时，根据IO类型进行不同的写回、淘汰策略。

例如将三副本中的两个从副本用NOCACHE标签经过适配层随IO请求一起带到内核缓存里去，这样内核缓存就可以不缓存，直接写后备盘。同时可以将Blue FS的IO标记成元数据类型，让其在内核缓存更长时间的驻留。或根据用户业务需求，将用户有比较重要的，且读写频繁的数据，标为高等级，其他不重要的数据标成中或低等级，然后在内核缓存针对高等级数据采用和元数据一样的处理策略；这样就可以根据用户需求来执行不同的淘汰和回写策略。

BlueStore使用的是Libaio API接口来下发IO请求，此时需要一个IOCB结构体作为下发请求的IO参数，可以通过io_prep_pwrite函数生成iocb结构体之后，把io flag设置到IOCB的Flag结构体当中，作为io_submit的参数，一起提交至内核层；内核在VFS层时捕捉到Direct io时，将flag转换到通用块设备层的BIO结构体里面，比如BIO的bi_rw结构体里面，此时位于通用块层的内核缓存即可捕捉到上层业务标签。内核缓存可根据不同的标签执行不同的回写、分配策略，比如让元数据更久的驻留在缓存当中，或者让高等级的用户数据和元数据执行相同的缓存策略。

Ceph在ARM架构上面临的问题与挑战

华为鲲鹏处理器与Intel Xeon主要存在如下六个方面的差异：
1、ARM的跨片访问：主要反映在内存方面，（数据是估测值，非实测数据，不做测评）。ARM相对X86来说不占优势，所以后面的优化手段中有规避跨片numa的操作。

2、矢量运算：这方面未获取到鲲鹏的具体参数，以ARM的A76作为参考，从目前来看， ARM也是不占优势的。

3、物理核数：ARM先天就有物理核数上面的优势。

4、协处理器：即加速器，在加速器方面鲲鹏920有EC/RSA/zlib等外围协处理器，相对通用的X86 6148来说是较为丰富，这是鲲鹏920的优势。

5、内存操作：ARM采用的是load-store的微架构，简单地理解为：ARM在内存到内存之间的拷贝是需要CPU参与的，X86则可以直接做到不用CPU参与内存到内存间的拷贝。这是ARM微架构决定的。

6、功耗比：单论总体的功耗不太准确，毕竟功耗还跟启用的物理核数有关系。当然先进的工艺在可以降低功耗。如果论单个物理核的功耗比，ARM确实相对X86是有优势的。

基于鲲鹏平台的Ceph调优

针对鲲鹏平台的Ceph，目前有以下几种主流的优化方案：

1、针对跨片NUMA操作场景，限定进程运行在片内NUMA

针对跨片NUMA操作场景，采用将进程限定在片内NUMA上面，以Ceph为例，Ceph M及以后的版本提供一个OSD_numa_node参数，该参数可以限定整个OSD进程所运行的numa。如果使用的是其他版本的ceph，可以借助numactl和taskset这两个工具来实现限定进程运行在指定numa的功能。numactl需要在进程启动时进行设置，主要的参数有绑分配内存NUMA(–membind)、绑进程运行的NUMA（–cpunodebind），以及更细的，绑进程运行的物理核(–physcpubind)。Taskset较为灵活，可以在进程运行时进行设置。限定了NUMA之前，对应的硬件都尽量分配在片内的总线下面，比如网卡、内存、SSD等都尽量分配在对应片内总线下面，以避免跨片访问。

2、矢量运算短板借助协处理器补齐

矢量运算方面可以借助鲲鹏920的平台的加速器，华为有提供一些基础设施的接口文档，可以根据这些文档进行相应的适配；比如这里的纠删码运算(EC)，华为提供的接口文档有详细的设置和参数配置，需要在代码层面上进行适配，此时需要投入工作量，进行稳定性方面的测试。

3、增加进/线程数以及内存操作

利用鲲鹏在物理核上的优势，可以增加相应处理业务的进程或线程，针对业务繁忙的线程，可以把线程拆分成两个，分配到不同物理核上去。

内存操作方面，除了减少内存操作，华为还针对ARM微架构出了一个补丁，该补丁主要优化了内存方面的接口，可以去华为的基础设施网站上下载patch来提升性能。

此外，还有其他优化手段：

绑定网卡/SSD中断：必须先把irqbalace服务关闭，否则irqbalace服务会将绑定给重新均衡掉。
cgroup隔离业务：针对对繁忙的线程或者进程来说是比较有效的，主要是基于CPU cache考虑，如果CPU被切换到不相关的进程和线程的时候，会导致CPU cache刷新，致使命中率下降，CPU cache预读也会浪费内存带宽。同时进程CPU一旦被切出，就会导致整个流水线被清空/排空的，此时并发的指令数也会减少，所以对性能还是有影响的。主要还是在业务比较繁忙的时候对性能的改善比较大。
第三方库：主要是优化内存的分配和回收效率，有Tcmalloc和jemalloc可选，可以去Tcmalloc和jemalloc的网站去下载相关文件进行阅读。

接下来，为大家介绍三种Ceph性能观测工具，如下图所示：

Ceph的OSD perf/perf daemon：这是Ceph自带的工具，其中OSD perf主要记录IO读写的时延，可以初步判断到底的瓶颈是否在我们的硬盘上面，如果是，可以采取相应的优化手段。

perf daemon主要是记录整个IO请求在Ceph内部的一些状态的处理流程，这些处理流程耗时多少，都会通过这个命令导出，可以进行初步的诊断。

操作系统——Perf工具：比较常用的perf top，显现当前整个系统的运行情况，如上图的右上脚，OSD进程显然是耗费了大量的CPU，可以进行层级下剥，查找到热点函数位置，再针对性地去优化热点函数。而perf stat主要是采集进程在一段时间内的总体的情况。还可以使用perf record，记录数据，后续可以结合FlamGraph生成一个火焰图，这种火焰图相对来说比较直观。主要关注一些平头的函数调用（图），因为这里耗费的cpu时间比重比较大，是优化的目标。

Systemtap：主要在Redhat系统用得比较多。通过采集内核函数、系统调用、用户函数的运行信息、函数出入口数据等，根据这些采集的数据，进行函数级别的分析。如基于openresty-systemtap-toolkit工具，进行二次开发。通过工具就可以去分析整个系统或者是程序在哪里有瓶颈点，然后再针对瓶颈点进行性能优化。

优化后的Ceph存储系统性能如何？

兼容性方面：从开始到结束整个过程没有遇到比较大的阻塞点，依赖库和部分技术问题在华为的基础设施网站上能够找到解决方法，将Ceph移植到鲲鹏平台上的整个流程较为顺利。

优化的性能：基于现有服务器配置进行的优化前后对比，这里的测试并未鲲鹏CPU的极限，主要的瓶颈点是在硬盘上。主要是展示经过上面介绍的优化方法、手段进行优化后的成果。如表所示，可以看到优化后的性能是有改善的。

低功耗：主要体现在ARM的单物理核的功耗确实比X86要低的，所以在后期运营成本上具备优势。

下面介绍一下我们的块存储产品运行在鲲鹏平台上的状况，主界面显示的是整个块存储产品集群的状态，节点信息部分，上面部署了monitor和OSD等组件，这里的服务器信息可以看出是华为的TaiShan服务器，TaiShan 200（型号2280）的服务器使用的就鲲鹏920的处理器。

其他管理功能，例如卷管理，Linux系统可以通过内核的krbd模块实现本地挂载，，也可以走iSCSI协议挂载到windows系统上供用户使用（图）。当了还有其他的功能，这就不展开了。

未来的展望和计划

首先是基于TaiShan服务器的一个长远计划，例如发布一个基于全闪存场景的产品，这种场景下所有的硬盘性能都比较高，而传统以太网网络将是一个瓶颈，现在TaiShan服务器刚好支持RDMA功能，为全闪存场景的部署铺平了道路，无需额外适配、调优网络端口了。

seastar对于ARM架构来说，多核竞争中跨片访问时，性能处于劣势，此时采用无共享编程的seastar框架，有利于规避ARM跨片访问的劣势；seastar架构的改造社区也在积极投入，我们也会持续跟进。

最后是安全存储产品对数据加解密和解压缩的处理较为重要，而鲲鹏外围加速器zlib/rsa/md5/sm3能够提供高效的数据安全处理流程。

关于强耦合的内核缓存改造后是否需要重新编译操作系统？不需要，在VFS层时是通过kernel hacking的方式处理I/O的，不需要改动内核原有的逻辑，只需将修改后的KO加载到操作系统就可以处理我们定制的IO了。

为什么不考虑将缓存做到blue Store里面？Blue Store在社区当时设计的目标是面向未来全闪存场景的，是没有考虑过混合场景的；而且混合场景只是一个过渡阶段，并不长远，所以社区在设计时就没有考虑过加缓存；如果将缓存做到Blue Store的话，是与社区设计理念相悖，同时导致整个Blue Store处理异常复杂；无论是以后跟进社区还是向社区推送改动都比较麻烦。

分享嘉宾信息：

演讲精彩视频

创作场景

基于鲲鹏平台的 Ceph 深度性能调优