杜華 郭俊 劉華春

摘 ?要： 冗余數(shù)據(jù)備份是云數(shù)據(jù)中心下數(shù)據(jù)可靠性的重要保障機(jī)制之一，OpenStack是一種開源的云計(jì)算IaaS層私有云服務(wù)搭建平臺(tái)，目前已經(jīng)在行業(yè)界廣泛應(yīng)用。OpenStack的Swift模塊采用一致性哈希算法，通過Ring環(huán)選取副本備份節(jié)點(diǎn)的方式完成負(fù)載均衡和數(shù)據(jù)備份。通過對(duì)Swift的實(shí)現(xiàn)機(jī)理和代碼進(jìn)行分析研究，指出其在副本放置節(jié)點(diǎn)選取上的不足，進(jìn)而提出優(yōu)化選取策略ABS。該機(jī)制在實(shí)時(shí)監(jiān)控當(dāng)前存儲(chǔ)節(jié)點(diǎn)的負(fù)載情況基礎(chǔ)上，根據(jù)預(yù)先設(shè)定的閾值上、下限自適應(yīng)選取最近可用的節(jié)點(diǎn)完成備份，以優(yōu)化整體備份效率。通過與現(xiàn)有副本備份策略進(jìn)行對(duì)比和實(shí)驗(yàn)驗(yàn)證表明，ABS在保持?jǐn)?shù)據(jù)副本分配均衡性的基礎(chǔ)上，將系統(tǒng)存儲(chǔ)的四種讀寫性能分別提高了3.4%～9.1%，達(dá)到了優(yōu)化存取的目的。

關(guān)鍵詞： 副本; 數(shù)據(jù)備份; Swift; ABS; 自適應(yīng)選取; 負(fù)載均衡

中圖分類號(hào)： TN915.9?34; TP311 ? ? ? ? ? ? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼： A ? ? ? ? ? ? ? ? ? ?文章編號(hào)： 1004?373X（2019）13?0090?06

Research on adaptive selection of Swift′s Hash consistency replica data backup node

DU Hua1， 2， GUO Jun2， LIU Huachun2

（1. Southwestern Institute of Physics， Chengdu 610225， China; 2. Department of Electronic Information and Computer Engineering， The Engineering

and Technical College of Chengdu University of Technology， Leshan 614000， China）

Abstract： Redundant data backup is one of the important guarantee mechanisms to ensure the reliability of data under the cloud data center. OpenStack is an open source platform for cloud computing， which belongs to IaaS layer private cloud services， and is widely used in computer field. The Swift module， as one of the OpenStack′s modules， uses the consistent Hash algorithm， and adopts Ring loop method to choose the replica backup node for load balancing and data backup. The implementation mechanism and code of Swift are researched to point out the shortcomings of the selection of the nodes in the replica placement nodes， and then the optimization selection strategy adaptive backup strategy （ABS） is put forward. On the basis of real?time monitoring of the current storage node load， the mechanism selects the recently available nodes adaptively to complete the backup according to predetermined threshold， which can optimize the overall backup efficiency. The proposed replica strategy is compared with the existing replica backup strategy. The experimental results show that the ABS can improve four reading and writing performances of the system by 3.4%～9.1% while maintaining the balance of data replica allocation， and achieves the purpose of optimizing access.

Keywords： replica; data backup; Swift; ABS; adaptive selection; load balancing

0 ?引 ?言

根據(jù)NIST對(duì)云計(jì)算的定義，云計(jì)算是利用虛擬化技術(shù)將各種IT資源整合到一起，以IT資源池的形式向云用戶提供“按需獲取、按量計(jì)費(fèi)”的一種新的資源使用形式。存儲(chǔ)資源是IT資源中比較基礎(chǔ)的資源之一，云計(jì)算采用大量低成本、低性能的基礎(chǔ)設(shè)施構(gòu)建大容量、高性能存儲(chǔ)服務(wù)[1]，所以在行業(yè)范圍內(nèi)快速發(fā)展。

OpenStack是目前國(guó)內(nèi)外較為流行的開源云計(jì)算IaaS層搭建平臺(tái)，該平臺(tái)技術(shù)已經(jīng)在多個(gè)實(shí)踐業(yè)務(wù)領(lǐng)域有過成功的項(xiàng)目經(jīng)驗(yàn)，且處在快速的版本迭代中，平臺(tái)功能日趨完善，平臺(tái)性能日趨穩(wěn)定。

OpenStack的Swift模塊專門負(fù)責(zé)云存儲(chǔ)功能[2]，該模塊目前主要采用基于復(fù)制的靜態(tài)副本管理策略。其主要思路是根據(jù)機(jī)架敏感與原理，將數(shù)據(jù)的一個(gè)副本放置在本地機(jī)架的存儲(chǔ)節(jié)點(diǎn)上，以獲取較高的網(wǎng)絡(luò)交換速度，從而提高數(shù)據(jù)備份的效率;另一個(gè)副本放置在不同機(jī)架的存儲(chǔ)節(jié)點(diǎn)上，以犧牲一定的網(wǎng)絡(luò)交換速度的方式來獲取更高的數(shù)據(jù)可靠性，避免一個(gè)機(jī)架的故障造成同一機(jī)架上的原始數(shù)據(jù)和備份數(shù)據(jù)同時(shí)損壞，從而造成數(shù)據(jù)不可恢復(fù)。

但是Swift在保持?jǐn)?shù)據(jù)一致性時(shí)，通過簡(jiǎn)單的再次哈希方式選取副本存儲(chǔ)節(jié)點(diǎn)[3]，而沒有具體分析不同節(jié)點(diǎn)在存儲(chǔ)性能上的差異，可能形成性能瓶頸并造成整體存儲(chǔ)性能優(yōu)化不夠的問題。

為此，本文在深入分析Swift的一致性哈希算法和Ring環(huán)機(jī)制的基礎(chǔ)上，提出一種自適應(yīng)備份機(jī)制，通過綜合分析副本節(jié)點(diǎn)的計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)帶寬性能，選取更加合適的副本節(jié)點(diǎn)，提高Swift的存儲(chǔ)效率。

1 ?Swift模塊

1.1 ?Swift的存儲(chǔ)組織結(jié)構(gòu)

OpenStack是2010年7月，由RackSpace和美國(guó)國(guó)家航空航天局合作，分別貢獻(xiàn)出RackSpace云文件平臺(tái)代碼和NASA Nebula，并以Apache許可證開源發(fā)布的一個(gè)云計(jì)算IaaS層搭建平臺(tái)[4]。它是一種云操作系統(tǒng)，通過數(shù)據(jù)中心控制計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源池，所有的管理工作只需要通過網(wǎng)絡(luò)接口使用系統(tǒng)自帶的Dashboard來操作。

OpenStack主要支持兩種形式的存儲(chǔ)：一種是對(duì)象存儲(chǔ)（Object?Based Storage），由Swift模塊負(fù)責(zé)完成;另一種是塊存儲(chǔ)（Block Storage），由Cinder模塊負(fù)責(zé)完成。

對(duì)象存儲(chǔ)適合用于存放靜態(tài)數(shù)據(jù)[5]。所謂靜態(tài)數(shù)據(jù)是指不太可能發(fā)生更新，或是更新頻率比較低的數(shù)據(jù)。例如虛擬機(jī)的鏡像、多媒體數(shù)據(jù)以及數(shù)據(jù)備份的副本都屬于此類。

Swift從架構(gòu)上可以分為兩個(gè)層次：訪問層和存儲(chǔ)層。訪問層負(fù)責(zé)RESTful請(qǐng)求的處理和用戶身份的認(rèn)證。存儲(chǔ)層由一系列的物理存儲(chǔ)節(jié)點(diǎn)組成，負(fù)責(zé)對(duì)象數(shù)據(jù)的存儲(chǔ)。為了在系統(tǒng)出現(xiàn)故障的情況下有效隔離，存儲(chǔ)層在物理上又劃分為以下4個(gè)部分[6]：

1） Region：物理位置上相互隔絕的地區(qū)，每個(gè)Swift系統(tǒng)默認(rèn)至少有一個(gè)Region。

2） Zone：一個(gè)Region內(nèi)部相互隔離的硬件區(qū)域，一個(gè)Zone代表一個(gè)獨(dú)立的存儲(chǔ)節(jié)點(diǎn)。

3） Device：在OpenStack中，通常是指一個(gè)廉價(jià)的磁盤。

4） Partition：OpenStack的Partition是指在Device上的文件系統(tǒng)中的目錄，不是通常意義上的磁盤分區(qū)。在Swift中，副本是以Partition為單位實(shí)現(xiàn)的，Swift管理副本的最小粒度是Partition。

Swift所存儲(chǔ)的對(duì)象在邏輯上又分為Account，Container和Object三個(gè)層次[7]，如圖1所示。

圖1 ?Swift對(duì)象存儲(chǔ)的邏輯結(jié)構(gòu)

Account代表對(duì)象存儲(chǔ)過程中的頂層隔離。一個(gè)Account代表一個(gè)租戶，一個(gè)租戶可能由多個(gè)個(gè)人賬戶共同使用。Container代表一組對(duì)象的封裝，類似文件夾或目錄。Swift要求一個(gè)對(duì)象必須存儲(chǔ)在某個(gè)Container中，所以一個(gè)Account至少應(yīng)該由一個(gè)Container來提供對(duì)象的存儲(chǔ)。Object代表被存儲(chǔ)的確切的數(shù)據(jù)對(duì)象。

1.2 ?Swift的負(fù)載均衡

通過對(duì)用Python語言編寫的Swift源代碼（/common/ring/ring.py文件）進(jìn)行分析可以發(fā)現(xiàn)：Swift主要采用一致性哈希算法來選擇存儲(chǔ)節(jié)點(diǎn)，存放原始數(shù)據(jù)，以保證節(jié)點(diǎn)存儲(chǔ)負(fù)載的均衡，其核心工作機(jī)制如圖2所示。

Ring環(huán)的主要工作原理如下：根據(jù)數(shù)據(jù)中心存儲(chǔ)節(jié)點(diǎn)的個(gè)數(shù)[n]，將Ring均勻地分為[n]段，然后每個(gè)分段的長(zhǎng)度就是[232n]。計(jì)算每個(gè)待存儲(chǔ)對(duì)象的Hash值，如果計(jì)算結(jié)果為[m]，那么它就應(yīng)該分配到[m×232n]分段所對(duì)應(yīng)的節(jié)點(diǎn)服務(wù)器上。

為了快速尋找對(duì)象的副本數(shù)據(jù)所在節(jié)點(diǎn)位置，Ring還要使用2個(gè)數(shù)據(jù)結(jié)構(gòu)表：設(shè)備表（Device Table）和設(shè)備查詢表（Device Lookup Table）。其中，設(shè)備表用來記錄每一個(gè)確切的Device所在的具體位置信息。設(shè)備表包含Region，Zone，IP，Port和Weight信息。而設(shè)備查詢表存儲(chǔ)的就是每個(gè)副本（默認(rèn)為3個(gè)）所在Device的確切信息。

圖2 ?Swift的Ring環(huán)映射圖

1.3 ?Swift的負(fù)載均衡

按照Eric Brewer的CAP（Consistency，Availability，Partition Tolerance）理論，數(shù)據(jù)存儲(chǔ)無法同時(shí)滿足三個(gè)方面。

假設(shè)變量[N]代表數(shù)據(jù)的副本總數(shù)，變量[W]代表寫操作被確認(rèn)接受的副本數(shù)量，變量[R]代表讀操作的副本數(shù)量。則有如下定義：

強(qiáng)一致性（[R+W>N]）：在這種一致性原則下，副本的讀寫操作一定會(huì)產(chǎn)生交集，從而保證可以讀取到最新版本。

弱一致性（[R+W≤N]）：在這種一致性原則下，讀寫操作的副本集合不產(chǎn)生交集，所以可能會(huì)讀到臟數(shù)據(jù);適合對(duì)一致性要求比較低的場(chǎng)景。

Swift采用比較折中的策略，寫操作需要滿足至少一半以上成功，即[W>N2]，再保證讀操作與寫操作的副本集合至少產(chǎn)生一個(gè)交集，即[R+W>N]。這種方式稱作最終一致性模型（Eventual Consistency），目的是兼顧高可用性和無限水平擴(kuò)展能力[8]。

Swift默認(rèn)配置是[N=3]，[W=2>N2]，[R=1]或2，即每個(gè)對(duì)象會(huì)存在3個(gè)副本，這些副本會(huì)盡量被存儲(chǔ)在不同區(qū)域的節(jié)點(diǎn)上，[W=2]表示至少需要更新2個(gè)副本才算寫成功。

當(dāng)[R=1]時(shí)，意味著某一個(gè)讀操作成功便立刻返回，此種情況下可能會(huì)讀取到舊版本（弱一致性模型）;

當(dāng)[R=2]時(shí)，需要通過在讀操作請(qǐng)求中增加[x-]newest=true參數(shù)來同時(shí)讀取2個(gè)副本的元數(shù)據(jù)信息。

然后比較時(shí)間戳來確定哪個(gè)是最新版本（強(qiáng)一致性模型）;如果數(shù)據(jù)出現(xiàn)不一致，后臺(tái)服務(wù)進(jìn)程會(huì)在一定時(shí)間窗口內(nèi)通過檢測(cè)和復(fù)制協(xié)議來完成數(shù)據(jù)同步，從而保證達(dá)到最終一致性。

Swift通過三種服務(wù)解決副本數(shù)據(jù)的一致性問題[9]：

Auditor：通過持續(xù)掃描磁盤來檢查Account，Container和Object的完整性。如果發(fā)現(xiàn)數(shù)據(jù)有所損壞，Auditor就會(huì)對(duì)文件進(jìn)行隔離，然后通過Replicator從其他節(jié)點(diǎn)上獲取對(duì)應(yīng)的副本以恢復(fù)本地?cái)?shù)據(jù)。

Updater：在創(chuàng)建一個(gè)Container時(shí)需要對(duì)包含該Container的Account信息進(jìn)行更新，使得該Account數(shù)據(jù)庫(kù)里面的Container列表包含新創(chuàng)建的Container。同時(shí)，在創(chuàng)建一個(gè)Object時(shí)，需要對(duì)包含該Object的Container信息進(jìn)行更新，使得該Container的數(shù)據(jù)庫(kù)里面的Object列表包含新創(chuàng)建的Object信息。

Replicator：負(fù)責(zé)檢測(cè)各個(gè)節(jié)點(diǎn)上的數(shù)據(jù)及其副本是否一致。當(dāng)發(fā)現(xiàn)不一致時(shí)，會(huì)將過時(shí)的副本更新為最新版本，并且將標(biāo)記為刪除的數(shù)據(jù)真正從物理介質(zhì)上刪除。

2 ?自適應(yīng)備份策略ABS

2.1 ?Swift存在的不足

從前面對(duì)Swift的分析可以發(fā)現(xiàn)：Swift采用Ring結(jié)構(gòu)，使用一致性哈希的原理很好地解決了負(fù)載均衡性問題。但是在副本存放節(jié)點(diǎn)的選擇上，簡(jiǎn)單地查找通過進(jìn)一步Hash的方式隨機(jī)獲取放置節(jié)點(diǎn)，沒有考慮所選節(jié)點(diǎn)本身的實(shí)時(shí)存儲(chǔ)性能和網(wǎng)絡(luò)帶寬，這在理論上可能形成兩個(gè)結(jié)果：

1） 副本所在節(jié)點(diǎn)設(shè)備存儲(chǔ)性能有差異，使得數(shù)據(jù)同步讀寫時(shí)性能降低到與性能較低的設(shè)備匹配，降低了系統(tǒng)的整體存儲(chǔ)性能。

2） 副本所在Zone的網(wǎng)絡(luò)帶寬有差異，可能使得網(wǎng)絡(luò)帶寬成為數(shù)據(jù)讀寫時(shí)的瓶頸，降低系統(tǒng)的整體存儲(chǔ)性能。

從以往的研究來看也證實(shí)了這兩種現(xiàn)象。文獻(xiàn)[10]發(fā)現(xiàn)在千兆網(wǎng)環(huán)境下，負(fù)載均衡服務(wù)器網(wǎng)卡的數(shù)據(jù)吞吐能力是存儲(chǔ)節(jié)點(diǎn)利用率的瓶頸。在萬兆網(wǎng)和超高并發(fā)連接時(shí)，存儲(chǔ)節(jié)點(diǎn)的帶寬基本用完，而負(fù)載均衡節(jié)點(diǎn)和代理節(jié)點(diǎn)的帶寬還有富余。文獻(xiàn)[11]中采用單線程測(cè)試上傳速率，發(fā)現(xiàn)在相同存儲(chǔ)環(huán)境下，傳輸相同大小的文件，并發(fā)量越大Swift傳輸性能越高。文獻(xiàn)[12]中實(shí)測(cè)發(fā)現(xiàn)多線程比單線程性能提升約25%的Swift寫性能，但即使如此，從整體上看，Swift的大文件寫性能依然比較差，沒有充分利用磁盤的帶寬[13]。

2.2 ?Swift的改進(jìn)方法

為了彌補(bǔ)Swift的上述兩個(gè)不足，提高存儲(chǔ)效率，可以從存儲(chǔ)節(jié)點(diǎn)的網(wǎng)絡(luò)帶寬、讀寫速率、磁盤負(fù)載方面著力，盡可能提高基礎(chǔ)設(shè)施的利用率，在整體上發(fā)揮設(shè)備性能。

因此，考慮為不同的存儲(chǔ)節(jié)點(diǎn)增加性能評(píng)估預(yù)測(cè)，在保持整個(gè)Ring負(fù)載均衡的前提下，選擇性能較優(yōu)的節(jié)點(diǎn)作為副本放置的節(jié)點(diǎn)[14]。所謂性能較優(yōu)主要表現(xiàn)為兩個(gè)方面：

1） 網(wǎng)絡(luò)性能較優(yōu)：帶寬更高、交換速率更快的網(wǎng)絡(luò)設(shè)備所在節(jié)點(diǎn)在選擇性上應(yīng)該更優(yōu)。

2） 存儲(chǔ)性能較優(yōu)：CPU處理速度更快、磁盤的平均讀寫速率更快、IOPS更高，當(dāng)前存取負(fù)載較低的節(jié)點(diǎn)，在選擇性上應(yīng)該更優(yōu)。

所以，為了改進(jìn)Swift的工作性能，必須在對(duì)現(xiàn)有節(jié)點(diǎn)的負(fù)載進(jìn)行實(shí)時(shí)監(jiān)控的情況下[15]，根據(jù)監(jiān)控?cái)?shù)據(jù)評(píng)估各個(gè)節(jié)點(diǎn)，然后根據(jù)Hash值和評(píng)估結(jié)果選擇較好的副本存儲(chǔ)節(jié)點(diǎn)。

2.3 ?ABS

根據(jù)前面的改進(jìn)思路，繪制出ABS（Adaptive Backup Strategy）工作機(jī)制示意圖，如圖3所示。

圖3 ?ABS工作機(jī)制示意圖

為了便于描述算法，定義如下概念：

1） 實(shí)時(shí)負(fù)載率[R]：某存儲(chǔ)節(jié)點(diǎn)的實(shí)際負(fù)載與滿負(fù)載情況下的比值。特別地，[Ri]表示第[i]個(gè)存儲(chǔ)節(jié)點(diǎn)的實(shí)時(shí)負(fù)載率。

2） 資源利用率：存儲(chǔ)節(jié)點(diǎn)的CPU、磁盤、網(wǎng)絡(luò)帶寬之中任何一個(gè)的實(shí)時(shí)利用情況。

3） 資源上閾值：存儲(chǔ)節(jié)點(diǎn)的某項(xiàng)資源利用率上限值。

4） 資源下閾值：存儲(chǔ)節(jié)點(diǎn)的某項(xiàng)資源空閑時(shí)的利用率。

并據(jù)此定義節(jié)點(diǎn)[i]的實(shí)時(shí)負(fù)載率為：

5） 定義VIM（Virtual Infrastructure Manager）負(fù)責(zé)計(jì)算當(dāng)前所有存儲(chǔ)節(jié)點(diǎn)的[Ri]值，并依據(jù)該值維護(hù)負(fù)載排序表LST（Load Sorting Table）。

定義當(dāng)前Ring中所有節(jié)點(diǎn)的平均負(fù)載率為[Ravg]：

ABS算法的目標(biāo)就是實(shí)時(shí)監(jiān)測(cè)當(dāng)前所選節(jié)點(diǎn)的實(shí)時(shí)負(fù)載率。如果實(shí)時(shí)負(fù)載率低于平均負(fù)載率，那么選擇該節(jié)點(diǎn)作為副本放置目標(biāo);如果實(shí)時(shí)負(fù)載率高于平均負(fù)載率，那么在LST中選擇緊挨著該節(jié)點(diǎn)的、首個(gè)低于平均負(fù)載率的節(jié)點(diǎn)作為副本放置目標(biāo)。

2.4 ?ABS的實(shí)現(xiàn)

構(gòu)建的LST數(shù)據(jù)結(jié)構(gòu)表中包含三種重要信息，即設(shè)備所在的物理地址信息（設(shè)備ID），設(shè)備的實(shí)時(shí)負(fù)載率和設(shè)備的優(yōu)先級(jí)排序。一個(gè)可能的LST示意表如表1所示。

表1 ?LST示意表

3 ?ABS仿真和分析

3.1 ?算法仿真

系統(tǒng)仿真使用了6臺(tái)Dell PowerEdgeT30服務(wù)器搭建了基本的OpenStack平臺(tái)，其中1臺(tái)作為控制節(jié)點(diǎn)，1臺(tái)作為計(jì)算節(jié)點(diǎn)，4臺(tái)作為存儲(chǔ)節(jié)點(diǎn)。服務(wù)器CPU為E3?1225，3.3 GHz，8 MB緩存;內(nèi)存為16 GB;STAT硬盤，容量1 TB;PCIe接口千兆網(wǎng)卡構(gòu)成局域網(wǎng)絡(luò)。

初始參數(shù)設(shè)置如表2所示。

表2 ?各項(xiàng)參數(shù)數(shù)值表

3.2 ?算法分析

從算法1可以分析得知，整個(gè)ABS算法的核心語句就是第6，12，18的if語句塊。它們的執(zhí)行次數(shù)決定了整個(gè)算法的執(zhí)行次數(shù)量級(jí)。

所以，ABS算法在隨機(jī)狀況下近似于最優(yōu)狀況下的執(zhí)行次數(shù)，時(shí)間復(fù)雜程度隨問題規(guī)模呈[Ο（n2）]增長(zhǎng)態(tài)勢(shì)。

3.3 ?實(shí)測(cè)分析

本文所提出的ABS副本放置策略與Swift原來的簡(jiǎn)單放置策略在負(fù)載均衡、資源利用和網(wǎng)絡(luò)動(dòng)蕩三方面進(jìn)行了比較。

1） 負(fù)載均衡

實(shí)驗(yàn)方法：選取大量*.py文件（即OpenStack的源代碼文件）放置于/tmp/files目錄下。然后用server.py程序啟動(dòng)服務(wù)器，將大量的源碼文件向測(cè)試系統(tǒng)進(jìn)行上傳。所使用命令如下：

圖4 ?負(fù)載均衡情況對(duì)比

從圖4中可以看出，文件總數(shù)為1 896，在ABS算法下，存儲(chǔ)文件數(shù)最多的節(jié)點(diǎn)是Node3，有481個(gè)，比理論預(yù)期值超出0.37%;文件數(shù)存儲(chǔ)最少的節(jié)點(diǎn)是Node4，有466個(gè)，比理論預(yù)期值偏少0.42%。整體而言，新算法在負(fù)載均衡方面基本上保持了原有算法的均衡性。

2） 資源利用

實(shí)驗(yàn)方法：通過使用TestDFSIO基準(zhǔn)測(cè)試來隨機(jī)評(píng)價(jià)單個(gè)節(jié)點(diǎn)磁盤的I/O效率，包括順序?qū)憽㈨樞蜃x、隨機(jī)讀、反向讀四種。得到的對(duì)比結(jié)果如圖5所示。

圖5 ?磁盤資源利用率對(duì)比

從圖5中可以看出，ABS算法在順序讀和隨機(jī)讀兩項(xiàng)操作中提升相對(duì)明顯，分別提升了9.1%和6.7%的讀取性能。但在反向讀的讀取性能上提升比較有限，僅有4.8%。順序?qū)懙奶嵘畈幻黠@，僅有3.4%。

4 ?結(jié) ?語

本文提出的ABS算法在原來Swift一致性哈希原理對(duì)副本放置節(jié)點(diǎn)的順序選取基礎(chǔ)上進(jìn)行改進(jìn)，實(shí)現(xiàn)了一種根據(jù)實(shí)時(shí)負(fù)載情況進(jìn)行存儲(chǔ)節(jié)點(diǎn)選取的增強(qiáng)算法。通過實(shí)驗(yàn)分析，ABS算法在保持原來較好的負(fù)載均衡優(yōu)點(diǎn)之上，磁盤讀寫性能提高了3.4%～9.1%，有了一定的改進(jìn)。

考慮到磁盤讀寫帶寬和IOPS基本已經(jīng)達(dá)到極限，要想在現(xiàn)有機(jī)制下更進(jìn)一步提高整體存儲(chǔ)的效率很難，因此，如何使用糾刪碼等新方式，通過未來云的強(qiáng)大計(jì)算性能來提升副本備份的效率可能成為一個(gè)可行的研究方向。

參考文獻(xiàn)

[1] ?XU Jing， YANG Shoubao， WANG Shuling， et al. CDRS： an adaptive cost?driven replication strategy in cloud storage [J]. ?Journal of the Graduate School of the Chinese Academy of Sciences， 2011， 28（6）： 759?767.

[2] 英特爾開源技術(shù)中心.OpenStack設(shè)計(jì)與實(shí)現(xiàn)[M].北京：電子工業(yè)出版社，2015：183?217.

Intel Open Source Technology Center. The design & implementation of OpenStack [M]. Beijing： Electronic Industry Press， ? ? ?2015： 183?217.

[3] 戢友.OpenStack開源云王者歸來[M].北京： 清華大學(xué)出版社，2014：337?369.

JI You. Return of the Open Source Cloud King [M]. Beijing： Tsinghua University Press， 2014： 337?369.

[4] TSUYUZAKI K， SHIRAISHI M. Recent activities involving OpenStack Swift [J]. NTT technical review， 2015， 13（12）： 1?6.

[5] KIM J M， JEONG H Y， CHO I， et al. A secure smart?work service model based OpenStack for cloud computing [J]. Cluster computing， 2014， 17（3）： 691?702.

[6] ZHANG Tianwei， LEE R B. Monitoring and attestation of virtual machine security health in cloud computing [J]. IEEE micro， 2016， 36（5）： 28?37.

[7] YAMATO Yoji. Cloud storage application area of HDD?SSD hybrid storage， distributed storage， and HDD storage [J]. IEEE transactions on electrical & electronic engineering， 2016， 11（5）： 674?675.

[8] 荀亞玲，張繼福，秦嘯.MapReduce集群環(huán)境下的數(shù)據(jù)放置策略[J].軟件學(xué)報(bào)，2015，26（8）：2056?2073.

XUN Yaling， ZHANG Jifu， QIN Xiao. Data placement strategy for MapReduce cluster environment [J]. Journal of software， 2015， 26（8）： 2056?2073.

[9] 唐震，吳恒，王偉，等.虛擬化環(huán)境下面向多目標(biāo)優(yōu)化的自適應(yīng)SSD緩存系統(tǒng)[J].軟件學(xué)報(bào)，2017，28（8）：1982?1998.

TANG Zhen， WU Heng， WANG Wei， et al. Self?adaptive SSD caching system for multiobjective optimization in virtualization environment [J]. Journal of software， 2017， 28（8）： 1982?1998.

[10] 鄭馳.基于OpenStack的對(duì)象存儲(chǔ)性能實(shí)驗(yàn)及研究[J].微型機(jī)與應(yīng)用，2014，33（18）：14?16.

ZHENG Chi. Object storage performance testing and research based on the OpenStack [J]. Microcomputer & its applications， 2014， 33（18）： 14?16.

[11] 王勝俊.Openstack云平臺(tái)中Swift組件的研究與測(cè)試[J].電腦知識(shí)與技術(shù)，2016，12（7）：77?78.

WANG Shengjun. Research and test of Swift components in Openstack cloud platform [J]. Computer knowledge and technology， 2016， 12（7）： 77?78.

[12] 葛江浩.OpenStack Swift關(guān)鍵技術(shù)分析與性能評(píng)測(cè)[J].微型電腦應(yīng)用，2013，29（11）：9?12.

GE Jianghao. The main technology analysis and performance evaluation on OpenStack Swift [J]. Microcomputer applications， 2013， 29（11）： 9?12.

[13] 陶永才，巴陽(yáng)，石磊，等.一種基于可用性的動(dòng)態(tài)云數(shù)據(jù)副本管理機(jī)制[J].小型微型計(jì)算機(jī)系統(tǒng)，2018，39（3）：490?495.

TAO Yongcai， BA Yang， SHI Lei， et al. Management mechanism of dynamic cloud data replica based on availability [J]. Journal of Chinese computer systems， 2018， 39（3）： 490?495.

[14] 徐敏.基于OpenStack的Swift負(fù)載均衡算法[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2018，27（1）：127?131.

XU Min. Swift load balancing algorithm based on OpenStack [J]. Computer systems & applications， 2018， 27（1）： 127?131.

[15] 周敬利.改進(jìn)的云存儲(chǔ)系統(tǒng)數(shù)據(jù)分布策略[J].計(jì)算機(jī)應(yīng)用，2012，32（2）：309?312.

ZHOU Jingli. Improved data distribution strategy for cloud storage system [J]. Journal of computer applications， 2012， 32（2）： 309?312.

[16] 胡麗聰.基于動(dòng)態(tài)反饋的一致性哈希負(fù)載均衡算法[J].微電子學(xué)與計(jì)算機(jī)，2012，29（1）：177?180.

HU Licong. A consistent Hash load balancing algorithm based on dynamic feedback [J]. Microelectronics & computer， 2012， 29（1）： 177?180.