一種云存儲(chǔ)系統(tǒng)分層性能監(jiān)測(cè)和采集方法

王海濤, 李戰(zhàn)懷, 張曉,2

1.西北工業(yè)大學(xué) 計(jì)算機(jī)學(xué)院, 陜西 西安　710129 2.高效能服務(wù)器和存儲(chǔ)技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室, 山東 濟(jì)南　250101

?

一種云存儲(chǔ)系統(tǒng)分層性能監(jiān)測(cè)和采集方法

王海濤1, 李戰(zhàn)懷1, 張曉1,2

1.西北工業(yè)大學(xué) 計(jì)算機(jī)學(xué)院, 陜西 西安710129 2.高效能服務(wù)器和存儲(chǔ)技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室, 山東 濟(jì)南250101

摘要：為了解決現(xiàn)有云存儲(chǔ)監(jiān)測(cè)方法無(wú)法獲得完整的系統(tǒng)特性，以確定最佳應(yīng)用場(chǎng)景并定位性能瓶頸，根據(jù)云存儲(chǔ)系統(tǒng)的分層架構(gòu)，調(diào)查研究了云存儲(chǔ)系統(tǒng)層上的性能監(jiān)測(cè)和采集方法，并提出了一種針對(duì)云存儲(chǔ)系統(tǒng)層進(jìn)行分層性能監(jiān)測(cè)和采集的框架。該框架可以獲得云存儲(chǔ)系統(tǒng)各個(gè)系統(tǒng)層次的性能數(shù)據(jù)，并做進(jìn)一步的綜合對(duì)比分析，確定系統(tǒng)的應(yīng)用場(chǎng)景并定位系統(tǒng)瓶頸，從而對(duì)其進(jìn)行進(jìn)一步優(yōu)化。最后在ceph云存儲(chǔ)系統(tǒng)上進(jìn)行了實(shí)驗(yàn)，驗(yàn)證了新方法的可用性。

關(guān)鍵詞：云存儲(chǔ)；分層架構(gòu)；性能監(jiān)測(cè)；數(shù)據(jù)采集

IDC研究表明，全球信息總量將以驚人的速度增長(zhǎng)[1]，現(xiàn)有的存儲(chǔ)區(qū)域網(wǎng)絡(luò)等架構(gòu)已難以滿足信息快速擴(kuò)展的需求，于是具有按需使用和高擴(kuò)展性特點(diǎn)的云存儲(chǔ)應(yīng)運(yùn)而生。目前的云存儲(chǔ)系統(tǒng)可以提供多種訪問(wèn)接口，在豐富的接口支持下，出現(xiàn)了多種基于云存儲(chǔ)系統(tǒng)的互聯(lián)網(wǎng)應(yīng)用。作為基礎(chǔ)設(shè)施即服務(wù)(IaaS)的重要部分，云存儲(chǔ)的性能對(duì)其上的應(yīng)用性能有重大的影響。云存儲(chǔ)系統(tǒng)的應(yīng)用方面存在的2個(gè)關(guān)鍵問(wèn)題是：①如何確定某個(gè)云存儲(chǔ)系統(tǒng)的應(yīng)用場(chǎng)景；②如何準(zhǔn)確定位云存儲(chǔ)系統(tǒng)的性能瓶頸。

第一個(gè)問(wèn)題發(fā)生在云存儲(chǔ)應(yīng)用部署之前，之所以要首先確定其最佳適用場(chǎng)景，主要是因?yàn)楹线m的應(yīng)用場(chǎng)景才能夠充分發(fā)揮云存儲(chǔ)系統(tǒng)的性能優(yōu)勢(shì)，為企業(yè)節(jié)約成本，增加效益；反之，部署不合適的應(yīng)用會(huì)浪費(fèi)云存儲(chǔ)系統(tǒng)的資源，使得投入的成本無(wú)法產(chǎn)生期望的收益，并且還會(huì)由于性能發(fā)揮不佳而損失用戶，從而對(duì)企業(yè)的發(fā)展造成不良影響。由于在現(xiàn)有的云存儲(chǔ)系統(tǒng)上應(yīng)用繁多，通過(guò)一項(xiàng)項(xiàng)試驗(yàn)來(lái)找出云存儲(chǔ)上的最佳應(yīng)用幾乎是不可能的，并且這樣會(huì)消耗大量成本，導(dǎo)致系統(tǒng)長(zhǎng)時(shí)間無(wú)法上線。因此需要有一種更為簡(jiǎn)單有效的方法來(lái)確定云存儲(chǔ)系統(tǒng)的具體適用場(chǎng)景。

第二個(gè)問(wèn)題發(fā)生在云存儲(chǔ)系統(tǒng)運(yùn)行過(guò)程中，在部署完應(yīng)用之后，隨著負(fù)載的變化，云存儲(chǔ)系統(tǒng)可能會(huì)出現(xiàn)一些性能瓶頸，如何準(zhǔn)確定位這些性能瓶頸并進(jìn)行相應(yīng)的優(yōu)化是非常關(guān)鍵的問(wèn)題。瓶頸定位的準(zhǔn)確有效，就能夠迅速地對(duì)負(fù)載的變化作出反應(yīng)，及時(shí)解決系統(tǒng)中存在的問(wèn)題，拓展系統(tǒng)性能；否則，就難以找出問(wèn)題發(fā)生的真實(shí)所在，只能憑經(jīng)驗(yàn)進(jìn)行估計(jì)，這樣就有可能陷入不斷修改卻無(wú)法優(yōu)化的循環(huán)。

要解決上述2個(gè)問(wèn)題，需要對(duì)云存儲(chǔ)系統(tǒng)進(jìn)行持續(xù)的性能監(jiān)測(cè)，通過(guò)性能數(shù)據(jù)的分析來(lái)發(fā)現(xiàn)問(wèn)題。在這一方面，目前國(guó)內(nèi)外針對(duì)特定接口的用戶性能評(píng)價(jià)進(jìn)行了一些研究[2-4]，而對(duì)系統(tǒng)級(jí)性能的研究不足。由于云存儲(chǔ)系統(tǒng)的復(fù)雜性，現(xiàn)有的面向用戶的性能評(píng)價(jià)工具無(wú)法得到穩(wěn)定的結(jié)果，不能夠反映云存儲(chǔ)系統(tǒng)的整體性能，因此需要有面向系統(tǒng)指標(biāo)的分析方法。這方面研究較少，主要包括：

卡內(nèi)基梅隆大學(xué)提出了一種通過(guò)日志分析進(jìn)行系統(tǒng)性能瓶頸檢測(cè)并進(jìn)行性能優(yōu)化的方法[5]。伯克利大學(xué)和Netapp公司也對(duì)實(shí)際環(huán)境中的Trace進(jìn)行了分析，通過(guò)面向?qū)ο蠛投喑叨鹊慕y(tǒng)計(jì)方法，得出了網(wǎng)絡(luò)訪問(wèn)負(fù)載規(guī)律，并將其用于數(shù)據(jù)管理優(yōu)化和Cache性能優(yōu)化[6]。微軟公司設(shè)計(jì)了Oktopus，通過(guò)增加一層抽象的網(wǎng)絡(luò)層，監(jiān)測(cè)多租戶和云環(huán)境下的數(shù)據(jù)中心網(wǎng)絡(luò)性能[7]。Amazon的CloudWatch，Hyperic的CloudStatus可對(duì)Amzon的EC2和S3進(jìn)行測(cè)量。Google的Dapper[8]是根據(jù)其自身業(yè)務(wù)特點(diǎn)和需求開發(fā)的一個(gè)大規(guī)模分布式系統(tǒng)監(jiān)控框架，實(shí)現(xiàn)了廣泛可部署性和不間斷監(jiān)控2個(gè)設(shè)計(jì)目標(biāo)，可以對(duì)幾乎所有的Google后臺(tái)服務(wù)器進(jìn)行監(jiān)控，并在新服務(wù)部署、定位長(zhǎng)尾延時(shí)、推斷服務(wù)間的依存關(guān)系等方面，為開發(fā)者和系統(tǒng)管理人員提供了重要的技術(shù)支持。

此外，也有一些開源項(xiàng)目可以對(duì)云存儲(chǔ)系統(tǒng)性能進(jìn)行監(jiān)測(cè)。Chukwa[9]是建立在開源云計(jì)算平臺(tái)Hadoop基礎(chǔ)上的數(shù)據(jù)收集系統(tǒng)，用于大規(guī)模云計(jì)算平臺(tái)的監(jiān)測(cè)和分析。Monalytics[10]是一個(gè)集成云計(jì)算平臺(tái)監(jiān)測(cè)和數(shù)據(jù)分析2個(gè)關(guān)鍵功能的監(jiān)測(cè)系統(tǒng)，能夠?qū)崿F(xiàn)數(shù)據(jù)中心的性能感知負(fù)載均衡、實(shí)時(shí)異常檢測(cè)、異常放大分析等功能。CloudBeacon[11]可以實(shí)現(xiàn)云計(jì)算平臺(tái)中網(wǎng)絡(luò)性能的測(cè)量和預(yù)測(cè)。

但是，現(xiàn)有的方法多針對(duì)云存儲(chǔ)系統(tǒng)的某一方面或者某一層次進(jìn)行性能監(jiān)測(cè)，以一種類似于“黑盒”的方式評(píng)估系統(tǒng)性能。由于云存儲(chǔ)系統(tǒng)是一個(gè)較為復(fù)雜的系統(tǒng)，其中包含多個(gè)軟硬件層次，且不同層次上的性能指標(biāo)有所不同，涉及的度量和采集方法也不同，并且不同層次的性能指標(biāo)之間存在一定的關(guān)系，所以單純地對(duì)系統(tǒng)的某個(gè)層次進(jìn)行性能監(jiān)測(cè)實(shí)際上僅能得出一個(gè)粗略的評(píng)估結(jié)果，缺乏對(duì)系統(tǒng)的深度剖析，無(wú)法解決前面提到的2個(gè)關(guān)鍵問(wèn)題。

基于上述背景，本文提出了一種云存儲(chǔ)系統(tǒng)分層性能監(jiān)測(cè)和采集框架，通過(guò)對(duì)云存儲(chǔ)的各個(gè)系統(tǒng)層次性能進(jìn)行持續(xù)地監(jiān)測(cè)和采集，并對(duì)這些數(shù)據(jù)進(jìn)行綜合分析，得出了各系統(tǒng)層次的性能關(guān)系以及變化規(guī)律，確定系統(tǒng)的適用場(chǎng)景以及準(zhǔn)確定位系統(tǒng)瓶頸。最后在ceph云存儲(chǔ)系統(tǒng)上進(jìn)行了實(shí)驗(yàn)，驗(yàn)證了該方法的可用性。

1云存儲(chǔ)系統(tǒng)分層結(jié)構(gòu)

云存儲(chǔ)系統(tǒng)的分層架構(gòu)如圖1所示。其中：存儲(chǔ)層、基礎(chǔ)管理層位于服務(wù)端，屬于云存儲(chǔ)的系統(tǒng)層；而應(yīng)用接口層與應(yīng)用訪問(wèn)層聯(lián)系緊密，并且與客戶端的環(huán)境密切相關(guān)，所以在這里將其歸于用戶層。用戶層的性能不能夠反映云存儲(chǔ)系統(tǒng)的整體性能，還需要關(guān)注云存儲(chǔ)的系統(tǒng)層的性能，所以下面將集中討論存儲(chǔ)層和基礎(chǔ)管理層的性能監(jiān)測(cè)和采集。

圖1　云存儲(chǔ)系統(tǒng)的分層架構(gòu)

2云存儲(chǔ)系統(tǒng)層性能監(jiān)測(cè)和數(shù)據(jù)采集

目前有一些方法和工具可以對(duì)云存儲(chǔ)的單個(gè)系統(tǒng)層次進(jìn)行監(jiān)測(cè)和數(shù)據(jù)采集，下面分層次討論這些方法。

2.1存儲(chǔ)層

存儲(chǔ)層提供數(shù)據(jù)的存儲(chǔ)服務(wù)，為用戶提供一塊超大容量的“虛擬磁盤”，其主要性能指標(biāo)是IO吞吐率以及IOPS。

現(xiàn)有的性能評(píng)估方法，一部分側(cè)重于存儲(chǔ)層的性能測(cè)試而非監(jiān)控，如文獻(xiàn)[12]所示，但難以對(duì)存儲(chǔ)層的真實(shí)負(fù)載做持續(xù)地性能監(jiān)測(cè)和采集；另一部分則需修改特定的虛擬化平臺(tái)，如施楊斌等人[13]通過(guò)在Xen的Dom0IO設(shè)備模擬程序中，嵌入IO請(qǐng)求監(jiān)聽模塊來(lái)實(shí)現(xiàn)存儲(chǔ)層IO特征數(shù)據(jù)的獲取，但系統(tǒng)侵入性大且不具有通用性。

目前還沒有一種通用的、系統(tǒng)侵入性小并且能夠監(jiān)測(cè)和采集系統(tǒng)在真實(shí)負(fù)載下的性能的方法，上述方法都不滿足需求。事實(shí)上，主流云存儲(chǔ)系統(tǒng)的存儲(chǔ)層操作系統(tǒng)使用的基本都是linux，通過(guò)linux系統(tǒng)的自帶工具(例如iostat)可以分別統(tǒng)計(jì)各系統(tǒng)管理磁盤設(shè)備的IO性能信息，包括IOPS、吞吐率等，然后進(jìn)行匯總分析，就可以得出云存儲(chǔ)系統(tǒng)存儲(chǔ)層的性能信息。由于這些工具是系統(tǒng)自帶的，可以直接使用，所以系統(tǒng)侵入性小，而且能夠?qū)崟r(shí)監(jiān)測(cè)系統(tǒng)的性能，滿足存儲(chǔ)層的監(jiān)測(cè)需求。

2.2基礎(chǔ)管理層

由于云存儲(chǔ)的基礎(chǔ)管理層主要關(guān)注分布式文件系統(tǒng)，所以此處的性能監(jiān)測(cè)與數(shù)據(jù)采集的指標(biāo)也主要針對(duì)分布式文件系統(tǒng)，主要指標(biāo)是IOPS和讀寫吞吐率。由于不同的分布式文件系統(tǒng)的具體實(shí)現(xiàn)方式不同，所以基本沒有通用的監(jiān)測(cè)方法，目前只有針對(duì)某一種或某一類系統(tǒng)的具體監(jiān)測(cè)方法：

1)ceph-dash是用Python開發(fā)的一個(gè)ceph監(jiān)控面板，用來(lái)監(jiān)控ceph的運(yùn)行狀態(tài)，可通過(guò)RESTAPI或者Web頁(yè)面訪問(wèn)性能數(shù)據(jù)。該工具是開源的，其配置及使用也很簡(jiǎn)單。其應(yīng)用范圍僅限于ceph，但是由于ceph目前在云存儲(chǔ)系統(tǒng)中的應(yīng)用比較廣泛，所以仍然具有很好的實(shí)用價(jià)值。

2)Ganglia[14]是UCBerkeley發(fā)起的一個(gè)開源集群監(jiān)視項(xiàng)目，主要是用來(lái)監(jiān)控系統(tǒng)性能，如：cpu、內(nèi)存、硬盤利用率、I/O負(fù)載、網(wǎng)絡(luò)流量情況等，通過(guò)曲線很容易看到每個(gè)節(jié)點(diǎn)的工作狀態(tài)，對(duì)合理調(diào)整、分配系統(tǒng)資源，提高系統(tǒng)整體性能有重要作用。其收集到的數(shù)據(jù)通過(guò)RRDTool工具進(jìn)行處理，并生成相應(yīng)的圖形，以Web方式直觀地提供給客戶端，可以用于監(jiān)測(cè)ceph文件系統(tǒng)以及Hadoop文件系統(tǒng)的性能指標(biāo)。

3)Hadoop在云存儲(chǔ)中應(yīng)用也非常廣泛，其對(duì)應(yīng)的文件系統(tǒng)HDFS(hadoopdistributedfilesystem)是當(dāng)前最流行的云存儲(chǔ)系統(tǒng)之一。ApacheAmbari是一個(gè)基于web的工具，可用于配置、管理和監(jiān)控Hadoop集群以及監(jiān)測(cè)HDFS的性能指標(biāo)。

分布式文件系統(tǒng)是云存儲(chǔ)基礎(chǔ)管理層中的核心，在實(shí)際對(duì)云存儲(chǔ)進(jìn)行監(jiān)測(cè)時(shí)，需要針對(duì)特定的分布式文件系統(tǒng)選擇合適的監(jiān)測(cè)方法。

2.3分層性能監(jiān)測(cè)和采集框架

本文根據(jù)云存儲(chǔ)系統(tǒng)的分層架構(gòu)，提出了一個(gè)分層性能監(jiān)測(cè)和采集框架(如圖2所示)，監(jiān)測(cè)框架整體上是傳統(tǒng)的客戶端-服務(wù)器架構(gòu)，各組成部分概述如下：

1) 監(jiān)測(cè)代理

監(jiān)測(cè)代理作為框架中的客戶端，運(yùn)行在存儲(chǔ)層的各個(gè)節(jié)點(diǎn)以及分布式文件系統(tǒng)層上。由于存儲(chǔ)層節(jié)點(diǎn)的操作系統(tǒng)基本是Linux，所以監(jiān)測(cè)代理可以使用Linux的系統(tǒng)工具，例如iostat。而在分布式文件系統(tǒng)層，由于不同的分布式系統(tǒng)所提供的接口不同，需要針對(duì)特定的分布式文件系統(tǒng)來(lái)實(shí)現(xiàn)監(jiān)測(cè)代理，例如ceph的分布式文件系統(tǒng)層可以使用ceph-dash作為監(jiān)測(cè)代理。監(jiān)測(cè)代理的作用是，接收監(jiān)測(cè)服務(wù)器的監(jiān)測(cè)命令，命令中包括監(jiān)測(cè)的指標(biāo)、數(shù)據(jù)采集的間隔(例如10s)以及采樣次數(shù)，然后以規(guī)定的間隔采集性能信息，將數(shù)據(jù)先保存到本地，達(dá)到采樣次數(shù)要求后，再以異步的方式將其發(fā)送給監(jiān)測(cè)服務(wù)器。之所以采用異步的方式是為了防止阻塞，減小監(jiān)測(cè)程序?qū)τ谠拼鎯?chǔ)系統(tǒng)本身的影響。

圖2　分層監(jiān)測(cè)與采集框架

2) 監(jiān)測(cè)服務(wù)器

監(jiān)測(cè)服務(wù)器是監(jiān)測(cè)框架中的服務(wù)端，負(fù)責(zé)向各個(gè)層次的監(jiān)測(cè)代理發(fā)送監(jiān)測(cè)命令，并接收來(lái)自各個(gè)監(jiān)測(cè)代理采集到的性能數(shù)據(jù)，然后對(duì)各個(gè)系統(tǒng)層的性能信息進(jìn)行綜合處理，匯總得出各個(gè)層次的指定性能指標(biāo)的變化曲線以及比值變化曲線，并將其展示給監(jiān)測(cè)用戶。用戶通過(guò)這些曲線的對(duì)比，分析不同層次之間的性能關(guān)系，從而定位性能瓶頸，為下一步的性能優(yōu)化提供依據(jù)。

3云存儲(chǔ)系統(tǒng)ceph的實(shí)驗(yàn)分析

根據(jù)圖2所示的分層性能監(jiān)測(cè)與數(shù)據(jù)采集框架，對(duì)典型的云存儲(chǔ)系統(tǒng)ceph進(jìn)行了性能數(shù)據(jù)的采集和綜合分析，以驗(yàn)證本文方法的可用性。

3.1實(shí)驗(yàn)設(shè)計(jì)

本文實(shí)驗(yàn)包括7個(gè)linux節(jié)點(diǎn)，這7個(gè)節(jié)點(diǎn)的配置見表1，實(shí)驗(yàn)系統(tǒng)的架構(gòu)如圖3所示。

表1　實(shí)驗(yàn)節(jié)點(diǎn)的配置

圖3　實(shí)驗(yàn)系統(tǒng)架構(gòu)

實(shí)驗(yàn)中使用6個(gè)linux節(jié)點(diǎn)搭建ceph云存儲(chǔ)系統(tǒng)，另外1個(gè)linux節(jié)點(diǎn)作為系統(tǒng)的客戶端；每個(gè)節(jié)點(diǎn)各有一個(gè)硬盤，各個(gè)節(jié)點(diǎn)之間使用千兆網(wǎng)絡(luò)連接。在客戶端掛載ceph集群，使用Linux下的fio命令為ceph集群添加一定負(fù)載。同時(shí)，存儲(chǔ)層監(jiān)測(cè)代理是我們實(shí)驗(yàn)室開發(fā)的linux性能采集工具LinuxGather；分布式文件系統(tǒng)層的監(jiān)測(cè)代理是ceph監(jiān)測(cè)工具ceph-dash。最后將整個(gè)存儲(chǔ)層的總體性能數(shù)據(jù)與分布式文件系統(tǒng)層的性能數(shù)據(jù)作對(duì)比分析。

云存儲(chǔ)系統(tǒng)中主要包含3種讀寫模式：順序讀、

順序?qū)懸约半S機(jī)讀寫。其中多數(shù)是順序讀操作，一般發(fā)生在用戶進(jìn)行大文件下載的時(shí)候；其次是順序?qū)懖僮?，一般發(fā)生在用戶上傳大文件的時(shí)候；最后是隨機(jī)讀寫，一般發(fā)生在用戶操作小文件的時(shí)候。在實(shí)驗(yàn)中，fio讀寫記錄的塊大小分別設(shè)置為16kB，32kB，…，4MB，8MB一共10組。在不同塊大小配置下，生成上述3種模式的負(fù)載。由于云存儲(chǔ)中讀操作占多數(shù)，所以在隨機(jī)讀寫模式中，設(shè)置讀比例為70%。然后通過(guò)存儲(chǔ)層和分布式文件系統(tǒng)層的監(jiān)測(cè)代理，監(jiān)測(cè)對(duì)應(yīng)的IOPS和讀寫吞吐率，監(jiān)測(cè)間隔為10s，采樣次數(shù)為200次。最后，統(tǒng)計(jì)這些結(jié)果并進(jìn)行分析。

3.2實(shí)驗(yàn)結(jié)果與分析

根據(jù)上一節(jié)的實(shí)驗(yàn)配置進(jìn)行實(shí)驗(yàn)，監(jiān)測(cè)服務(wù)器接收到各個(gè)系統(tǒng)層次的性能數(shù)據(jù)并匯總之后，得到了各種模式之下，分布式文件系統(tǒng)層和存儲(chǔ)層的IOPS和吞吐率指標(biāo)值，以及二者的比值(文件系統(tǒng)層/存儲(chǔ)層)，結(jié)果如下：

3.2.1IOPS

由圖4～圖6，可以觀察到以下現(xiàn)象：

圖4　存儲(chǔ)層IOPS　　　　　　圖5　文件系統(tǒng)層IOPS圖6　IOPS比值(文件系統(tǒng)層/存儲(chǔ)層)

隨著讀寫記錄塊的增大，存儲(chǔ)層IOPS基本保持穩(wěn)定，文件系統(tǒng)層順序讀IOPS隨著記錄塊的增大成指數(shù)型下降，并且在塊大小達(dá)到64kB時(shí)，與存儲(chǔ)層順序讀IOPS相等。文件系統(tǒng)層順序?qū)慖OPS在塊大小達(dá)到64kB之前保持穩(wěn)定，在塊大小超過(guò)64kB以后，塊大小每增加一倍，IOPS就大約下降一倍。隨機(jī)讀寫的規(guī)律與順序?qū)懙念愃?，但是IOPS性能最差。

通過(guò)對(duì)上述現(xiàn)象進(jìn)行分析可以得出：

1)ceph的文件系統(tǒng)層默認(rèn)塊大小為64kB，也就是說(shuō)文件系統(tǒng)層向其底層的存儲(chǔ)層進(jìn)行讀寫操作的單位是64kB，這使得存儲(chǔ)層所操作的塊大小一直保持不變，所以存儲(chǔ)層的IOPS基本保持不變，并且使得文件系統(tǒng)層的順序讀IOPS與存儲(chǔ)層的順序讀IOPS在塊大小為64kB的時(shí)候達(dá)到相同值。

2) 文件系統(tǒng)層在順序讀的情況下，第一次讀取64kB數(shù)據(jù)后將其緩存起來(lái)，當(dāng)文件系統(tǒng)層讀取的塊小于64kB時(shí)就直接從緩存讀取并返回，而在此過(guò)程中還在源源不斷的從存儲(chǔ)層預(yù)讀取數(shù)據(jù)。操作的塊越小，能夠預(yù)讀的塊就越多，所以在文件系統(tǒng)層看來(lái)，順序讀IOPS隨著塊的增大以2的冪次減小，在塊大小等于64kB的時(shí)候，文件系統(tǒng)層與存儲(chǔ)層的IOPS值持平(比值為1)，驗(yàn)證了ceph云存儲(chǔ)系統(tǒng)的默認(rèn)塊操作單位為64kB。

3) 文件系統(tǒng)層在順序?qū)懙那闆r下，如果記錄塊小于64kB，則會(huì)先將若干個(gè)記錄塊在緩存中拼接為64kB，再往下層的存儲(chǔ)層寫，一個(gè)單位塊寫完之后才算一次IO完成。所以，在塊大小沒有超過(guò)64kB的時(shí)候，文件系統(tǒng)層的IOPS是基本不變的，即都相當(dāng)于64kB順序?qū)?，而?dāng)塊大于64kB之后，需要將記錄塊先拆分為64kB的單位，然后以64kB為單位向存儲(chǔ)層寫，只有所有的子記錄塊寫完，才會(huì)通知文件系統(tǒng)層1次IO完成。所以，在這種情況下，基本上文件系統(tǒng)層的記錄塊大小每增加1倍，其IOPS就下降1倍。

4) 對(duì)于隨機(jī)讀寫，由于其隨機(jī)性使得文件系統(tǒng)層的記錄塊預(yù)讀以及磁盤順序讀寫的優(yōu)勢(shì)無(wú)法發(fā)揮，所以不論在存儲(chǔ)層或在文件系統(tǒng)層其IOPS性能都是最低的。但是在隨機(jī)讀寫的時(shí)候，依然是按照64kB單位進(jìn)行，所以塊大小達(dá)到64kB之前，其IOPS基本不變，超過(guò)64kB之后IOPS有下降趨勢(shì)，原因與順序?qū)戭愃?。另外隨機(jī)讀寫的吞吐率增加是因?yàn)殡S著記錄塊的增大，隨機(jī)讀寫的模式逐漸靠近順序讀寫，順序?qū)懙耐掏侣试龃蟮内厔?shì)使得隨機(jī)讀寫的吞吐率也有增大的趨勢(shì)。

圖7　存儲(chǔ)層吞吐率　　　　　　圖8　文件系統(tǒng)層吞吐率圖9　吞吐率比值(文件系統(tǒng)層/存儲(chǔ)層)

3.2.2吞吐率

由圖7～圖9可以看出，存儲(chǔ)層的順序讀吞吐率整體上保持不變，文件系統(tǒng)層的順序讀吞吐率有微小的增長(zhǎng)趨勢(shì)，而其他讀寫模式的吞吐率基本保持線性增長(zhǎng)，在塊大小達(dá)到4MB的時(shí)候停止。文件系統(tǒng)層與存儲(chǔ)層的性能比值大致保持穩(wěn)定，其中順序讀的比值約為0.5，隨機(jī)讀寫的比值約為0.2，而順序?qū)懙谋戎导s為0.1。這說(shuō)明，ceph云存儲(chǔ)系統(tǒng)從文件系統(tǒng)層到存儲(chǔ)層進(jìn)行操作時(shí)存在比較嚴(yán)重的讀寫放大問(wèn)題，特別是寫操作，很大程度上浪費(fèi)了存儲(chǔ)層的性能資源。

綜合各個(gè)系統(tǒng)層的性能數(shù)據(jù)，通過(guò)對(duì)比分析可以得出以下結(jié)論：

1)ceph云存儲(chǔ)系統(tǒng)具有良好的順序讀寫性能，其中順序讀操作最能夠充分利用底層存儲(chǔ)層的性能，順序?qū)懖僮鲗?duì)底層存儲(chǔ)層性能的利用率較低(吞吐率比值只有0.1左右)，隨機(jī)讀寫的性能最差，對(duì)底層存儲(chǔ)層的利用率介于上述二者之間，但是由于存儲(chǔ)層本身的隨機(jī)讀寫性能本身較差，所以造成上層的隨機(jī)讀寫性能無(wú)法有效提高。因此，ceph云存儲(chǔ)系統(tǒng)最佳應(yīng)用場(chǎng)景是大文件順序讀占絕大多數(shù)的應(yīng)用，如視頻分享網(wǎng)站等，而不適合小文件隨機(jī)讀寫，例如一般的數(shù)據(jù)庫(kù)操作。

2) 總體上ceph存儲(chǔ)層的性能越高則分布式文件系統(tǒng)層性能越高，2個(gè)層次上的讀寫吞吐率比值基本保持穩(wěn)定，但是在塊大小為4MB時(shí)遇到了瓶頸。如果以傳統(tǒng)的經(jīng)驗(yàn)分析，則一般會(huì)認(rèn)為系統(tǒng)瓶頸就是存儲(chǔ)層性能瓶頸，也就是磁盤性能瓶頸，換性能更高的磁盤或者使用SSD、內(nèi)存盤等即可改善系統(tǒng)性能。這樣做雖然能一定程度上優(yōu)化系統(tǒng)，但代價(jià)較高，且會(huì)引入其他棘手的問(wèn)題(如SSD的寫壽命問(wèn)題)。通過(guò)分層性能監(jiān)測(cè)和采集的方法，綜合分析可以判斷，本實(shí)驗(yàn)中ceph系統(tǒng)在用于大文件讀寫時(shí)存在的系統(tǒng)性能瓶頸實(shí)際上在于文件系統(tǒng)層，即文件系統(tǒng)默認(rèn)塊大小的限制以及讀寫放大問(wèn)題的限制。要真正改善系統(tǒng)，就要針對(duì)這2個(gè)具體的瓶頸入手，一是設(shè)置大一些的默認(rèn)塊(如128kB或更大)，二是對(duì)系統(tǒng)的讀寫算法進(jìn)行修改，減小讀寫放大。

4結(jié)論

本文提出了一種云存儲(chǔ)系統(tǒng)分層性能監(jiān)測(cè)和采集的框架及對(duì)各系統(tǒng)層性能信息進(jìn)行綜合分析的方法，能夠簡(jiǎn)便地確定云存儲(chǔ)系統(tǒng)的應(yīng)用場(chǎng)景以及定位系統(tǒng)性能瓶頸，并在開源云存儲(chǔ)系統(tǒng)ceph上進(jìn)行了實(shí)驗(yàn)，驗(yàn)證了本文所提出方法的可用性。

就目前查到的資料來(lái)看，通過(guò)對(duì)云存儲(chǔ)系統(tǒng)進(jìn)行分層的性能監(jiān)測(cè)和采集，然后進(jìn)行整體分析來(lái)確定其應(yīng)用場(chǎng)景和定位性能瓶頸，是一種新的思路。本文提出的方法目前只在ceph云存儲(chǔ)系統(tǒng)上進(jìn)行了驗(yàn)證，未來(lái)還需要在其他類型的主流云存儲(chǔ)系統(tǒng)上(例如Hadoop云存儲(chǔ))進(jìn)行實(shí)驗(yàn)，以完善和改進(jìn)分層采集框架和分析方法。另外，本文所提出的分析方法目前還沒有實(shí)現(xiàn)完全的自動(dòng)化，未來(lái)可以考慮實(shí)現(xiàn)分層性能數(shù)據(jù)的自動(dòng)處理，為評(píng)估人員提供最終的報(bào)表以作進(jìn)一步分析。

參考文獻(xiàn)：

[1]InternationalDataCorporation(IDC).BigData-TheChallengesandtheOpportunity(2013-10-31),http://nextgendistribution.com.au/industry-trends/big-data-challenges-opportunity/

[2]AntoniouA.PerformanceEvaluationofCloudInfrastructureUsingComplexWorkloads[D].DelftUniversityofTechnology,

2012

[3]CooperBF,SilbersteinA,TamE,etal.BenchmarkingCloudServingSystemswithYCSB[C]∥Proceedingsofthe1stACMSymposiumonCloudComputing, 2010: 143-154

[4]ZhangX,FengWX,QinX.PerformanceEvaluationofOnlineBackupCloudStorage[J].InternationalJournalofCloudApplicationsandComputing, 2013, 3(3): 20-33

[5]TanJ,KavulyaS,GandhiR,etal.Visual,Log-BasedCausalTracingforPerformanceDebuggingofMapReduceSystems[C]∥30thIEEEInternationalConferenceonDistributedComputingSystems, 2010: 795-806

[6]ChenY,SrinivasanK,GoodsonG,etal.DesignImplicationsforEnterpriseStorageSystemsviaMulti-DimensionalTraceAnalysis[C]∥ProceedingsoftheTwenty-ThirdACMSymposiumonOperatingSystemsPrinciples, 2011:43-56

[7]BallaniH,CostaP,KaragiannisT,etal.TowardsPredictableDatacenterNetworks[C]∥ACMComputerCommunicationReviewofSpecialInterestGrouponDataCommunication, 2011, 41(4): 242-253

[8]BenjaminHSigelman,LuizAndreBarroso,MikeBurrows,etal.Dapper,aLarge-ScaleDistributedSystemsTracingInfrastructure[R].GoogleResearch,2010

[9]BoulonJ,KonwinskiA,QiR,etal.Chukwa,ALarge-ScaleMonitoringSystem[C]∥ProceedingsofComputabilityandComplexityinAnalysis. 2008, 8: 1-5

[10]KutareM,EisenhauerG,WangC,etal.Monalytics:OnlineMonitoringandAnalyticsforManagingLargeScaleDataCenters[C]∥Proceedingsofthe7thInternationalConferenceonAutonomicComputing,2010:141-150

[11]WangYA,HuangC,LiJ,etal.EstimatingthePerformanceofHypotheticalCloudServiceDeployments:AMeasurement-BasedApproach[C]∥IEEEInternationalConferenceonComputerCommunications,2011: 2372-2380

[12]NoorshamsQ,BruhnD,KounevS,etal.PredictivePerformanceModelingofVirtualizedStorageSystemsUsingOptimizedStatisticalRegressionTechniques[C]∥Proceedingsofthe4thACM/SPECInternationalConferenceonPerformanceEngineering, 2013: 283-294

[13] 施楊斌, 吳杰, 梁瑾. 云存儲(chǔ)上的I/O特征獲取機(jī)制[J]. 計(jì)算機(jī)工程與設(shè)計(jì), 2011, 32(8):2870-2873

ShiYangbin,WuJie,LiangJin.EfficientI/OCharacteristicsCollectionMethodonCloudStorage[J].ComputerEngineeringandDesign, 2011,32(8):2870-2873 (inChinese)

[14]MassieML,ChunBN,CullerDE.TheGangliaDistributedMonitoringSystem:Design,ImplementationandExperience[J].ParallelComputing, 2003, 30(7):817-840

收稿日期：2015-10-22基金項(xiàng)目：國(guó)家“863”重大項(xiàng)目(2013AA01A215)、自然科學(xué)基金面上項(xiàng)目(61472323)、西北工業(yè)大學(xué)基礎(chǔ)研究基金(3102015JSJ0009)及高效能服務(wù)器和存儲(chǔ)技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室開放基金(2014HSSA11)資助

作者簡(jiǎn)介：王海濤(1990—)，西北工業(yè)大學(xué)博士研究生，主要從事云存儲(chǔ)的研究。

中圖分類號(hào)：TP391

文獻(xiàn)標(biāo)志碼：A

文章編號(hào):1000-2758(2016)03-029-07

ALayeredPerformanceMonitoringandGatheringMethodofCloudStorage

HaitaoWang1,ZhanhuaiLi1,XiaoZhang1,2

1.School of Computer Science, Northwestern Polytechnical University, Xi′an 710129, China 2.State Key Laboratory of High-End Server and Storage Technology, Jinan 250101, China

Abstract:In order to solve the problem that existing cloud storage monitoring methods can′t obtain the whole system characters to find the best application scenario or perform failure analysis, this paper reviewed the models that used to monitor and gather performance data on system layers of cloud storage system, and proposed a frmework which can evaluate the whole system by gathering and analyzing performance information of main layers in cloud storage according to it′s layered architecture. This framework can gather performance data of system layers to do further analysis, determine the best application scenario and locate system bottlenecks, then provide some optimized advises to improve the system. In the end, an experiment was conducted on the ceph cloud storage system using this method, the result verified the availability of proposed method.

Keywords:cloud storage; performance evaluation; monitoring model; failure analysis