基于FTP協(xié)議的數(shù)據(jù)服務(wù)解決方案①

李 云,張海明

1(中國科學(xué)院 計算機網(wǎng)絡(luò)信息中心,北京 100190)

2(中國科學(xué)院大學(xué),北京 100049)

1 概述

隨著大數(shù)據(jù)時代的到來,分布式文件系統(tǒng)因其良好的拓展性、支持大規(guī)模存儲而備受關(guān)注.很多優(yōu)秀的分布式文件系統(tǒng)也隨之出現(xiàn),例如谷歌的GFS[1]、Facebook 優(yōu)化過的HDFS[2]、阿里的TFS[3]以及開源社區(qū)的明星項目CephFS[4]、GlusterFS[5].這些分布式文件系統(tǒng)在實際使用過程中在拓展性、存儲規(guī)模方面都表現(xiàn)得十分出色.但是,在面向用戶提供數(shù)據(jù)服務(wù)時相比于普通的文件系統(tǒng)缺少了靈活性,普通的文件系統(tǒng)可以通過直接搭建FTP 服務(wù)來為用戶提供數(shù)據(jù)服務(wù),方便用戶上傳下載數(shù)據(jù),而分布式文件系統(tǒng)由于其自身的局限性,無法直接提供類似的服務(wù).因此,就分布式文件系統(tǒng)如何面向用戶提供高效的數(shù)據(jù)服務(wù),本文提出基于FTP 協(xié)議的解決方案——SPDScheme.

分布式文件系統(tǒng)向外提供數(shù)據(jù)服務(wù)接口,但是這些接口對于用戶并不友好.需要由研發(fā)人員將這些接口進行封裝,使之成為方便用戶使用的方式.在工業(yè)領(lǐng)域,目前常用的方案是將分布式文件系統(tǒng)掛載到普通文件系統(tǒng)上,通過在普通文件系統(tǒng)搭建FTP 服務(wù)端來向外提供服務(wù),這種方案的優(yōu)勢在于快速搭建,但是劣勢也十分明顯,無法對分布式文件系統(tǒng)的特點以及用戶服務(wù)做出有針對性的調(diào)整.SPDScheme 主要設(shè)計了一個基于FTP 協(xié)議的獨立服務(wù)SPDServer,作用于用戶和分布式文件系統(tǒng)之間,根據(jù)分布式文件系統(tǒng)的高IO、高吞吐量等特點進行優(yōu)化,同時根據(jù)一些用戶需求進行針對性的調(diào)整.另外通過使用一些開源技術(shù)保證服務(wù)的高可用、高并發(fā)以及可拓展性.因此,本文提出的SPDScheme 具有如下幾方面的技術(shù)優(yōu)勢.

1)利用生成器、協(xié)程、多線程、緩沖區(qū)等技術(shù),針對分布式文件系統(tǒng)的特性設(shè)計優(yōu)化數(shù)據(jù)傳輸?shù)哪Ｐ秃退惴?極大的提高了數(shù)據(jù)服務(wù)的傳輸效率.

2)SPDServer 獨立于分布式文件系統(tǒng),與分布式文件系統(tǒng)耦合程度很低,服務(wù)掛掉不會對分布式文件系統(tǒng)產(chǎn)生任何的影響.由于利用Keepalived[6]和LVS[7]實現(xiàn)高可用,一臺機器的服務(wù)出現(xiàn)問題,也不會對用戶服務(wù)產(chǎn)生任何影響.

3)利用LVS 對請求做負載均衡,實現(xiàn)用戶請求的高并發(fā),同時也使服務(wù)具備了非常好的拓展性,可以隨著用戶請求的增加,相應(yīng)的增加服務(wù)節(jié)點,提高服務(wù)的響應(yīng)速度以及傳輸速度.

4)FTP 協(xié)議的認證方式是在服務(wù)啟動時將明文密碼配置到服務(wù)中,使用過程非常不靈活,而本文提出的SPDServer 通過連接MySQL 數(shù)據(jù)庫,將用戶登錄信息和權(quán)限信息保存到數(shù)據(jù)庫中,實現(xiàn)動態(tài)認證.同時利用編碼探測技術(shù),分析請求中內(nèi)容的編碼格式,做到多種編碼格式的兼容,以及針對用戶體驗做出的其它一些調(diào)整,對用戶十分友好.

2 SPDScheme 總體架構(gòu)

SPDScheme 是一個面向用戶,針對分布式文件系統(tǒng)的數(shù)據(jù)服務(wù)解決方案,整體為C/S 架構(gòu),其中核心服務(wù)SPDServer 作用于用戶和分布式文件系統(tǒng)之間,是一個相對獨立的服務(wù),旨在為用戶提供簡單、方便、快捷、安全的數(shù)據(jù)服務(wù),主要由用戶認證、文件操作、模式選擇、編碼兼容和日志收集等模塊構(gòu)成；另外通過Keepalived+LVS 實現(xiàn)服務(wù)的高可用和高并發(fā).方案架構(gòu)如圖1所示.

圖1 方案總體架構(gòu)

2.1 SPDServer 底層框架

FTP 協(xié)議建立在客戶端-服務(wù)器端模型體系結(jié)構(gòu)之上[8],在客戶端和服務(wù)器端之間使用單獨的控制和數(shù)據(jù)連接.使用FTP 協(xié)議進行數(shù)據(jù)傳輸,需要有FTP 客戶端軟件和FTP 服務(wù)端的軟件配合使用.優(yōu)秀的客戶端軟件有很多,例如Flashfxp[9]、Filezilla[10]、Xftp[11]等,用戶可以選擇其中任意一款作為客戶端使用.FTP 服務(wù)端工具同樣層出不窮,例如Vsftpd[12]、Pyftpdlib[13]、Proftpd[14]、Twisted[15]等,這些服務(wù)端軟件都有著非常好的性能表現(xiàn),但是不能直接使用在分布式文件系統(tǒng)上,原因在于這些服務(wù)端軟件都只能對接操作系統(tǒng)下的文件系統(tǒng).若要使得FTP 服務(wù)端能夠?qū)拥椒植际轿募到y(tǒng),可以在現(xiàn)有的服務(wù)端軟件之上進行傳輸算法、傳輸模型以及部分功能的重構(gòu),會減少大量沒有必要的重復(fù)研發(fā),因此SPDServer 底層框架的選擇非常關(guān)鍵.通過對幾款常用服務(wù)端軟件測試對比如圖2.

圖2 多種FTP 軟件性能比較

從測試數(shù)據(jù)中可以清楚地了解到,Pyftpdlib 在上傳、下載速度以及多客戶端的連接和斷開所用時間上都表現(xiàn)十分優(yōu)異,因此選取Pyftpdlib 軟件作為SPDServer 的底層框架.

2.2 高可用、高并發(fā)方案設(shè)計

SPDScheme 使用Keepalived 實現(xiàn)服務(wù)的高可用,使用LVS 進行負載均衡,實現(xiàn)服務(wù)的高并發(fā),并保證服務(wù)可以橫向拓展,在用戶請求增加時,可以通過增加服務(wù)節(jié)點的數(shù)量來增大并發(fā)量.Keepalived 的優(yōu)勢在于通過簡單的配置就可以實現(xiàn)高可用,使用靈活.LVS 的優(yōu)勢在于極強的負載均衡性能,只分發(fā)請求,不會有流量經(jīng)過的特點,保證了均衡器的IO 性能不會受到大規(guī)模流量的影響.同時由于其工作在網(wǎng)絡(luò)的傳輸層,上層應(yīng)用協(xié)議支持廣泛,FTP 協(xié)議可以很好的在LVS 上層工作.

3 SPDServer 詳細設(shè)計

在Pyftpdlib 底層框架的基礎(chǔ)上,SPDServer 利用緩沖區(qū)[16]、生成器[17]、協(xié)程[18]、多線程[19]等技術(shù),針對分布式文件系統(tǒng)的特點進行了數(shù)據(jù)傳輸算法和傳輸模型的優(yōu)化.在用戶認證、文件操作、模式選擇、編碼兼容和日志收集方面設(shè)計了全新的管理策略.

3.1 傳輸算法、傳輸模型的優(yōu)化

對于評價數(shù)據(jù)服務(wù)的性能,上傳文件和下載文件速度是一項重要指標(biāo).上傳文件時數(shù)據(jù)流的傳輸過程是客戶端將文件分片發(fā)送到SPDServer,SPDserver 收到分片的數(shù)據(jù)再發(fā)送到分布式文件系統(tǒng),下載文件的過程與之相反.但是這個過程中,存在著容易被忽視的問題,客戶端的讀寫能力和吞吐量相比于分布式文件系統(tǒng)要小的多,如果SPDServer 只是簡單的接收數(shù)據(jù)片再發(fā)送到分布式文件系統(tǒng),就會導(dǎo)致部分資源閑置以及沒有必要的網(wǎng)絡(luò)開銷.而SPDServer 能夠進行高速的數(shù)據(jù)傳輸,原因在于使用基于生成器的協(xié)議技術(shù)、緩沖區(qū)技術(shù)以及多線程技術(shù)用來解決上述存在的問題.同時,整個數(shù)據(jù)流的傳輸過程,可以抽象成為生產(chǎn)者-消費者模型,可以把SPDServer 抽象成為中間存放商品的倉庫,使用生產(chǎn)者-消費者模型的思想對其進行優(yōu)化.

利用生成器特性加快傳輸速度.利用生成器,本質(zhì)是一種協(xié)程的思想.若不使用生成器,由于文件數(shù)據(jù)是分片讀取或者寫入,每次讀取或者寫入都要讀取該文件對應(yīng)的元數(shù)據(jù)信息,但多次查詢元數(shù)據(jù)信息,極大的耗費了傳輸時間.利用生成器,就可以保存查詢到的元數(shù)據(jù)在生成器上下文當(dāng)中,在上傳文件時,通過文件操作可以返回一個生成器句柄,每次向生成器寫入數(shù)據(jù)即可；在下載文件時,同樣返回一個生成器句柄,每次從生成器讀出數(shù)據(jù)即可.

SPDServer 使用生成器避免了大量的元數(shù)據(jù)查詢,在處理每個上傳下載任務(wù)后可以快速恢復(fù)到服務(wù)主程序,極大地提高了傳輸速度.具體算法步驟如算法1.

算法1.基于協(xié)程思想的上傳算法1.Def Generator：2.Metadata ← getMetadata()3.While DATA_PIECE：4.DATA_PIECE ← yield 5.Write(Metadata,DATAPIECE)6.Def Upload：7.Generator ← getGenerator()8.While GET_DATA_PIECE()：// 接收數(shù)據(jù)片9.Generator.send(DATA_PIECE)10.Generator.close()

在協(xié)程思想的基礎(chǔ)上利用緩沖區(qū)加快傳輸速度.文件是分片進行傳輸?shù)?每一片的大小會有一個具體的值.在上傳文件時,如果數(shù)據(jù)片的大小被設(shè)置的很小,數(shù)據(jù)就會被分為更多的片,在向存儲后端發(fā)送數(shù)據(jù)時,每次寫入都會有時間開銷,次數(shù)越多,耗費的時間也會越多.如果數(shù)據(jù)片的大小被設(shè)置的很大,單次寫入的數(shù)據(jù)越大,一個數(shù)據(jù)片耗費的時間也會越多,次數(shù)雖然變小了,但是總的時間開銷依然很大.于是數(shù)據(jù)片過大和過小都會造成時間上不必要的耗費,因此這里需要一個經(jīng)驗值讓傳輸速度達到最佳狀態(tài),SPDServer 采用這樣的設(shè)計：在內(nèi)存中開辟一片緩沖區(qū),按數(shù)據(jù)片的順序暫存在緩沖區(qū),當(dāng)緩沖區(qū)中數(shù)據(jù)的大小等于這個經(jīng)驗值時,就可以將緩沖區(qū)中的內(nèi)容一起通過生成器發(fā)送到分布式文件系統(tǒng)中.

以字符串拼接的方案作為對比,可以更好地理解緩沖區(qū)的作用.對分片的數(shù)據(jù)進行拼接,需要多次的賦值操作,本質(zhì)是對內(nèi)存的反復(fù)申請釋放,產(chǎn)生大量的時間開銷.而對于緩沖區(qū)來說,只需要每次按順序?qū)?shù)據(jù)片放入緩沖區(qū),這樣可以極大地節(jié)省反復(fù)申請內(nèi)存的時間.具體算法步驟如算法2.

算法2.基于緩沖區(qū)的上傳算法1.Def createBuffer：2.Buffer ← SYSTEM_CALL()3.return Buffer 4.Def Upload：5.Generator ← getGenerator()6.Buffer ← createBuffer()7.While GET_DATA_PIECE()：// 接收數(shù)據(jù)片8.if sizeof(Buffer)＜BUFFER_SIZE：9.Write(Buffer,DATA_PIECE)10.else：11.Generator.send(Buffer)12.Empty(Buffer)

13.Generator.send(Buffer)14.Generator.close()15.Buffer.close()?

在協(xié)程和緩沖區(qū)技術(shù)的基礎(chǔ)上,再使用多線程技術(shù)加速傳輸效率.多線程和多進程是指對任務(wù)進行異步處理,可以加快任務(wù)的處理效率.任務(wù)從使用資源情況看可以分為兩種,一種是I/O 密集型任務(wù),即占用大量的I/O 資源,另一種是計算密集型任務(wù),即占用大量的CPU 資源.多進程的優(yōu)點在于每個進程相互獨立,但是占用內(nèi)存多,創(chuàng)建、銷毀、切換進程效率低,比較適合大量計算的計算密集型任務(wù),不用多次切換或創(chuàng)建銷毀.而多線程占用內(nèi)存少,切換簡單.適合需要快速切換、創(chuàng)建銷毀的I/O 密集型任務(wù),對于基于FTP協(xié)議的數(shù)據(jù)服務(wù)來說,并沒有復(fù)雜的計算過程,有的只是密集的請求和讀寫過程,是I/O 密集型任務(wù).于是SPDServer 采用多線程的方式處理各種客戶端請求.

多線程的使用,相比于單個線程的處理能力,性能提升明顯；相比于多進程,在提高對客戶端請求的處理能力的同時,沒有增加更多的時間開銷和內(nèi)存開銷,進一步提高了數(shù)據(jù)服務(wù)服務(wù)的響應(yīng)速度.具體算法步驟如算法3.

算法3.基于多線程的上傳算法1.Def Work(Generator,Buffer)：2.Generator.send(Buffer)3.return ok 4.Def Upload：5.Ex ← ThreadingPool(size)6.Generator ← getGenerator()7.Buffer ← createBuffer()8.While GET_DATA_PIECE()：// 接收數(shù)據(jù)片9.if sizeof(Buffer)＜BUFFER_SIZE：10.Write(Buffer,DATA_PIECE)11.else：12.Ex.submit(Work,Generator,Buffer)13.Empty(Buffer)14.Ex.submit(Work,Generator,Buffer)15.WAIT_COMPLETED(Ex)16.Generator.close()17.Buffer.close()18.Ex.close()

3.2 認證與用戶管理

Pyftpdlib 原本的認證模塊是在啟動服務(wù)時,傳入用戶名、口令以及對應(yīng)的操作權(quán)限,在用戶登錄時進行對比認證,但是服務(wù)一旦啟動,這些信息無法被修改,若要修改認證信息,必須重啟服務(wù)[20].由于面向用戶服務(wù)時,用戶端登錄信息以及權(quán)限信息是動態(tài)變化的,無法將所有用戶的數(shù)據(jù)在FTP 服務(wù)啟動時讀入.線上的數(shù)據(jù)服務(wù),也不可能經(jīng)常性的重新啟動.因此,登錄過程需要重新設(shè)計為動態(tài)認證,即拿到用戶的登錄數(shù)據(jù)后需要和一個可以動態(tài)更新的用戶數(shù)據(jù)表進行比對認證.

SPDServer 使用MySQL 數(shù)據(jù)庫存儲用戶信息,同時基于該數(shù)據(jù)庫向用戶提供Web 服務(wù),用戶通過Web端可以在任意時間修改數(shù)據(jù)庫中的信息,SPDServer 每次處理認證請求時都會檢查該數(shù)據(jù)庫中的認證和權(quán)限信息,實現(xiàn)動態(tài)認證的效果.另外,數(shù)據(jù)庫中指定了用戶的訪問路徑,做到用戶與用戶之間隔離,底層存儲互不影響.為了區(qū)分用戶的讀寫權(quán)限,SPDServer 采用一個用戶名對應(yīng)兩個口令的方式,兩個口令分別對應(yīng)只讀權(quán)限和讀寫權(quán)限.在認證通過之后返回權(quán)限信息,用于檢查用戶的每個請求是否有足夠的權(quán)限,并予以正確響應(yīng).

3.3 文件操作管理

Pyftpdlib 原本的文件操作模塊包括各種文件系統(tǒng)操作函數(shù),這些函數(shù)需要全部對接到分布式文件系統(tǒng),才能夠進行文件傳輸,SPDServer 對這些文件操作進行了功能的重構(gòu),最核心的部分如表1.

表1 功能重構(gòu)的文件操作函數(shù)

3.4 模式管理

FTP 協(xié)議中的服務(wù)模式分為主動模式和被動模式,主動和被動都是針對服務(wù)端而言,FTP 協(xié)議在進行數(shù)據(jù)傳輸時,客戶端和服務(wù)端會建立兩個連接,一個是控制連接,另一個是數(shù)據(jù)連接[21].無論是主動模式還是被動模式,服務(wù)端建立控制連接所用的都是21 端口,但是在建立數(shù)據(jù)連接時,服務(wù)端會根據(jù)請求模式的不同,采取不同的連接方式.主動模式下,服務(wù)端使用20 端口主動連接客戶端的高端端口,但是客戶端多為內(nèi)網(wǎng)用戶,在防火墻之后,防火墻會屏蔽掉服務(wù)器發(fā)過來的主動連接請求.被動模式下,服務(wù)端會隨機打開一個高端端口,被動等待客戶端發(fā)過來的連接請求,但是FTP服務(wù)需要開放到公網(wǎng),服務(wù)器的端口為了避免受到攻擊不能任意開放.兩種連接方式都有著不能忽略的弊端,SPDServer 采用了折中的辦法,即指定被動模式下用于建立連接的高端端口區(qū)間.固定的區(qū)間,降低了受到攻擊的風(fēng)險,也避免了一部分客戶端在防火墻之后不能建立連接,保證了數(shù)據(jù)服務(wù)的穩(wěn)定.

3.5 編碼管理

Windows 系統(tǒng)默認編碼為GBK,而Pyftpdlib 底層框架默認編碼為UTF8,Windows 用戶在訪問服務(wù)時,客戶端發(fā)送請求為GBK 編碼格式,而服務(wù)端處理請求時,會使用默認的UTF8 編碼格式進行解碼,兩者屬于完全不同的編碼類型,于是產(chǎn)生了亂碼問題.如果只是將SPDServer 的默認編碼修改為GBK 編碼,那么當(dāng)Linux 系統(tǒng)上的客戶端訪問時,同樣會出現(xiàn)亂碼問題,因為Linux 默認編碼是UTF8.因此,選取一種編碼格式作為默認編碼,并不能夠解決多平臺兼容問題.SPDServer提出通過智能檢測技術(shù)來處理編碼問題的方法.

Chardet[22]是一個非常優(yōu)秀的字符編碼識別方法庫,SPDServer 使用Chardet 工具對接收到的請求編碼進行智能判斷,準(zhǔn)確地獲取接收到請求的編碼類型,有針對性的對接收到的請求進行解碼.同時,在響應(yīng)該請求時也使用相同的編碼對客戶端進行反饋.因此,SPDServer 可以處理任意編碼的請求,有著十分強大的編碼兼容能力,能夠避免使用不同操作系統(tǒng)導(dǎo)致的編碼問題.

3.6 日志策略

日志是服務(wù)運行時不可缺少的部分,好的日志策略可以保證系統(tǒng)的平穩(wěn)運行,在出現(xiàn)問題時,迅速準(zhǔn)確地定位到系統(tǒng)問題所在[23].SPDServer 擁有單獨的日志管理模塊,該管理模塊支持兩種輸出,一種是標(biāo)準(zhǔn)輸出到屏幕,另外一種是輸出到文本；線下測試使用輸出到屏幕,方便研發(fā)調(diào)試,線上運行環(huán)境輸出到文本,方便大量存儲、記錄用戶的行為并追蹤定位問題.另外,線上環(huán)境的日志輸出到文本,以文本的大小為單位,當(dāng)文本的大小達到設(shè)定值時,文本自動分割打包,新產(chǎn)生的日志繼續(xù)寫入到空的文本中.當(dāng)文本的大小又達到設(shè)定值時,繼續(xù)自動分割打包,依次類推.這樣可以留存長時間的日志記錄,避免了日志寫入單一文件,導(dǎo)致文件過大不好處理,又可以保證日志的時限.

4 SPDScheme 實際運行效果

一個方案的實際運行效果,必須在實際項目中使用,這樣才能夠全面、準(zhǔn)確的了解.中國科技云iHarbor存儲系統(tǒng)是一個帶有文件目錄樹的分布式對象存儲系統(tǒng),本質(zhì)上可以作為一個分布式文件系統(tǒng)使用.iHarbor使用了本文提出的方案SPDScheme.本文對iHarbor存儲系統(tǒng)的數(shù)據(jù)服務(wù)進行了兼容性測試、性能測試、穩(wěn)定性測試以及并發(fā)拓展測試.測試結(jié)果表明,單個數(shù)據(jù)傳輸連接可以達到200 MB/s 的傳輸速度,在兼容性、穩(wěn)定性、可拓展性等方面,均表現(xiàn)優(yōu)秀.具體測試數(shù)據(jù)過程詳見下文.

4.1 實驗環(huán)境

測試所用的客戶端與iHarbor 數(shù)據(jù)服務(wù)在同一網(wǎng)段內(nèi),均為萬兆光纖網(wǎng)絡(luò),可以避免網(wǎng)絡(luò)帶寬不足造成的瓶頸,并測試出數(shù)據(jù)服務(wù)實際性能的上限.存儲設(shè)備方面,客戶端和iHarbor 底層存儲均使用普通機械硬盤.另外,在性能測試環(huán)節(jié),SPDServer 部署在單個節(jié)點上,測試數(shù)據(jù)基于單個SPDServer.測試使用的SPDServer配置均為8 核CPU,8 GB 內(nèi)存.在LVS 支持的范圍內(nèi),每增加一個新的SPDServer 節(jié)點,就會增加和測試SPDServer 節(jié)點同樣的處理能力,損耗可忽略不計.

4.2 兼容性測試

表2是FTP 客戶端兼容性測試結(jié)果,測試方法是在不同的操作系統(tǒng)平臺上,使用多種不同的客戶端工具,訪問中國科技云iHarbor 存儲系統(tǒng)數(shù)據(jù)服務(wù),查看服務(wù)是否可以正常響應(yīng).測試使用的客戶端幾乎包含了各大平臺當(dāng)前常用的客戶端工具.測試結(jié)果表明數(shù)據(jù)服務(wù)在客戶端的兼容性方面考慮地比較全面,可以支持主流的FTP 客戶端工具.

表2 FTP 客戶端兼容性測試

4.3 性能與穩(wěn)定性測試

性能與穩(wěn)定性的測試用例主要考慮到客戶端個數(shù)、文件個數(shù)、單個文件大小等因素.

測試在不同并發(fā)客戶端數(shù)下,一小時可以上傳或者下載的小文件數(shù)量,用于測試的小文件的大小都在幾個字節(jié)左右.客戶端的數(shù)量從1 個到50 個.測得的結(jié)果如圖3,橫坐標(biāo)表示并發(fā)客戶端數(shù),縱坐標(biāo)表示用時1 分鐘可以上傳或者下載的小文件數(shù)目.

圖3 測試小文件上傳下載情況

數(shù)據(jù)統(tǒng)計了多個客戶端傳輸過程中的文件累計傳輸數(shù)量.可以看到,隨著客戶端并發(fā)數(shù)的增大,并沒有過多的影響到數(shù)據(jù)服務(wù)的性能.同時,沒有出現(xiàn)明顯的波動情況,驗證了數(shù)據(jù)服務(wù)的穩(wěn)定性.在單客戶端下,可以在1 分鐘內(nèi)上傳600 個以上的小文件；在50 個客戶端同時上傳的情況下,也能達到將近6000 個小文件,效率很高.

測試在不同并發(fā)客戶端數(shù)下,上傳或者下載單個10 GB大文件用時.測試結(jié)果如圖4,橫坐標(biāo)表示并發(fā)客戶端數(shù),縱坐標(biāo)表示上傳或者下載單個10 GB 大文件的用時.

數(shù)據(jù)統(tǒng)計了在多個客戶端傳輸大文件過程中的最長用時,最短用時,平均用時.可以看到,隨著客戶端的增多,數(shù)據(jù)服務(wù)的效率稍有下降,但是總的來看服務(wù)依舊是高效、穩(wěn)定的.

4.4 高可用與并發(fā)量測試

對iHarbor 數(shù)據(jù)服務(wù)的高可用和并發(fā)測試情況如下.在服務(wù)運行時,人為停掉一個LVS 節(jié)點和一個SPDServer 服務(wù),數(shù)據(jù)服務(wù)不受任何影響.

用并發(fā)測試軟件JMeter 對啟動單個SPDServer 的數(shù)據(jù)服務(wù)進行并發(fā)測試.在1 s 內(nèi)并發(fā)下載100 KB 的文件,可以保證420 個連接的高效服務(wù),吞吐率保持在36 req/s.受硬件資源限制,本次實驗測試的最大規(guī)模為10 個節(jié)點.并且在LVS 支持的范圍內(nèi),每增加一個新的SPDServer 節(jié)點,就會增加和測試SPDServer 節(jié)點相同的處理能力,損耗可忽略不計,可以通過增加節(jié)點的方法,增大并發(fā)量.

圖4 測試大文件上傳下載情況

5 結(jié)束語

隨著存儲技術(shù)的不斷發(fā)展,越來越多的應(yīng)用需要建立在方便、快捷的數(shù)據(jù)服務(wù)之上.同時,越來越多的需求也在被用戶提出來,這些需求對存儲環(huán)境的拓展性、易用性和可靠性提出了更高要求.本文提出的解決方案經(jīng)過運行在真實系統(tǒng)上,有效性、可靠性、高效性得到驗證,能夠為用戶提供優(yōu)質(zhì)的數(shù)據(jù)服務(wù).

接下來將繼續(xù)研究數(shù)據(jù)傳輸模型以及算法中的瓶頸,以及SPDServer 中各個模塊的解耦,如何根據(jù)用戶需求在拓展功能時更加的方便靈活.同時希望本文提出的解決方案SPDScheme 可以應(yīng)用到更多的存儲系統(tǒng)架構(gòu)中.