云際存儲系統(tǒng)性能優(yōu)化研究現(xiàn)狀與展望*

朱良杰,沈佳杰,周揚帆 ,王 新,3

(1.復旦大學計算機科學技術學院,上海 201203;2.上海市智能信息處理重點實驗室,上海 200433;3.復旦大學信息化辦公室,上海 200433)

1 引言

隨著互聯(lián)網(wǎng)技術與應用的快速發(fā)展，用戶數(shù)據(jù)開始呈現(xiàn)爆發(fā)式增長。根據(jù)國際數(shù)據(jù)資訊公司IDC的預測，從2020 年開始，每2年上網(wǎng)用戶總量將增長一倍，每6～9個月企業(yè)產(chǎn)生的數(shù)據(jù)量將會翻一番[1]。面對如此海量的用戶數(shù)據(jù)，云存儲作為一種有效的存儲方案被廣泛應用于在線數(shù)據(jù)存儲。

然而，當前的云存儲系統(tǒng)普遍存在諸多問題：首先，云存儲系統(tǒng)存在云提供商存儲服務鎖死的問題[2]。當用戶需要更換供應云提供商時，需要進行大量數(shù)據(jù)拷貝和遷移操作，從而導致大量的數(shù)據(jù)傳輸開銷。其次，云存儲系統(tǒng)存在存儲數(shù)據(jù)可靠性的問題。當云存儲失效時，可能會導致用戶數(shù)據(jù)丟失的情況[3]。最后，云存儲存在安全問題。當云基礎設施被黑客攻陷后，攻擊者將獲取云存儲中的數(shù)據(jù)[4]。

為了彌補云存儲系統(tǒng)的上述不足之處，學者們提出了云際存儲方案[5]。在云際存儲系統(tǒng)中，采用不同提供商的云存儲服務來構建一個統(tǒng)一的存儲管理平臺，提供安全可靠的存儲服務。通過將數(shù)據(jù)編碼存儲在不同的云服務提供商的存儲空間中，云際存儲系統(tǒng)可以保障在若干個云失效的情況下恢復出用戶數(shù)據(jù)。此外，云際存儲系統(tǒng)對機密數(shù)據(jù)進行加密和編碼生成多個分片上傳至不同的云存儲空間，即使中間的若干個云被黑客攻破，攻擊者因信息不全將無法破解出完整的機密數(shù)據(jù)[6]，從而保證數(shù)據(jù)的機密性。

由于云際存儲系統(tǒng)具有這些優(yōu)良的特性，近年來已成為云存儲系統(tǒng)的重要發(fā)展方向和研究熱點。然而，若簡單地用當前云際存儲方案替換云存儲方案部署在當前在線應用而不優(yōu)化上層的軟硬件架構，則會限制云際存儲系統(tǒng)的性能。具體說來，制約云際存儲系統(tǒng)性能的主要因素有：

(1)網(wǎng)絡適配能力。用戶端設備需要通過互聯(lián)網(wǎng)將加密和編碼后的數(shù)據(jù)上傳到云端。由于在這種網(wǎng)絡環(huán)境下帶寬往往具有較大的波動性，云際存儲系統(tǒng)需要動態(tài)調整傳輸策略以適應當前網(wǎng)絡狀態(tài)，從而更好地滿足實際在線應用的存儲需求。

(2)資源管理機制。在數(shù)據(jù)存儲過程中，云際存儲系統(tǒng)需要將數(shù)據(jù)分發(fā)到多個云，并有效地管理這些已經(jīng)存儲在云端的數(shù)據(jù)。這就要求云際存儲系統(tǒng)可以高效地管理用戶端設備和云端的計算、傳輸和存儲資源，從而保證用戶數(shù)據(jù)存儲的安全性和效率。

(3)應用場景適應能力。不同的存儲應用中用戶端設備和云端可使用的資源往往有較大的差異。由于不同在線應用的存儲需求差異較大，云際存儲系統(tǒng)往往需要根據(jù)在線應用的需求特性來優(yōu)化對應數(shù)據(jù)讀寫和修復方案，并調整自身的數(shù)據(jù)傳輸及資源管理策略，從而適應不同的應用場景。

針對上述3個問題，當前的研究工作通過構建高效的云際存儲管理機制和數(shù)據(jù)分發(fā)方案來解決這些問題。本文綜述了當前云際存儲系統(tǒng)的性能優(yōu)化方案，包括以下3個方面內容：

首先，本文介紹了云際存儲系統(tǒng)中數(shù)據(jù)讀寫及修復操作執(zhí)行過程，并總結了常見的數(shù)據(jù)分發(fā)方案。在此基礎上，本文介紹了當前提升云際存儲系統(tǒng)網(wǎng)絡傳輸效率的主流設計方案，如構建新的編碼網(wǎng)絡方案來減少數(shù)據(jù)修復操作。本文綜述了這些操作對于網(wǎng)絡的需求及當前云際存儲中主要的用戶端設備和云端之間的網(wǎng)絡傳輸方案。

其次，在分析了運行過程中用戶端設備和云端所使用的主要資源的基礎上，本文介紹了云際存儲系統(tǒng)主要的管理方案。針對于云際存儲3種主要的系統(tǒng)資源(即，計算、網(wǎng)絡和存儲資源)，本文綜述了當前主流的云際存儲系統(tǒng)資源管理方案并分析了這些方案的適用場景及優(yōu)缺點。

最后，本文介紹了云際存儲系統(tǒng)的3種經(jīng)典應用場景(即，數(shù)據(jù)備份、移動應用和云際計算)。在此基礎上，本文總結了當前云際存儲系統(tǒng)的實現(xiàn)機制和優(yōu)化方案。通過分析和對比當前云際存儲系統(tǒng)及其適合的應用場景，本文總結了云際存儲系統(tǒng)亟待解決的問題。

2 云際存儲和數(shù)據(jù)分發(fā)方案背景介紹

云際存儲系統(tǒng)需要使用數(shù)據(jù)分發(fā)算法(Dispersal Algorithm)將數(shù)據(jù)分片上傳，并完成數(shù)據(jù)讀寫及修復等操作。本文首先介紹當前的云際存儲系統(tǒng)背景及運行時需要執(zhí)行的操作。在此基礎上，本文總結了當前云際存儲系統(tǒng)中主要的數(shù)據(jù)分發(fā)方案，并分析了它們的復雜度。

2.1 云際存儲背景介紹

為了保證用戶存儲數(shù)據(jù)的可靠性，當前云際存儲系統(tǒng)使用數(shù)據(jù)分發(fā)算法將數(shù)據(jù)分發(fā)到不同的云存儲空間。

圖1[7]展示了云際存儲系統(tǒng)中的主要操作。

Figure 1 Main operations in cloud-of-clouds storage圖1 云際存儲系統(tǒng)中主要操作

在云際存儲系統(tǒng)中，用戶端設備執(zhí)行寫入(加密、編碼和上傳)操作和讀取(下載、解碼和解密)操作，云端執(zhí)行修復操作。在這些操作的執(zhí)行過程中，存在2種主要的網(wǎng)絡傳輸優(yōu)化方案，即通過構建編碼方案來減少網(wǎng)絡數(shù)據(jù)傳輸量或根據(jù)當前網(wǎng)絡和系統(tǒng)狀態(tài)來動態(tài)調整相應數(shù)據(jù)傳輸機制。

根據(jù)實際應用場景的需求和特點，云際存儲系統(tǒng)需要使用不同的數(shù)據(jù)分發(fā)方案來提供存儲服務。例如，為了保證存儲數(shù)據(jù)的安全性和可靠性，云際存儲系統(tǒng)需要使用分發(fā)算法將數(shù)據(jù)加密并編碼生成多個分片并分配到不同云。因此，研究人員提出多種數(shù)據(jù)分發(fā)方案來提升云際存儲系統(tǒng)的性能。若一個數(shù)據(jù)分發(fā)算法將原始數(shù)據(jù)加上冗余數(shù)據(jù)之后的目標數(shù)據(jù)分為n個分片，并且利用其中任意k個分片即可恢復原始數(shù)據(jù)。同時為保證云際存儲系統(tǒng)數(shù)據(jù)安全性，黑客在攻陷t個存儲節(jié)點時無法獲取機密消息的相關數(shù)據(jù)。這樣的數(shù)據(jù)分發(fā)算法被定義為(n,k,t)數(shù)據(jù)分發(fā)算法，其中t為安全度，云系統(tǒng)上存儲的目標數(shù)據(jù)與原始數(shù)據(jù)的比值定義為存儲增益Ω 。下面將介紹當前云際存儲系統(tǒng)廣泛使用的數(shù)據(jù)分發(fā)方案。

2.2 數(shù)據(jù)分發(fā)方案

在提出云際存儲系統(tǒng)相關概念之前，研究人員已經(jīng)開展了很多與數(shù)據(jù)分發(fā)操作相關的工作[7]，很多分發(fā)操作方案依然被廣泛用于當前的云際存儲系統(tǒng)來安全地讀寫數(shù)據(jù)。Rabin[8]提出了一個信息分配算法IDA(Information Dispersal Algorithm)在不考慮安全性(安全度t=0)的情況下完成數(shù)據(jù)分發(fā)操作。在保證數(shù)據(jù)安全性的基礎上(安全度t=k-1)，Shamir[9]提出了Shamir秘密共享算法SSSS(Shamir’s Secret Sharing Scheme)來完成數(shù)據(jù)分發(fā)操作。Blakley等人[10]提出了機密信息共享RSSS(Ramp Secret Sharing Scheme) 方案來構建安全性可調(安全度t∈[0,k-1])的通用分發(fā)算法。Krawczyk[11]提出了消息分享方案SSMS(Secret Sharing Made Short)來減少Shamir秘密共享算法SSSS的存儲開銷。這些方案在設計之初只考慮了安全性，卻忽略了帶來的存儲空間和性能開銷的問題。

上述數(shù)據(jù)分發(fā)算法具有很高的計算復雜性，因而在實際的云際存儲系統(tǒng)中很難高效地執(zhí)行這些算法。Resch等人[6]提出了AONT-RS(All-Or-Northing Transform with Reed-Solomon coding)算法來提升數(shù)據(jù)分發(fā)算法的性能和安全性。但是，AONT-RS使用隨機密鑰來加密機密消息，這種機制會影響數(shù)據(jù)去重的性能和數(shù)據(jù)存儲效率。Li等人[4]提出了2種不同的分配算法CRSSS (Convergent RSSS)和CAONT-RS (Convergent AONT-RS)來有效提升云際存儲的存儲空間利用率。Shen等人[12]利用非系統(tǒng)編碼HCE-PPC(Hash Cyclic Encryption-Privacy Protecting Codes)來快速進行數(shù)據(jù)編解碼操作。Yao等人[13]提出一種安全的數(shù)據(jù)分發(fā)算法SAONT-RS(Safe and efficient AONT-RS)來提升數(shù)據(jù)存儲操作的安全性。通過對云際存儲冗余數(shù)據(jù)的合理分配，Mao等人[14]有效提升了云際存儲系統(tǒng)的可用性。Bernstein等人[15]構建了一個云際存儲系統(tǒng)的測試平臺，用于分析各種云際存儲方案優(yōu)缺點。針對數(shù)據(jù)安全性問題，Louk等人[16]提出了一種云際同態(tài)加密方案。Shen等人[17]提出了基于網(wǎng)絡編碼的數(shù)據(jù)分發(fā)方案NCCS(Network Coding based Cloud of clouds Storage)來減少移動應用場景中用戶設備存儲數(shù)據(jù)的開銷。Kapusta等人[18]引入新的數(shù)據(jù)分片方式KFA(Kapusta’s Fragmentation Algorithm)，將數(shù)據(jù)塊拆分為更小的迷你塊，再利用偽隨機的重排列優(yōu)化分片方式，提升數(shù)據(jù)存儲的安全性。表1比較了數(shù)據(jù)分發(fā)算法的安全度和存儲增益[17]。

Table 1 Security and storage gain of dispersal algorithms表1 主要的數(shù)據(jù)分發(fā)算法的安全度和存儲增益

由于不同的應用場景對于安全度和存儲增益的要求不一致，現(xiàn)有云際存儲系統(tǒng)需要部署不同的數(shù)據(jù)分發(fā)算法。與此同時，在數(shù)據(jù)分發(fā)過程中，由于需要執(zhí)行加密、編碼和傳輸操作，這些操作將會引起較大數(shù)據(jù)讀寫時延，從而增加了云際存儲系統(tǒng)的時延開銷。為了保證可以執(zhí)行相應的存儲操作，云際存儲系統(tǒng)需要進一步優(yōu)化讀寫操作來減少操作時延。

當前，云際存儲系統(tǒng)已經(jīng)被廣泛地部署，用于存儲用戶數(shù)據(jù)。其中比較著名的云際存儲系統(tǒng)包括IBM的Cleversafe、歐盟基金會的SafeCloud和法國的InterCloud。Cleversafe使用AONT-RS[6]來分發(fā)用戶數(shù)據(jù)，從而保證云端用戶數(shù)據(jù)的安全性和可靠性，其主要被用于IBM云對象存儲。SafeCloud主要面向個人數(shù)據(jù)存儲。當前SafeCloud已經(jīng)被部署到了多個歐洲企業(yè)。InterCloud與阿里云、AWS、Azure和Google等合作，提供了軟件定義云互聯(lián)平臺。InterCloud主要用于企業(yè)數(shù)據(jù)存儲，其客戶包括施耐德電氣、空客等公司。

2.3 數(shù)據(jù)分發(fā)算法的復雜度分析

當前數(shù)據(jù)分發(fā)算法的計算瓶頸為解碼時對大規(guī)模線性方程組的求解。傳統(tǒng)求解方法有多種,如高斯消元法、LU分解法和QR分解法等。如今馮達等人[19]也提出一種優(yōu)化方案EVLE-LS(Efficient Verifiable outsourcing of solving large scale Linear Equations with Low Storage overhead)。EVLE-LS利用偽隨機數(shù)生成器將系數(shù)矩陣改造為稀疏矩陣，從而優(yōu)化解方程的時間開銷。本文以高斯消元法為求解方法分析數(shù)據(jù)分發(fā)算法的復雜度。

IDA算法計算開銷主要在解碼恢復數(shù)據(jù)階段中。對生成矩陣A求逆矩陣A-1時，其復雜度為O(n3)。SSSS分發(fā)算法插值的開銷為O(n*log(n)),由于數(shù)據(jù)向量中存在冗余數(shù)據(jù)，所求數(shù)據(jù)僅存在于向量組中的一個向量，所以求逆矩陣時，其復雜度為O(n4)。RSSS與CRSSS的復雜度與安全度相關，當t=0時，RSSS和CRSSS的復雜度為O(n3)，而極端情況下t逼近k-1時，復雜度為O(n4)。CRSSS的加密哈希密鑰是由自身數(shù)據(jù)生成的，以部分哈希值的計算開銷為代價，減少了數(shù)據(jù)重復。SSMS的主要開銷為SSSS分享，復雜度與SSSS相同，也為O(n4)。

AONT-RS和CAONT-RS的主要開銷也是在求生成矩陣的逆矩陣這一階段。AONT-RS、CAONT-RS引入RS糾刪碼。RS code是基于有限域(Galois Field)的一種編碼算法，其可基于范德蒙(Vandermonde)矩陣和柯西矩陣，基于二者矩陣編碼的復雜度為O(n2)，但在解碼這一過程中，范德蒙矩陣解碼復雜度為O(n3),而柯西矩陣解碼復雜度為O(n2)。與AONT-RS相比，CAONT-RS的加密哈希密鑰是由自身數(shù)據(jù)生成的，減少了數(shù)據(jù)重復的同時也增加了計算開銷，兩者的復雜度均為O(n3)。

HCE-PPC的主要開銷也在解碼時。與AONT-RS、CAONT-RS算法相比，HCE-PPC在編碼時，不依賴整體數(shù)據(jù)的哈希值，而是基于當前數(shù)據(jù)塊的哈希值，并行化程度更高。同時，HCE-PPC的生成矩陣更加簡單。雖然復雜度也為O(n3)，但實際運行中，HCE-PPC的運行速度會更快。

而在NCCS中，NAONT-RS和NCAONT-RS所需工作量仍與AONT-RS和CAONT-RS一致，但引入網(wǎng)絡編碼時，移動終端編碼解碼傳輸?shù)闹饕^程由速度更快的服務器完成。KFA分片過程的操作為生成拆分排列、數(shù)據(jù)分發(fā)、編碼和數(shù)據(jù)重排列，其中主要開銷為迷你塊的編碼。在解碼過程中，與ANOT-RS類似，其復雜度為O(n3)。表2展示了當前數(shù)據(jù)分發(fā)算法的復雜度。

Table 2 Complexity of dispersal algorithms in cloud-of-clouds storage system表2 云際存儲系統(tǒng)中主要數(shù)據(jù)分發(fā)算法的復雜度

3 云際存儲網(wǎng)絡管理方案

由于在線應用需要高速地訪問用戶數(shù)據(jù)并保證存儲數(shù)據(jù)的可靠性，云際存儲系統(tǒng)需要頻繁地執(zhí)行讀寫、修復和傳輸操作，在不同的應用場景下可針對這些操作進行相應的性能優(yōu)化。

3.1 用戶端設備數(shù)據(jù)讀寫操作

在云際存儲系統(tǒng)中，用戶端設備需要通過讀寫用戶數(shù)據(jù)來完成相應的讀寫請求。

數(shù)據(jù)分發(fā)：為了保存用戶數(shù)據(jù)，云際存儲系統(tǒng)需要將數(shù)據(jù)分發(fā)到不同的云存儲空間。圖2[17]展示了數(shù)據(jù)分發(fā)操作在云際存儲系統(tǒng)中的執(zhí)行過程。

Figure 2 Data dispersal process in cloud-of-clouds storage圖2 云際存儲系統(tǒng)數(shù)據(jù)分發(fā)過程

如圖2所示，云際存儲系統(tǒng)通過機密消息加密、編碼和傳輸?shù)榷鄠€步驟完成數(shù)據(jù)分發(fā)操作，這些操作往往會帶來大量的系統(tǒng)開銷，包括計算開銷和傳輸開銷，并降低數(shù)據(jù)寫入操作的性能。

數(shù)據(jù)讀?。涸谠齐H存儲系統(tǒng)讀取數(shù)據(jù)時，需要執(zhí)行下載、解碼和解密操作來獲取原始用戶數(shù)據(jù)，圖3[7]展示了云際存儲系統(tǒng)的數(shù)據(jù)讀取操作過程。

Figure 3 Data reading process in cloud-of-clods storage圖3 云際存儲系統(tǒng)數(shù)據(jù)讀取過程

云際存儲系統(tǒng)讀取操作過程中的下載、解碼和解密操作會產(chǎn)生計算和傳輸開銷，這些操作會增加存儲系統(tǒng)執(zhí)行讀寫操作的時延，從而影響用戶體驗并限制云際存儲系統(tǒng)的應用場景。

3.2 云端數(shù)據(jù)修復操作

由于在云際存儲中存在存儲失效問題，為了保證數(shù)據(jù)的可靠性，云際存儲系統(tǒng)需要修復失效的云節(jié)點中的數(shù)據(jù)。圖4[7]展示了云際存儲修復操作的例子。

Figure 4 Erasure code based data recovery process圖4 傳統(tǒng)糾刪碼云際存儲修復方案

假設大小為1 MB的原始對象被分成2個數(shù)據(jù)分片A和B，每一個分片為0.5 MB。假設分片A所在云存儲節(jié)點失效，為了修復1個分片A的數(shù)據(jù)，云端需要下載總數(shù)據(jù)量為1 MB的2個分片，即分片B和A+B，來完成修復工作。這些數(shù)據(jù)傳輸操作將會帶來較大的傳輸開銷，降低云際存儲系統(tǒng)的可靠性。

針對云際存儲系統(tǒng)數(shù)據(jù)修復過程傳輸開銷較大的問題[7]，不同的研究者提出了許多減少云際存儲系統(tǒng)數(shù)據(jù)修復操作數(shù)據(jù)傳輸量的方案。例如，通過在云際存儲系統(tǒng)中部署再生碼來減少修復過程消耗的網(wǎng)絡帶寬[3]。圖5[3]展示了基于再生碼的云際存儲數(shù)據(jù)的修復過程的例子：

Figure 5 Regeneration code based data recovery process圖5 基于再生碼的云際存儲修復方案

在圖5中，一個大小為1 MB的對象分成了4個分片A、B、C和D。其中，每一個分片為0.25 MB。通過隨機線性編碼，云際存儲系統(tǒng)將這些分片生成編碼分片P1、P2、P3、P4、P5、P6、P7和P8。每一個編碼分片為0.25 MB。當前在恢復數(shù)據(jù)的過程中，代理服務器僅僅需要從幸存的每一個云節(jié)點下載一個大小為0.25 MB的編碼分片，生成新的編碼分片P′1和P′2，并將這些分片存儲到新生節(jié)點。在這個過程中，網(wǎng)絡的數(shù)據(jù)傳輸總量為0.25*3=0.75 MB。

在這個例子中，相較于傳統(tǒng)糾刪碼數(shù)據(jù)修復方案，基于再生碼[20]的數(shù)據(jù)修復方案將修復過程需要傳輸?shù)臄?shù)據(jù)量從1 MB減少到0.75 MB。通過減少數(shù)據(jù)修復過程傳輸?shù)臄?shù)據(jù)量，云際存儲系統(tǒng)可以有效地減少修復過程中網(wǎng)絡數(shù)據(jù)傳輸操作所需要的時間，從而提升云際存儲數(shù)據(jù)的可靠性。

3.3 網(wǎng)絡傳輸優(yōu)化方案

由于云際存儲系統(tǒng)需要通過互聯(lián)網(wǎng)將用戶數(shù)據(jù)上傳到云端，用戶端設備與云端之間帶寬通常十分有限。此外，云端修復數(shù)據(jù)的過程中云存儲節(jié)點之間也需要傳輸數(shù)據(jù)，如何減少數(shù)據(jù)傳輸操作帶來的時延成為了提升云際存儲系統(tǒng)性能的關鍵性問題。

首先，研究人員[3,18,21,22]嘗試構建編碼來減少云際存儲系統(tǒng)需要完成數(shù)據(jù)讀寫和修復操作需要傳輸?shù)臄?shù)據(jù)量。通過部署再生碼，Chen等人[3]設計了NCCloud(Network-Coding-based storage system in a Cloud of Clouds)來減少修復操作網(wǎng)絡需要傳輸?shù)臄?shù)據(jù)量。通過在移動云際存儲系統(tǒng)中部署網(wǎng)絡編碼方案，Shen等人[17]設計了NCCSCLOUD(Network Coding based Cloud of clouds Storage CLOUD)來減少用戶端設備的計算與數(shù)據(jù)傳輸開銷，從而提升數(shù)據(jù)分發(fā)效率。Cui 等人[21]提出了QuickSync在移動場景下加速同步用戶端設備和云端的數(shù)據(jù)同步性能。Tang等人[22]通過合理存儲UniDrive來減少用戶在云際存儲數(shù)據(jù)讀取過程中的時延。通過部署非系統(tǒng)碼HCE-PPC，Shen等人[12]設計云際存儲系統(tǒng)CloudS(multi-Cloud Storage system with multi-level security)提升數(shù)據(jù)編碼效率。

其次，為了更好地適應網(wǎng)絡狀態(tài)的變化，云際存儲系統(tǒng)需要根據(jù)當前的網(wǎng)絡狀態(tài)調整數(shù)據(jù)傳輸策略。Li等人[23,24]通過根據(jù)網(wǎng)絡拓撲選擇和并行化數(shù)據(jù)修復過程提出了基于樹形的和基于流水線的數(shù)據(jù)修復方案。通過根據(jù)異構網(wǎng)絡帶寬確定數(shù)據(jù)傳輸量，Wang等人[25]提出了彈性樹形修復拓撲構建檔案FTR(Flexible Tree-structured Regeneration)來保證修復后數(shù)據(jù)的完整性,并進一步縮短修復過程的時間。Shen等人[26]提出數(shù)據(jù)修復方案OMFR(Optimal Multiple Failures Repair),以根據(jù)當前的網(wǎng)絡帶寬決定修復操作開始的時間，從而減少修復操作需要傳輸?shù)臄?shù)據(jù)量和消耗的時間。

由于數(shù)據(jù)讀寫操作和數(shù)據(jù)修復操作是云際存儲系統(tǒng)中引起數(shù)據(jù)傳輸操作的主要原因，當前云際存儲系統(tǒng)性能優(yōu)化方案主要圍繞減少這2種類型的操作的網(wǎng)絡開銷展開研究工作。表3展示了當前云際存儲傳輸優(yōu)化方案針對的操作類型，其中PTR代表基于流水線的修復方案。

Table 3 Optimization schemes for cloud-of-clouds storage system表3 云際存儲系統(tǒng)傳輸優(yōu)化方案

如表3所示，當前云際存儲系統(tǒng)數(shù)據(jù)傳輸優(yōu)化方案通常僅針對存儲或修復中的一種操作。因此，若有機地結合2種不同的數(shù)據(jù)傳輸優(yōu)化方案，可以進一步優(yōu)化云際存儲系統(tǒng)數(shù)據(jù)傳輸效率。

4 云際存儲資源管理方案

為了高效地管理云際存儲的資源，云際存儲系統(tǒng)提出了很多資源管理方案。由于云際存儲系統(tǒng)主要包括用戶端設備資源和云端資源，云際存儲系統(tǒng)需要合理管理這些資源來完成讀寫和修復操作。

4.1 用戶端設備資源管理

云際存儲系統(tǒng)需要合理地管理用戶端設備資源來完成數(shù)據(jù)讀寫操作。在云際存儲系統(tǒng)中，用戶端設備通常需要使用以下資源：

(1)計算資源。為了保證數(shù)據(jù)的安全性和可靠性，用戶端設備需要進行加密操作和編碼操作，從而產(chǎn)生了用戶端設備的計算開銷[17]。然而，用戶端移動設備的計算資源通常比較有限，如移動存儲應用場景下，這些加密和編碼操作帶來的計算開銷將導致較大的數(shù)據(jù)計算時延，且降低了云際存儲系統(tǒng)的存儲性能。

(2)傳輸資源。云際存儲系統(tǒng)需要通過互聯(lián)網(wǎng)來傳輸用戶端設備與云端的數(shù)據(jù)，而互聯(lián)網(wǎng)上可用帶寬十分有限，并且波動性較大[24]。因此，云際存儲系統(tǒng)數(shù)據(jù)讀寫性能提升的關鍵在于減少用戶端設備與云端之間傳輸?shù)臄?shù)據(jù)量。

由于用戶端設備計算和網(wǎng)絡資源有限，云際存儲系統(tǒng)需要根據(jù)應用場景合理地分配用戶端設備的資源，從而完成相應用戶數(shù)據(jù)讀寫操作。構建高效的機制來有效地管理用戶端設備資源成為了保證云際存儲系統(tǒng)性能的關鍵性問題。

4.2 云端資源管理

為了在云端可靠地保存用戶數(shù)據(jù)，云存儲節(jié)點需要在數(shù)據(jù)失效時完成存儲數(shù)據(jù)修復操作，為了修復這些失效的數(shù)據(jù)，云端需要管理以下資源：

(1)計算資源。在數(shù)據(jù)修復過程中，云端需要編碼現(xiàn)存的數(shù)據(jù)來生成失效云節(jié)點，以保證存儲數(shù)據(jù)的可靠性。為了完成數(shù)據(jù)的編碼操作，云端需要有效地管理云節(jié)點的計算資源。

(2)存儲資源。為了保證數(shù)據(jù)的可靠性，云節(jié)點在存儲用戶數(shù)據(jù)之外還需要保存冗余數(shù)據(jù)。因此，云際存儲系統(tǒng)需要在保證用戶數(shù)據(jù)可靠性的前提下合理地管理存儲空間，從而減小存儲開銷。

(3)傳輸資源。當出現(xiàn)云節(jié)點故障時，云際存儲系統(tǒng)需要根據(jù)現(xiàn)存數(shù)據(jù)恢復出已失效的數(shù)據(jù)，在這個修復過程中，云節(jié)點之間需要傳輸大量的數(shù)據(jù)。此外，為了減少用戶端設備上傳到云端的數(shù)據(jù)量，云際存儲方案需要將用戶端設備的計算和傳輸開銷遷移到云端[17]。合理地管理云端網(wǎng)絡傳輸資源將有效地保證存儲數(shù)據(jù)可靠性和數(shù)據(jù)讀寫的性能。

為了快速地完成加解密、編解碼和傳輸操作，云際存儲系統(tǒng)需要高效地管理用戶端設備和云端資源。下面，本文將綜述云際存儲系統(tǒng)的資源管理方案并分析這些方案適用的場景。

4.3 云際存儲資源管理方案

為了高效地管理云際存儲系統(tǒng)的計算、存儲和網(wǎng)絡資源，研究人員主要從存儲數(shù)據(jù)可靠性和訪問性能2方面提出了各種資源管理及優(yōu)化方案。

首先，為了保證存儲數(shù)據(jù)的可靠性，云際存儲平臺需要根據(jù)應用場景的需求選擇適當?shù)馁Y源管理策略。Pereira等人[27]設計了Storekeeper方案，并構建了安全可靠的數(shù)據(jù)分享機制和管理平臺來整合各云服務提供商的存儲資源。Zhao等人[28]設計了中間件SafeSky，從而實現(xiàn)了云際存儲系統(tǒng)中對用戶文件存儲的操作請求進行重定位操作。Ma等人[29]使用緩存副本的方式提出了CAROM(Cache A Replica On Modification)來提升用戶數(shù)據(jù)訪問性能和云際存儲系統(tǒng)可靠性。

其次，為了快速完成用戶端讀寫操作，研究人員分析了云際存儲系統(tǒng)應用場景的特點并提出了相應的優(yōu)化方案。Chung等人[30]提出了CYRUS(Client-defined privacY-protected Reliable cloUd Service)來優(yōu)化在多用戶情況下的并行數(shù)據(jù)訪問能力。Shen等人[31]提出了基于流水線的數(shù)據(jù)存儲方案，以充分利用計算和傳輸資源來并行化加密、編碼和傳輸操作，加速數(shù)據(jù)存儲過程。通過將糾刪碼與副本存儲方案相結合，Wu等人[32]提出了DAC(Deduplication_Assisted primary storage system in Cloud-of-clouds)方案來增加數(shù)據(jù)去冗余度，從而提升高存儲頻率用戶數(shù)據(jù)的數(shù)據(jù)訪問性能。通過使用糾刪碼與副本來存儲不同大小的文件，Mao等人[14]設計了HyRD來減少云際存儲系統(tǒng)的存儲開銷和訪問時延。Bernstein等人[33]設計了簡單副本管理協(xié)議SSRP(Simple Storage Replication Protocol)來管理云際存儲空間。表4展示了云際存儲系統(tǒng)中主要資源管理方案,其中Pipeline代表基于流水線的數(shù)據(jù)存儲方案。

Table 4 Resource management schemes forcloud-of-clouds storage system表4 云際存儲系統(tǒng)資源管理方案

如表4所示，當前的資源管理方案通常僅優(yōu)化針對系統(tǒng)可靠性和性能中的一項。因此，云際存儲系統(tǒng)資源管理方案如何在不同應用場景下兼顧數(shù)據(jù)可靠性和讀寫性能依然是一個值得研究的問題。

5 云際存儲應用場景

由于云際存儲具有高可靠性、高安全性的特點，云際存儲方案被廣泛應用到了數(shù)據(jù)備份、移動存儲應用和云際計算等諸多場景。

5.1 數(shù)據(jù)備份場景

當存儲的數(shù)據(jù)出現(xiàn)失效時，用戶端設備需要從其它存儲系統(tǒng)中獲取備份數(shù)據(jù)來保證用戶數(shù)據(jù)的可靠性。通過將數(shù)據(jù)加密和編碼后分發(fā)到不同的云，云際存儲提供了安全且可靠的數(shù)據(jù)存儲服務。因此，云際存儲廣泛地應用到了數(shù)據(jù)備份場景。

圖6[21]展示了云際備份存儲場景。

Figure 6 Backup paradigm for cloud-of-clouds storage system圖6 云際備份存儲場景

通過使用數(shù)據(jù)同步算法[21]，用戶端設備可以將本地數(shù)據(jù)與云際存儲系統(tǒng)的數(shù)據(jù)進行同步操作。當前用戶端設備出現(xiàn)數(shù)據(jù)失效時，用戶端設備可以下載備份在云端的數(shù)據(jù)，從而恢復出本地失效的數(shù)據(jù)。在這個過程中，云際存儲系統(tǒng)需要保證存儲在云端數(shù)據(jù)的安全性和可靠性。

雖然備份存儲系統(tǒng)可以安全可靠地存儲用戶數(shù)據(jù)，云際存儲系統(tǒng)部署到其他的應用場景依然面對諸多挑戰(zhàn)。首先，為了保證在線應用的用戶體驗，云際存儲系統(tǒng)需要根據(jù)應用場景來提升讀寫操作的性能。其次，由于不同的應用場景往往有著不同數(shù)據(jù)存儲需求，云際存儲系統(tǒng)需要有針對性地優(yōu)化相應的數(shù)據(jù)讀寫和修復方案。下面，本文將分析2種經(jīng)典的云際存儲應用場景，即移動應用場景和云際計算場景，并總結不同的云際存儲系統(tǒng)的應用場景和這些系統(tǒng)包含的主要功能及實現(xiàn)機制。

5.2 移動應用場景

在移動云際存儲系統(tǒng)中，用戶端設備相較于云端的計算和傳輸資源通常較為有限，并且用戶端設備需要通過無線網(wǎng)絡(如WiFi[34]、LTE[35]和5G NR[36])和互聯(lián)網(wǎng)來傳輸數(shù)據(jù)。因此，相較于云端虛擬機，移動設備需要更長的時間來完成數(shù)據(jù)加密、編碼和傳輸操作。

根據(jù)移動應用場景下用戶端設備和云端設備的特點，云際存儲系統(tǒng)需要調整數(shù)據(jù)分發(fā)方案來優(yōu)化數(shù)據(jù)讀寫操作的性能?；诰W(wǎng)絡編碼的數(shù)據(jù)分發(fā)方案通過使用網(wǎng)絡編碼存儲的例子來說明如何在實際的云際存儲系統(tǒng)中減少用戶端上傳到云端的數(shù)據(jù)量。

假設移動云際存儲系統(tǒng)中有4個不同的云和1個用戶端設備。用戶希望寫入1個M字節(jié)大小的機密消息。為了存儲k個分片加密后的M/k字節(jié)消息，當前分發(fā)方案需要用戶編碼并將分片上傳到所有的云。圖7[17]展示了云際存儲系統(tǒng)中數(shù)據(jù)分發(fā)過程。

Figure 7 Traditional and the dispersal scheme based on network code圖7 傳統(tǒng)分發(fā)方案和基于網(wǎng)絡編碼的分發(fā)方案

圖7a展示了傳統(tǒng)基于糾刪碼的數(shù)據(jù)分發(fā)方案。在存儲的過程中，用戶設備將加密消息分成2個數(shù)據(jù)分片A和B，編碼后生成校驗分片A+B和A+2B，并且最后上傳到云端。為了存儲M字節(jié)機密消息,用戶端設備編碼M字節(jié)數(shù)據(jù)并發(fā)送了2M字節(jié)數(shù)據(jù)。由于移動設備通常計算和傳輸資源有限，這些操作將會嚴重影響分發(fā)操作的性能。

為了減少用戶端設備數(shù)據(jù)計算和傳輸開銷，云際存儲系統(tǒng)可以通過部署網(wǎng)絡編碼將這些開銷遷移到云端系統(tǒng)。基于網(wǎng)絡編碼的數(shù)據(jù)分發(fā)方案將4個云分成2個初始云和2個后繼云。圖7b展示了基于網(wǎng)絡編碼的數(shù)據(jù)分發(fā)方案執(zhí)行過程，首先，用戶設備生成2個數(shù)據(jù)分片A和B，并且上傳這些分片到初始云。其次，初始云將分片A和B分成數(shù)據(jù)包A1、A2、B1和B2。其中，每一個包大小為M/4字節(jié)。然后，初始云將數(shù)據(jù)包A1、B1、A2和B2傳輸?shù)胶罄^云。最后，后繼云編碼生成數(shù)據(jù)包A1+B1、A1+2B1、A2+B2和A2+2B2，并交換數(shù)據(jù)包A1+2B1和A2+B2來生成校驗分片A+B和A+2B。

相較于基于糾刪碼的數(shù)據(jù)分發(fā)方案，用戶端移動設備需要編碼M字節(jié)并傳輸2M字節(jié)數(shù)據(jù)，通過部署網(wǎng)絡編碼方案，用戶端移動設備在無需編碼操作的前提下，只需要上傳M字節(jié)數(shù)據(jù)。

通過上述例子可知，通過將編碼計算和網(wǎng)絡傳輸負載遷移到云端，基于網(wǎng)絡編碼的數(shù)據(jù)分發(fā)方案可以有效地減少用戶端設備上傳到云端的數(shù)據(jù)量，從而有效地提升移動設備的存儲操作性能。與此同時，除了存儲操作外，云際存儲依然存在數(shù)據(jù)更新時延較長等問題。因此，如何優(yōu)化其他操作依然是提升移動云際存儲性能的重點問題。

5.3 云際計算場景

通過合理地協(xié)調各個用戶占用云端的各類資源，云際計算平臺[37]提供了高效的服務平臺來完成用戶端設備提交的各種計算和存儲任務。圖8展示了云際計算系統(tǒng)的體系結構[37]。

Figure 8 Architecture of cloud-of-clouds computing 圖8 云際計算系統(tǒng)架構

為了有效地利用云端資源和管理用戶端設備，云際計算系統(tǒng)通過云際服務仲裁系統(tǒng)整合了云端資源，并將用戶進行分組管理。為了保證數(shù)據(jù)可靠性，云際計算系統(tǒng)需要在云端存儲多個副本并要求對應的云際存儲系統(tǒng)保證這些副本的一致性。這將引入較大的數(shù)據(jù)讀寫時延，并嚴重降低系統(tǒng)性能。

為了給云際計算提供高可用的存儲服務，云際存儲系統(tǒng)需要在保證數(shù)據(jù)一致性的前提下，降低數(shù)據(jù)存儲的時延。針對這一問題，研究人員提出了許多高效的副本數(shù)據(jù)讀寫策略。例如，DepSky[5]通過加入元數(shù)據(jù)來實現(xiàn)云端副本的弱一致性。

圖9[5]展示了DepSky的數(shù)據(jù)存儲和讀取過程：

Figure 9 Data storage and read process of DepSky圖9 DepSky的數(shù)據(jù)存儲和讀取過程

不同于經(jīng)典的一致性協(xié)議(如，拜占庭仲裁)[38]，Depsky使用元數(shù)據(jù)來確定當前最新版本的副本。為了保證寫入數(shù)據(jù)的完整性，計算節(jié)點會先在云端存儲副本數(shù)據(jù)，然后將帶有版本信息的元數(shù)據(jù)上傳到云端。在數(shù)據(jù)讀取過程中，計算節(jié)點首先從云端下載元數(shù)據(jù)來確定云端副本的版本，從而保證在此之后計算節(jié)點可以獲取最新版本的副本數(shù)據(jù)。

綜上所述，由于相較于直接讀取副本數(shù)據(jù)僅需要多下載副本元數(shù)據(jù)，這種方案可以以較小的代價保證寫入和讀取數(shù)據(jù)的一致性。由于云際計算系統(tǒng)需要對存儲數(shù)據(jù)復制多個副本，這些副本的存儲往往會占用較大的存儲空間。如何在保證數(shù)據(jù)一致性和訪問性能的前提下，部署存儲空間利用率高的存儲方案(如糾刪碼存儲)依然是一個值得研究的問題。

5.4 面臨的挑戰(zhàn)及解決方案

雖然當前有很多數(shù)據(jù)分發(fā)方案，但如何部署這些存儲機制到實際的在線應用中依然是一個具有挑戰(zhàn)性的問題。研究人員開發(fā)了許多云際存儲系統(tǒng)來滿足各種應用場景的數(shù)據(jù)存儲需求。

首先，為了安全且可靠地存儲用戶數(shù)據(jù)，云際存儲系統(tǒng)使用了不同的安全和可靠性方案。通過設計仲裁機制，Bessani等人[5]提出了DepSky系統(tǒng)，解決了云端存儲副本數(shù)據(jù)的一致性問題。Bessani等人[39]設計了SCFS(Shared Cloud-backed File Systems)，通過設計一致性將文件分發(fā)到多個云的元數(shù)據(jù)和數(shù)據(jù)來提升數(shù)據(jù)分享的效率。Lacoste等人[40]構建了Supercloud平臺，從而提升了云際計算操作的安全性和可靠性。通過應用冗余磁盤陣列編碼技術(RAID)，Abu-Libdeh等人[2]設計了RACS(Redundant Array of Cloud Storage)來提升云際存儲系統(tǒng)的可靠性和數(shù)據(jù)存儲效率。通過將元數(shù)據(jù)和數(shù)據(jù)分別保存在私有云和公有云，Dobre等人[41]設計了Hybris來提升云際存儲系統(tǒng)的安全性。通過在用戶端設備加入遠端認證服務，Matos等人[42]構建了RockFS(RecOverable Cloud-backed File-System)系統(tǒng)來同時兼顧用戶端設備及云端存儲數(shù)據(jù)的可靠性。

除此以外，為了提升云際存儲系統(tǒng)操作的執(zhí)行效率，研究人員在不同應用場景下優(yōu)化了云際存儲系統(tǒng)性能。通過在多個云存儲提供商存儲用戶數(shù)據(jù)的副本，Wu等人[43]設計了Spanstore系統(tǒng)，從而提升云際文件存儲系統(tǒng)的可靠性和訪問性能。通過將CAONT-RS和CRSSS部署到云端，Li等人[44]設計了CDStore(Store via Convergent Dispersal)來提升云際存儲系統(tǒng)的存儲空間利用率。Mu等人[45]提出了μlibcloud作為中間件來統(tǒng)一管理云際存儲的訪問請求，從而提升云際存儲系統(tǒng)的可用性。Verissimo等人[37]構建了Tcloud平臺來處理云際計算任務。Burihabwa等人[46]總結了云際存儲系統(tǒng)的數(shù)據(jù)加密算法和可靠性機制，并測量了加密和傳輸操作的執(zhí)行效率，以對比存儲系統(tǒng)性能。表5展示了當前云際存儲系統(tǒng)及其應用場景。

通過分析表5可以發(fā)現(xiàn)，當前的云際存儲系統(tǒng)的應用場景主要集中在存儲備份。由于云際存儲系統(tǒng)在數(shù)據(jù)讀寫過程中需要一系列的計算、傳輸和存儲操作，其數(shù)據(jù)讀寫時延依然是制約其上運行的應用性能的瓶頸。如何進一步將云際存儲系統(tǒng)部署到不同的在線應用中依然是一個值得研究的問題。

Table 5 Cloud-of-clouds storage system and their application scenarios表5 云際存儲系統(tǒng)及其主要應用場景

6 結束語

云際存儲系統(tǒng)作為一種高效的云存儲資源管理方案被廣泛地應用于當前的在線存儲系統(tǒng)。本文綜述了當前云際存儲系統(tǒng)的相關工作，包括數(shù)據(jù)分發(fā)方案、網(wǎng)絡傳輸方案、云際存儲系統(tǒng)資源管理機制及其主要的應用場景。在此基礎上，本文總結了當前云際存儲系統(tǒng)適用的應用場景和相應的存儲系統(tǒng)性能優(yōu)化方案，并在此基礎上分析了當前網(wǎng)絡傳輸機制和資源管理方案對于云際存儲系統(tǒng)性能的影響。

雖然當前的云際存儲系統(tǒng)可以安全可靠地存儲用戶數(shù)據(jù)，實際系統(tǒng)運行過程中依然存在諸多性能瓶頸，例如網(wǎng)絡帶寬嚴重限制了云際存儲系統(tǒng)的廣泛應用。為了克服這些性能瓶頸，云際存儲系統(tǒng)需要使用新的網(wǎng)絡傳輸和存儲方案。例如，為了減少用戶端設備的網(wǎng)絡傳輸時延，云際存儲系統(tǒng)可以將數(shù)據(jù)緩存在邊緣節(jié)點，從而加快讀寫操作。此外，云際存儲系統(tǒng)也需要針對新出現(xiàn)的應用場景，如區(qū)塊鏈及內容分發(fā)系統(tǒng)，提出相應的優(yōu)化方案。