李 云,張海明

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

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

1 概述

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

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

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

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

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

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

2 SPDScheme 總體架構(gòu)

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

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

2.1 SPDServer 底層框架

FTP 協(xié)議建立在客戶端-服務(wù)器端模型體系結(jié)構(gòu)之上[8],在客戶端和服務(wù)器端之間使用單獨(dú)的控制和數(shù)據(jù)連接.使用FTP 協(xié)議進(jìn)行數(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ù)端軟件都只能對(duì)接操作系統(tǒng)下的文件系統(tǒng).若要使得FTP 服務(wù)端能夠?qū)拥椒植际轿募到y(tǒng),可以在現(xiàn)有的服務(wù)端軟件之上進(jìn)行傳輸算法、傳輸模型以及部分功能的重構(gòu),會(huì)減少大量沒(méi)有必要的重復(fù)研發(fā),因此SPDServer 底層框架的選擇非常關(guān)鍵.通過(guò)對(duì)幾款常用服務(wù)端軟件測(cè)試對(duì)比如圖2.

圖2 多種FTP 軟件性能比較

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

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

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

3 SPDServer 詳細(xì)設(shè)計(jì)

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

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

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

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

SPDServer 使用生成器避免了大量的元數(shù)據(jù)查詢(xún),在處理每個(gè)上傳下載任務(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ū)加快傳輸速度.文件是分片進(jìn)行傳輸?shù)?每一片的大小會(huì)有一個(gè)具體的值.在上傳文件時(shí),如果數(shù)據(jù)片的大小被設(shè)置的很小,數(shù)據(jù)就會(huì)被分為更多的片,在向存儲(chǔ)后端發(fā)送數(shù)據(jù)時(shí),每次寫(xiě)入都會(huì)有時(shí)間開(kāi)銷(xiāo),次數(shù)越多,耗費(fèi)的時(shí)間也會(huì)越多.如果數(shù)據(jù)片的大小被設(shè)置的很大,單次寫(xiě)入的數(shù)據(jù)越大,一個(gè)數(shù)據(jù)片耗費(fèi)的時(shí)間也會(huì)越多,次數(shù)雖然變小了,但是總的時(shí)間開(kāi)銷(xiāo)依然很大.于是數(shù)據(jù)片過(guò)大和過(guò)小都會(huì)造成時(shí)間上不必要的耗費(fèi),因此這里需要一個(gè)經(jīng)驗(yàn)值讓傳輸速度達(dá)到最佳狀態(tài),SPDServer 采用這樣的設(shè)計(jì)：在內(nèi)存中開(kāi)辟一片緩沖區(qū),按數(shù)據(jù)片的順序暫存在緩沖區(qū),當(dāng)緩沖區(qū)中數(shù)據(jù)的大小等于這個(gè)經(jīng)驗(yàn)值時(shí),就可以將緩沖區(qū)中的內(nèi)容一起通過(guò)生成器發(fā)送到分布式文件系統(tǒng)中.

以字符串拼接的方案作為對(duì)比,可以更好地理解緩沖區(qū)的作用.對(duì)分片的數(shù)據(jù)進(jìn)行拼接,需要多次的賦值操作,本質(zhì)是對(duì)內(nèi)存的反復(fù)申請(qǐng)釋放,產(chǎn)生大量的時(shí)間開(kāi)銷(xiāo).而對(duì)于緩沖區(qū)來(lái)說(shuō),只需要每次按順序?qū)?shù)據(jù)片放入緩沖區(qū),這樣可以極大地節(jié)省反復(fù)申請(qǐng)內(nèi)存的時(shí)間.具體算法步驟如算法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ù)加速傳輸效率.多線程和多進(jìn)程是指對(duì)任務(wù)進(jìn)行異步處理,可以加快任務(wù)的處理效率.任務(wù)從使用資源情況看可以分為兩種,一種是I/O 密集型任務(wù),即占用大量的I/O 資源,另一種是計(jì)算密集型任務(wù),即占用大量的CPU 資源.多進(jìn)程的優(yōu)點(diǎn)在于每個(gè)進(jìn)程相互獨(dú)立,但是占用內(nèi)存多,創(chuàng)建、銷(xiāo)毀、切換進(jìn)程效率低,比較適合大量計(jì)算的計(jì)算密集型任務(wù),不用多次切換或創(chuàng)建銷(xiāo)毀.而多線程占用內(nèi)存少,切換簡(jiǎn)單.適合需要快速切換、創(chuàng)建銷(xiāo)毀的I/O 密集型任務(wù),對(duì)于基于FTP協(xié)議的數(shù)據(jù)服務(wù)來(lái)說(shuō),并沒(méi)有復(fù)雜的計(jì)算過(guò)程,有的只是密集的請(qǐng)求和讀寫(xiě)過(guò)程,是I/O 密集型任務(wù).于是SPDServer 采用多線程的方式處理各種客戶端請(qǐng)求.

多線程的使用,相比于單個(gè)線程的處理能力,性能提升明顯；相比于多進(jìn)程,在提高對(duì)客戶端請(qǐng)求的處理能力的同時(shí),沒(méi)有增加更多的時(shí)間開(kāi)銷(xiāo)和內(nèi)存開(kāi)銷(xiāo),進(jìn)一步提高了數(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 認(rèn)證與用戶管理

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

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

3.3 文件操作管理

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

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

3.4 模式管理

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

3.5 編碼管理

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

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

3.6 日志策略

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

4 SPDScheme 實(shí)際運(yùn)行效果

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

4.1 實(shí)驗(yàn)環(huán)境

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

4.2 兼容性測(cè)試

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

表2 FTP 客戶端兼容性測(cè)試

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

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

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

圖3 測(cè)試小文件上傳下載情況

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

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

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

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

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

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

圖4 測(cè)試大文件上傳下載情況

5 結(jié)束語(yǔ)

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

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