Swift的哈希一致性副本數據備份節點自適應選取研究

杜華 郭俊 劉華春

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

關鍵詞： 副本; 數據備份; Swift; ABS; 自適應選取; 負載均衡

中圖分類號： TN915.9?34; TP311 ? ? ? ? ? ? ? ? ? 文獻標識碼： A ? ? ? ? ? ? ? ? ? ?文章編號： 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 ?引 ?言

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

OpenStack是目前國內外較為流行的開源云計算IaaS層搭建平臺，該平臺技術已經在多個實踐業務領域有過成功的項目經驗，且處在快速的版本迭代中，平臺功能日趨完善，平臺性能日趨穩定。

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

但是Swift在保持數據一致性時，通過簡單的再次哈希方式選取副本存儲節點[3]，而沒有具體分析不同節點在存儲性能上的差異，可能形成性能瓶頸并造成整體存儲性能優化不夠的問題。

為此，本文在深入分析Swift的一致性哈希算法和Ring環機制的基礎上，提出一種自適應備份機制，通過綜合分析副本節點的計算、存儲和網絡帶寬性能，選取更加合適的副本節點，提高Swift的存儲效率。

1 ?Swift模塊

1.1 ?Swift的存儲組織結構

OpenStack是2010年7月，由RackSpace和美國國家航空航天局合作，分別貢獻出RackSpace云文件平臺代碼和NASA Nebula，并以Apache許可證開源發布的一個云計算IaaS層搭建平臺[4]。它是一種云操作系統，通過數據中心控制計算、存儲和網絡資源池，所有的管理工作只需要通過網絡接口使用系統自帶的Dashboard來操作。

OpenStack主要支持兩種形式的存儲：一種是對象存儲（Object?Based Storage），由Swift模塊負責完成;另一種是塊存儲（Block Storage），由Cinder模塊負責完成。

對象存儲適合用于存放靜態數據[5]。所謂靜態數據是指不太可能發生更新，或是更新頻率比較低的數據。例如虛擬機的鏡像、多媒體數據以及數據備份的副本都屬于此類。

Swift從架構上可以分為兩個層次：訪問層和存儲層。訪問層負責RESTful請求的處理和用戶身份的認證。存儲層由一系列的物理存儲節點組成，負責對象數據的存儲。為了在系統出現故障的情況下有效隔離，存儲層在物理上又劃分為以下4個部分[6]：

1） Region：物理位置上相互隔絕的地區，每個Swift系統默認至少有一個Region。

2） Zone：一個Region內部相互隔離的硬件區域，一個Zone代表一個獨立的存儲節點。

3） Device：在OpenStack中，通常是指一個廉價的磁盤。

4） Partition：OpenStack的Partition是指在Device上的文件系統中的目錄，不是通常意義上的磁盤分區。在Swift中，副本是以Partition為單位實現的，Swift管理副本的最小粒度是Partition。

Swift所存儲的對象在邏輯上又分為Account，Container和Object三個層次[7]，如圖1所示。

圖1 ?Swift對象存儲的邏輯結構

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

1.2 ?Swift的負載均衡

通過對用Python語言編寫的Swift源代碼（/common/ring/ring.py文件）進行分析可以發現：Swift主要采用一致性哈希算法來選擇存儲節點，存放原始數據，以保證節點存儲負載的均衡，其核心工作機制如圖2所示。

Ring環的主要工作原理如下：根據數據中心存儲節點的個數[n]，將Ring均勻地分為[n]段，然后每個分段的長度就是[232n]。計算每個待存儲對象的Hash值，如果計算結果為[m]，那么它就應該分配到[m×232n]分段所對應的節點服務器上。

為了快速尋找對象的副本數據所在節點位置，Ring還要使用2個數據結構表：設備表（Device Table）和設備查詢表（Device Lookup Table）。其中，設備表用來記錄每一個確切的Device所在的具體位置信息。設備表包含Region，Zone，IP，Port和Weight信息。而設備查詢表存儲的就是每個副本（默認為3個）所在Device的確切信息。

圖2 ?Swift的Ring環映射圖

1.3 ?Swift的負載均衡

按照Eric Brewer的CAP（Consistency，Availability，Partition Tolerance）理論，數據存儲無法同時滿足三個方面。

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

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

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

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

Swift默認配置是[N=3]，[W=2>N2]，[R=1]或2，即每個對象會存在3個副本，這些副本會盡量被存儲在不同區域的節點上，[W=2]表示至少需要更新2個副本才算寫成功。

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

當[R=2]時，需要通過在讀操作請求中增加[x-]newest=true參數來同時讀取2個副本的元數據信息。

然后比較時間戳來確定哪個是最新版本（強一致性模型）;如果數據出現不一致，后臺服務進程會在一定時間窗口內通過檢測和復制協議來完成數據同步，從而保證達到最終一致性。

Swift通過三種服務解決副本數據的一致性問題[9]：

Auditor：通過持續掃描磁盤來檢查Account，Container和Object的完整性。如果發現數據有所損壞，Auditor就會對文件進行隔離，然后通過Replicator從其他節點上獲取對應的副本以恢復本地數據。

Updater：在創建一個Container時需要對包含該Container的Account信息進行更新，使得該Account數據庫里面的Container列表包含新創建的Container。同時，在創建一個Object時，需要對包含該Object的Container信息進行更新，使得該Container的數據庫里面的Object列表包含新創建的Object信息。

Replicator：負責檢測各個節點上的數據及其副本是否一致。當發現不一致時，會將過時的副本更新為最新版本，并且將標記為刪除的數據真正從物理介質上刪除。

2 ?自適應備份策略ABS

2.1 ?Swift存在的不足

從前面對Swift的分析可以發現：Swift采用Ring結構，使用一致性哈希的原理很好地解決了負載均衡性問題。但是在副本存放節點的選擇上，簡單地查找通過進一步Hash的方式隨機獲取放置節點，沒有考慮所選節點本身的實時存儲性能和網絡帶寬，這在理論上可能形成兩個結果：

1） 副本所在節點設備存儲性能有差異，使得數據同步讀寫時性能降低到與性能較低的設備匹配，降低了系統的整體存儲性能。

2） 副本所在Zone的網絡帶寬有差異，可能使得網絡帶寬成為數據讀寫時的瓶頸，降低系統的整體存儲性能。

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

2.2 ?Swift的改進方法

為了彌補Swift的上述兩個不足，提高存儲效率，可以從存儲節點的網絡帶寬、讀寫速率、磁盤負載方面著力，盡可能提高基礎設施的利用率，在整體上發揮設備性能。

因此，考慮為不同的存儲節點增加性能評估預測，在保持整個Ring負載均衡的前提下，選擇性能較優的節點作為副本放置的節點[14]。所謂性能較優主要表現為兩個方面：

1） 網絡性能較優：帶寬更高、交換速率更快的網絡設備所在節點在選擇性上應該更優。

2） 存儲性能較優：CPU處理速度更快、磁盤的平均讀寫速率更快、IOPS更高，當前存取負載較低的節點，在選擇性上應該更優。

所以，為了改進Swift的工作性能，必須在對現有節點的負載進行實時監控的情況下[15]，根據監控數據評估各個節點，然后根據Hash值和評估結果選擇較好的副本存儲節點。

2.3 ?ABS

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

圖3 ?ABS工作機制示意圖

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

1） 實時負載率[R]：某存儲節點的實際負載與滿負載情況下的比值。特別地，[Ri]表示第[i]個存儲節點的實時負載率。

2） 資源利用率：存儲節點的CPU、磁盤、網絡帶寬之中任何一個的實時利用情況。

3） 資源上閾值：存儲節點的某項資源利用率上限值。

4） 資源下閾值：存儲節點的某項資源空閑時的利用率。

并據此定義節點[i]的實時負載率為：

5） 定義VIM（Virtual Infrastructure Manager）負責計算當前所有存儲節點的[Ri]值，并依據該值維護負載排序表LST（Load Sorting Table）。

定義當前Ring中所有節點的平均負載率為[Ravg]：

ABS算法的目標就是實時監測當前所選節點的實時負載率。如果實時負載率低于平均負載率，那么選擇該節點作為副本放置目標;如果實時負載率高于平均負載率，那么在LST中選擇緊挨著該節點的、首個低于平均負載率的節點作為副本放置目標。

2.4 ?ABS的實現

構建的LST數據結構表中包含三種重要信息，即設備所在的物理地址信息（設備ID），設備的實時負載率和設備的優先級排序。一個可能的LST示意表如表1所示。

表1 ?LST示意表

3 ?ABS仿真和分析

3.1 ?算法仿真

系統仿真使用了6臺Dell PowerEdgeT30服務器搭建了基本的OpenStack平臺，其中1臺作為控制節點，1臺作為計算節點，4臺作為存儲節點。服務器CPU為E3?1225，3.3 GHz，8 MB緩存;內存為16 GB;STAT硬盤，容量1 TB;PCIe接口千兆網卡構成局域網絡。

初始參數設置如表2所示。

表2 ?各項參數數值表

3.2 ?算法分析

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

所以，ABS算法在隨機狀況下近似于最優狀況下的執行次數，時間復雜程度隨問題規模呈[Ο（n2）]增長態勢。

3.3 ?實測分析

本文所提出的ABS副本放置策略與Swift原來的簡單放置策略在負載均衡、資源利用和網絡動蕩三方面進行了比較。

1） 負載均衡

實驗方法：選取大量*.py文件（即OpenStack的源代碼文件）放置于/tmp/files目錄下。然后用server.py程序啟動服務器，將大量的源碼文件向測試系統進行上傳。所使用命令如下：

圖4 ?負載均衡情況對比

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

2） 資源利用

實驗方法：通過使用TestDFSIO基準測試來隨機評價單個節點磁盤的I/O效率，包括順序寫、順序讀、隨機讀、反向讀四種。得到的對比結果如圖5所示。

圖5 ?磁盤資源利用率對比

從圖5中可以看出，ABS算法在順序讀和隨機讀兩項操作中提升相對明顯，分別提升了9.1%和6.7%的讀取性能。但在反向讀的讀取性能上提升比較有限，僅有4.8%。順序寫的提升最不明顯，僅有3.4%。

4 ?結 ?語

本文提出的ABS算法在原來Swift一致性哈希原理對副本放置節點的順序選取基礎上進行改進，實現了一種根據實時負載情況進行存儲節點選取的增強算法。通過實驗分析，ABS算法在保持原來較好的負載均衡優點之上，磁盤讀寫性能提高了3.4%～9.1%，有了一定的改進。

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

參考文獻

[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] 英特爾開源技術中心.OpenStack設計與實現[M].北京：電子工業出版社，2015：183?217.

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

[3] 戢友.OpenStack開源云王者歸來[M].北京： 清華大學出版社，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集群環境下的數據放置策略[J].軟件學報，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] 唐震，吳恒，王偉，等.虛擬化環境下面向多目標優化的自適應SSD緩存系統[J].軟件學報，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的對象存儲性能實驗及研究[J].微型機與應用，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云平臺中Swift組件的研究與測試[J].電腦知識與技術，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關鍵技術分析與性能評測[J].微型電腦應用，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] 陶永才，巴陽，石磊，等.一種基于可用性的動態云數據副本管理機制[J].小型微型計算機系統，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負載均衡算法[J].計算機系統應用，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].計算機應用，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] 胡麗聰.基于動態反饋的一致性哈希負載均衡算法[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.