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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1存儲層

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

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

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

2.2基礎(chǔ)管理層

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

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

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

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

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

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

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

1) 監(jiān)測代理

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

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

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

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

3云存儲系統(tǒng)ceph的實驗分析

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

3.1實驗設(shè)計

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

表1　實驗節(jié)點的配置

圖3　實驗系統(tǒng)架構(gòu)

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

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

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

3.2實驗結(jié)果與分析

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

3.2.1IOPS

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

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

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

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

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

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

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

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

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

3.2.2吞吐率

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

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

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

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

4結(jié)論

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

就目前查到的資料來看，通過對云存儲系統(tǒng)進(jìn)行分層的性能監(jiān)測和采集，然后進(jìn)行整體分析來確定其應(yīng)用場景和定位性能瓶頸，是一種新的思路。本文提出的方法目前只在ceph云存儲系統(tǒng)上進(jìn)行了驗證，未來還需要在其他類型的主流云存儲系統(tǒng)上(例如Hadoop云存儲)進(jìn)行實驗，以完善和改進(jìn)分層采集框架和分析方法。另外，本文所提出的分析方法目前還沒有實現(xiàn)完全的自動化，未來可以考慮實現(xiàn)分層性能數(shù)據(jù)的自動處理，為評估人員提供最終的報表以作進(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] 施楊斌, 吳杰, 梁瑾. 云存儲上的I/O特征獲取機(jī)制[J]. 計算機(jī)工程與設(shè)計, 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基金項目：國家“863”重大項目(2013AA01A215)、自然科學(xué)基金面上項目(61472323)、西北工業(yè)大學(xué)基礎(chǔ)研究基金(3102015JSJ0009)及高效能服務(wù)器和存儲技術(shù)國家重點實驗室開放基金(2014HSSA11)資助

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

中圖分類號：TP391

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

文章編號: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