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

随着 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 处理异常复杂；无论是以后跟进社区还是向社区推送改动都比较麻烦。

分享嘉宾信息：

演讲精彩视频