联系方式

售后服务热线

售后服务热线 400-838-3331转3

售后服务热线

关注官方公众号

服务邮箱

服务邮箱 support@szsandstone.com

服务邮箱

关注杉岩小助手

[HDC.Cloud]基于鲲鹏平台的Ceph深度性能调优

分类:存储知识 发布时间:2020年04月07日
分享:

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


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


一、Ceph介绍



CLIENT——用户层面:Ceph对外提供的三个服务


  • Block storage即(RDB块存储接口):如同一个没有格式化的U盘,在第一次接入个人PC时,windows操作系统会弹出一个格式化的请求界面供用户选择参数,如比较重要的文件系统选项,有NTFSexFAT等文件系统以供选择,格式化完成后的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现有架构与业务存在的问题


Q1Ceph数据与内核缓存的割裂问题。以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调优——CephARM架构上面临的问题与挑战

一、华为鲲鹏处理器与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自带工具——CephOSD perf/perf daemonOSD 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处理异常复杂;无论是以后跟进社区还是向社区推送改动都比较麻烦。




我们重视您的隐私

我们使用 cookie 来个性化和增强您在我们网站上的浏览体验。点击“接受所有 Cookie”,即表示您同意使用 Cookie。您可以阅读我们的Cookie 政策以了解更多信息。

电话咨询

服务热线

400-838-3331

更多联系方式

顶部

扫码关注