随着IOT、大数据、移动互联等应用的暴涨，产生的数据也越来越多，整个存储市场总量也逐年增长，预计到2021年分布式存储会占到整个存储市场的50%，到2027年，分布式存储会占到整个市场的70%。Ceph则是典型的分布式存储软件的代表。
杉岩数据作为一家软件定义存储商，软件的发展与硬件的结合密必不可分，与华为共建ARM生态是杉岩发展的关键着力点。目前，杉岩数据的对象存储MOS和块存储USP已完成在鲲鹏平台的适配工作，且可进行商用了，以下是杉岩数据在Ceph开发和应用方面的经验分享
一、Ceph介绍
CLIENT——用户层面：Ceph对外提供的三个服务
Block storage即（RDB块存储接口）：如同一个没有格式化的U盘，在第一次接入个人PC时，windows操作系统会弹出一个格式化的请求界面供用户选择参数，如比较重要的文件系统选项，有NTFS、exFAT等文件系统以供选择，格式化完成后的U盘才能进行创建目录、拷贝文件等操作；形象一点的概括：整个块设备可以看成一栋大楼的框架，在进入大楼工作生活前，需要对这栋大楼进行装修，即格式化。而大楼不可能只有一个人，所以需要物业进行管理，物业可以比作一个文件系统。
Object storage即（RADOS GW对象存储）：对象存储在大家的生活中也是接触较多的，例如我们平常使用的云盘；或者我们使用的智能手机都有云备份功能，都是基于对象存储的一种业务表现。所以对象存储是为了解决信息化时代海量不规则文件的存储问题。就如世界上没有两片相同的叶子，每个人都会产生不同的信息，如何解决这些独一无二数据的存储，对象存储就是提供了一种解决方法。
Flie system文件系统：把Ceph提供文件系统服务，类比成购买个人电脑的过程，DIY用户可能会买各种硬件、零件组装起来装上操作系统之后才能使用，而电脑商家还会提供一个已经预装好windows系统的整机供用户选择，用户购买之后接通电源开机后可直接使用。Ceph提供的文件系统服务也就类似于这样的一个整机，用户只需将对应的目录挂载到本地即可进行工作。
RGW——对象存储接口
使用这个接口服务需要配合一些客户端软件；当然了,手机上的云备份功能是因为手机操作系统已经内置了APP进行支撑，所以不需要再额外安装软件。
RBD——块存储接口
如果使用的是Linux系统，可以使用内核模块krbd直接在本地直接生成一个块设备供用户使用。针对Windows系统，则可以通过iSCSI协议，虚拟一块硬盘来供用户使用。
RADOS——抽象的对象存储集群
红色的RADOS层是整个Ceph集群的统一抽象层，上面的所有接口数据经过处理后都会以对象的形式保存在集群当中。同时RADOS还确保这些接口数据在整个集群中的一致性，而LIBRADOS，主要是访问RADOS层的接口库。
接下来看看Ceph集群中一些比较重要的组件，还有一些组件，如mgr，mirror等在图中没体现。这些组分布在集群中的各个服务器上；下面简略的说明各个组件的职能：
MON——monitor
第一个是MON，可以认为是集群的大脑，负责集群状态的维护和元数据的管理。
MDS——元数据服务器
MDS是为Ceph FS接口服务提供文件层次结构检索和元数据管理的，如果不需要Ceph FS服务，可以选择不部署该组件。
OSD——对象存储设备
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现有架构与业务存在的问题
Q1：Ceph数据与内核缓存的割裂问题。以BlueStore为例，它将OSD的元数据保存在RockDB中，RockDB又是运行在一个简化的文件系统(Blue FS)之上的，此时可以认为Blue FS的IO就是OSD的元数据，但对于内核缓存来说，它是无法感知OSD下发的数据是有元数据和业务数据之分的。
Q2：内核缓存无法区分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调优——Ceph在ARM架构上面临的问题与挑战
一、华为鲲鹏处理器与Intel Xeon的差异
ARM的跨片访问：主要反映在内存方面，（数据是估测值，非实测数据，不做测评）。ARM相对X86来说不占优势，所以后面的优化手段中有规避跨片numa的操作。
矢量运算方面，未获取到鲲鹏的具体参数，以ARM的A76作为参考，从目前来看， ARM也是不占优势的（图）。
内存操作：ARM采用的是load-store的微架构，简单地理解为：ARM在内存到内存之间的拷贝是需要CPU参与的，X86则可以直接做到不用CPU参与内存到内存间的拷贝。这是ARM微架构决定的。
协处理器即加速器：加速器方面鲲鹏920有EC/RSA/zlib等外围协处理器，相对通用的X86 6148来说是较为丰富，这是鲲鹏920的优势。
物理核数：ARM先天就有物理核数上面的优势。功耗比，单论总体的功耗不太准确，毕竟功耗还跟启用的物理核数有关系。当然先进的工艺在可以降低功耗。如果论单个物理核的功耗比，ARM确实相对X86是有优势的。
二、主流的优化方案
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)，华为提供的接口文档有详细的设置和参数配置，需要在代码层面上进行适配，此时需要投入工作量，进行稳定性方面的测试。
线程数以及内存操作
利用鲲鹏在物理核上的优势，可以增加相应处理业务的进程或线程，针对业务繁忙的线程，可以把线程拆分成两个，分配到不同物理核上去。
内存操作方面，除了减少内存操作，华为还针对ARM微架构出了一个补丁，该补丁主要优化了内存方面的接口，可以去华为的基础设施网站上下载patch来提升性能。
三、其他优化手段
绑网卡或NVME SSD中断：必须先把irqbalace服务关闭，否则irqbalace服务会将绑定给重新均衡掉。
cgroup隔离业务：针对对繁忙的线程或者进程来说是比较有效的，主要是基于CPU cache考虑，如果CPU被切换到不相关的进程和线程的时候，会导致CPU cache刷新，致使命中率下降，CPU cache预读也会浪费内存带宽。同时进程CPU一旦被切出，就会导致整个流水线被清空/排空的，此时并发的指令数也会减少，所以对性能还是有影响的。主要还是在业务比较繁忙的时候对性能的改善比较大。
第三方库：主要是优化内存的分配和回收效率，有Tcmalloc和jemalloc可选，可以去Tcmalloc和jemalloc的网站去下载相关文件进行阅读。
四、性能观测工具
Ceph自带工具——Ceph的OSD perf/perf daemon：OSD perf主要记录IO读写的时延，可以初步判断到底的瓶颈是否在我们的硬盘上面，如果是，可以采取相应的优化手段。
perf daemon主要是记录整个IO请求在Ceph内部的一些状态的处理流程，这些处理流程耗时多少，都会通过这个命令导出，可以进行初步的诊断。
操作系统——Perf工具：比较常用的perf top，显现当前整个系统的运行情况，如上图的右上脚，OSD进程显然是耗费了大量的CPU，可以进行层级下剥，查找到热点函数位置，再针对性地去优化热点函数。而perf stat主要是采集进程在一段时间内的总体的情况。还可以使用perf record，记录数据，后续可以结合FlamGraph生成一个火焰图，这种火焰图相对来说比较直观。主要关注一些平头的函数调用（图），因为这里耗费的cpu时间比重比较大，是优化的目标。
Systemtap：主要在Redhat系统用得比较多。通过采集内核函数、系统调用、用户函数的运行信息、函数出入口数据等，根据这些采集的数据，进行函数级别的分析。如基于openresty-systemtap-toolkit工具，进行二次开发。通过工具就可以去分析整个系统或者是程序在哪里有瓶颈点，然后再针对瓶颈点进行性能优化。
成果——经过优化后Ceph存储系统性能
产品移植到鲲鹏上面的成果：兼容性方面，从开始到结束整个过程没有遇到比较大的阻塞点，依赖库和部分技术问题在华为的基础设施网站上能够找到解决方法，将产品移植到鲲鹏平台上的整个流程较为顺利。
优化的性能：基于现有服务器配置进行的优化前后对比，这里的测试并未鲲鹏CPU的极限，主要的瓶颈点是在硬盘上。主要是展示经过上面介绍的优化方法、手段进行优化后的成果。如表所示，可以看到优化后的性能是有改善的。
低功耗：主要体现在ARM的单物理核的功耗确实比X86要低的，所以在后期运营成本上具备优势。
下面介绍一下我们的块存储产品运行在鲲鹏平台上的状况，主界面显示的是整个块存储产品集群的状态，节点信息部分，这个上面部署了monitor和OSD等组件，这里的服务器信息可以看出是华为的TaiShan服务器，TaiShan2280的服务器使用的就鲲鹏920的cpu。
其他管理功能，例如卷管理，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处理异常复杂；无论是以后跟进社区还是向社区推送改动都比较麻烦。
