一種輕量級分布式塊存儲的QoS方法*

王利朋 胡明生 賈志娟 張 玉

（鄭州師范學院信息科學與技術學院 鄭州 450044）

1 引言

QoS（Quality of Service）即配額，為服務系統提供了針對不同用戶或者不同數據流的不同優先級服務的能力。在計算機網絡領域中，QoS能夠在滿足用戶需求的前提下，提供了避免網絡延遲和擁塞的能力［1～2］；在電信領域，尤其在電話、電視、視頻會議等一些對服務質量要求很高的多媒體服務領域，QoS能夠根據不同需求定制服務，提供不同優先級服務能力；在存儲領域，QoS能夠根據系統配置，將IO數據流按照優先級進行資源分配，提高了存儲的服務質量［3～4］。

云計算時代，資源調度是一項非常困難的研究課題，這是由于數據中心規模龐大、資源類型復雜、以及云計算構件具有可變性和不可預測性［5］。作為云計算公有基礎設施之一的云存儲，對于資源有限的場景來說，如何根據用戶對存儲性能的需求進而為用戶提供滿足其需求的服務便成為一種重要的研究課題。一般QoS限定的對象有IOPS、帶寬、時延、抖動、丟包率等，具體在分布式存儲領域，常用的主要是帶寬和IOPS，而限定的指標主要有權重（weight）、預留（reservation）、上限（limit）。

作為近年來熱門的統一分布式存儲系統，Ceph已在科研領域得到廣泛關注。Ceph本質上是一個分布式對象存儲系統，它首次提出了一種通過計算來獲取存儲位置的數據分配的算法，稱為CRUSH算法，具有良好的容錯自修復能力［6～8］，與大多數存儲系統采用表結構來維護數據到存放位置映射關系的實現不同［9～11］，上述方法避免了因查詢元數據服務器而引入性能瓶頸的問題，同時緩解了增刪存儲設備時帶來的數據遷移問題。李翔對CRUSH算法和其對象存儲服務進行了詳細的分析，指出了Ceph在擴展性和可靠性方面，相對于現有的存儲系統具備較大的優勢［12］。作為一個PB級的開源系統，Ceph已在工業圈得到廣泛應用［13］。

實現QoS的一般方法都是統計每個連接傳輸的數據量，然后根據預定義的流量額度對傳輸進行控制［14］。Mrittika等提出一種分布式存儲中實現動態QoS的方法［15］，該方法首先確定存儲節點的能力，并度量達到目標服務質量所關聯的性能指標，然后動態地確定分布式存儲集群中計算設備的配置信息以實現定制服務的目的，本方法通過調度物理層資源進而動態實現QoS。

思科改進了兩種分別稱為shaping和policing的流控方法，這兩種方法均是基于令牌桶算法。policing方法是將超過限制的流量直接舍棄，輸出的波形呈現出一種具有波峰的鋸齒，而shaping的方法是將數據直接緩存起來，然后按照時間序列以一定速率發送出去，輸出的波形是一種平滑曲線［16］。這兩種方法作為一種網絡層資源調度算法，主要應用于數據中心的帶寬控制。Ajay等［17］提出了一種分布式存儲系統中對權重、預留和上限進行IO資源調度的dmClock算法，該算法能夠對滿足預留和上限的IO資源按照權重進行資源調度。

具體在云計算環境中，針對共享存儲設備的虛擬機不能規劃資源以及系統管理員不能為運行同一服務的不同虛擬機分配共享資源的問題，Ajay等［18］提出一種稱為SRP的IO資源分配方法，SRP可以將一組虛擬機劃分到一個邏輯組中，邏輯組又稱為pool，SRP能夠支持邏輯組級或虛擬機級別的權重、預留和上限的限定。在SSD的復合IO應用場景中，當多虛擬機共享SSD資源時，存在資源利用率低的問題，尤其在突發IO流應用場景中，Yang等［19］提出了一種稱為GREM的方法，GREM將SSD作為一種二級緩存，將整個SSD切分長期域和短期域，動態調整長期域中運行的虛擬機的IO的預留，以更充分地調用SSD資源。

由于分布式存儲系統存在集群節點拓撲結構多樣化、資源調度復雜等問題，實現能夠同時對IOPS和帶寬進行輕量級資源調度的方法十分有必要，本文將針對這一問題進行相應的研究。

2 相關工作

目前在分布式存儲系統中實現QoS存在兩種可能的實現算法，分別是經典令牌桶算法和dmClock算法［17］，下面將分別對其進行討論。

經典令牌桶算法實現分布式存儲QoS功能，原理就是通過監督進入存儲網絡端口的流量速率，對超出流量進行懲罰，調配各客戶端IO，使IO輸出輸入性能在預設范圍內。令牌桶中令牌會在后臺按照預設速度自動添加，令牌桶具有最大容量限制，如果令牌桶中的令牌數超過了該最大容量，新添加的令牌將會溢出。需要說明的是，令牌桶中令牌更新過程與限定IO過程一般是異步執行的。

經典令牌桶算法的原理示意圖如圖1所示。

圖1 令牌桶算法圖解

經典令牌桶算法一般實現在客戶端，一旦出現故障，只會影響當前用戶的數據傳輸，而不會將故障傳播給其他用戶，另外算法復雜度低，且由于沒有在分布式存儲服務端節點引入額外操作，對底層存儲系統的性能幾乎無影響。

然而由于會存在以下三個問題，是無法直接將經典令牌桶算法應用到分布式存儲中來限定IOPS和帶寬。首先添加令牌流程依賴于系統時間，如果系統時間出現異常，會導致經典令牌桶算法出現故障。其次在限定帶寬時，一次IO可能會需要一批令牌，如果令牌數不能滿足本次IO需求，本次IO便會被阻塞，只有等到桶中生成足夠多令牌后，數據流才會恢復執行，這一阻塞過程導致底層存儲資源不能得到有效使用，當表現在上層客戶端時，此時出現的現象就是IO劇烈抖動。最后在限定帶寬時，IO數據長度并不固定，而經典令牌桶算法存在最大容量限制，如果某次IO數據長度超過令牌桶最大容量，則會導致本次IO因為不會獲得足夠令牌而無限期阻塞。

為了解決分布式存儲資源調度問題，近些年來提出了dmClock算法，能夠在分布式存儲系統中實現Qos功能，且功能相對于經典令牌桶算法更為強大。dmClock算法能夠對分布式存儲I∕O資源的三種指標進行限定，分別是：權重（weight，縮寫w，客戶端占共享IO資源的比重）、預留（reservation，縮寫r，客戶端獲得的最小IO資源）、上限（limit，縮寫l，客戶端可獲得的最高IO資源）。例如在對存儲系統IOPS進行限定時，dmClock算法首先保證輸出IOPS的最小值，對于沒有超過最大IOPS的IO資源，按權重再重新進行分配。

dmClock算法主要步驟如下［20］：

1）指定參數值，包括r、w和l，服務端據此計算出IO請求預期被處理的時間標簽。

2）服務端處理滿足r標簽的請求。

3）服務端處理滿足l標簽請求前提下的w標簽請求。

這里的時間標簽是指某個請求預期被服務器處理的時間戳，如果以qi表示客戶機i的指定參數值，表示客戶機i的第r個請求對應的時間標簽，則其計算公式如下所示：

在應用到分布式存儲領域時，作為一種分布式調度算法，dmClock本身也存在一定問題。首先dmClock算法需要實現在存儲系統服務端底層的數據分派模塊中，一旦該算法出現錯誤，會導致整個存儲系統崩潰，導致數據丟失，影響系統可用性；其次dmClock算法需要依賴數據存儲端和客戶端協同進行限流處理，算法復雜度高，會降低存儲系統的整體性能。

3 算法優化

3.1 方案架構

提出一種開源分布式存儲系統Ceph塊存儲的QoS方案，方案以改進后的經典令牌桶算法進行實現，能夠對IOPS和帶寬同時進行限流。為了方便論述，新算法稱為dbstb算法（Distributed Block Storage based on Token Bucket，dbstb），新算法包含了IOPS限流和帶寬限流兩個部分。

dbstb算法吸收了經典令牌桶算法中的概念，令牌是控制IO是否執行的標記，令牌桶是存儲令牌的存儲池，令牌桶具有最大容量。為了方便論述，對幾個重要參數進行標記。

1）限定速率V：限定單位時間內發送數據的速度。

2）令牌桶最大容量MAX：用于突發流量控制。

3）時間間隔Interval：向令牌桶添加令牌的間隔時間。

4）等待時間β：所需令牌不能滿足時，IO阻塞的時間。

為了使阻塞時間最小，同時盡可能使當前令牌數滿足本次IO所需數目，β的最小值滿足以下條件：βmin=max{bs/V，Interval}，其中 bs為本次IO的數據長度。

在進行限流操作時，假如需要n支令牌，首先判斷當前令牌桶是否存在n支令牌，如果當前令牌桶中令牌數少于n，則本次IO將會被阻塞，阻塞時間為β。如果當前令牌桶中令牌數等于或超過n，則從中取出n支令牌，并允許本次IO執行。在限流的同時，令牌桶中令牌添加過程作為后臺線程異步執行，每隔1/Interval秒向令牌桶中添加V×Interval支令牌。如果令牌桶中的令牌數超過了MAX，新添加令牌將會溢出，也就是說令牌桶填滿令牌的時間是由令牌桶最大容量、令牌填充速度和令牌流出速度三個方面共同決定的。

dbstb算法具備一定的應對突發IO洪流的作用，也就是允許某種程度的突發傳輸。在存儲領域，這種場景包括了開機風暴等。具體在dbstb算法中，是通過MAX參數進行控制。

需要說明的是，對于不同限流場景，令牌對應的指標并不相同，一般以字節數、比特數或IO次數等為目標對象。例如在限定IOPS場景中，若IOPS上限為100，此時一次IO對應了一支令牌。若限定此時令牌桶最大大小為120，在對客戶IO進行限定時，dbstb算法保證每秒向令牌桶中添加100支令牌，如果桶中令牌數量超過120，生成的令牌將會被丟棄。將令牌桶最大容量設置為120，表示允許最大為120 IOPS的IO突發洪流。當用戶每發送一次IO，令牌桶中令牌減少1，如果令牌桶中令牌為空，則本次IO就會被阻塞一定時間。dbstb算法在限定帶寬時，此時一支令牌對應1Byte。如果當前IO的數據長度為100Bytes，則必須要從令牌桶中取100支令牌才能允許本次IO繼續執行。

dbstb算法主要是對Ceph塊存儲進行IOPS和帶寬的上限控制，且對讀寫操作分別進行限定，需要說明的是本研究對混合讀寫操作同樣適用。

dbstb算法對Ceph進行適配時，會為每一個卷操作分別定義四個令牌桶，分別為讀IOPS令牌桶、寫IOPS令牌桶、讀帶寬令牌桶和寫帶寬令牌桶。在Ceph中，用戶可以為指定卷設定讀寫操作對應的IOPS和帶寬上限值，限定值作為卷屬性被存儲起來，這樣即使限流模塊出現故障，用戶配置也不會丟失。Ceph中有相應的默認配置參數，也就是模板參數，用戶也可以不用顯式設定對應的選項值。dbstb算法對應的模板參數包括讀IOPS限定值riops、讀帶寬限定值rbw、寫IOPS限定值wiops、寫帶寬限定值wbw以及QoS開關選項sqos，其中sqos∈｛True，False｝，True代表開啟 QoS，False代表關閉QoS。

在將dbstb算法適配到Ceph時，創建卷時候，首先讀取集群限流模板參數{riops，rbw，wiops，wbw，sqos}，然后將模板參數作為卷屬性存儲到存儲集群中。刪除卷的時候，不需要引入額外的操作，Ceph原始流程會刪除限流參數信息。在修改限流參數時，Ceph提供了相應的操作接口，可方便修改限流配置信息。

在讀寫卷數據時，卷對應的限流配置會從底層存儲中讀取上來，并用這些值初始化對應的令牌桶。在基于dbstb算法對卷數據讀寫IO執行限流操作時，步驟如下所示。

1）讀取卷限流配置，如果不存在，則從模板參數中獲取，并以卷屬性形式寫入到后端存儲中。

2）判斷sqos是否為True，如果為False跳至第五步。

3）基于dbstb算法IOPS限定步驟對IOPS執行限流。

4）基于dbstb算法帶寬限定步驟對帶寬執行限流。

5）將IO數據下發至底層存儲中。

其中步驟3）和步驟4）將會在后面兩節中分別進行闡述。

卷限流模塊實現在Ceph的讀寫API接口中，以Ceph 10.2.3為例，塊存儲讀寫數據的API接口如表1所示。執行成功一次API函數，對存儲系統來說，就是執行成功一次IO操作，此時便對應了1個IOPS。如果用戶在1s內成功調用10次IO函數，此時存儲系統端的測出的IOPS便是10。對帶寬而言，則是對應于這些API接口函數中單位時間中數據塊累加長度。本文在對IOPS和帶寬進行限定時，需要在這些接口函數中進行實現，需要說明的是在對帶寬限定時，為了減少性能抖動，需要分塊操作后執行帶寬限流操作。

表1 Ceph的RBD端讀寫接口

3.2 dbstb限定IOPS流程

客戶端在每發送一次IO，便需要在IOPS令牌桶中申請一支令牌，如果申請不到，本次IO便會被阻塞，直到獲取到足夠令牌后，本次IO才會恢復執行。

dbstb算法限定IOPS流程中更新令牌的算法如下所示：

其中：MAXiops=αiops×Viops，MAXiops代表IOPS令牌桶中令牌的最大容量，αiops主要用于應對IO洪峰，αiops≥1。Tiops(i)代表第i次IO操作時令牌桶中的令牌數量，另外令Tiops(1)=0。Viops為IOPS限定值，代表向令牌桶中添加令牌的速度。Interval代表本次IO操作與上一次IO操作之間的時間差，以秒為單位，第一次迭代時，該數值為1。

dbstb算法限定IOPS的算法步驟如下所示。

1）判斷是否開啟QoS功能，如果沒有，則跳轉至最后一步繼續執行。

2）根據式（2）更新IOPS令牌桶中令牌數量。

3）判斷IOPS令牌桶中令牌數是否為0，如果是，則休眠β秒后，返回步驟2）繼續執行。

4）IOPS令牌桶中令牌數減1。

5）將本次IO下發至底層存儲系統中。

當令牌桶中元素個數為0時，則睡眠 βs，β≥max{bs/Viops，Interval}。如果 β 過大，令牌桶中令牌消耗完后，會導致客戶端的IO在βs內下發不下去，進而導致IO出現性能抖動，為了避免這種情況，一般設置 β≤1。

迭代剛開始時，也就是i=1時，給定Viops，Tiops(1)初始化為0，此時 Interval初始化為1，一般將αiops=1.2，β=1，此時 MAXiops=1.2Viops。

3.3 dbstb限定帶寬流程

dbstb算法在對帶寬進行限流時，一個Byte對應一支令牌，每發送m Bytes的數據，便需要m支令牌，否則便會阻塞IO，一直等到令牌桶中生成所需的令牌數為止。需要說明的是，與IOPS限定策略不同，帶寬限定策略是在分布式存儲讀寫接口函數完成分片之后，在對每片數據下發IO的時候再執行帶寬控制流程。

dbstb算法限定帶寬流程中令牌桶更新步驟與IOPS令牌桶更新的策略類似，其更新算法如下所示。

其中bs(i+1)為第i+1次迭代時IO數據的長度，Tbw(i)代表第i次迭代時帶寬令牌桶中的令牌數量，Vbw表示帶寬限定值，Interval代表本次IO操作與上一次IO操作之間的時間差，以秒為單位，第一次迭代時，該數值為1。abw主要用于IO洪峰，αbw≥1。

需要說明的是，帶寬令牌桶最大容量并不是固定的，每次迭代時令牌桶最大容量都是變化的。這是由于如果某次IO的數據長度超過了令牌桶最大容量，本次IO操作將會永遠無法獲得足夠令牌數，導致本次IO無限阻塞。為了解決該問題，帶寬令牌桶最大容量不是固定的，而是根據數據塊大小和Vbw的變化而動態變化的。需要說明的是，如果IO數據塊大小波動較大，就會導致令牌桶最大容量變化劇烈，進而導致上層IO性能劇烈抖動。另外如果本次IO數據量大，就會導致需求令牌數較多，進而導致阻塞時間長，從而使得下層存儲資源一直處于空閑狀態。綜合上述兩種原因，需要先對數據塊進行分片，然后再執行帶寬控制策略。

dbstb算法限定帶寬的算法步驟如下所示。

1）IO數據塊按固定大小進行分片。

2）依次遍歷分片數據，并根據式（3）更新帶寬令牌桶中令牌數量。

3）判斷當前令牌桶中令牌數是否滿足所需數量，不滿足則阻塞。

4）帶寬令牌桶減去所需的令牌數。

5）向底層存儲下發數據，判斷是否遍歷完所有分片數據，如果沒有，則返回步驟2）繼續執行。

4 性能分析

4.1 可用性分析

在將dbstb算法適配到Ceph中時，可能會出現由于芯片故障或者惡意軟件等原因導致系統時間被修改的情形，這樣會導致分布式存儲軟件Ceph出現故障而中斷業務，影響系統的可用性。本文新提出的dbstb算法是基于一定時間間隔來更新令牌的，實現中是以開機時間進行計時，并不是采用系統時間，這樣也就意味著即使系統時間被惡意篡改，也不會影響算法的正常執行流程。

dbstb算法只在當前會話空間中生效，不同會話之間是相互獨立的，這樣也就意味著新算法僅對當前連接有效，一旦限流模塊出現故障并導致連接斷開，再次重連后，dbstb算法重置系統環境并繼續執行限流操作，故障不會傳遞給其他連接，同時也不會影響重連后數據操作流程。

dbstb算法會在創建和打開卷時進行初始化，若當前卷正在使用過程中，用戶重新設置算法相關參數，設置會立即生效，這一過程無須重啟服務，不會影響正常的業務流程，提高了存儲系統的可用性。

4.2 穩定性分析

一般情況下，上層客戶端一般會通過異步或同步IO模型向存儲系統發送數據。當使用異步模型發送IO數據時，使用經典令牌桶算法或某些改進算法在進行限流操作時，就會出現IO抖動問題，影響分布式存儲系統IO性能的穩定性。

由于IOPS和帶寬之間存在一定的對應關系，也就是 IOPS×bs=BandWidth，當同時對IOPS和帶寬進行限定時，某一時刻可能只有一項指標在起作用。例如塊大小為4K，IOPS限定為50，帶寬設定為512KB∕s，IOPS換算出對應的帶寬值是200KB∕s，取其最小值生效，顯然此時只有IOPS限定值起作用。為了方便論述，下文進行分析時，將以IOPS為例進行說明，帶寬的分析類似。

當客戶端異步IO引擎一次下發的IO數量Num剛超過2Viops時，檢測出的存儲系統IOPS數值會出現0、2Viops、0、2Viops…的劇烈抖動現象，下面將對此現象進行分析。經典令牌桶算法進行IOPS限定時，執行一次IO操作，便會消耗掉令牌桶中的一支令牌，如果當前令牌桶中沒有令牌，那么IO操作便會被阻塞。若異步IO一次性下發的IO請求數超過了令牌添加速度的兩倍，必將會導致某一時間段內令牌桶中令牌數不能滿足本次IO的需求量，進而阻塞IO，導致這一時間段內測量出的IOPS為0。此外由于經典令牌桶算法具有保證IOPS平均值等于Viops的特性，因此，實時測試結果便會出現上述所看到的劇烈抖動現象。

實際情況中，上層客戶端一次性下發的IO數量都在τ=128以下，也就是Num≤τ，下面證明當Viops＞(τ/2)時，則不會出現這種劇烈抖動現象。

定理1：Num=λViops，Num∈N ，Viops≥0，當Num≤τ而且Viops＞(τ/2)時，不會出現劇烈抖動現象。

證明：由前面分析可知，若使性能不出現抖動，應滿足0＜λ＜2，下面按不同情況進行分析。

當0＜λ≤1時，此時 Num≤Viops，可以得知令牌桶添加令牌的速度大于等于用戶一次性下發的IO數量，用戶下發的IO能夠一次性得到處理，此時不會出現劇烈抖動現象。

綜上可知，當 Num≤τ而且Viops＞(τ/2)時，不會出現劇烈抖動現象。為避免出現劇烈抖動現象，推薦IOPS上限的最小值應該設為τ/2=64，也就是Viops＞64。

一般使用場景中，滿足用戶業務需求的IOPS一般都在100以上，故可將Viops的范圍定義為［100，1000000］。之所以設置為1000000，是因為實際中很少會用到這么大數值，此外也可以避免因用戶誤輸入引發數據越界問題。需要說明的是，為了衡量引入限流模塊后對系統性能的影響，可將Viops設置為最大值1000000，同時開啟QoS功能，此時雖然限流模塊已打開，但處于空轉狀態。

4.3 數據安全性分析

在實際應用場景中，由于程序Bug或其它原因可能會導致卷限流模塊出現故障，可能會導致IO不能正常下發，嚴重情況下會導致連接崩潰。下文將分析dbstb算法即使在故障業務場景中，仍然能夠保證數據完整性。

上層客戶端的操作系統一般都實現了IO數據恢復的事務性機制，如果存儲端限流模塊出現故障，會導致存儲端沒有向客戶端返回讀寫成功標記，此時客戶端操作系統仍能保證數據的完整性。下面將分兩個場景對dbstb算法的數據安全性進行論述。

如果操作系統在向分布式存儲端發起IO請求時，如果此時限流模塊發生故障并導致會話中斷，分布式存儲端并沒有成功下發IO請求，此時也不會向客戶端返回操作成功的消息。恢復連接后，由于操作系統沒有收到IO操作成功消息，操作系統會重新發送IO請求。

第二個場景是分布式存儲端成功執行IO操作，在向上層客戶端操作系統發送IO執行成功消息之后，限流模塊發生了故障。由于此時IO請求已經執行成功，同時操作系統也認為數據已經寫入到存儲端，故障恢復后，操作系統同樣能夠正常運行。

5 實驗結果和分析

5.1 實驗設計

在對IOPS和帶寬進行限流時，會存在多種因素會影響限流效果，例如常見的幾種操作系統都會合并順序IO，導致在客戶端觀察到的數值會高于存儲端測試出來的IOPS和帶寬值。如前文分析可知，IOPS、塊大小和帶寬之間存在對應關系，IOPS和帶寬兩者之間的限流效果會相互影響。因此，在實驗設計時，將會綜合考慮這些因素，統一環境配置，為IOPS和帶寬設計出對應的測試方法。

為了避免操作系統合并IO對實驗結果的影響，本研究將會利用FIO工具調用Ceph的RBD引擎進行測試，同時只考察隨機IO。FIO詳細配置如圖2所示。

圖2 FIO的配置參數

對于隨機讀（randR）、隨機寫（randW）、順序讀（seqR）和順序寫（seqW），限流模塊并不能對其進行區分，因此，對于IO操作類型，例如讀寫、隨機順序等區別不做考察。

本實驗將對常見的三種應用場景進行測試，分別是遠程桌面（Remote Desktop，RD）、在線事務處理（Online Transaction Processing，OLTP）和數據遷移（Data Migration，DM）。對于這三種業務流，RD是一種高IOPS低帶寬應用場景，OLTP是一種高IOPS高帶寬應用場景，而DM則是高帶寬低IOPS、分塊數據較大的應用場景。這三種應用場景對應的參數設置如表2所示，需要注意的是這里的數值并不代表真實場景對應的數值，而只是模擬場景下的實驗參數。這三種業務流，均是采用FIO工具進行模擬，在后續實驗中，將分別在虛擬機上按照這三種應用場景的配置來執行FIO操作，以模擬這三種應用場景。

表2 三種應用場景對應的配置參數

在考察dbstb算法性能時，分布式存儲集群采用的硬件和軟件配置環境如表3所示，搭建集群時的配置參數如表4所示。

表3 物理和軟件配置參數

表4 分布式存儲集群配置參數

在考察dmClock算法對存儲系統實時性能影響時，dmClock采用的物理環境和軟件參數如文獻［12］所示，即虛擬機采用VMware ESX server，主機 為 Dell Poweredge 2950 server，2 Intel Xeon 3.0GHz CPU，8GB內存，10*HDD，其中主機采用32 iodepth，集群采用基于FC SAN的EMC CLARiiONCX3-40磁盤存儲陣列。

實驗將重點考察算法對系統性能的影響，也就是考察相對性能損失，而不對絕對性能損失進行分析，因此采用兩套不同物理環境是具有一定意義的。為了將dbstb和dmClock兩組實驗結果統一起來進行考察，本文定義了性能損失率這一指標。在某一個時刻序列 {t0，t1，t2，…，tn} 時采集到的 IOPS值分別為 {?(t0)，?(t1)，?(t2)，…，?(tn)} ，則時刻 ti對應的性能損失率為

5.2 實驗結果及分析

5.2.1 dbstb算法限流效果分析

三種業務流均是在虛擬機上進行模擬仿真，分別用三節點進行模擬。VM1代表第一臺虛擬機，其上運行FIO工具來模擬執行RD業務流，VM2代表第二臺虛擬機，模擬OLTP業務流，VM3代表第三臺虛擬機，模擬DM業務流。分布式存儲集群由5塊機械硬盤組成，1塊機械硬盤提供的IOPS能力大概為150左右，因此該分布式存儲集群提供的IOPS估計約為800左右，雙副本場景下，估算性能要除2。經過實際測試發現，該集群提供的最大IOPS能力約為350，這也符合上述估計。本組實驗主要側重于對多業務場景中限流效果進行功能性驗證，以衡量dbstb算法是否能夠有效地將性能控制在約定范圍內。

測試流程如下，首先開啟虛擬機VM1執行RD業務流，此時先不啟動QoS，主要目的是對分布式存儲系統進行預熱。然后在第60s的時候，開啟QoS，衡量限流模塊在RD業務場景中表現。在第130s，開啟虛擬機VM2，執行開啟QoS流程的OLTP業務流，然后在170s，開啟虛擬機VM3，執行開啟QoS流程的DM業務流。

當未開啟QoS功能時，對于VM1，可以看到性能抖動比較劇烈，這是因為Ceph內部并沒有做嚴格的恒流處理，容易受到外部業務數據流以及存儲集群設備的影響，進而出現性能波動的現象。

從圖3實驗數據可以看到，在對VM1執行限流操作后，其性能曲線趨于平穩，在開啟VM2和VM3后，兩者的性能曲線均在預設值附近，且其波動范圍基本上都在15%以內。dbstb算法通過自身的令牌調度機制，通過睡眠這一手段的調控，能夠有效地平滑IO輸出性能。也就意味著盡管Ceph本身并沒有提供恒流存儲能力，dbstb算法仍為分布式存儲系統提供了一定的平滑IO輸出性能的能力。

從圖3可以發現，在第60s時，VM1開啟了Qos服務，此時無須重啟存儲軟件，實時IO性能顯示此時IOPS立即達到預設值附近，中間緩沖時間少于1s。dbstb算法本身并沒有建立一個數據緩存，一旦檢測到配置發生變化，能夠立即生效，使得其對配置變化的反應十分敏感。

圖3 多業務場景下性能結果

表5代表限流生效后，各應用場景下IOPS統計的平均值。從實驗結果來看，各應用場景下IOPS均值均在預設值附近，而且均小于預設值，且平均誤差均在2%以內，說明dbstb算法具有良好的限流能力。

表5 多業務場景下限流平均效果

從表5可以看到隨著設置的IOPS上限值的減少，其平均誤差也隨著減少，這是因為Ceph本身并不是一個恒流分布式存儲系統，設置的上限值越大，允許輸出IO的能力范圍越大，性能抖動就會越大，導致平均誤差也就越大。

5.2.2 多業務場景下系統性能分析

為了考察dbstb算法和dmClock算法引入后對存儲系統性能的影響，將采用性能損失率這一指標來對此進行衡量。系統每隔60s開啟一次新業務流，共五次業務流。

在對比實驗中，上層客戶端業務流采用的數據分塊大小為4K，IOPS上限為60，帶寬上限為240KB∕s，同樣利用安裝FIO軟件的虛擬機來模擬客戶端業務環境。本組實驗之所以采用較小分塊大小數據塊，是因為在這種業務場景中，IO輸出性能比較高，對損失率進行評估時更為精確。

在對dbstb算法進行考察時，首先開啟QoS功能，然后將IOPS和帶寬上限值設置為最大，即IOPS為 1000000，帶寬 4096000000bytes∕s。上述參數值均超過了本實驗中分布式存儲集群提供的最大性能值，其目的是使限流模塊處于空轉狀態，這樣便能評估dbstb模塊對系統實時性能的影響。

在對dmClock算法進行考察時，對于五次業務流，dmClock配置參數 w 為1∶1∶2∶2∶2。

實驗每隔1s采樣一組IOPS數據，在取得數據后，求取最大值，將實時IOPS值除以最大IOPS值，并用1減去上述值，進而得到實時性能損失率。

從圖4可以看到，作為一種實現在分布式存儲系統底層的算法，dmClock算法本身也存在一定性能波動，從圖中可以看到，隨著啟動業務數量的增加，該算法對應的性能損失率呈現上升趨勢。到第五個業務流開啟后，存儲系統性能損失可達20%左右。

圖4 dbstb與dmClock算法性能損失對比

需要說明的是，由于緩存、網絡以及業務啟動時間的原因，從加入新業務再到業務數據傳遞到存儲系統中，然后再被檢測到需要一定的時間，所以在第120s開啟第三個業務后，又等待了10s左右才出現了性能劇烈波動。

從圖4可以看到，dbstb算法相對于dmClock算法抖動比較劇烈，一方面由于Ceph系統本身并沒有提供一套穩定數據流輸出輸入能力的機制，導致性能波動較大，另外一方面，此時設置的實驗參數導致dbstb算法限流效果并沒有真正生效，只是在空轉。從實驗結果中可以看到，250s左右dbstb算法的損失率可達25%左右。然而從損失率曲線總體走向來看，其平均性能損失率基本保持不變，不會因引入越來越多的業務流導致存儲系統總體性能下降，而且自引入第五個業務流后，dbstb算法的性能損失率基本控制在5%以內，其性能損失幾乎可以省略。

之所以出現上述現象，這是dbstb算法和dmClock算法實現機制導致的。dbstb算法實現在客戶端，并沒有像dmClock算法實現在存儲系統底端，因此并沒有影響分布式存儲系統總體存儲能力。dbstb算法不會使存儲系統總體性能下降，這在對系統性能要求比較苛刻的存儲場景中，dbstb算法更為適合。

6 結語

提出了一種在分布式存儲開源軟件Ceph塊存儲上控制IOPS和帶寬上限的限流方法，也就是dbstb算法。新算法實現在上層客戶端，具備較小的開發復雜度，且不會降低存儲系統性能。新算法位于用戶會話空間中，不同會話空間中限流算法相互獨立，新算法實現模塊發生的故障不會傳播到其它會話空間中，具備良好的故障隔離性。新算法解決了帶寬控制中大塊IO不能下發的問題，同時有效地降低了性能抖動問題。最后分析了避免性能劇烈抖動滿足的理論條件，并對系統的可用性和數據安全性進行了分析。實驗結果顯示，在多業務場景中，dbstb算法平均誤差控制在2%以內，且不影響存儲系統性能。