基于國(guó)產(chǎn)化ARM平臺(tái)的Ceph分布式存儲(chǔ)集群設(shè)計(jì)?

周浩宇 李含輝 樊 榮 肖 威

（中國(guó)船舶重工集團(tuán)公司第七二二研究所 武漢 430205）

1 引言

目前，國(guó)防科技中的存儲(chǔ)仍然以單點(diǎn)存儲(chǔ)為主，輔助以少量的RAID磁盤(pán)陣列。此類(lèi)傳統(tǒng)的存儲(chǔ)方案存在著許多弊端：

1）容錯(cuò)性差，遇到斷電重啟以后，容易導(dǎo)致數(shù)據(jù)丟失，且難以恢復(fù)；

2）當(dāng)前存儲(chǔ)容量不夠用時(shí)，容量擴(kuò)展不方便；

3）存儲(chǔ)節(jié)點(diǎn)的功耗缺乏控制，面臨一些特殊情況時(shí)，可能會(huì)造成隱患；

4）國(guó)防科技信息化程度飛速發(fā)展的今天，傳統(tǒng)的存儲(chǔ)方案已經(jīng)開(kāi)始無(wú)法滿(mǎn)足海量增長(zhǎng)的數(shù)據(jù)；未來(lái)大數(shù)據(jù)在國(guó)防科技的應(yīng)用，更是對(duì)存儲(chǔ)的要求日益苛刻。

因此，在國(guó)際形勢(shì)日益緊張和國(guó)防科技大力發(fā)展的今天，研究一套適合現(xiàn)代化國(guó)防建設(shè)的分布式存儲(chǔ)系統(tǒng)是符合現(xiàn)實(shí)國(guó)情和迫在眉睫的需求。

Ceph最初是一項(xiàng)關(guān)于存儲(chǔ)系統(tǒng)的PhD研究項(xiàng)目［1］，由 SageWeil在 University of California，Santa Cruz（UCSC）實(shí)施，后被Red Hat公司收購(gòu)。Ceph是當(dāng)下最流行的云平臺(tái)軟件OpenStack的標(biāo)配開(kāi)源存儲(chǔ)方案之一［2］。Ceph消除了對(duì)系統(tǒng)單一中心節(jié)點(diǎn)的依賴(lài)，實(shí)現(xiàn)了真正的無(wú)中心結(jié)構(gòu)的設(shè)計(jì)思想。作為一項(xiàng)存儲(chǔ)系統(tǒng)，Ceph可以提供塊存儲(chǔ)（RBD）、對(duì)象存儲(chǔ)（RADOWSGW）和文件系統(tǒng)存儲(chǔ)（Cephfs）三種方式［3］。其中塊存儲(chǔ)，也是本文的重點(diǎn)，可以對(duì)接主流IaaS云平臺(tái)軟件，例如OpenStack以及類(lèi)似的 CloudStack、Zstack、Eucalyptus以及 KVM 等，也可以?xún)?nèi)核模塊的方式映射成為本地的一個(gè)塊設(shè)備，繼而就可以iSCSI的方式提供存儲(chǔ)服務(wù)；對(duì)象存儲(chǔ)可以對(duì)接網(wǎng)盤(pán)（ownCloud）應(yīng)用業(yè)務(wù)等；文件系統(tǒng)Cephfs暫時(shí)還不太成熟，官方不建議在生產(chǎn)環(huán)境下使用。本文旨在搭建一個(gè)ARM環(huán)境下的Ceph存儲(chǔ)集群，并提供塊存儲(chǔ)，給Windows環(huán)境的客戶(hù)端提供iSCSI存儲(chǔ)接口。

2 整體框架設(shè)計(jì)

2.1 硬件選型

存儲(chǔ)節(jié)點(diǎn)服務(wù)器初步選用我國(guó)Firefly開(kāi)源團(tuán)隊(duì)設(shè)計(jì)的Firefly-RK3399，它采用我國(guó)瑞芯微（Rockchip）公司生產(chǎn)的64位“服務(wù)器級(jí)”處理器RK3399，擁有4GBDDR3主存，提供PCIe M.2接口和千兆（Gbit）網(wǎng)卡。其中RK3399處理器采用big.LITTLE大小核架構(gòu)，雙核Cortex-A72加上四核Cortex-A53。

各存儲(chǔ)節(jié)點(diǎn)上的存儲(chǔ)設(shè)備為PCIe M.2接口的Intel P600固態(tài)硬盤(pán)（SSD），大小為 512G，采用NVMe協(xié)議。

客戶(hù)端使用普通的x86架構(gòu)的機(jī)架服務(wù)器，并配備上萬(wàn)兆（10Gbit）網(wǎng)卡。

交換機(jī)采用10Gbit口交換機(jī)。

2.2 Ceph架構(gòu)簡(jiǎn)介

Ceph是一種分布式的軟件定義存儲(chǔ)方案。相比于傳統(tǒng)的一個(gè)存儲(chǔ)節(jié)點(diǎn)掛載很多存儲(chǔ)設(shè)備，軟件定義存儲(chǔ)通過(guò)分布式設(shè)計(jì)，利用了更多的存儲(chǔ)節(jié)點(diǎn)，因此在解決了單節(jié)點(diǎn)故障的同時(shí)，也讓存儲(chǔ)容量的擴(kuò)展變得更加方便［2］。

1）Ceph集群組件

作為一種分布式存儲(chǔ)集群，Ceph核心部件包括Monitor節(jié)點(diǎn)和OSD節(jié)點(diǎn)，同時(shí)還有MDS，Rad?owsGW等一些組件用于提供不同的服務(wù)。首先簡(jiǎn)單介紹一下這幾種節(jié)點(diǎn)：

（1）OSDs：Ceph OSD 守護(hù)進(jìn)程（Ceph OSD）的功能是存儲(chǔ)數(shù)據(jù)，處理數(shù)據(jù)的復(fù)制、恢復(fù)、回填、再均衡，并通過(guò)檢查其他OSD守護(hù)進(jìn)程的心跳來(lái)向Ceph Monitors提供一些監(jiān)控信息。當(dāng)Ceph存儲(chǔ)集群設(shè)定為有2個(gè)副本時(shí)，至少需要2個(gè)OSD守護(hù)進(jìn)程，集群才能達(dá)到active+clean狀態(tài)（Ceph默認(rèn)有3個(gè)副本，但你可以調(diào)整副本數(shù)）。

（2）Monitors：Ceph Monitor維護(hù)著展示集群狀態(tài)的各種圖表，包括監(jiān)視器圖、OSD圖、歸置組（PG）圖、和CRUSH圖。Ceph保存著發(fā)生在Moni?tors、OSD和PG上的每一次狀態(tài)變更的歷史信息（稱(chēng)為epoch）。

（3）MDS：元數(shù)據(jù)服務(wù)器，在提供Ceph的文件系統(tǒng)服務(wù)Cephfs時(shí)使用，本文不作介紹。

2）Ceph分布式讀寫(xiě)原理

客戶(hù)端可以通過(guò)Cephfs，RBD，RadowsGW等方式訪(fǎng)問(wèn)Ceph集群。寫(xiě)入集群時(shí)，客戶(hù)端首先文件按照指定的對(duì)象大小分割成多個(gè)對(duì)象。通過(guò)使用CRUSH算法，Ceph可以計(jì)算出哪個(gè)歸置組（PG）應(yīng)該持有指定的對(duì)象（Object），然后進(jìn)一步計(jì)算出哪個(gè)OSD守護(hù)進(jìn)程持有該歸置組。CRUSH算法使得Ceph存儲(chǔ)集群能夠動(dòng)態(tài)地伸縮、再均衡和修復(fù)。如果設(shè)置了多副本，那么同一對(duì)象將分不到不同的OSD中（一個(gè)主OSD和幾個(gè)副O(jiān)SD），達(dá)到了數(shù)據(jù)的冗余備份效果，保證了數(shù)據(jù)的安全性。而讀取數(shù)據(jù)的時(shí)候，是從主OSD里讀取數(shù)據(jù)

2.3 存儲(chǔ)集群架構(gòu)

1）Ceph集群

我們采用10個(gè)上述的ARM服務(wù)器節(jié)點(diǎn)，操作系統(tǒng)為Ubuntu 16.04 LTS版本，并且安裝jewel版本的Ceph軟件。每個(gè)服務(wù)器節(jié)點(diǎn)都充當(dāng)存儲(chǔ)節(jié)點(diǎn)的角色，并分別部署兩個(gè)OSD進(jìn)程，每個(gè)OSD對(duì)應(yīng)的數(shù)據(jù)空間大小為236G，日志空間大小為3G。在這10個(gè)服務(wù)器節(jié)點(diǎn)中，選取其中三個(gè)作為管理節(jié)點(diǎn)，并分別部署一個(gè)MON進(jìn)程。由于集群規(guī)模比較小，可以不用設(shè)置DNS服務(wù)器和NTP服務(wù)器。下圖為集群實(shí)物圖，可以看到，每一個(gè)都有一個(gè)固態(tài)硬盤(pán)，我們將集群部署在這10個(gè)節(jié)點(diǎn)上。

2）客戶(hù)端

采用上述配有10Gbit網(wǎng)卡的x86服務(wù)器作為客戶(hù)端，操作系統(tǒng)為Ubuntu 16.04 LTS版本，并且安裝jewel版本的Ceph軟件。該客戶(hù)端上配置好ad?min節(jié)點(diǎn)的密鑰環(huán)（Keyring），以保證能免密連接到集群。利用Ceph里的RBD（RADOSBlock Device）功能創(chuàng)建一個(gè)鏡像，并映射到客戶(hù)端本地成為一個(gè)本地的塊設(shè)備。此時(shí)，我們就有多種方式使用它，可以和本地的一個(gè)普通塊設(shè)備一樣格式化然后作為文件系統(tǒng)被訪(fǎng)問(wèn)，或者提供Samba服務(wù)、FTP服務(wù)共享給其他客戶(hù)端使用；也可以iSCSI的方式提供給其他Windows系統(tǒng)的客戶(hù)端使用。

3 對(duì)比傳統(tǒng)存儲(chǔ)方案的優(yōu)勢(shì)

3.1 無(wú)單點(diǎn)故障

傳統(tǒng)的單點(diǎn)存儲(chǔ)方案是每個(gè)服務(wù)器下掛載很多存儲(chǔ)設(shè)備，一般是硬盤(pán)或者閃存，可能會(huì)輔助磁盤(pán)陣列（RAID）的方式來(lái)增加數(shù)據(jù)的安全性。即使如此，也只能應(yīng)對(duì)單個(gè)服務(wù)器上數(shù)個(gè)硬盤(pán)出現(xiàn)故障的情況，如果整個(gè)服務(wù)器宕機(jī)，仍然會(huì)有造成數(shù)據(jù)丟失的可能，嚴(yán)重的情況是，該服務(wù)器上所有的數(shù)據(jù)都丟失。所以傳統(tǒng)的存儲(chǔ)方案存在單點(diǎn)故障的問(wèn)題，很多時(shí)候?qū)τ诖巴ㄐ诺沫h(huán)境，容易造成隱患。并且對(duì)于單節(jié)點(diǎn)，性能瓶頸在單個(gè)節(jié)點(diǎn)CPU的處理能力和節(jié)點(diǎn)網(wǎng)卡的帶寬上［3，9］。

而對(duì)于基于ARM服務(wù)器的Ceph存儲(chǔ)集群，由于其去中心化的設(shè)計(jì)，通過(guò)CRUSH數(shù)據(jù)分布算法，將數(shù)據(jù)分散到各個(gè)服務(wù)器節(jié)點(diǎn)的OSD里，并且采取了多副本冗余的策略，保證了部分OSD故障時(shí)，數(shù)據(jù)仍然能保持完整性。并且采取了數(shù)據(jù)分布的存儲(chǔ)方案，并且有更多的計(jì)算節(jié)點(diǎn)，因此把計(jì)算的壓力分布到了更多的CPU上，同時(shí)把數(shù)據(jù)流量分?jǐn)偟搅烁嗟木W(wǎng)卡上，比起傳統(tǒng)的單點(diǎn)存儲(chǔ)方案，優(yōu)勢(shì)明顯。

3.2 易拓展性

在存儲(chǔ)容量不夠時(shí)，傳統(tǒng)的存儲(chǔ)方案擴(kuò)容是一件令人很頭痛的問(wèn)題。但是對(duì)于Ceph來(lái)說(shuō)，擴(kuò)容是一件相當(dāng)容易的事。我們可以在節(jié)點(diǎn)上加入新的存儲(chǔ)設(shè)備，或者直接增加新的節(jié)點(diǎn)，并且支持異構(gòu)硬件。并且這一過(guò)程不會(huì)影響集群正常的運(yùn)行，對(duì)于使用集群的客戶(hù)端來(lái)說(shuō)，它們根本不會(huì)發(fā)現(xiàn)有擴(kuò)容的過(guò)程發(fā)生。并且隨著存儲(chǔ)節(jié)點(diǎn)的增加，集群的各方面性能也會(huì)提升，并且能提供大部分存儲(chǔ)方案無(wú)法提供的PB級(jí)存儲(chǔ)。而且節(jié)點(diǎn)數(shù)越多，集群遇到問(wèn)題時(shí)，恢復(fù)也更加的快速［8］。

3.3 低成本和低功耗

單個(gè)存儲(chǔ)節(jié)點(diǎn)成本不大于1000元，一個(gè)固態(tài)存儲(chǔ)設(shè)備成本也不大于1000元，這相比于傳統(tǒng)的機(jī)架服務(wù)器，價(jià)格優(yōu)勢(shì)明顯。

單節(jié)點(diǎn)功耗不大于5W，一個(gè)9節(jié)點(diǎn)的集群經(jīng)測(cè)試功率不大于60W，相比一個(gè)320W的機(jī)架服務(wù)器，按一天24h，一年365天持續(xù)工作的情況計(jì)算，可以節(jié)約大約2300kW·h的電能。對(duì)于更多節(jié)點(diǎn)的情況，功耗優(yōu)勢(shì)更加明顯。

4 應(yīng)用與測(cè)試

我們選取裝載有10Gbps網(wǎng)卡的服務(wù)器作為客戶(hù)端訪(fǎng)問(wèn)本集群。利用Ceph的RBD組件在集群中名為rbd的默認(rèn)存儲(chǔ)池中創(chuàng)建一個(gè)名為fio_image的鏡像，然后將該鏡像映射到該客戶(hù)端本地的操作系統(tǒng)內(nèi)核，對(duì)應(yīng)塊設(shè)備/dev/rbd0。我們利用fio工具，對(duì)這個(gè)塊設(shè)備進(jìn)行吞吐量和IOPS測(cè)試。最后我們講這個(gè)塊設(shè)備/deb/rbd0進(jìn)行格式化并掛載到本地，進(jìn)行大文件拷貝測(cè)試。通過(guò)這些測(cè)試，來(lái)分析節(jié)點(diǎn)數(shù)不同時(shí)，性能的變化情況［2］。

1）3/6/9個(gè)存儲(chǔ)節(jié)點(diǎn)下的讀寫(xiě)帶寬

分別選擇4K/16K/512K塊大小對(duì)集群進(jìn)行讀寫(xiě)測(cè)試，測(cè)試引擎選擇Linux原生異步IO接口libaio，并且繞過(guò)io的buffer，隊(duì)列深度設(shè)置為64，測(cè)試尋址空間選擇為磁盤(pán)存儲(chǔ)空間的10%，圖8～9是存儲(chǔ)節(jié)點(diǎn)數(shù)量為3/6/9時(shí)fio測(cè)得的4K/16K/512K塊大小下的隨機(jī)讀寫(xiě)和順序讀寫(xiě)的折線(xiàn)圖。

2）4K塊大小讀寫(xiě)IOPS測(cè)試

測(cè)試過(guò)程同上一步，不過(guò)此處僅統(tǒng)計(jì)不同數(shù)量的節(jié)點(diǎn)時(shí)4K塊大小讀寫(xiě)的IOPS，圖10是測(cè)試的折線(xiàn)圖。

3）大文件拷貝測(cè)試

我們將塊設(shè)備/dev/rbd0進(jìn)行格式化，本次測(cè)試選擇的ext4格式，然后將它掛載到本地目錄/mnt/fio_test，然后從本地用cp命令，從本地拷貝一個(gè)大小為3.3G的單個(gè)大文件到/mnt/fio_test，并用time命令統(tǒng)計(jì)cp命令完成的耗時(shí)。

從以上的測(cè)試，我們可以得到以下結(jié)論：

4K/16K塊大小的情況下，節(jié)點(diǎn)數(shù)量的變化對(duì)順序讀寫(xiě)性能的影響不大，而對(duì)隨機(jī)讀寫(xiě)的性能都會(huì)隨著節(jié)點(diǎn)數(shù)增加而增加。

對(duì)于4K塊大小的隨機(jī)讀，IOPS相當(dāng)?shù)拇螅⑶以?節(jié)點(diǎn)時(shí)能達(dá)到1.5萬(wàn)多。這說(shuō)明本集群對(duì)于小文件的處理相當(dāng)具有優(yōu)勢(shì)。

讀寫(xiě)塊較大時(shí)，例如512K時(shí)，讀寫(xiě)性能隨著集群中節(jié)點(diǎn)數(shù)量的線(xiàn)性增長(zhǎng)就特別的明顯。并且從大文件拷貝可以看出，隨著節(jié)點(diǎn)數(shù)增加，拷貝耗時(shí)接近線(xiàn)性較少。而且9節(jié)點(diǎn)時(shí)，拷貝的速度已經(jīng)是客戶(hù)端帶寬的速度。進(jìn)一步測(cè)試我們會(huì)發(fā)現(xiàn)，集群性能的瓶頸包括客戶(hù)端的帶寬，所以在客戶(hù)端網(wǎng)卡速率足夠大時(shí)，本集群能發(fā)揮的性能更強(qiáng)。

5 結(jié)語(yǔ)

本文基于國(guó)產(chǎn)化的ARM平臺(tái)組件出了一個(gè)可用高效的Ceph分布式集群。該集群經(jīng)實(shí)測(cè)驗(yàn)證可用，不僅解決了單點(diǎn)存儲(chǔ)存在的單點(diǎn)故障問(wèn)題，而且擁有單點(diǎn)存儲(chǔ)所不能比擬的高性能、大容量、易擴(kuò)展性的問(wèn)題，并且成本和功耗也遠(yuǎn)遠(yuǎn)優(yōu)于傳統(tǒng)的存儲(chǔ)方案。對(duì)其提供的塊存儲(chǔ)的性能測(cè)試中，該集群在4K塊大小進(jìn)行讀寫(xiě)時(shí)具有相當(dāng)高的IOPS，對(duì)于小文件存儲(chǔ)性能也相當(dāng)?shù)膹?qiáng)；增加存儲(chǔ)節(jié)點(diǎn)時(shí)存儲(chǔ)的性能會(huì)接近線(xiàn)性增長(zhǎng)，大文件拷貝時(shí)會(huì)發(fā)現(xiàn)瓶頸存在于客戶(hù)端的帶寬，因此集群在客戶(hù)端帶寬足夠大時(shí)能發(fā)揮出相當(dāng)大的性能優(yōu)勢(shì)。

本文對(duì)于船舶通信中的分布存儲(chǔ)系統(tǒng)只是一個(gè)初步的探索，對(duì)于集群的CRUSH數(shù)據(jù)選擇算法，集群的功耗控制，集群的冷熱分區(qū)等等方面還有很多可以進(jìn)一步探索和優(yōu)化的空間，筆者將在今后進(jìn)一步深入的探索。

相信在數(shù)據(jù)量劇增，數(shù)據(jù)安全穩(wěn)定性要求日益增強(qiáng)，云計(jì)算，數(shù)據(jù)挖掘即將應(yīng)用的將來(lái)，本文中的這種便于集成的功耗低并且性能卓越的基于ARM的Ceph分布式集群擁有很廣闊的應(yīng)用前景。

［1］馮幼樂(lè)，朱六璋.CEPH動(dòng)態(tài)元數(shù)據(jù)管理方法分析與改進(jìn)［J］.電子技術(shù)，2010，47（9）：7-9.

［2］李翔等.Ceph分布式文件系統(tǒng)的研究及性能測(cè)試［D］.西安：西安電子科技大學(xué)，2014：10-13.

［3］詹明非.軟件定義存儲(chǔ)技術(shù)及其應(yīng)用研究［J］.電信技術(shù)，2014（12）：30-32.

［4］程靚坤.基于Ceph的云存儲(chǔ)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)［D］.廣州：中山大學(xué)，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.