一種云存儲系統分層性能監測和采集方法

王海濤, 李戰懷, 張曉,2

1.西北工業大學 計算機學院, 陜西 西安　710129 2.高效能服務器和存儲技術國家重點實驗室, 山東 濟南　250101

?

一種云存儲系統分層性能監測和采集方法

王海濤1, 李戰懷1, 張曉1,2

1.西北工業大學 計算機學院, 陜西 西安710129 2.高效能服務器和存儲技術國家重點實驗室, 山東 濟南250101

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

關鍵詞：云存儲；分層架構；性能監測；數據采集

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

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

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

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

卡內基梅隆大學提出了一種通過日志分析進行系統性能瓶頸檢測并進行性能優化的方法[5]。伯克利大學和Netapp公司也對實際環境中的Trace進行了分析，通過面向對象和多尺度的統計方法，得出了網絡訪問負載規律，并將其用于數據管理優化和Cache性能優化[6]。微軟公司設計了Oktopus，通過增加一層抽象的網絡層，監測多租戶和云環境下的數據中心網絡性能[7]。Amazon的CloudWatch，Hyperic的CloudStatus可對Amzon的EC2和S3進行測量。Google的Dapper[8]是根據其自身業務特點和需求開發的一個大規模分布式系統監控框架，實現了廣泛可部署性和不間斷監控2個設計目標，可以對幾乎所有的Google后臺服務器進行監控，并在新服務部署、定位長尾延時、推斷服務間的依存關系等方面，為開發者和系統管理人員提供了重要的技術支持。

此外，也有一些開源項目可以對云存儲系統性能進行監測。Chukwa[9]是建立在開源云計算平臺Hadoop基礎上的數據收集系統，用于大規模云計算平臺的監測和分析。Monalytics[10]是一個集成云計算平臺監測和數據分析2個關鍵功能的監測系統，能夠實現數據中心的性能感知負載均衡、實時異常檢測、異常放大分析等功能。CloudBeacon[11]可以實現云計算平臺中網絡性能的測量和預測。

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

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

1云存儲系統分層結構

云存儲系統的分層架構如圖1所示。其中：存儲層、基礎管理層位于服務端，屬于云存儲的系統層；而應用接口層與應用訪問層聯系緊密，并且與客戶端的環境密切相關，所以在這里將其歸于用戶層。用戶層的性能不能夠反映云存儲系統的整體性能，還需要關注云存儲的系統層的性能，所以下面將集中討論存儲層和基礎管理層的性能監測和采集。

圖1　云存儲系統的分層架構

2云存儲系統層性能監測和數據采集

目前有一些方法和工具可以對云存儲的單個系統層次進行監測和數據采集，下面分層次討論這些方法。

2.1存儲層

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

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

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

2.2基礎管理層

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

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

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

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

分布式文件系統是云存儲基礎管理層中的核心，在實際對云存儲進行監測時，需要針對特定的分布式文件系統選擇合適的監測方法。

2.3分層性能監測和采集框架

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

1) 監測代理

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

圖2　分層監測與采集框架

2) 監測服務器

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

3云存儲系統ceph的實驗分析

根據圖2所示的分層性能監測與數據采集框架，對典型的云存儲系統ceph進行了性能數據的采集和綜合分析，以驗證本文方法的可用性。

3.1實驗設計

本文實驗包括7個linux節點，這7個節點的配置見表1，實驗系統的架構如圖3所示。

表1　實驗節點的配置

圖3　實驗系統架構

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

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

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

3.2實驗結果與分析

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

3.2.1IOPS

由圖4～圖6，可以觀察到以下現象：

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

隨著讀寫記錄塊的增大，存儲層IOPS基本保持穩定，文件系統層順序讀IOPS隨著記錄塊的增大成指數型下降，并且在塊大小達到64kB時，與存儲層順序讀IOPS相等。文件系統層順序寫IOPS在塊大小達到64kB之前保持穩定，在塊大小超過64kB以后，塊大小每增加一倍，IOPS就大約下降一倍。隨機讀寫的規律與順序寫的類似，但是IOPS性能最差。

通過對上述現象進行分析可以得出：

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

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

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

4) 對于隨機讀寫，由于其隨機性使得文件系統層的記錄塊預讀以及磁盤順序讀寫的優勢無法發揮，所以不論在存儲層或在文件系統層其IOPS性能都是最低的。但是在隨機讀寫的時候，依然是按照64kB單位進行，所以塊大小達到64kB之前，其IOPS基本不變，超過64kB之后IOPS有下降趨勢，原因與順序寫類似。另外隨機讀寫的吞吐率增加是因為隨著記錄塊的增大，隨機讀寫的模式逐漸靠近順序讀寫，順序寫的吞吐率增大的趨勢使得隨機讀寫的吞吐率也有增大的趨勢。

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

3.2.2吞吐率

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

綜合各個系統層的性能數據，通過對比分析可以得出以下結論：

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

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

4結論

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

就目前查到的資料來看，通過對云存儲系統進行分層的性能監測和采集，然后進行整體分析來確定其應用場景和定位性能瓶頸，是一種新的思路。本文提出的方法目前只在ceph云存儲系統上進行了驗證，未來還需要在其他類型的主流云存儲系統上(例如Hadoop云存儲)進行實驗，以完善和改進分層采集框架和分析方法。另外，本文所提出的分析方法目前還沒有實現完全的自動化，未來可以考慮實現分層性能數據的自動處理，為評估人員提供最終的報表以作進一步分析。

參考文獻：

[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]. 計算機工程與設計, 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)、自然科學基金面上項目(61472323)、西北工業大學基礎研究基金(3102015JSJ0009)及高效能服務器和存儲技術國家重點實驗室開放基金(2014HSSA11)資助

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

中圖分類號：TP391

文獻標志碼：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