基于AmazonS3的云存儲系統的設計

郭巍，李小勇

?

基于AmazonS3的云存儲系統的設計

郭巍，李小勇

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

關鍵詞：云存儲；S3；高并發模式；性能測試

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

0 引言

隨著互聯網技術的發展，各式各樣的應用與需求應運而生。云存儲作為其中代表，受到了廣泛的關注。對比傳統網絡存儲，云存儲突破了網絡的限制，用戶可以在任何時間任何地點，通過網絡獲取相關服務。

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

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

1 S3與對象存儲

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

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

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

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

2 系統框架解析

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

圖1　S3engine+BOSS體系架構

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

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

S3 engine是為BOSS存儲系統所設計的S3協議引擎。通過對用戶所發送的S3協議內容的解析，轉變為某個對象的讀寫，并按照實際情況將解析好的請求交給下層的BOSS來處理。完成請求后，將應答包裝成S3協議格式，向用戶發送應答。作為BOSS與用戶之間的橋梁，服務于整個系統。

3 關鍵技術設計

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

3.1 高并發模型設計

S3engine的應用場景是面向百萬級鏈接、為上層用戶提供高并發、低延遲的S3協議的存取服務。為此高并發模型設計的好壞直接影響系統的性能與可用性。

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

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

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

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

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

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

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

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

圖3　多線程并發執行耗時

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

表2　線程調度次數統計

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

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

3.2 磁盤異步IO

分布式系統的主要事件包括網絡事件與磁盤I/O事件。將網絡連接設為非阻塞方式可以有效的規避網絡接收信息延遲所造成的阻塞。

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

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

3.3 副本、審計與恢復策略

副本策略BOS

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

圖4　primary-slave模式數據推送過程

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

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

審計策略與修復策略

審計與修復是系統保證一致性與高可用性的重要方法。審計負責系統不一致性錯誤的發現并向修復服務報告。審計按照處理任務與執行流程的不同分為兩種：實時審計和周期性審計。

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

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

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

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

4 系統測試

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

表3　節點數據

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

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

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

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

圖6　單副本大文件寫

圖7　單副本大文件讀

圖8　雙副本大文件寫

圖9　雙副本大文件讀

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

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

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

5總結

通過與gluster的對比可以證明BOSS所采用并發架構是高效的。雖然通過試驗比較可以看出BOSS在性能上十分優秀，然而還需要長時間的開發周期改進現有系統。下一步的工作重點是繼續完善S3engine的功能，設計一套有效的安全機制，使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] 姚墨涵, 謝紅薇.一致性哈希算法在分布式系統中的應用[J].電腦開發與應用, 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）

作者簡介：郭 巍（1989-），男，甘肅蘭州人，上海交通大學，信息安全工程學院，碩士研究生，研究方向：海量存儲，上海，200240

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

中圖分類號：TP311

文獻標志碼：A