邵珠興，陳 彩

（北京工業(yè)大學(xué) 計(jì)算機(jī)學(xué)院，北京100124）

0 引 言

目前面對(duì)海量數(shù)據(jù)的存儲(chǔ)需求，傳統(tǒng)的數(shù)據(jù)存儲(chǔ)方案在存儲(chǔ)容量、數(shù)據(jù)的可靠性、存儲(chǔ)成本等方向存在很大的不足。云存儲(chǔ)［1，2］具有自身獨(dú)特的優(yōu)勢，可以動(dòng)態(tài)、靈活地進(jìn)行擴(kuò)展和配置，使用戶可以通過網(wǎng)絡(luò)按需獲得云存儲(chǔ)的軟硬件資源。OpenStack［3，4］是一個(gè)開源的云計(jì)算平臺(tái)，它的對(duì)象存儲(chǔ)服務(wù)Swift［5］可以用來構(gòu)建冗余的、可擴(kuò)展的分布式對(duì)象存儲(chǔ)集群，存儲(chǔ)容量可達(dá)PB 級(jí)，結(jié)合OpenStack的身份認(rèn)證服務(wù)Keystone［6］，可以提供安全可靠的云存儲(chǔ)服務(wù)。對(duì)象存儲(chǔ)服務(wù)Swift仍存在某些不足，Swift不能存儲(chǔ)任意大小的文件，已有的解決方案為服務(wù)器端的解決方案，靈活性和擴(kuò)展性較差。

本方案充分利用了對(duì)象存儲(chǔ)服務(wù)Swift的優(yōu)異特性，為了解決大文件存儲(chǔ)的不足之處，設(shè)計(jì)并實(shí)現(xiàn)了GB 級(jí)大文件的存儲(chǔ)方案。本文設(shè)計(jì)了云存儲(chǔ)系統(tǒng)的層次架構(gòu)，制定了大文件的存儲(chǔ)策略，設(shè)計(jì)了上傳和下載的核心流程，并用Java語言實(shí)現(xiàn)了本方案，最后通過實(shí)驗(yàn)驗(yàn)證了其可行性。本文所述方案為客戶端解決方案，便于用戶調(diào)用，易于擴(kuò)展，突破了Swift對(duì)文件大小的限制，大大提高了文件的上傳和下載速度。

1 OpenStack開源云平臺(tái)

OpenStack是一個(gè)開源的云計(jì)算平臺(tái)，通過多個(gè)相互聯(lián)系的服務(wù)提供基礎(chǔ)設(shè)施即服務(wù) （infrastructure as a service，IaaS）類型的解決方案。各個(gè)服務(wù)之間通過各自的REST風(fēng)格的API相互聯(lián)系。根據(jù)用戶的需求，可以安裝Open－Stack的部分或全部服務(wù)，建立公有或私有云存儲(chǔ)服務(wù)［7］。OpenStack主要包含以下幾個(gè)服務(wù)：計(jì)算服務(wù) （項(xiàng)目名稱為Nova）、對(duì)象存儲(chǔ)服務(wù) （項(xiàng)目名稱為Swift）、鏡像服務(wù) （項(xiàng)目名稱為Glance）、身份認(rèn)證服務(wù) （項(xiàng)目名稱為Keystone）、網(wǎng)絡(luò)服務(wù)和塊存儲(chǔ)服務(wù)［8］。

Swift是OpenStack開源云計(jì)算項(xiàng)目的子項(xiàng)目之一，提供了強(qiáng)大的擴(kuò)展性、冗余性和持久性。Swift是一個(gè)對(duì)象存儲(chǔ)系統(tǒng)，所有數(shù)據(jù)以 “對(duì)象”的形式組織。本文中，客戶端磁盤上的數(shù)據(jù)實(shí)體稱為 “文件”，云存儲(chǔ)端的數(shù)據(jù)實(shí)體稱為 “對(duì)象”。Swift主要有3 個(gè)組成部分：Proxy Server、Storage Server和Consistency Server。Proxy server 是服務(wù)的入口，負(fù)責(zé)將Swift架構(gòu)整合起來。Consistency Server負(fù)責(zé)查找并解決由數(shù)據(jù)損壞和硬件故障引起的錯(cuò)誤。Storage Server提供了磁盤設(shè)備上的存儲(chǔ)服務(wù)。Swift中的數(shù)據(jù)分三級(jí)來組織：賬戶 （account）、容器 （container）和對(duì)象（object）［9］，一個(gè)賬戶包含多個(gè)容器，一個(gè)容器包含多個(gè)對(duì)象。Swift規(guī)定云存儲(chǔ)端的一個(gè)對(duì)象的大小不能超過5GB。Swift已有的大文件解決方案：靜態(tài)大對(duì)象 （static large objects）存儲(chǔ)方案和動(dòng)態(tài)大對(duì)象 （dynamic large objects）存儲(chǔ)方案［10］，都是Swift服務(wù)端的存儲(chǔ)方案，在靈活性、擴(kuò)展性等方面存在一定的不足。

Keystone主要包含兩個(gè)功能：管理用戶以及用戶的權(quán)限，提供服務(wù)的目錄和它們的API?？梢酝ㄟ^Keystone和Swift之間的相互協(xié)作，完成用戶信息的認(rèn)證和授權(quán)，以及每次請(qǐng)求的權(quán)限驗(yàn)證。

本文主要關(guān)注GB級(jí)大文件的存儲(chǔ)，應(yīng)用Swift提供的基本對(duì)象存儲(chǔ)服務(wù)，在客戶端解決大于5GB文件的存儲(chǔ)問題。

2 大文件存儲(chǔ)方案

2.1 云存儲(chǔ)的架構(gòu)設(shè)計(jì)

為了安全、快速的存儲(chǔ)GB 級(jí)大文件，本文將云存儲(chǔ)的架構(gòu)和內(nèi)部模塊做如下分層設(shè)計(jì)，如圖1所示。云存儲(chǔ)系統(tǒng)主要分兩部分：服務(wù)器端和客戶端，服務(wù)器端由原生的對(duì)象存儲(chǔ)服務(wù)Swift和身份認(rèn)證服務(wù)Keystone構(gòu)成，所有的存儲(chǔ)方案在客戶端實(shí)現(xiàn)。整體結(jié)構(gòu)主要分如下四層：

表示層，與用戶交互，可以配置用戶的認(rèn)證信息、線程池的數(shù)量等等，為用戶提供上傳文件和下載文件的同步和異步接口。

邏輯層，為用戶提供邏輯和控制功能，包括存儲(chǔ)策略、用戶的認(rèn)證和授權(quán)、復(fù)雜任務(wù)的工作流、任務(wù)的調(diào)度、日志記錄等，存儲(chǔ)策略是本文的重點(diǎn)研究的內(nèi)容。

服務(wù)層，為上層提供對(duì)象存儲(chǔ)服務(wù)和身份認(rèn)證服務(wù)。最下層為資源層，包括磁盤、網(wǎng)絡(luò)交換機(jī)、路由器，還是其它的一些資源。

2.2 大文件存儲(chǔ)策略

簡單來說，存儲(chǔ)策略是：上傳一個(gè)大文件時(shí)，把一個(gè)大文件拆分為一系列小文件，分別上傳到云存儲(chǔ)端。下載時(shí)，再把這些小文件合并為一個(gè)大文件。在云存儲(chǔ)端，用兩種類型的對(duì)象來代替一個(gè)大的對(duì)象：

圖1 云存儲(chǔ)層次架構(gòu)

（1）片段對(duì)象 （segment object）：把一個(gè)大文件拆分成小的片段，分別作為一個(gè)單獨(dú)的對(duì)象上傳這些片段，這些對(duì)象稱為片段對(duì)象。

（2）清單對(duì)象 （manifest object）：清單對(duì)象的功能是記錄構(gòu)成一個(gè)大文件的所有片段對(duì)象的信息，包括片段對(duì)象所在的容器名稱 （container name）、片段對(duì)象的名字（segment object name）、片 段 對(duì) 象 在 大 文 件 中 的 偏 移 量（offset）、片段對(duì)象的二進(jìn)制數(shù)據(jù)長度 （segment length）。根據(jù)這些信息，可以把一個(gè)大文件拆分為一組片段，并且可以把一組片段重新合成為原文件。

也就是說，一個(gè)大文件在云存儲(chǔ)端由唯一的清單對(duì)象和一組片段對(duì)象構(gòu)成。片段對(duì)象與一般的對(duì)象沒有任何區(qū)別，但是清單對(duì)象很特別，它代表了磁盤中的大文件，當(dāng)下載清單對(duì)象時(shí)，需要把所有的片段對(duì)象連接成一個(gè)整體返回給用戶；當(dāng)查詢清單對(duì)象的信息時(shí)，清單對(duì)象的元數(shù)據(jù)代表了大文件的相關(guān)屬性。為了便于組織信息，把所有的片段對(duì)象信息序列化為JSON 格式的字符串，作為清單對(duì)象的內(nèi)容。所以清單對(duì)象的內(nèi)容就是JSON 格式的所有片段對(duì)象信息的列表。根據(jù)容器名稱和片段對(duì)象的名稱，可以定位云存儲(chǔ)端片段對(duì)象的位置，根據(jù)偏移量和片段大小，可以定位片段對(duì)象在原文件中的位置，所以JSON 格式的片段信息列表中，片段信息不需要按照它們?cè)谠募械捻樞蚺帕?。例如，一個(gè)視頻文件為graduate.mp4，其大小為5400 M，假設(shè)以片段大小150 M 拆分此文件，則其清單對(duì)象的內(nèi)容為：

文件往往有一些屬性需要存儲(chǔ)在云存儲(chǔ)端，由于清單對(duì)象與原文件是一一對(duì)應(yīng)關(guān)系，因此可以用清單對(duì)象的元數(shù)據(jù)代表原文件的元數(shù)據(jù)，即原文件的相關(guān)屬性。為了便于進(jìn)行文件的校驗(yàn)和下載，清單對(duì)象必須具備以下兩個(gè)自定義元數(shù)據(jù)：

（1）X－Object－Meta－Etag，原 始 文 件 的MD5 校 驗(yàn) 值，用于下載文件后對(duì)下載文件進(jìn)行MD5校驗(yàn)；

（2）X－Object－Meta－Length，原始文件的總長度。

對(duì)象存儲(chǔ)服務(wù)Swift定義了對(duì)象的很多固有元數(shù)據(jù)，所有對(duì)象，包括片段對(duì)象和清單對(duì)象，必須具備以下兩個(gè)元數(shù)據(jù)：

（1）Content－Type，清單對(duì)象的內(nèi)容類型為JSON 格式，所以其值為application／json；一般對(duì)象包括片段對(duì)象的值為application／octet－stream。

（2）Etag，作為整體上傳的一般對(duì)象的Etag值為整個(gè)文件的MD5 校驗(yàn)值，片段對(duì)象的Etag 值為文件片段的MD5校驗(yàn)值，清單對(duì)象的Etag值為JSON 字符串的MD5校驗(yàn)值。上傳文件時(shí)，在Http Header 中添加Etag 值，Swift會(huì)在上傳結(jié)束后對(duì)比服務(wù)器端的對(duì)象的MD5 值與Etag值，以確保傳輸前后數(shù)據(jù)的一致性。

2.3 核心流程設(shè)計(jì)

為了在上傳、下載過程中，保證數(shù)據(jù)在客戶端、服務(wù)器端的一致性，上傳、下載、查詢必須按照一定的流程，遵循一致的協(xié)議。上傳文件時(shí)，需要先根據(jù)文件的大小確定是否需要分割上傳，如果需要分割，將文件轉(zhuǎn)換為一組片段對(duì)象和一個(gè)清單對(duì)象，其核心流程如圖2所示。為了確保數(shù)據(jù)在客戶端和云存儲(chǔ)端是一致的，上傳整個(gè)文件、上傳文件片段和上傳清單對(duì)象時(shí)，都要計(jì)算數(shù)據(jù)的MD5校驗(yàn)值，在上傳HTTP 請(qǐng)求的Header中加入Etag 鍵值對(duì)，Swift會(huì)根據(jù)Etag值完成數(shù)據(jù)的一致性校驗(yàn)。在上傳清單對(duì)象時(shí)，除了計(jì)算其JSON 字符串的MD5校驗(yàn)值，還需要計(jì)算整個(gè)大文件的MD5校驗(yàn)值，作為X－Object－Meta－Etag鍵值對(duì)加入Http Header中。

下載文件的核心流程與上傳文件的流程相對(duì)應(yīng)。云存儲(chǔ)中的清單對(duì)象代表了一個(gè)大文件，其記錄了組成大文件的片段對(duì)象的相關(guān)信息，云存儲(chǔ)中的一般對(duì)象可能代表了一個(gè)沒有分割上傳的文件，也可能代表了一個(gè)大文件的一個(gè)片段。所以，對(duì)于待下載的云端對(duì)象，必須先驗(yàn)證此對(duì)象是清單對(duì)象還是一般對(duì)象，然后再分別做不同的處理，其流程如圖3所示。圖中的兩種下載方式的最后都需要比較下載后的文件的MD5 校驗(yàn)值和原文件的MD5 校驗(yàn)值，以確保文件的一致性。如果文件對(duì)應(yīng)一個(gè)對(duì)象，則文件的MD5校驗(yàn)值為對(duì)象的Etag值，如果文件對(duì)應(yīng)一個(gè)清單對(duì)象和一組片段對(duì)象，則文件的MD5 校驗(yàn)值為清單對(duì)象的XObject－Meta－Etag值。

圖2 上傳流程

圖3 下載流程

2.4 關(guān)鍵模塊設(shè)計(jì)與實(shí)現(xiàn)

當(dāng)用戶調(diào)用云存儲(chǔ)客戶端的上傳命令時(shí)，會(huì)把上傳任務(wù)轉(zhuǎn)交給UploadHandler，UploadHandler主要有4個(gè)方法：預(yù)處理任務(wù)、處理上傳任務(wù)、處理后續(xù)任務(wù)、處理程序異常。預(yù)處理任務(wù)主要進(jìn)行文件分段、計(jì)算各個(gè)片段的MD5值；上傳任務(wù)包括上傳一般的對(duì)象 （包括上傳片段對(duì)象）和上傳清單對(duì)象。預(yù)處理任務(wù)和上傳任務(wù)涉及到讀取硬盤、網(wǎng)絡(luò)通信，可能會(huì)導(dǎo)致程序阻塞，因此執(zhí)行預(yù)處理任務(wù)和上傳任務(wù)時(shí)，為了提高處理速度，UploadHandler會(huì)把任務(wù)交給線程池來執(zhí)行。片段對(duì)象和清單對(duì)象可以按照任意順序上傳，所以上傳任務(wù)非常適合由多線程來執(zhí)行。詳細(xì)的上傳過程如圖4所示。

圖4 上傳文件時(shí)序

下載文件功能由DownloadHandler 實(shí)現(xiàn)，DownloadHandler和UploadHandler實(shí)現(xiàn)了相同的接口，它們具有同樣的4個(gè)方法：預(yù)處理任務(wù)、處理任務(wù)、處理后續(xù)任務(wù)、處理程序異常。預(yù)處理任務(wù)、下載文件、文件的MD5校驗(yàn)這3個(gè)過程涉及網(wǎng)絡(luò)通信和硬盤訪問，為了提高執(zhí)行速度，這3個(gè)任務(wù)會(huì)交給線程池來執(zhí)行。其主要原理與上傳相對(duì)應(yīng)，細(xì)節(jié)不再詳述。下載過程中，所有的片段對(duì)象都下載完畢，并 “合并”成一個(gè)大文件后才能進(jìn)行MD5校驗(yàn)，因此需要保證下載片段文件和MD5 校驗(yàn)先后次序正確。片段對(duì)象合并成原文件的操作，是在下載的過程中直接進(jìn)行 “合并”，通過RandomAccessFile，直接依照片段對(duì)象的偏移量寫入到原文件的指定位置，當(dāng)所有的片段文件都下載完畢，原文件就完整的下載到了磁盤上了。

3 驗(yàn)證與分析

3.1 實(shí)驗(yàn)環(huán)境部署

在實(shí)驗(yàn)環(huán)境中，選用了5臺(tái)服務(wù)器搭建云存儲(chǔ)系統(tǒng)：1臺(tái)服務(wù)器作為認(rèn)證節(jié)點(diǎn)，用于運(yùn)行keystone服務(wù)；1 臺(tái)服務(wù)器作為代理節(jié)點(diǎn)，用于運(yùn)行Proxy service；其余3臺(tái)服務(wù)器作為存儲(chǔ)節(jié)點(diǎn)，用于運(yùn)行Account service、Container service和Object service［11］。在真實(shí)運(yùn)行環(huán)境中，可以添加存儲(chǔ)節(jié)點(diǎn)以增加存儲(chǔ)容量，可以添加代理節(jié)點(diǎn)以分散用戶的請(qǐng)求。本實(shí)驗(yàn)環(huán)境可以模擬真實(shí)的運(yùn)行環(huán)境，因此實(shí)驗(yàn)結(jié)果有意義。圖5所示為實(shí)驗(yàn)環(huán)境中的云存儲(chǔ)部署結(jié)構(gòu)。

3.2 實(shí)驗(yàn)結(jié)構(gòu)及分析

測試本方案的可行性。測試文件大小為5598 M，已經(jīng)超過了對(duì)象存儲(chǔ)服務(wù)Swift最高存儲(chǔ)5GB的限制。作為一個(gè)整體直接上傳該文件，HTTP 請(qǐng)求返回的狀態(tài)碼為413，返回的錯(cuò)誤提示為：Request Entity Too Large，The body of your request was too large for this server。說明直接上傳一個(gè)超過5GB 的大文件是不成功的。用本方案上傳該文件，云存儲(chǔ)客戶端按照預(yù)先設(shè)定的片段大小分割文件，將一組片段對(duì)象和一個(gè)清單對(duì)象上傳到云存儲(chǔ)端，并通過片段對(duì)象和清單對(duì)象的MD5校驗(yàn)確定了云存儲(chǔ)端和客戶端是一致。接著，用本方案下載該文件，云存儲(chǔ)客戶端會(huì)根據(jù)清單對(duì)象，把組成此文件的所有片段下載到客戶端并合并成一個(gè)文件，通過驗(yàn)證下載的文件的MD5值確定了此文件與上傳前的文件是一致的。因此，證明了本方案是可行的，上傳和下載過程中都能保證客戶端和云存儲(chǔ)端數(shù)據(jù)的一致性，解決了Swift中對(duì)象不能超過5G 的限制。

圖5 云存儲(chǔ)系統(tǒng)部署

測試文件的上傳時(shí)間。上傳GB 級(jí)文件時(shí)，本文用了兩種方式上傳并作了對(duì)比，一種方式是本文所述方案，即大文件分割上傳；第二種是原始的上傳方式，即大文件作為一個(gè)整體上傳，但這種方式只能用于上傳小于5G 的文件。這兩種方式上傳同一個(gè)文件的時(shí)間對(duì)比如圖6 所示。可以看到對(duì)于同樣大小的文件，分割上傳比整體上傳節(jié)省時(shí)間。設(shè)節(jié)省時(shí)間比＝ （整體上傳的時(shí)間－分割上傳的時(shí)間）／整體上傳的時(shí)間，則平均節(jié)省時(shí)間百分比為10.17。

圖6 上傳文件時(shí)間折線

測試文件的下載時(shí)間。在下載實(shí)驗(yàn)之前，將GB 級(jí)大文件用上文所述的兩種方式上傳到云存儲(chǔ)中，所以同一個(gè)文件，一是作為一個(gè)整體存儲(chǔ)在云存儲(chǔ)服務(wù)中，二是文件作為片段存儲(chǔ)在云存儲(chǔ)服務(wù)。然后下載兩種形式的對(duì)象，下載所需要的時(shí)間對(duì)比如圖7所示。從圖中可以看出，下載片段形式的對(duì)象比下載整體形式的對(duì)象更節(jié)省時(shí)間，其平均節(jié)省時(shí)間百分比為34.12。

圖7 下載文件時(shí)間折線

4 結(jié)束語

開源云平臺(tái)OpenStack的對(duì)象存儲(chǔ)服務(wù)Swift具有強(qiáng)大的擴(kuò)展性、冗余性和持久性等特點(diǎn)，同時(shí)在大文件存儲(chǔ)方面也有其不足之處。本文為解決GB 級(jí)大文件存儲(chǔ)問題，設(shè)計(jì)了云存儲(chǔ)系統(tǒng)的層次架構(gòu)，制定了大文件的上傳和下載策略，設(shè)計(jì)了上傳和下載的核心流程，并用Java語言實(shí)現(xiàn)了本方案。本方案不同于Swift的靜態(tài)大對(duì)象存儲(chǔ)方案和動(dòng)態(tài)大對(duì)象存儲(chǔ)方案，是一個(gè)客戶端的大文件存儲(chǔ)方案，易于調(diào)用，便于擴(kuò)展。通過實(shí)驗(yàn)結(jié)果表明了本方案是可行的，成功的存儲(chǔ)了大于5GB的文件，并且提高了的GB級(jí)大文件的上傳速度和下載速度。

［1］ZENG Wenying，ZHAO Yuelong，SHANG Min.Research on cloud computing and cloud storage ecosystem ［J］.Journal of Computer Research and Development，2011 （S1）：234－239（in Chinese）.［曾文英，趙躍龍，尚敏.云計(jì)算及云存儲(chǔ)生態(tài)系統(tǒng)研究 ［J］.計(jì)算機(jī)研究與發(fā)展，2011 （S1）：234－239］.

［2］Grossman R L，Gu Y H，Sabala M，et al.Compute and storage clouds using wide area high performance networks ［J］.Future Generation Computer Systems－the International Journal of Grid Computing Theory Methods and Applications，2009，25 （2）：179－183.

［3］Wen Xiaolong，Gu Genqiang，Li Qingchun，et al.Comparison of open－source cloud management platforms：OpenStack and OpenNebula［C］／／9th International Conference on Fuzzy Systems and Knowledge Discovery，2012：2457－2461.

［4］Von Laszewski Gregor，Diaz Javier，Wang Fugang，et al.Comparison of multiple cloud frameworks［C］／／IEEE 5th International Conference on Cloud Computing，2012：734－741.

［5］Swift 1.12.0.113.g076634edocumentation［EB／OL］.［2014－02－20］.http：／／docs.openstack.org／developer／swift／.

［6］Keystone 2014.1.dev449.ge2ce639documentation ［EB／OL］.［2014－02－20］.http：／／docs.openstack.org／developer／keystone／.

［7］Toor Salman，Toebbicke Rainer，Resines Maitane Zotes，et al.Investigating an open source cloud storage infrastructure for CERN－Specific data analysis ［C］／／IEEE 7th International Confe－rence on Networking，Architecture and Storage，2012：84－88.

［8］Bonner S，Pulley C，Kureshi I，et al.Using OpenStack to improve student experience in an H.E.environment ［C］／／Science and Information Conference，2013：888－893.

［9］JIANG Yi，SUN Xuetao，YANG Chuan.Swift cloud storage environment based on I／O load balanced reading strategies［J］.Computer Engineering and Design，2013，34 （9）：3024－3027（in Chinese）.［蔣溢，孫雪濤，楊川.Swift云存儲(chǔ)環(huán)境下基于I／O 負(fù)載均衡的讀取策略 ［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2013，34 （9）：3024－3027.］

［10］OpenStack object storage API v1reference－API v1 ［EB／OL］.［2014－02－20］.http：／／docs.openstack.org／api／openstack－object－storage／1.0／content／.

［11］OpenStack Installation guide for Ubuntu 12.04（LTS）－h(huán)avana［EB／OL］. ［2014－02－20］.http：／／docs.openstack.org／havana／install－guide／install／apt／content／.