劉福鑫，李勁巍，王熠弘，李 琳

（武漢理工大學計算機科學與技術(shù)學院，武漢430070）

0 引言

云計算已成為互聯(lián)網(wǎng)未來的趨勢之一，擁有不可估量的潛力［1］。云應(yīng)用和云平臺的普及使開發(fā)者能夠?qū)⒏嗟木ν度胗趹?yīng)用程序本身的開發(fā)與維護上，不用再關(guān)心硬件架構(gòu)、服務(wù)器資源與日常硬件維護等與業(yè)務(wù)本身無關(guān)的雜項工作。近年來，越來越多的業(yè)務(wù)開始從傳統(tǒng)的服務(wù)器架構(gòu)遷移到云上，同時我們也看到有更多的業(yè)務(wù)從設(shè)計之初即計劃運行在云端。這些業(yè)務(wù)通常被稱作云原生業(yè)務(wù)，意指其與云的高度結(jié)合。云原生業(yè)務(wù)相對傳統(tǒng)業(yè)務(wù)通常會更加充分且頻繁地應(yīng)用例如微服務(wù)、彈性計算和服務(wù)編排等云平臺所提供的先進技術(shù)幫助業(yè)務(wù)更穩(wěn)定、高效地運行。部分前沿實踐甚至嘗試使用更加輕量的操作系統(tǒng)（如Alpine Linux 等）來適應(yīng)容器化和虛擬化技術(shù)［2］。

當前較為典型的云原生業(yè)務(wù)是移動互聯(lián)網(wǎng)時代的社交平臺，這些平臺大多充分利用了云計算的優(yōu)勢，比如微博廣泛使用阿里云作為其計算后端，構(gòu)建大規(guī)模混合云，將部分高頻業(yè)務(wù)運行于公有云平臺上，以靈活處理熱點事件的突發(fā)負載［3］。社交平臺的用戶量不斷增加，且對計算和存儲的需求極大，這不僅需要靈活而穩(wěn)定的基礎(chǔ)架構(gòu)來保障其穩(wěn)定性，還要利用自動化擴容與災備等高級功能使其在突發(fā)負載下依舊為用戶提供良好的體驗［4］。

早在2010 年，F(xiàn)acebook 就已發(fā)表了其應(yīng)對大規(guī)模照片與文件存儲的方案，這一方案被稱為Haystack。Haystack是一個專注于海量文件存儲的對象存儲系統(tǒng)，它充分滿足Facebook對文件的存儲需求。它使用文件塊將小文件打包進名為Superblock的物理卷中，并將元數(shù)據(jù)緩存在內(nèi)存里以獲得極高的索引和查詢性能。它同樣支持集群化部署，能夠?qū)⒋鎯ω撦d進行分散，以有效提升性能與可擴展性［5］。

隨著近些年來云計算的普及，互聯(lián)網(wǎng)展現(xiàn)出了整體向云上遷移的趨勢，以便充分享受云平臺所帶來的高效與穩(wěn)定。但Haystack 及其大多數(shù)相似實現(xiàn)卻依舊被設(shè)計為運行在傳統(tǒng)硬件架構(gòu)上，需要相對復雜的配置才能使其運行于云端，這與云原生開箱即用、輕量部署的理念有一定差距。若出現(xiàn)熱點事件或用戶量極速增長，手動擴容集群規(guī)模往往不能及時應(yīng)對突發(fā)壓力，甚至在擴容過程中還會由于節(jié)點拓撲無法在線修改，引發(fā)不可避免的閃斷，降低服務(wù)可用性。此外，上述存儲方案在緩存與資源利用上的缺失，同樣導致了它們大多并不能充分利用云所能提供的資源與環(huán)境，所提供的性能依舊不夠理想，這一問題也影響了該類存儲方案的普及。

綜上所述，無論是傳統(tǒng)的文件系統(tǒng)還是當前的對象存儲系統(tǒng)，其設(shè)計與優(yōu)化都不能充分滿足數(shù)據(jù)密集型業(yè)務(wù)在云上不斷擴張的需求，原因主要在于上述存儲方案大多都無法充分利用云平臺所提供的調(diào)度功能，適應(yīng)負載的波動并利用以上功能實現(xiàn)自動化調(diào)度，進一步實現(xiàn)自我優(yōu)化、自我管理。

為了解決以上問題，本文提出了一種新的存儲系統(tǒng)，稱之為Kubestorage，指運行在Kubernetes 上的存儲系統(tǒng)。該系統(tǒng)基于Haystack，但在服務(wù)發(fā)現(xiàn)和自動容錯等宏觀調(diào)度方面進行了專門優(yōu)化，使其更符合云原生技術(shù)的定義，更適合部署在云端，也更適合于在存儲方面驅(qū)動數(shù)據(jù)密集型的云業(yè)務(wù)高效穩(wěn)定運行；此外還針對Haystack 于磁盤方面的性能瓶頸，在緩存與易用性方面進行了優(yōu)化。

1 相關(guān)工作

學術(shù)界在對象存儲方面的研究要遠早于云計算。早在1996 年，卡內(nèi)基梅隆大學就開始了由Garth Gibson 領(lǐng)導的相關(guān)研究，并于1998 年首次提出了對象存儲的概念與基礎(chǔ)架構(gòu)［6］。此后，對象存儲在各存儲公司的支持下持續(xù)蓬勃發(fā)展。據(jù)統(tǒng)計，在1999 年到2013 年之間，在對象存儲方面的風險投資已突破3 億美元［7］，這使得對象存儲技術(shù)得到了極大的發(fā)展，并迅速應(yīng)用于大量成熟的產(chǎn)品中。

美國亞馬遜公司旗下的AWS（Amazon Web Services）早在2006年初就將對象存儲作為開放服務(wù)，開發(fā)了亞馬遜S3對象存儲服務(wù)。僅2012年一年，S3對象存儲系統(tǒng)就新增了超過一萬億個對象，而在短短一年后，甚至增加到每年新增兩萬億個對象。此外，S3 還能確保這些數(shù)據(jù)可以隨時被訪問與隨機讀寫。據(jù)亞馬遜官方報告，S3 中的任意一個文件都可以承載每秒最高110萬次的讀?。?］。

另一個相對較為知名的對象存儲解決方案是由Weil、Brandt、Miller、Long 和Maltzahn 在2006年USENIX 操作系統(tǒng)設(shè)計會議（OSDI 2006）中提出的Ceph［9］。Ceph 在軟件層面進行大量優(yōu)化，能使用普通硬件實現(xiàn)大規(guī)模的文件存儲，相對于來自IBM、EMC等大型存儲方案公司的產(chǎn)品擁有更好的兼容性。

Facebook 公司在2010 年通過論文的形式提出了一種專注于大量小文件的存儲、更實用且更靈活的對象存儲模型，稱之為Haystack。Haystack 的獨特之處在于將小文件合并到一個稱為物理卷的文件塊中，以便在存儲大量小文件的同時保持較為理想的索引速度。文件索引則包含了文件的基礎(chǔ)信息、文件在文件塊中的偏移量等元數(shù)據(jù)。此外，文件索引被讀入內(nèi)存中，以此提升索引速度，降低磁盤負擔。

2 Kubestorage存儲系統(tǒng)的架構(gòu)

Kubestorage存儲系統(tǒng)由三部分組成：

1）目錄服務(wù)器，用于節(jié)點信息的存儲、文件到存儲節(jié)點的映射、節(jié)點自動管理與負載均衡等功能。

2）存儲服務(wù)器，用于文件存儲、元數(shù)據(jù)管理和存儲一致性的自動維護。

3）緩存服務(wù)器，用于緩存高頻訪問的文件，以獲得更好的性能。

整個存儲系統(tǒng)運行在以Docker 為容器后端的Kubernetes集群之上，通過Kubernetes 配置文件的方式進行快速部署，Kubernetes負責提供管理、服務(wù)發(fā)現(xiàn)與故障恢復等功能。

Kubestorage 為解決Haystack 和其他存儲解決方案的缺點，進行了以下改進：

1）使用Raft 一致性算法［10］實現(xiàn)了對多目錄服務(wù)器的支持，使目錄服務(wù)器更穩(wěn)定、可靠，避免單點故障造成整個存儲系統(tǒng)失效。

2）相較于Haystack，Kubestorage 并未將存儲服務(wù)器直接暴露給外部用戶或業(yè)務(wù)，而是使用反向代理由目錄服務(wù)器與業(yè)務(wù)進行讀取與寫入操作以提升安全性，同時增強目錄服務(wù)器對整體的控制能力。鑒于Kubernetes 環(huán)境下虛擬交換機帶寬大于傳統(tǒng)服務(wù)器互聯(lián)帶寬，且可以通過負載均衡器實現(xiàn)集群部署，因此相對于帶寬瓶頸，相對應(yīng)的安全性與簡便性提升更有價值。

目錄服務(wù)器為業(yè)務(wù)提供單點API，涵蓋所有的讀寫與管理操作，以便簡化業(yè)務(wù)開發(fā)，避免存儲服務(wù)器暴露所導致的安全隱患。

3）定期巡檢所有文件，并自動壓縮長時間未訪問的數(shù)據(jù)，以節(jié)省存儲空間.

4）使用多級緩存機制以最大限度地降低檢索文件以及從磁盤中讀取文件造成的性能損失。

5）自動將經(jīng)常訪問的文件復制到多個存儲服務(wù)器中，以分散文件讀取壓力，實現(xiàn)負載均衡。

此外，Kubestorage 還充分利用了容器化的特性和Kubernetes 所提供的豐富功能，保證了在不同軟硬件上運行環(huán)境的一致性，并在此基礎(chǔ)上使其具有如下更多功能：

1）動態(tài)監(jiān)測所有Kubestorage 節(jié)點的狀態(tài)，并在磁盤空間、CPU配額、內(nèi)存空間不足時自動擴容。

2）自動運行狀況檢查，其中包括一致性檢查、有效性校驗、延遲檢查、壓力測試與硬件健康檢查。

3）基于kube-apiserver 與kube-dns 的自動服務(wù)發(fā)現(xiàn)，可在服務(wù)不中斷的情況下動態(tài)修改存儲集群拓撲，提升Kubestorage的可用性。

Kubestorage 的詳細架構(gòu)如圖1 所示，主要由目錄服務(wù)器、存儲服務(wù)器和緩存服務(wù)器三個部分組成。

2.1 目錄服務(wù)器

目錄服務(wù)器主要承擔以下工作：

1）管理邏輯卷和物理卷之間的映射；

2）管理目錄服務(wù)器級別緩存；

3）當某個文件訪問量激增時，開啟自動文件冗余，在多個存儲服務(wù)器上建立該文件的副本以提升吞吐能力；

4）作為負載均衡器，對存儲服務(wù)器進行反向代理，并向外部業(yè)務(wù)提供統(tǒng)一的API。

同時，Kubestorage還具有以下功能，使其更適合自動化集群部署，并提供一致性與可靠性保障：

1）使用Raft 一致性算法提供較高的一致性與可靠性，避免單點故障導致整個存儲系統(tǒng)失效，外部業(yè)務(wù)對附屬節(jié)點的訪問將會被轉(zhuǎn)發(fā)到主節(jié)點。該算法保證了數(shù)據(jù)的一致性與可靠性，使得在每個輪換周期內(nèi)有且僅有一個目錄服務(wù)器負責響應(yīng)用戶請求。

2）Kubernetes 將會對每臺目錄服務(wù)器設(shè)置3 個預設(shè)標簽：角色、狀態(tài)和健康度。例如角色為kube-storage-directory，狀態(tài)為leader 或slave，運行狀況將是以下4 種類型之一：正在運行（Running）、正在初始化（Initializing）、忙碌（Busy）或離線（Offline）。當每個目錄服務(wù)器需要知道其他目錄服務(wù)器的狀態(tài)和數(shù)量時，可以使用這3 個標簽作為選擇器，向kubeapiserver 詢問目錄服務(wù)器列表，kube-apiserver 將返回集群內(nèi)滿足所選擇條件的服務(wù)器。

3）為了保障數(shù)據(jù)一致性，避免使用讀/寫鎖造成系統(tǒng)邏輯復雜化，所有目錄服務(wù)器將會共享一個數(shù)據(jù)庫后端。數(shù)據(jù)庫后端的種類可以根據(jù)實際需求自由決定，但以Redis為例的內(nèi)存數(shù)據(jù)庫通常可以提供最佳的性能。

此外，目錄服務(wù)器還會記錄最近的文件讀取請求并存儲在數(shù)據(jù)庫內(nèi)該文件對應(yīng)的記錄中，然后定期讀取上一個巡檢周期內(nèi)各文件訪問次數(shù)。對于頻次超過設(shè)定閾值的文件，目錄服務(wù)器會使用存儲服務(wù)器的冗余寫入API 進行自動冗余，依靠在多個服務(wù)器上建立該文件的副本以提升性能，若下一次巡檢發(fā)現(xiàn)已冗余的文件訪問量低于閾值，目錄服務(wù)器則會使用冗余刪除API進行已冗余文件的移除。

圖1 Kubestorage的架構(gòu)示意圖Fig.1 Schematic diagram of Kubestorage architecture

2.2 存儲服務(wù)器

存儲服務(wù)器主要承擔以下工作：

1）負責管理存儲在其中的文件、文件的元數(shù)據(jù)以及文件的寫入和讀?。?/p>

2）管理存儲服務(wù)器級別緩存；

3）執(zhí)行數(shù)據(jù)壓縮、解壓縮與有效性校驗；

4）定期向目錄服務(wù)器報告其狀態(tài)，以便根據(jù)統(tǒng)計信息進行自動化管理。

存儲服務(wù)器的技術(shù)實現(xiàn)如下：

1）元數(shù)據(jù)和物理卷的底層存儲與Haystack 基本一致，但Kubestorage 在此基礎(chǔ)上增加了對壓縮文件的支持，文件是否被壓縮的狀態(tài)被存儲在元數(shù)據(jù)中，并在寫入時壓縮存入，讀取時解壓讀取。

2）Kubernetes所提供的持久卷（Persistent Volume）將用作存儲服務(wù)器的存儲后端。它具有高度抽象的特性，獨立于特定的操作系統(tǒng)、存儲架構(gòu)和硬件，可以與現(xiàn)有的存儲方案良好兼容，并可避免計算與存儲的強耦合。為了使Kubestorage 盡可能簡潔，冗余和高可用由實際的存儲后端自主實現(xiàn)，以充分利用磁盤/網(wǎng)絡(luò)存儲行業(yè)中長期的技術(shù)積累。

3）Kubestorage 選擇了較為松散的元數(shù)據(jù)存儲后端結(jié)構(gòu)，以接口方式實現(xiàn)，使其能充分利用云平臺中所提供的數(shù)據(jù)庫服務(wù)進行元數(shù)據(jù)的存儲。此外，為了簡化部署和使用，Kubestorage搭載了leveldb［11］作為其默認數(shù)據(jù)庫。該數(shù)據(jù)庫在存儲量較小但訪問頻次較高、數(shù)據(jù)結(jié)構(gòu)單一的情況下可以實現(xiàn)用很少的資源消耗提供相對理想的性能，避免普通文件數(shù)據(jù)庫頻繁磁盤讀寫與復雜存儲結(jié)構(gòu)造成的性能瓶頸。

4）每個存儲服務(wù)器將定期運行自檢服務(wù)，獲取當前存儲容量、并發(fā)讀寫狀態(tài)、文件數(shù)量、硬件健康狀態(tài)、網(wǎng)絡(luò)情況以及其他所需信息，并提供API，便于外部查詢服務(wù)器狀態(tài)。自檢服務(wù)使得目錄服務(wù)器、Kubernetes、甚至運維人員可以隨時了解到當前每個節(jié)點的狀態(tài)并及時進行管理。

5）當具有副本標記的文件寫入請求到達存儲服務(wù)器時，存儲服務(wù)器會首先在本地存儲該文件。然后存儲服務(wù)器會根據(jù)寫入請求中所指定的地址向?qū)?yīng)的其他存儲服務(wù)器發(fā)送副本創(chuàng)建請求，其他存儲服務(wù)器收到請求后同樣將文件寫入。副本創(chuàng)建請求同樣也可以被目錄服務(wù)器所觸發(fā)，以根據(jù)訪問頻次進行副本數(shù)的動態(tài)變化，實現(xiàn)動態(tài)負載均衡。

6）刪除文件時，存儲服務(wù)器會立即刪除元數(shù)據(jù)，但此時文件尚未被物理刪除。巡檢程序會定期啟動，以比較物理卷和元數(shù)據(jù)中的文件對應(yīng)情況。如果發(fā)現(xiàn)當前物理卷有已刪除文件或損壞的文件，巡檢程序?qū)?chuàng)建新的臨時物理卷，并根據(jù)元數(shù)據(jù)將物理卷中的每個文件復制到臨時物理卷。

2.3 緩存服務(wù)器

緩存服務(wù)器負責統(tǒng)一的數(shù)據(jù)緩存，由于需要存儲文件，因此使用Redis作為其存儲后端，從內(nèi)存中進行文件讀寫以保障性能。緩存服務(wù)器使用了目錄/存儲兩級緩存設(shè)計，以提升緩存性能，盡量降低響應(yīng)時間與服務(wù)器負載。

其具體的技術(shù)實現(xiàn)如下：

1）緩存服務(wù)器定期檢查存儲在其中的目錄與存儲級緩存，刪除重復的緩存（即緩存文件都存在于目錄級緩存和存儲級緩存中），并自動清除一段時間內(nèi)未訪問的緩存以節(jié)省內(nèi)存空間。

2）緩存服務(wù)器還會將頻繁訪問但只緩存在存儲級緩存中的文件移動到目錄級緩存中，以提升請求效率。

2.4 文件上傳與下載的流程

將文件上傳到Kubestorage 的過程分為以下幾步：目錄服務(wù)器首先接收來自業(yè)務(wù)的文件上傳請求，其中包括文件的副本次數(shù)和文件的二進制數(shù)據(jù)。如果當前目錄服務(wù)器不是Leader 服務(wù)器，則受理上傳請求的目錄服務(wù)器將向Leader 服務(wù)器發(fā)送一個反向代理請求。Leader 服務(wù)器將會核對數(shù)據(jù)庫，以確保物理卷數(shù)量足夠，然后創(chuàng)建區(qū)塊和存儲數(shù)據(jù)的請求將被發(fā)送到指定的存儲服務(wù)器。目錄服務(wù)器最后生成對應(yīng)鏈接以便后續(xù)訪問。

從Kubestorage 下載文件的過程則分為以下幾步：首先業(yè)務(wù)將向目錄服務(wù)器發(fā)送文件下載請求，請求中包含此前所生成的永久鏈接，目錄服務(wù)器首先將檢查文件是否存在于目錄級緩存中，如果文件存在，數(shù)據(jù)將從內(nèi)存中讀取，并直接傳輸給業(yè)務(wù)；如果未命中緩存，則會將文件獲取請求發(fā)送到相應(yīng)的存儲服務(wù)器，存儲服務(wù)器同樣將檢查文件是否存在于存儲級緩存中，如果在存儲級緩存中則直接傳輸，如果緩存未命中，則存儲服務(wù)器會將當前文件放在存儲級緩存中，以此減少下次讀取時間，如果頻繁訪問該文件，它還會被轉(zhuǎn)移到目錄級緩存進一步提高文件的訪問速度。

2.5 緩存策略的實現(xiàn)

存儲服務(wù)器會將接收到的每一次讀取請求記錄在數(shù)據(jù)庫中（每次巡檢周期結(jié)束后清空一次計數(shù)），并在下一次巡檢周期開始時將滿足訪問次數(shù)閾值的文件放置于相對應(yīng)的存儲級緩存中。對于已緩存的文件，若下一次巡檢的讀取次數(shù)低于閾值，則將其從緩存中清除。若多次巡檢發(fā)現(xiàn)緩存依然未被清除，則將該文件轉(zhuǎn)移至目錄級緩存。

若緩存服務(wù)器緩存體積超過最高安全閾值，則會按照上一個巡檢周期內(nèi)的緩存命中次數(shù)對文件進行排序，清除命中次數(shù)較低的文件直至緩存體積低于最低安全閾值。

上文所述所有閾值與巡檢周期均可配置，以便平衡性能與成本，適配不同規(guī)模的存儲需求。

2.6 對服務(wù)器節(jié)點故障的處理

Kubestorage 能容許服務(wù)器節(jié)點的故障并能實現(xiàn)自動恢復。每臺目錄服務(wù)器都會通過kube-apiserver 組件定時獲取當前所有節(jié)點狀態(tài)，若發(fā)現(xiàn)某臺服務(wù)器出現(xiàn)異常（即Kubernetes 自檢不成功，Pod 狀態(tài)為NotReady 或狀態(tài)標簽為Offline），目錄服務(wù)器會立刻調(diào)用kube-apiserver 清除故障節(jié)點并完成持久卷綁定、數(shù)據(jù)庫初始化等操作，實現(xiàn)自恢復。該策略對目錄服務(wù)器、存儲服務(wù)器與緩存服務(wù)器均有效。

由于負載均衡的存在，所有請求均會被傳遞到正常的目錄服務(wù)器中，若出現(xiàn)異常的目錄服務(wù)器為Raft 集群的Leader，則剩余的所有Followers會重新進行選舉。選舉期間的請求將會被放入等待隊列，并在對應(yīng)存儲服務(wù)器恢復后立刻繼續(xù)任務(wù)。對故障緩存服務(wù)器的請求被視為緩存未命中，直接從存儲服務(wù)器請求所需文件。

3 性能測試

3.1 測試環(huán)境

性能分析部分將使用阿里云的ECS 服務(wù)器作為測試平臺，配置為Intel Xeon Platinum 8163 處理器（8 個虛擬核心），32 GB 內(nèi)存，同時掛載6 TB 的SSD 云磁盤作為測試用數(shù)據(jù)盤（標稱IOPS為25 000，吞吐量為讀/寫均256 MB/s）。

我們選擇了EXT4、ZFS 和SeaweedFS 作為基準，分別代表傳統(tǒng)文件系統(tǒng)、現(xiàn)代文件系統(tǒng)和傳統(tǒng)對象存儲系統(tǒng)。SSD 云磁盤將分別被格式化為EXT4、ZFS 文件系統(tǒng)，并對其進行一系列的測試。該云磁盤也將被格式化為EXT4，并在其上配置Kubernetes 單機集群（使用Flannel 虛擬網(wǎng)絡(luò)），以便使用Kubestorage和SeaweedFS進行測試。

3.2 測試方法

測試方法如下：在測試服務(wù)器上運行使用Golang 開發(fā)的文件讀寫API，并使用另一臺配置相同的服務(wù)器在局域網(wǎng)內(nèi)遠程訪問此API，避免測試工具本身對測試造成的干擾。Kubestorage 將構(gòu)建于Kubernetes 上，使用2 個目錄服務(wù)器、8個存儲服務(wù)器與1 個緩存服務(wù)器構(gòu)成小型的Kubestorage 集群，物理卷大小為每文件1 GB，文件默認副本數(shù)為2。SeaweedFS 將保持與Kubestorage 相同的硬件配置與環(huán)境配置，并按照使用文檔使其運行于Kubernetes上。

3.3 測試過程

測試過程如下：

1）提前分別將1 000 萬個文件大小為4 KB、40 KB 與400 KB 的文件寫入待測試的存儲系統(tǒng)，文件內(nèi)容為隨機ASCII字符。為避免EXT4由于inode不足造成測試失敗，已提前擴增inode容量。

2）在另一臺服務(wù)器上（兩臺服務(wù)器之間網(wǎng)絡(luò)帶寬為10 Gb/s）通過測試軟件分別啟動足量線程直至測試服務(wù)器報告其正在執(zhí)行的并發(fā)請求數(shù)量為50、500、1 000、5 000（避免由于發(fā)起線程數(shù)與測試服務(wù)器收到請求數(shù)不一致對測試造成干擾，使接收請求數(shù)盡量接近實際的并發(fā)讀取數(shù)），使用上文所提及統(tǒng)一的API 從測試服務(wù)器中隨機進行文件的讀取和寫入，在發(fā)起請求的服務(wù)器上記錄每次讀取和寫入的響應(yīng)時間以供后續(xù)性能分析。每輪讀取測試中，1 000萬個文件中的隨機20 萬個將被以隨機的不同頻次總共讀取500 萬次，以模擬云計算環(huán)境中真實業(yè)務(wù)中的負載場景。每輪寫入測試中，將寫入20 萬個文件，每個文件大小分別為4 KB、40 KB 與400 KB，文件內(nèi)容同樣為隨機ASCII。

3）從預寫入的1 000 萬個40 KB 文件中隨機選取100 個40 KB 文件進行熱點測試，模擬社交平臺中常見的熱點圖片資源，對這100 個文件同時進行并發(fā)數(shù)為1 000 的隨機讀取，每個文件讀取10 000次，記錄讀取過程中性能的變化、緩存的變化與文件分布的變化，以測試上文所述緩存策略與自動冗余策略是否有效。

4）在1 000個線程的40 KB隨機讀寫測試過程中，手動將一半的目錄服務(wù)器與一半的存儲服務(wù)器狀態(tài)配置為Offline（拒絕所有請求），以測試性能波動與服務(wù)穩(wěn)定性。

由于Kubestorage 與SeaweedFS 均不支持目錄功能，為保證測試的準確性與可信度，對于傳統(tǒng)文件系統(tǒng)，所有讀取與寫入的文件均放置在同一目錄下。

3.4 度量標準

在測試過程中，將記錄并比較平均響應(yīng)時間、響應(yīng)時間方差和1 000并發(fā)下響應(yīng)時間占比（即小于特定響應(yīng)時間的請求占比）。平均時間越短，表示性能越好；方差越小，表示越穩(wěn)定；響應(yīng)時間占比中低延時所占百分比越多表示性能越好。每組實驗將在相同條件下重復5 次，并取所有數(shù)據(jù)的平均值。實驗結(jié)果如表1～3所示。

表1 不同線程數(shù)量下各存儲方案的平均讀取時間、平均寫入時間與方差對比Tab.1 Comparison of average read time，average write time and their variances of different storage schemes under different thread number

表2 1 000并發(fā)請求下各存儲方案的讀取與寫入時間占比Tab.2 Average read and write time proportion of different storage schemes under 1 000 concurrent requests

表3 熱點訪問測試中平均響應(yīng)時間與方差 單位：msTab.3 Average response time and variance in hot spot access test unit：ms

3.5 測試結(jié)果與分析

3.5.1 性能分析

從表1、2 中可以看出，ZFS 受限于其復雜的設(shè)計，響應(yīng)時間與穩(wěn)定性落后于其他存儲方案，這是由于ZFS相較于性能，更側(cè)重于可管理性與可擴展性，導致文件讀寫過程相對復雜，相應(yīng)的資源耗費更多。當并發(fā)讀取量較低時，Kubestorage、SeaweedFS 的讀取性能與EXT4 大致相同。當并發(fā)讀取量上升后，Kubestorage 開始逐漸展現(xiàn)出其優(yōu)勢，盡管Kubestorage和SeaweedFS 具有相同的存儲模型，但在讀取時，Kubestorage受益于其多級內(nèi)存緩存與自動建立副本的設(shè)計，相對SeaweedFS 性能更占優(yōu)勢。從表中可以看出，Kubestorage 在1 000 與5 000 并發(fā)時的平均響應(yīng)時間與穩(wěn)定性相對于SeaweedFS 與EXT4 均占有一定優(yōu)勢?？傮w而言，采用Haystack 存儲結(jié)構(gòu)的Kubestorage 與SeaweedFS 性能均優(yōu)于EXT4 和ZFS，其中Kubestorage 由于緩存與自動副本策略的引入，性能相對更優(yōu)。

從表1、2 中還可以看出，由于創(chuàng)建元數(shù)據(jù)和將文件插入物理卷的開銷較大，Kubestorage 和SeaweedFS 的寫入性能均遠低于其他文件系統(tǒng)，這一問題在請求數(shù)量增多時格外明顯。

從表3 中可以看出，在熱點訪問測試過程中，由于EXT4、ZFS、SeaweedFS 均不帶有文件緩存，在不同測試階段的性能并無顯著變化，但Kubestorage 隨著訪問計數(shù)的不斷增加開始逐漸開啟副本冗余（10 min 內(nèi)500 次讀取觸發(fā)）、寫入緩存（10 min 內(nèi)1 000 次讀取觸發(fā)），以降低存儲服務(wù)器的磁盤壓力。表3數(shù)據(jù)充分證明了緩存策略為Kubestorage 帶來的性能與穩(wěn)定性提升。

3.5.2 穩(wěn)定性分析

在手動關(guān)閉服務(wù)器的測試過程中，被關(guān)閉的目錄服務(wù)器是當前Raft集群的Leader，Kubernetes 的負載均衡將所有請求移交給另一臺Follower，F(xiàn)ollower 在節(jié)點檢測過程中檢測到Leader 不可用，立刻開始新一輪選舉，并將自己設(shè)置為Leader。期間正在處理的請求被放入目錄服務(wù)器隊列，并在選舉完成后繼續(xù)請求。隨后新的Leader在選舉完成后立即調(diào)用kube-apiserver 新建了一臺新的目錄服務(wù)器以填補空缺，該服務(wù)器成為Follower，服務(wù)恢復正常。

被關(guān)閉的一半存儲服務(wù)器在節(jié)點檢測過程中被目錄服務(wù)器判斷為不可用，并由目錄服務(wù)器調(diào)用kube-apiserver 新建了4 臺新的存儲服務(wù)器，自動完成持久卷掛載與數(shù)據(jù)初始化操作，然后取出所需文件傳輸給客戶端。由于存儲服務(wù)器的初始化需要一定時間，關(guān)閉后約20 s內(nèi)出現(xiàn)了一定的性能波動，這20 s 內(nèi)的平均讀取響應(yīng)時間由10.7 ms 增加到1 466.1 ms，但由于默認副本數(shù)為2，只有少部分文件完全不可讀。

4 結(jié)語

綜上所述，本文所提出的Kubestorage 存儲系統(tǒng)被設(shè)計為更適合存儲云平臺與云業(yè)務(wù)中的大量小文件，尤其是以社交網(wǎng)絡(luò)為典型，即讀遠多于寫的使用場景。上述測試充分展現(xiàn)了Kubestorage 在架構(gòu)設(shè)計上的優(yōu)勢與潛力，且部署過程簡單，使用預配置的腳本僅需數(shù)條命令即可搭建出任意規(guī)模的Kubestorage存儲集群，這使其更為靈活，在云上擁有比傳統(tǒng)存儲解決方案更好的性能和更優(yōu)秀的穩(wěn)定性。Kubestorage開箱即用，更適合云原生業(yè)務(wù)部署，為云上的應(yīng)用提供更快捷穩(wěn)定的存儲解決方案。

但同時我們也看到了目前Kubestorage 所存在的一些不足，將來還需要在以下方面進行改進，以提供更好的使用體驗，進一步提升其實用性與易用性：

1）使用緩存服務(wù)器對文件寫入進行緩存，以實現(xiàn)異步文件保存功能，提供更好的寫入性能；

2）添加對目錄、文件別名、軟鏈接等高級特性的支持，以保持與傳統(tǒng)文件系統(tǒng)的雙向兼容和相互轉(zhuǎn)換，提升兼容性與靈活度，便于讓更多業(yè)務(wù)享受對象存儲的便利；

3）考慮到目標應(yīng)用場景內(nèi)可能有大量重復的文件資源，因此可對散列相同的文件進行合并存儲，以節(jié)省磁盤空間。