郭巍，李小勇

?

基于AmazonS3的云存儲系統(tǒng)的設(shè)計

郭巍，李小勇

摘 要：BlueOcean Storage System是一款自主設(shè)計研發(fā)的分布式文件系統(tǒng)。在此基礎(chǔ)之上，設(shè)計并實現(xiàn)了S3 engine，使其能夠勝任云存儲的工作。通過對高并發(fā)模式的分析，體現(xiàn)出BOSS+S3engine在設(shè)計上的優(yōu)勢。最后通過與開源項目的對比來證明結(jié)論，是使用可靠的。

關(guān)鍵詞：云存儲；S3；高并發(fā)模式；性能測試

李小勇（1972-），男，甘肅天水人，上海交通大學(xué)，信息安全工程學(xué)院，副教授，博士，研究方向：操作系統(tǒng)和高性能網(wǎng)絡(luò)，上海，200240

0 引言

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，各式各樣的應(yīng)用與需求應(yīng)運而生。云存儲作為其中代表，受到了廣泛的關(guān)注。對比傳統(tǒng)網(wǎng)絡(luò)存儲，云存儲突破了網(wǎng)絡(luò)的限制，用戶可以在任何時間任何地點，通過網(wǎng)絡(luò)獲取相關(guān)服務(wù)。

目前，云存儲接口的主要標(biāo)準包括Amazon的S3、OpenStack的Swift的API、SNIA提出的CDMI。相較于后者，Amzaon的S3的優(yōu)勢主要包括：（1）簡介且功能全面；（2）考慮到安全性的要求；（3）經(jīng)過商業(yè)化的實踐檢驗。因此，將方案定為Amazon的S3接口是符合實際需求的。

本系統(tǒng)的底層存儲是建立在BlueOcean Storage System（簡稱BOSS）上的。通過BOSS可以搭建一套穩(wěn)定且高效的S3協(xié)議引擎，對上層用戶提供云存儲服務(wù)。用戶可以自定義存儲的方式（版本信息）、存儲的周期（數(shù)據(jù)的生命周期）、訪問控制權(quán)限和共享的管理等等，方便上層用戶的使用。

1 S3與對象存儲

Amazon S3是一個公開的服務(wù)，上層用戶可以使用它存儲數(shù)字資產(chǎn)，包括圖片、視頻、音樂和文檔。Amazon 的 S3公開了 RESTful API[1]，使用戶可以使用任何支持 HTTP通信的語言訪問 S3。

S3用容器與對象模型代替了傳統(tǒng)的目錄與文件模型。上層用戶所看到的不再是遞歸嵌套的目錄樹結(jié)構(gòu)，而是扁平的二級目錄結(jié)構(gòu)。S3規(guī)定了容器之間是不允許進行嵌套的，因此所有的對象都存儲在同一層次中。同時，S3為每個對象維護了一個全局唯一的ID號，這個ID號由容器名與對象名組成。S3保證容器名的全局唯一性，從而保證了對象號的全局唯一。

對象是S3的基本單元。每個對象都是由數(shù)據(jù)本身以及與數(shù)據(jù)有關(guān)的元數(shù)據(jù)組成。元數(shù)據(jù)是描述數(shù)據(jù)屬性的數(shù)據(jù)，包括數(shù)據(jù)分布、服務(wù)質(zhì)量等。S3提供了2種元數(shù)據(jù):系統(tǒng)元數(shù)據(jù)與用戶自定義元數(shù)據(jù)。系統(tǒng)元數(shù)據(jù)指描述存儲系統(tǒng)本身的元數(shù)據(jù)，包括副本數(shù)量、存儲區(qū)域等。而用戶自定義元數(shù)據(jù)指用戶可以選擇的服務(wù)，包括對象的版本信息、對象的生命周期等。兩者從不同的角度支持整個系統(tǒng)的運作。對象的大小可以不同，可以包含整個數(shù)據(jù)結(jié)構(gòu)，如文件、數(shù)據(jù)庫表項等。

相比于傳統(tǒng)的文件目錄結(jié)構(gòu)，容器對象結(jié)構(gòu)的主要優(yōu)勢在于：（1）傳統(tǒng)目錄結(jié)構(gòu)數(shù)據(jù)很難均衡的分布在所有節(jié)點中，造成節(jié)點之間的不均衡。而對象存儲可以依靠對象號的HASH值，將對象均勻的分布在整個存儲集群中，做到負載均衡與線性擴展。（2）相比于目錄結(jié)構(gòu)，對象存儲可以由對象自身維護自己的屬性，從而簡化了存儲系統(tǒng)的管理任務(wù)，增加了靈活性。（3）當(dāng)目錄層次較深時，一次文件的訪問會經(jīng)過多次的讀盤與權(quán)限的驗證，而對象存儲只有兩級結(jié)構(gòu)，因此可以極大的減少IO路徑，同時readahead技術(shù)也可以有效的減少同容器下對象的檢索時間，提高效率?；谶@些優(yōu)點，相信對象存儲將會成為互聯(lián)網(wǎng)存儲領(lǐng)域的領(lǐng)導(dǎo)方向。

2 系統(tǒng)框架解析

本存儲系統(tǒng)主要由兩部分組成S3engine與BOSS存儲系統(tǒng)組成，如圖1所示：

圖1　S3engine+BOSS體系架構(gòu)

BlueOcean Storage System（簡稱BOSS）存儲系統(tǒng)，是一款自主設(shè)計與研發(fā)的分布式對象存儲系統(tǒng)，能夠向上層提供海量（PB級）、可擴展、高可用、低成本的存儲

服務(wù)。采用完全對稱的存儲架構(gòu)，所有節(jié)點在整個存儲集群中都是等價的，從而不會存在任何的單點問題。數(shù)據(jù)通過改良的一致性hash算法[3]，被均勻的分布到所有的存儲結(jié)點，因而也不會存在任何的熱點問題。

S3 engine是為BOSS存儲系統(tǒng)所設(shè)計的S3協(xié)議引擎。通過對用戶所發(fā)送的S3協(xié)議內(nèi)容的解析，轉(zhuǎn)變?yōu)槟硞€對象的讀寫，并按照實際情況將解析好的請求交給下層的BOSS來處理。完成請求后，將應(yīng)答包裝成S3協(xié)議格式，向用戶發(fā)送應(yīng)答。作為BOSS與用戶之間的橋梁，服務(wù)于整個系統(tǒng)。

3 關(guān)鍵技術(shù)設(shè)計

由于篇幅的限制，本文將重點放在高并發(fā)模型設(shè)計與副本、審計與修復(fù)策略上。

3.1 高并發(fā)模型設(shè)計

S3engine的應(yīng)用場景是面向百萬級鏈接、為上層用戶提供高并發(fā)、低延遲的S3協(xié)議的存取服務(wù)。為此高并發(fā)模型設(shè)計的好壞直接影響系統(tǒng)的性能與可用性。

BOSS分布式文件系統(tǒng)采用多進程的并發(fā)模式。多進程（pre-fork）與傳統(tǒng)的線程池模式對比如表1所示：

表1　多進程（pre-fork）與傳統(tǒng)的線程池模式對比

從表1的分析中可知，多進程與多線程模式性能的差異主要表現(xiàn)在數(shù)據(jù)同步與進程切換上。

通過lmbench的測試，進程上下文切換的代價如圖2所示：

圖2　進程在不同情況下上下文切換時間消耗

1K、2K、4K、8K、16K、32K、64K為所切換的進程空間大小。

從圖2中可以看出，進程空間的大小與進程并發(fā)數(shù)共同影響著進程上下文切換時間。由于進程的空間相互獨立，所以在并發(fā)數(shù)相同的情況下空間越大，消耗的時間越多。相對而言線程共享進程空間，切換時的代價僅為自身的堆棧信息，所以代價要低于進程。通過《Linux線程庫性能分析》[4]這篇文章可知，在單CPU中，線程大小為10Kb時，10線程的切換所消耗的平均時間為0.968微秒。低于進程的大約4微秒的時間。

線程鎖帶來的開銷主要包括兩部分：鎖本身的開銷與因為鎖而造成的線程切換所帶來的開銷。因此，測試通過程序模擬鎖的開銷與線程切換的開銷，在不同線程數(shù)量的情況下總耗時上的差異。測試程序為每個線程執(zhí)行1000000次加法操作。使用線程鎖的測試程序在每次的加法前申請鎖，完成一次加法以后釋放鎖。測試結(jié)果如圖3所示：

圖3　多線程并發(fā)執(zhí)行耗時

不加鎖的模式下，消耗的時間隨線程數(shù)緩慢增加，128個線程并發(fā)的情況下所耗費時間約為1.432秒。加鎖的模式下，時間消耗陡增，128個線程并發(fā)耗時高達19.352秒。通過systemtap工具可以清楚地看到在加鎖與不加鎖兩種情況CPU調(diào)度次數(shù)。systemtap結(jié)果如表2所示：

表2　線程調(diào)度次數(shù)統(tǒng)計

正常運行的情況下，系統(tǒng)每秒種的CPU調(diào)度約為960次。在不加鎖的情況下，CPU調(diào)度次數(shù)隨線程數(shù)增加而緩慢增加。當(dāng)加鎖的情況下，CPU發(fā)生了劇烈的上下文切換，從而浪費了大量的系統(tǒng)時間。從CPU占有情況也可以看出，從32線程到128線程在加鎖的情況下，CPU占有率都接近100%，系統(tǒng)處于頻繁的上下文切換之中，浪費了大量資源。測試選用一次加法作為臨界區(qū)，放大臨界區(qū)會提高一定的性能，但現(xiàn)實情況下很難有對較大規(guī)模臨界區(qū)的加鎖使用。除此之外相較于傳統(tǒng)的線程池模式，任何進程的錯誤都不會影響別的進程并能快速恢復(fù)，這是線程池模式不可能實現(xiàn)的。

從上述分析，可以得出結(jié)論：在線程池模式中，對臨界資源，如緩沖區(qū)的訪問是必須加鎖，鎖的開銷會直接降低系統(tǒng)并發(fā)性能，造成大量不必要的調(diào)度。在多進程模式下，進程之間彼此獨立，加鎖操作顯著減少。雖然進程調(diào)度消耗的時間較多，但在可靠性與可用性方面，多進程顯然是具有巨大優(yōu)勢的。因此，選擇多進程模式符合系統(tǒng)設(shè)計的需求并且便于開發(fā)。

3.2 磁盤異步IO

分布式系統(tǒng)的主要事件包括網(wǎng)絡(luò)事件與磁盤I/O事件。將網(wǎng)絡(luò)連接設(shè)為非阻塞方式可以有效的規(guī)避網(wǎng)絡(luò)接收信息延遲所造成的阻塞。

相比之下，磁盤的I/O特性要復(fù)雜許多。I/O通過同步/異步、阻塞/非阻塞可以分為4大類。在磁盤I/O方面使用的最多的是同步阻塞式I/O——標(biāo)準的read/write，以及異步非阻塞式I/O——AIO。AIO是 LINUX 2.6 版本內(nèi)核的一個標(biāo)準特性。AIO 的基本思想是允許進程發(fā)起很多I/O操作，而不用阻塞或等待任何操作完成。稍后在接收到 I/O 操作完成的通知時，進程就可以檢索 I/O 操作的結(jié)果。

磁頭的移動是毫秒級的，海量并發(fā)請求會使得磁頭進行大量無規(guī)則運動，浪費大量時間。如果使用AIO，在大量I/O提交以后，內(nèi)核會優(yōu)化整個I/O隊列，使得尋道時間（磁頭的移動）得到相當(dāng)程度的減少，從而在另一個方面提高整體的吞吐率，減少延遲抖動。epoll是一種阻塞的I/O復(fù)用系統(tǒng)調(diào)用，是基于事件觸發(fā)的。AIO事件可以觸發(fā)epoll，通過epoll可以減少系統(tǒng)不必要的空轉(zhuǎn)與阻塞。最大程度合理利用資源。

3.3 副本、審計與恢復(fù)策略

副本策略BOS

S 分布式文件系統(tǒng)的設(shè)計目的是為用戶提供一個高可用、高可靠的數(shù)據(jù)存儲平臺，因而將采用強一致性的模型設(shè)計[5]。對象數(shù)據(jù)通過primary-slave 的模式寫入存儲系統(tǒng)，primary-slave 數(shù)據(jù)推送過程如圖4 所示：

圖4　primary-slave模式數(shù)據(jù)推送過程

所有讀寫都通過primary向用戶回復(fù)。讀請求用戶任意選擇兩個節(jié)點進行對比，決定讀取數(shù)據(jù)。寫流程為：（1）用戶發(fā)送寫請求給primary。（2）primary將請求轉(zhuǎn)發(fā)給slave，slave完成相應(yīng)請求。（3）slave向primary發(fā)送應(yīng)答。（4）primary向另一個slave發(fā)送寫請求。（5）slave向primary回復(fù)。（6）primary匯集所有信息向client回復(fù)完成情況。其中（2）、（4）可以并發(fā)同時進行。三個副本可以幾乎同時進行寫的操作，因而讀寫時延較低。

通過NRW理論[5]可知，任何存儲系統(tǒng)想保持強一致性，必須滿足寫成功的最小次數(shù)W與讀操作讀取副本次數(shù)R之和大于副本個數(shù)N，即R+W＞N。所以在推送流程中，至少保證寫成功2個副本，才能返回成功。在讀的過程中，必須訪問2個副本比較時間戳，獲取最新版本。

審計策略與修復(fù)策略

審計與修復(fù)是系統(tǒng)保證一致性與高可用性的重要方法。審計負責(zé)系統(tǒng)不一致性錯誤的發(fā)現(xiàn)并向修復(fù)服務(wù)報告。審計按照處理任務(wù)與執(zhí)行流程的不同分為兩種：實時審計和周期性審計。

實時審計負責(zé)副本跟新時錯誤的匯報。由于網(wǎng)絡(luò)的傳輸存在丟包或亂序的可能，多個副本之間數(shù)據(jù)跟新可能會發(fā)生錯誤。為了捕獲這種錯誤，每次的修改操作都會使對象的版本號加1，實時審計會檢查primary節(jié)點推送來的數(shù)據(jù)版本號是否與當(dāng)前版本一致，從而判斷是否進行這次寫操作。

由于存儲介質(zhì)的問題，數(shù)據(jù)長時間存放后可能會發(fā)生扇區(qū)損壞，出現(xiàn) Latent Sector Errors（LSEs）[6]錯誤。當(dāng)出現(xiàn)這類錯誤時，系統(tǒng)處于潛在的不一致狀態(tài)。周期審計會周期性的計算多個副本之間的校驗和并進行比較，維護系統(tǒng)一致性。每當(dāng)發(fā)現(xiàn)出問題的對象，審計服務(wù)會將這個對象移動到一個修復(fù)目錄下，供修復(fù)進程周期性的修復(fù)。

修復(fù)服務(wù)會檢測修復(fù)目錄發(fā)現(xiàn)修復(fù)對象。通過與其他的幾個節(jié)點同一對象的對比，確定正確對象的版本信息，將正確的對象覆蓋原有的錯誤對象。從而使整個系統(tǒng)恢復(fù)3副本的一致狀態(tài)。副本版本之間的判定策略為少數(shù)服從多數(shù)。如果3個副本的版本信息都不一樣，則以primary節(jié)點存儲的對象為準。

周期性審計與修復(fù)服務(wù)會占有大量的磁盤IO與網(wǎng)絡(luò)帶寬，造成正常服務(wù)性能的降低。所以，周期性審計與修復(fù)必須基于一定的流控機制。在開始一次任務(wù)前，周期性審計與修復(fù)服務(wù)會獲取當(dāng)前系統(tǒng)的CPU利用率、磁盤吞吐率等系統(tǒng)重要參數(shù)，決定這次任務(wù)所處理的數(shù)據(jù)總量。當(dāng)系統(tǒng)處于重負載時，減少或推遲本次的審計或修復(fù)任務(wù)，從而盡可能的減少對正常功能的影響。

4 系統(tǒng)測試

測試對比的開源系統(tǒng)是OpenStack的Swift，以及glusterfs。swift由5個節(jié)點組成，1個代理節(jié)點、1個認證節(jié)點、3個數(shù)據(jù)節(jié)點。glusterfs由3個節(jié)點組成。BOSS由3個節(jié)點組成，在每個BOSS節(jié)點部署S3engine。所有節(jié)點通過萬兆以太網(wǎng)交換機相連。節(jié)點數(shù)據(jù)如表3所示：

表3　節(jié)點數(shù)據(jù)

swift與S3engine+BOSS對512M大文件讀寫性能如圖5所示：

圖5　swift與S3engine+BOSS讀寫性能測試

Swift與S3engine+BOSS在大文件的寫性能上都十分的低，swift只有不到30MB/S，而S3engine+BOSS也只有32MB/S。原因在于，兩者在接收到數(shù)據(jù)的時候都要計算512MB數(shù)據(jù)的校驗和，從而直接降低了兩者寫性能。在讀性能的對比上，S3engine+BOSS的寫性能能達到78MB/S要遠高于swift。Swift在訪問數(shù)據(jù)時，首先要訪問驗證服務(wù)器，接著逐層訪問用戶賬戶account、容器container確定權(quán)限，最后才能讀取數(shù)據(jù)。雖然這樣能保證安全性，但直接影響了性能。S3engine在設(shè)計時并沒有如此復(fù)雜的安全限制，所以訪問速度較快。

基于上述原因，高并發(fā)測試選擇的對比軟件是glusterfs。測試對象為BOSS與glusterfs，測試重點為兩系統(tǒng)的在高并發(fā)情況下的性能對比。測試結(jié)果如圖6-圖9所示：

圖6　單副本大文件寫

圖7　單副本大文件讀

圖8　雙副本大文件寫

圖9　雙副本大文件讀

通過數(shù)據(jù)可以看出，在大文件讀寫測試的情況下gluster 與BOSS在寫性能上類似。讀性能方面，gluster要高于BOSS。通過深入地分析，我們發(fā)現(xiàn)gluster使用了預(yù)讀技術(shù)，這樣會提高大文件順序讀寫的性能。然而另一方面，預(yù)讀會影響小數(shù)據(jù)塊隨機讀的性能，為了更加明顯的體現(xiàn)出差異，我們將測試磁盤換為SSD，隨機讀的塊大小為4KB。測試結(jié)果如圖10所示：

圖10　小文件隨機讀寫性能對比

文件的隨機讀性能是體現(xiàn)程序并發(fā)程度的重要指標(biāo)。如圖10所示，在高并發(fā)隨機讀的情況下，BOSS的性能要遠好于gluster。通過計算可以算出，此時BOSS的IOPS約為9萬。

5總結(jié)

通過與gluster的對比可以證明BOSS所采用并發(fā)架構(gòu)是高效的。雖然通過試驗比較可以看出BOSS在性能上十分優(yōu)秀，然而還需要長時間的開發(fā)周期改進現(xiàn)有系統(tǒng)。下一步的工作重點是繼續(xù)完善S3engine的功能，設(shè)計一套有效的安全機制，使BOSS的功能更加完善。

參考文獻

[1] Amazon Web Services, Inc. and/or its affiliates. Amazon Simple Storage Service API Reference[EB/OL]. http://docs.aws.amazon.com/AmazonS3/latest/API/s3-api. pdf, 2006,03.

[2] 姚墨涵, 謝紅薇.一致性哈希算法在分布式系統(tǒng)中的應(yīng)用[J].電腦開發(fā)與應(yīng)用, 2012,25(7) .

[3] Laboratories HP，Mcvoy L， Staelin C.lmbench: Portable Tools for Performance Analysis[J]. Usenix Annual Technical Conference, 1996:279-294.

[4] 楊沙洲, Linux 線程庫性能測試與分析 [EB/OL]. http://www.ibm.com/developerworks/cn/linux/l-nptl/inde x.html, 2010,09.

[5] BIANCA SCHROEDER, SOTIRIOS DAMOURAS and PHILLIPAGILL .Understanding Latent Sector Errors and How to Protect Against Them[J].ACM Transactions on Storage (TOS) TOS Homepage archive Volume 6 Issue 3, September 2010 Article No. 9.

[6] Werner Vogels. Eventually Consistent - Revisited[EB/OL] http://www.allthingsdistributed.com/2008/12/eventually_ consistent.html, 2008,12.

Cloud Storage System Based on AmazonS3 API

GuoWei, LiXiaoYong
(School of Information Security , Shanghai Jiao Tong University, Shanghai 200240, China)

Abstract:BlueOcean Storage System is a self-design-and-development of distributed file systems. On this basis, design and implement the S3 engine to make it capable of cloud storage work. Through the analysis of high concurrency model, it reflects the BOSS + S3engine advantage in design. Finally, by contrast with the open source projects, it demonstrates results.

Key words:Cloud Storage; S3; High Concurrency Model; Performance Evaluation

收稿日期：（2015.08.04）

作者簡介：郭 ?。?989-），男，甘肅蘭州人，上海交通大學(xué)，信息安全工程學(xué)院，碩士研究生，研究方向：海量存儲，上海，200240

文章編號：1007-757X(2016)01-0044-04

中圖分類號：TP311

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