基于国产化ARM平台的Ceph分布式存储集群设计∗

周浩宇 李含辉 樊 荣 肖 威

（中国船舶重工集团公司第七二二研究所 武汉 430205）

1 引言

目前，国防科技中的存储仍然以单点存储为主，辅助以少量的RAID磁盘阵列。此类传统的存储方案存在着许多弊端：

1）容错性差，遇到断电重启以后，容易导致数据丢失，且难以恢复；

2）当前存储容量不够用时，容量扩展不方便；

3）存储节点的功耗缺乏控制，面临一些特殊情况时，可能会造成隐患；

4）国防科技信息化程度飞速发展的今天，传统的存储方案已经开始无法满足海量增长的数据；未来大数据在国防科技的应用，更是对存储的要求日益苛刻。

因此，在国际形势日益紧张和国防科技大力发展的今天，研究一套适合现代化国防建设的分布式存储系统是符合现实国情和迫在眉睫的需求。

Ceph最初是一项关于存储系统的PhD研究项目［1］，由 SageWeil在 University of California，Santa Cruz（UCSC）实施，后被Red Hat公司收购。Ceph是当下最流行的云平台软件OpenStack的标配开源存储方案之一［2］。Ceph消除了对系统单一中心节点的依赖，实现了真正的无中心结构的设计思想。作为一项存储系统，Ceph可以提供块存储（RBD）、对象存储（RADOWSGW）和文件系统存储（Cephfs）三种方式［3］。其中块存储，也是本文的重点，可以对接主流IaaS云平台软件，例如OpenStack以及类似的 CloudStack、Zstack、Eucalyptus以及 KVM 等，也可以内核模块的方式映射成为本地的一个块设备，继而就可以iSCSI的方式提供存储服务；对象存储可以对接网盘（ownCloud）应用业务等；文件系统Cephfs暂时还不太成熟，官方不建议在生产环境下使用。本文旨在搭建一个ARM环境下的Ceph存储集群，并提供块存储，给Windows环境的客户端提供iSCSI存储接口。

2 整体框架设计

2.1 硬件选型

存储节点服务器初步选用我国Firefly开源团队设计的Firefly-RK3399，它采用我国瑞芯微（Rockchip）公司生产的64位“服务器级”处理器RK3399，拥有4GBDDR3主存，提供PCIe M.2接口和千兆（Gbit）网卡。其中RK3399处理器采用big.LITTLE大小核架构，双核Cortex-A72加上四核Cortex-A53。

各存储节点上的存储设备为PCIe M.2接口的Intel P600固态硬盘（SSD），大小为 512G，采用NVMe协议。

客户端使用普通的x86架构的机架服务器，并配备上万兆（10Gbit）网卡。

交换机采用10Gbit口交换机。

2.2 Ceph架构简介

Ceph是一种分布式的软件定义存储方案。相比于传统的一个存储节点挂载很多存储设备，软件定义存储通过分布式设计，利用了更多的存储节点，因此在解决了单节点故障的同时，也让存储容量的扩展变得更加方便［2］。

1）Ceph集群组件

作为一种分布式存储集群，Ceph核心部件包括Monitor节点和OSD节点，同时还有MDS，Rad⁃owsGW等一些组件用于提供不同的服务。首先简单介绍一下这几种节点：

（1）OSDs：Ceph OSD 守护进程（Ceph OSD）的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD守护进程的心跳来向Ceph Monitors提供一些监控信息。当Ceph存储集群设定为有2个副本时，至少需要2个OSD守护进程，集群才能达到active+clean状态（Ceph默认有3个副本，但你可以调整副本数）。

（2）Monitors：Ceph Monitor维护着展示集群状态的各种图表，包括监视器图、OSD图、归置组（PG）图、和CRUSH图。Ceph保存着发生在Moni⁃tors、OSD和PG上的每一次状态变更的历史信息（称为epoch）。

（3）MDS：元数据服务器，在提供Ceph的文件系统服务Cephfs时使用，本文不作介绍。

2）Ceph分布式读写原理

客户端可以通过Cephfs，RBD，RadowsGW等方式访问Ceph集群。写入集群时，客户端首先文件按照指定的对象大小分割成多个对象。通过使用CRUSH算法，Ceph可以计算出哪个归置组（PG）应该持有指定的对象（Object），然后进一步计算出哪个OSD守护进程持有该归置组。CRUSH算法使得Ceph存储集群能够动态地伸缩、再均衡和修复。如果设置了多副本，那么同一对象将分不到不同的OSD中（一个主OSD和几个副OSD），达到了数据的冗余备份效果，保证了数据的安全性。而读取数据的时候，是从主OSD里读取数据

2.3 存储集群架构

1）Ceph集群

我们采用10个上述的ARM服务器节点，操作系统为Ubuntu 16.04 LTS版本，并且安装jewel版本的Ceph软件。每个服务器节点都充当存储节点的角色，并分别部署两个OSD进程，每个OSD对应的数据空间大小为236G，日志空间大小为3G。在这10个服务器节点中，选取其中三个作为管理节点，并分别部署一个MON进程。由于集群规模比较小，可以不用设置DNS服务器和NTP服务器。下图为集群实物图，可以看到，每一个都有一个固态硬盘，我们将集群部署在这10个节点上。

2）客户端

采用上述配有10Gbit网卡的x86服务器作为客户端，操作系统为Ubuntu 16.04 LTS版本，并且安装jewel版本的Ceph软件。该客户端上配置好ad⁃min节点的密钥环（Keyring），以保证能免密连接到集群。利用Ceph里的RBD（RADOSBlock Device）功能创建一个镜像，并映射到客户端本地成为一个本地的块设备。此时，我们就有多种方式使用它，可以和本地的一个普通块设备一样格式化然后作为文件系统被访问，或者提供Samba服务、FTP服务共享给其他客户端使用；也可以iSCSI的方式提供给其他Windows系统的客户端使用。

3 对比传统存储方案的优势

3.1 无单点故障

传统的单点存储方案是每个服务器下挂载很多存储设备，一般是硬盘或者闪存，可能会辅助磁盘阵列（RAID）的方式来增加数据的安全性。即使如此，也只能应对单个服务器上数个硬盘出现故障的情况，如果整个服务器宕机，仍然会有造成数据丢失的可能，严重的情况是，该服务器上所有的数据都丢失。所以传统的存储方案存在单点故障的问题，很多时候对于船舶通信的环境，容易造成隐患。并且对于单节点，性能瓶颈在单个节点CPU的处理能力和节点网卡的带宽上［3，9］。

而对于基于ARM服务器的Ceph存储集群，由于其去中心化的设计，通过CRUSH数据分布算法，将数据分散到各个服务器节点的OSD里，并且采取了多副本冗余的策略，保证了部分OSD故障时，数据仍然能保持完整性。并且采取了数据分布的存储方案，并且有更多的计算节点，因此把计算的压力分布到了更多的CPU上，同时把数据流量分摊到了更多的网卡上，比起传统的单点存储方案，优势明显。

3.2 易拓展性

在存储容量不够时，传统的存储方案扩容是一件令人很头痛的问题。但是对于Ceph来说，扩容是一件相当容易的事。我们可以在节点上加入新的存储设备，或者直接增加新的节点，并且支持异构硬件。并且这一过程不会影响集群正常的运行，对于使用集群的客户端来说，它们根本不会发现有扩容的过程发生。并且随着存储节点的增加，集群的各方面性能也会提升，并且能提供大部分存储方案无法提供的PB级存储。而且节点数越多，集群遇到问题时，恢复也更加的快速［8］。

3.3 低成本和低功耗

单个存储节点成本不大于1000元，一个固态存储设备成本也不大于1000元，这相比于传统的机架服务器，价格优势明显。

单节点功耗不大于5W，一个9节点的集群经测试功率不大于60W，相比一个320W的机架服务器，按一天24h，一年365天持续工作的情况计算，可以节约大约2300kW·h的电能。对于更多节点的情况，功耗优势更加明显。

4 应用与测试

我们选取装载有10Gbps网卡的服务器作为客户端访问本集群。利用Ceph的RBD组件在集群中名为rbd的默认存储池中创建一个名为fio_image的镜像，然后将该镜像映射到该客户端本地的操作系统内核，对应块设备/dev/rbd0。我们利用fio工具，对这个块设备进行吞吐量和IOPS测试。最后我们讲这个块设备/deb/rbd0进行格式化并挂载到本地，进行大文件拷贝测试。通过这些测试，来分析节点数不同时，性能的变化情况［2］。

1）3/6/9个存储节点下的读写带宽

分别选择4K/16K/512K块大小对集群进行读写测试，测试引擎选择Linux原生异步IO接口libaio，并且绕过io的buffer，队列深度设置为64，测试寻址空间选择为磁盘存储空间的10%，图8～9是存储节点数量为3/6/9时fio测得的4K/16K/512K块大小下的随机读写和顺序读写的折线图。

2）4K块大小读写IOPS测试

测试过程同上一步，不过此处仅统计不同数量的节点时4K块大小读写的IOPS，图10是测试的折线图。

3）大文件拷贝测试

我们将块设备/dev/rbd0进行格式化，本次测试选择的ext4格式，然后将它挂载到本地目录/mnt/fio_test，然后从本地用cp命令，从本地拷贝一个大小为3.3G的单个大文件到/mnt/fio_test，并用time命令统计cp命令完成的耗时。

从以上的测试，我们可以得到以下结论：

4K/16K块大小的情况下，节点数量的变化对顺序读写性能的影响不大，而对随机读写的性能都会随着节点数增加而增加。

对于4K块大小的随机读，IOPS相当的大，并且在9节点时能达到1.5万多。这说明本集群对于小文件的处理相当具有优势。

读写块较大时，例如512K时，读写性能随着集群中节点数量的线性增长就特别的明显。并且从大文件拷贝可以看出，随着节点数增加，拷贝耗时接近线性较少。而且9节点时，拷贝的速度已经是客户端带宽的速度。进一步测试我们会发现，集群性能的瓶颈包括客户端的带宽，所以在客户端网卡速率足够大时，本集群能发挥的性能更强。

5 结语

本文基于国产化的ARM平台组件出了一个可用高效的Ceph分布式集群。该集群经实测验证可用，不仅解决了单点存储存在的单点故障问题，而且拥有单点存储所不能比拟的高性能、大容量、易扩展性的问题，并且成本和功耗也远远优于传统的存储方案。对其提供的块存储的性能测试中，该集群在4K块大小进行读写时具有相当高的IOPS，对于小文件存储性能也相当的强；增加存储节点时存储的性能会接近线性增长，大文件拷贝时会发现瓶颈存在于客户端的带宽，因此集群在客户端带宽足够大时能发挥出相当大的性能优势。

本文对于船舶通信中的分布存储系统只是一个初步的探索，对于集群的CRUSH数据选择算法，集群的功耗控制，集群的冷热分区等等方面还有很多可以进一步探索和优化的空间，笔者将在今后进一步深入的探索。

相信在数据量剧增，数据安全稳定性要求日益增强，云计算，数据挖掘即将应用的将来，本文中的这种便于集成的功耗低并且性能卓越的基于ARM的Ceph分布式集群拥有很广阔的应用前景。

［1］冯幼乐，朱六璋.CEPH动态元数据管理方法分析与改进［J］.电子技术，2010，47（9）：7-9.

［2］李翔等.Ceph分布式文件系统的研究及性能测试［D］.西安：西安电子科技大学，2014：10-13.

［3］詹明非.软件定义存储技术及其应用研究［J］.电信技术，2014（12）：30-32.

［4］程靓坤.基于Ceph的云存储系统设计与实现［D］.广州：中山大学，2014：15-18.

［5］Tang B，Sandhu R.Extending OpenStack access control with domain trust［J］.Network and System Security.Springer International Publishing，2014：54-69.

［6］Red Hat Inc.Red Hat to Acquire Inktank，Provider of Ceph［Z］.Red Hat.Retrieved，2014（8）：3-6.

［7］Armando Fox，Eric Brewer.Harvest，Yield and Scalable TolerantSystems［C］//Proc.IEEECS，1999：174-178.

［8］Weil SA，Brandt SA，Miller EL，etal.Ceph：A scalable，high-performance distributed file system［C］//Proc.7th Symposium on Operating Systems Design and Implementa⁃tion.Seattle，Washington，USA.2006：307-320.

［9］Gudu D，Hardt M，Streit A.Evaluating the performance and scalability of the ceph distributed storage system［C］//Proc.2014 IEEE International Conference on Big Data（Big Data）.Washington DC，USA.2014.177-182.

［10］Ongaro D，Ousterhout J.In search of an understandable consensus algorithm［C］//Proc.2014 USENIX Confer⁃ence on USENIX Annual Technical Conference.Philadel⁃phia，PA，USA.2014.305-320.

［11］ Diane L.Tang.Benchmarking Filesystems［D］.Cam⁃bridge，Massachusetts.1995（4）：12-16.