基于代理的并行文件系統元數據優化與實現

易建亮 陳志廣 肖 儂,2 盧宇彤

1(國防科技大學計算機學院 長沙 410073)2(高性能計算國家重點實驗室(國防科技大學) 長沙 410073)3(中山大學數據科學與計算機學院 廣州 510275)(jianliang.yi@foxmail.com)

數值計算已成為繼理論推理、實驗驗證之后的第三大科學研究手段，隨著人們越來越多地借助計算手段解決科學研究、工業生產中的問題，人類社會對高性能計算系統的需求日益增加，并催生了天河[1]、Titan[2]、紅杉[3]等一系列超大規模高性能計算系統.這些高性能計算系統包含數百萬計算核心，能夠支持數百萬進程的并發執行，協同處理TB級、甚至PB級的數據.在處理這些數據的過程中，計算進程會頻繁地執行文件輸入輸出(inputout， IO)操作.為此，高性能計算系統一般配備并行文件系統實現數據的管理和IO.例如，Titan采用Lustre[4]管理數據和存儲資源；天河系列超級計算機在Lustre的基礎上輔以H2FS[5]實現異構存儲資源的管理；紅杉則采用IBM研發的GPFS[6].并行文件系統的所有功能由元數據服務器和數據服務器實現.其中，元數據服務器是整個并行文件系統的核心.早期的高性能計算系統規模較小，并行文件系統元數據服務器承載的壓力較低，一般采用單節點的元數據服務器即可滿足整個計算系統的IO需求.隨著計算系統規模的不斷增大，尤其是百萬核系統(天河二號包含312萬個計算核心，Titan包含56萬個運算核心)的陸續出現，傳統的單節點元數據服務器逐漸不能滿足高并發訪問需求.因此，各種并行文件系統逐步采用分布式元數據管理方式，提供可擴展的元數據服務.例如，Lustre從2.X版本以后開始提供分布式元數據服務，采用子樹劃分的方式將元數據分布到多個元數據服務器上.分布式元數據管理能夠有效提高元數據服務能力，但是，鑒于計算系統規模不斷增大，尤其是E級計算系統在不久的將來即將出現，并行文件系統的分布式元數據管理仍然面臨以下2方面的挑戰：

1) 高性能計算系統中計算節點數目不斷增加，且經常出現大量節點同時產生并發IO請求的情況，傳統的分布式元數據管理機制逐漸難以應對超大規模計算系統產生的并發元數據操作；

2) 對于高性能計算系統中運行的一個任務，參與該任務的所有進程往往在同一時間點向同一文件夾發出大量的IO請求，這會導致該文件夾下很重的元數據訪問負載，而傳統的基于子樹劃分的負載均衡機制并不能將同一文件夾下的元數據負載分散到多個元數據服務器上.

本文針對以上2方面的挑戰，結合高性能計算系統中經常出現屬于同一任務的大量進程向同一文件夾發出并發元數據操作的負載特點，在并行文件系統中引入代理機制，通過代理上的元數據聚合和動態負載均衡，顯著提升元數據操作的性能.實驗表明，本文提出的基于代理的元數據優化機制具備優秀的平均文件IO性能及可擴展的元數據管理方案.

1 高性能計算系統的I/O特征

在高性能計算系統中運行的任務往往包含大量的進程，這些進程相互協作、不斷迭代以完成計算任務.具體地，所有進程每完成一個階段的計算任務后執行1次同步操作、實現交互通信，然后進入下一階段的執行，每個執行階段都被稱作一個迭代步，一個任務往往要經歷成千上萬的迭代步才能最終完成.任務執行過程中一旦在某個迭代步出現了進程失效，最直接的應對方法就是重啟任務，從第1個迭代步重新執行，直至該任務的所有迭代步順利完成.由于高性能計算系統的規模不斷增大，系統中運行的任務所包含的進程不斷增多，進程失效已成為經常發生事件.如果每次出現進程失效都從第1個迭代步重新執行，這將導致計算任務永遠無法完成.為此，研究人員引入檢查點(checkpoint)機制，應對計算過程中的頻繁進程失效.檢查點機制的具體做法是：計算任務每隔若干迭代步就把整個任務的執行狀態持久保存在底層并行文件系統中，一旦出現進程失效，任務可以從最近保存的檢查點重啟，而不必從第1個迭代步重新開始執行，這樣，計算任務每保存一個檢查點即表明計算過程向前推進一步，最終一定能夠保證計算任務順利完成.研究表明，讀寫檢查點已成為高性能計算系統中最重要的IO行為之一.

高性能計算系統中另一類重要的IO操作是輸出中間結果.典型的高性能計算程序包含大量的迭代步，各迭代步的中間結果也具有重要科學價值.為此，研究人員可能選擇一些重要迭代步輸出其中間結果，并使用數據可視化等手段加以觀測、分析.輸出中間結果的IO模式與輸出檢查點類似，但檢查點只有在程序因故中斷、再次恢復執行時才可能讀取，讀取的幾率較低，而輸出的中間結果一般都會再次讀入到計算系統中加以分析.

高性能計算程序一般采用2種模式將其產生的檢查點或中間結果保存在并行文件系統中，即共享模式(shared mode)和獨占模式(independent mode).所謂共享模式，就是該應用程序的所有并發進程將輸出數據(檢查點或中間結果)寫到同一個共享的大文件中.相應地，獨占模式是指每個進程將輸出數據寫到各自的文件中.由于高性能計算系統的規模不斷增大，能夠支撐的并發進程不斷增多，以共享模式輸出數據將會導致大量進程針對同一個文件的鎖競爭，從而降低數據輸出效率.因此，共享模式逐漸不適用于超大規模高性能計算系統.然而，同樣因為高性能計算系統規模不斷變大的原因，以獨占模式輸出數據會產生大量的文件，給數據管理帶來不便.為此，研究人員采用折中方案，將高性能計算程序的所有進程分組，組內的若干進程以共享模式將輸出數據寫到同一個共享文件中，每個組生成一個獨立的文件.這種方法能夠顯著降低應用程序產生的文件數量，同時能夠將針對同一文件的鎖競爭限制在可控范圍之內.但是，隨著計算規模的不斷增大，應用程序產生的文件仍然較多.

高性能計算程序在某個迭代步輸出數據(中間結果)時，往往將該迭代步產生的所有文件輸出到同一個目錄下，且該目錄下所有文件的文件名由應用程序保證不會發生沖突.因此，高性能計算應用的典型IO模式可簡單歸納為：大量進程在同一目錄下并發讀寫大量文件，且這些文件命名不會發生沖突.

2 引入元數據代理的并行文件系統架構

在高性能計算環境中，并行文件系統面臨百萬量級的客戶端，這些客戶端往往在同一時間段內發出大量并發IO請求，使元數據服務器承載巨大的壓力.另一方面，這些客戶端發出的并發讀寫請求往往指向同一目錄，導致很難將元數據負載均衡調度到多個服務器上.為此，本文提出在并行文件系統的客戶端和元數據服務器之間增加一級代理(proxy)，并提出相應的優化措施降低元數據服務器的負載.本文在元數據代理上實現2方面的優化:1)由于高性能計算程序往往并發訪問大量的文件，可以考慮通過元數據聚合將大量請求合并成一個請求發送到元數據服務器上，降低元數據服務器的負載；2)高性能計算程序的并發IO往往指向同一目錄，而傳統的元數據負載均衡機制一般采用子樹劃分的方法將元數據負載調度到多個元數據服務器上[7]，無法實現針對同一目錄元數據操作的負載均衡，本文通過代理將針對同一目錄的元數據操作調度到多個元數據服務器上，實現細粒度的負載均衡.

如圖1所示，系統由3個組件構成：客戶端(client)、元數據服務器(meta data server, MDS)、代理服務器(proxy server).客戶端實現了部分接口，提供給上層應用程序調用；元數據服務器存儲每個文件目錄的關鍵元數據，主要功能包括管理文件系統名字空間、文件目錄和對象物理存儲位置之間的映射[8]；代理服務器實現客戶端和元數據服務器之間的橋接，接受客戶端的IO請求，經適當處理后轉發到元數據服務器，代理服務器由多個節點實現，每個節點負責管理元數據服務器集群的部分節點，本文提出的優化措施將集中在代理服務器上實現.

Fig. 1 System architecture圖1 系統架構圖

3 基于代理的元數據聚合

我們認識到，并行文件系統的工作負載本質上是動態的，隨著上層應用和數據集的變化，數據塊和元數據訪問請求也隨之發生變化.在用戶創建文件文件夾過程當中，需要依靠文件系統遍歷目錄項來判斷是否已有重名文件文件夾存在，傳統文件系統采用加鎖機制來維護目錄項，目錄項是一種臨界資源，進程之間只能通過互斥來訪問，為此，每個進程在進入臨界區之前，先對臨界資源進行檢查，看它是否正被其他進程訪問，如果此刻該臨界資源未被訪問，進程便可以進入臨界區對該資源進行訪問，并設置它正被訪問的標志；如果此刻該臨界資源正被某進程訪問，則本進程不能進入臨界區.面對高性能計算環境大量并發IO請求的場景，這種方式將產生無法接受的響應延遲，嚴重制約了高性能計算所帶來的并發處理能力.針對以上問題，我們提出了基于代理的元數據聚合解決方案.

來自客戶端的IO請求首先由代理進行優化處理，再由其負責轉發至元數據服務器端.代理服務器維護一個請求隊列來接收來自客戶端的IO請求，并且為每個MDS維護一個轉發隊列，如{Serv1,Serv2,Serv3,Serv4}，轉發隊列用于存儲優化后的IO請求.優化步驟包括以下3個部分：

1) 目錄子樹分配表.根據第4節提出的負載均衡策略，系統會自動生成一張目錄子樹分配表.為了提升查表效率，目錄樹分配表采用Hash表來保存.代理從請求隊列中依次取出IO請求，將請求的訪問路徑與目錄子樹分區表中的路徑進行比對，從而找到相應的MDS，并將此請求添加到相應的服務器轉發隊列中.

2) 最長路徑名匹配.當查找usrlocalcofsetcconfig這個路徑時，會匹配usrlocalcofs和usrlocalcofsetc 這2條路徑，因為它們同時符合要求，借鑒TCPIP協議中IP路由查找的最長匹配原則[9]， usrlocalcofsetc能匹配更長的目錄路徑，所以選擇usrlocalcofsetc作為索引來選擇MDS.當列表中出現多個最長路徑名匹配的條目時，選擇其中路徑名長度最小的條目.

3) 組內聚合操作.經過以上步驟，請求包被分成Serv1,Serv2,Serv3,Serv4四部分，將每個組別的請求聚合成1個請求包，將請求包保存到相應轉發隊列.

4 基于代理的元數據負載均衡

在分布式元數據管理方式中，為了防止熱點出現，系統需要一套負載均衡機制，以實時監控節點狀況，調整負載分配，達到均衡狀態.根據系統運行階段的不同，分為靜態均衡機制和動態均衡機制.靜態均衡機制在文件系統啟動階段運行，以使得系統達到一個靜態的、粗略的均衡狀態；動態均衡機制作為文件系統的子服務，在文件系統運行時執行，以實時監控各節點情況，實現系統動態均衡.

4.1 靜態均衡機制

4.1.1 目錄樹分區

在文件系統啟動階段，為了將名稱空間分配給各節點，需要對任務進行劃分，達到初始均衡狀態.借鑒CEPH[7]存儲系統策略，我們將文件系統元數據組織成一顆多叉樹結構，采用目錄樹分區方式來組織文件系統元數據.具體方式如圖2所示：

Fig. 2 Partitions of namespace圖2 名稱空間的分區

4.1.2 目錄樹分配表

為了使系統達到初始均衡狀態，我們對目錄樹進行切分[10]，將整個目錄樹劃分成若干個子目錄樹結構(根據節點數量確定)，并根據各節點配置情況，將這些子目錄樹分攤到相應節點，從而達到靜態均衡.我們首先假設所有元數據的負載大小是相同的，例如每個元數據有一次訪問.圖1每個虛線框代表劃分的子樹，MDSm,MDSn,MDSp,MDSb代表分配的節點.訪問次數為當前情況下每個元數據的訪問請求量，初始情況下假設為1，即只有一條訪問請求訪問當前元數據；之后每當有一條新的請求訪問某條元數據時，就將對應的訪問次數加1.目錄樹分配表記錄了子樹與節點的對應關系，表1記錄了圖2分配策略下的對應關系.

Table 1 Partition Table of Directory Subtree表1 目錄子樹分配表

4.2 動態均衡機制

隨著時間的推移，每個元數據的負載發生了變化(某些元數據同時有多個訪問，某些元數據則訪問量為0)，導致各節點負載發生了變化，服務器集群的均衡狀態被破壞(即某些節點請求量超過了它的處理能力，出現服務失效；而某些節點則無請求到來，處在空閑狀態，導致資源浪費).此時，需要代理服務器的動態均衡機制進行調整，重新回到均衡狀態，如圖3所示:

Fig. 3 Graph of load-balance algorithm圖3 負載均衡算法圖解

4.2.1 負載計算方法

本文使用訪問延遲來衡量某個服務器上的負載情況(元數據的訪問請求是小文件IO操作，每個請求的服務時間的差異性不大，因而使用訪問延遲作為衡量指標)，對于連續IO操作，則使用吞吐量比較合理[11].在某個時刻t，觀測服務器Si上的訪問延遲為Latencyi(t).使用一個基于權重的平均來計算訪問延遲，避免某個時刻的訪問延遲突然變得很大影響綜合情況[12].

Latencyi(t)=(1-α)×Latencyi(t)+
α×Latencyi(t-1).

(1)

設在時刻t-1到時刻t這段時間內，服務器Si上的平均訪問延遲為Latencyi(t)，其中i代表第i個節點，t為時刻，α為權重系數.按照式(1)計算權值后，各節點以心跳的方式將計算結果反饋給代理服務器(如圖2).則所有服務器上的加權平均訪問延遲為[13]：

(2)

其中w1(t),w2(t),…,wn(t)為各節點t時間所分配的權值.

4.2.2 負載均衡策略

當Latencyi(t)≤AvgLatencyi(t)時，將服務器Si歸為集合A；當Latencyi(t)>AvgLatencyi(t)時，將服務器Si歸為集合B.其中，集合A包含負載較輕的節點，集合B包含負載較重的節點.我們的目標是動態地調整服務器負載，使得集合B中服務器將部分負載轉移到集合A中服務器上，并調整目錄分配表條目，達到動態負載均衡的目的.

代理服務器節點從集合A中選擇響應延遲超出平均值一定值的節點作為遷移源，從集合B中選擇響應延遲低于平均值一定值的節點作為遷移目的地.

如圖4所示，均衡任務由代理服務器檢測到后，發起元數據遷移任務，并由代理服務器負責選擇遷移源和遷移目的地.源服務器接收到遷移任務后，開始具體執行數據復制，之后源服務器將源數據刪除[14]，并將操作結果反饋給代理服務器.

Fig. 4 The schedule of metadata migration圖4 元數據遷移流程

4.2.2.1 副本策略

代理服務器負責監控集群，判斷集群是否處于失衡狀態，并在失衡狀態時觸發系統負載均衡機制.均衡器對集合A和B中的節點按照延遲大小進行排序，如集合A排序后為{a,b,c,d}，集合B排序后為{m,n,o,p}.然后在集合A中選擇延遲比較高的若干節點作為遷移源(如選擇m)，在集合B中選擇同等數據的延遲低的節點作為遷移目的地(如選擇p)，將高延遲和低延遲節點配對(如m→p).考慮到元數據集群規模很小，不超過10個節點，排序過程并不會對系統性能產生很大影響.將每一組配對中前一個節點上的目錄樹復制一份到配對后一個節點上，如圖5所示.

Fig. 5 Copy of directories subtree圖5 目錄子樹復制

由于元數據規模很小，在1PB數據量的文件系統中，理論上元數據量不超過2 GB，分在每個節點上的元數據較少，所以復制過程并不會對系統性能造成重大影響.

4.2.2.2 一致性問題

副本策略實現了IO分流，使原本屬于節點n的一部分流量導向節點a，降低了n的壓力.然而隨著時間的推移，a和n上保存的子目錄副本將變得非常不一致.

我們了解到，當且僅當涉及到create_file(創建文件)、delete_file(刪除文件)等操作時，系統才會出現不一致.針對這個特點，這里采用“更新轉移”策略: 只要涉及創建文件等操作，即在分配表中生成一條新的紀錄導向另外的節點.當客戶端打開剛剛創建的文件，只需查找目錄表，找到這一條目即可.實踐證明此方案很好地解決了不一致問題.

4.2.3 修改分配表條目

目錄分配表記錄的是子目錄樹與節點的對應關系，每次負載均衡機制執行完成，都要將修改反饋到分配表條目上.執行完目錄樹復制后，目錄分配表中需要添加條目來記錄副本與節點的對應關系.表2為執行均衡策略后的目錄分配表，其中加深的2行對應相同的子樹，但是對應不同的節點.

Table 2 Partition Table of Directory Tree表2 目錄樹分配表

5 元數據代理的系統實現

系統由3個組件構成：客戶端、元數據服務器和代理服務器.元數據服務器(MDS)存儲每個文件目錄的關鍵元數據，主要功能包括管理文件系統名字空間等；每個代理服務器(proxy)維護整個文件系統的部分目錄分配表，實現元數據服務器集群動態負載均衡.

代理服務器由多個節點構成，從1開始編號，我們假設共有N個節點.首先將所有元數據服務器節點平均分成N個組，編號分別對應1,2,…,N，每個組里面的元數據服務器分別由對應編號的代理節點負責管理.代理節點與元數據服務器之間的對應關系如圖6所示：

Fig. 6 The architecture of system圖6 系統實現結構

5.1 代理與客戶端的映射

我們對文件名進行了擴展.文件名用一個40 b的存儲空間保存，如圖7所示，其中前8 b用于標識文件所對應的代理節點路徑,通過對文件名采用邏輯運算的方法獲取前8 b的值，即獲取到文件所對應的代理節點編號；后32 b保存文件的目錄路徑，用于保存文件的“真實”名稱.

Fig. 7 Construction of file name圖7 文件名組成

圖8所示為文件操作的總體流程.首先由客戶端通過邏輯操作，獲取文件名的前8 b的值(即為代理節點的編號);之后將此文件操作命令轉發給對應編號的代理服務器，代理服務器再根據邏輯操作獲取文件名的后32 b作為目錄路徑.根據目錄路徑查找自己的目錄表，然后根據目錄表條目通過Hash的方法找到相對應的元數據服務器，轉發到相對應的元數據服務器上進行操作.

Fig. 8 Mapping relations圖8 映射關系

5.2 代理服務器操作流程

Client?Proxy：代理采用線程池技術處理來自客戶端的請求.每個代理服務器有一個連接隊列，用來維護來自客戶端的請求包.線程池中的線程相互競爭，到連接隊列里取包進行處理.引入線程池機制，能極大提高系統處理并發的能力.

Proxy?MDS：代理為每個MDS維護一個轉發隊列，用來保存分組結果；代理服務器的轉發器實時監控每個轉發隊列，一旦發現某個隊列填滿，就將此隊列中的請求打包，并發給相應MDS.

Proxy：負載均衡器采用后臺運行模式，實時接收來自MDS端的心跳信息，定時運行負載均衡機制，實現動態負載均衡.

具體包含如下步驟：

1) 應用程序調用客戶端API接口，發出文件open操作請求；

2) 請求通過網絡傳送給對應編號的代理服務器端；

3) 代理服務器負責接收來自客戶端的文件請求，并將收集到的請求根據目錄分配表進行分組，并將每個裝滿的分組打包成請求包，對應元數據服務器的處理包；

4) 代理服務器上的轉發器選擇將各請求包轉發給對應元數據服務器進行處理；

5) 元數據服務器將請求包“解包”成相應文件請求，對每個請求執行相應的操作；

6) 元數據服務器將處理結果分發給相應客戶端.

系統采用IO多路復用技術，利用epoll庫實現異步事件處理機制.客戶端實現了write_file和read_file接口，應用程序調用這2個接口，和文件系統交互.其中write_file實現將buffer緩沖區的數據寫入到系統中；read_file實現將文件系統數據寫入到buffer緩沖區中.

6 性能測試及擴展性評估

我們通過一系列測試數據來評估原型系統，以展現其在性能、可靠性以及擴展性方面的特征.原型系統包含客戶端、MDS以及代理服務器3個部分.MDS和代理服務器有自己單獨的硬件運行環境.我們選擇了一些不涉及數據塊的文件操作，這些操作在運行過程中會產生大量元數據相關操作，而不會有很多數據塊相關操作，從而模擬實際生產環境中大規模IO請求的場景，來驗證系統承受壓力的情況.

6.1 硬件環境

測試所使用的服務器配置情況如表3所示：

Table 3 Server Configuration表3 軟件環境配置

主機的型號與配置情況如表4所示：

Table 4 Hardware Configuration表4 硬件環境描述

6.2 元數據更新延遲

首先考慮元數據更新所帶來的延遲問題.客戶端在某一時刻產生大量文件和目錄，這些請求提交給代理，由代理進行預處理后轉發給相應元數據服務器.圖9為隨備份副本數量的變化，元數據更新操作延遲的變化曲線.

Fig. 9 Delay of metadata update圖9 元數據更新延遲

元數據讀請求比較復雜一些，圖10為客戶端嵌套訪問10 000個目錄，對每個目錄執行readdir操作和stat操作[15].我們統計了在每個目錄下分別包含10個文件和1個文件時，這2種操作所消耗的累積時間.對實驗結果分析可知，隨著目錄變大，MDS消耗更多時間來處理ls命令操作，其中stat操作消耗的累積時間加速增長，readdir則基本維持不變，甚至出現時間減少的情況.

Fig. 10 Cumulative time of ls command圖10 ls命令累積時間

然而，增加代理會延長IO路徑，會對元數據訪問帶來額外的開銷.

6.3 擴展性評估

我們使用包含24個節點的Linux集群來評估元數據服務器的可擴展性能.圖11表示隨著集群規模的擴展，單節點IOPS的變化情況曲線圖.以單節點時候的吞吐率為基準畫一條水平線，這條線就代表了理想情況下的線性擴展，即隨著集群規模的變大，單節點吞吐量保持不變.

Fig. 11 Per-MDS IOPS along with cluster’s scale圖11 隨集群規模擴展單節點IOPS的變化情況

如圖11所示，MDS集群節點平均吞吐量從單個節點時的20 000 IOPS降到了24個節點時的13 800 IOPS.當節點規模24時，單節點下降到理想情況的69%，以上結果驗證了系統具有較好的擴展性.

7 總 結

分布式存儲系統可以提供海量信息的存儲以及設備級的安全性，廣泛應用于科學計算以及數據密集型應用.訪問數據之前必須要訪問元數據，元數據訪問很容易成為性能瓶頸[16].因而，合理的元數據管理，對于提高整個系統的 IO 性能具有重要的意義.如何在元數據服務器之間均衡地分布元數據負載，是元數據管理的關鍵技術之一.本文設計了一種分布式的元數據負載均衡機制，可以按照服務器的性能來分布負載，不僅能夠自適應負載的變化，而且能夠自適應服務器規模的變化.在服務器增加和刪除時，動態地均衡負載.

[1]TOP500.org. Tianhe-2 (milkyway-2) [EB/OL]. 2015 [2016-05-27]. http://www.top500.org/system/177999

[2]TOP500.org. Introducing TITAN: Advancing the era of accelerated computing[EB/OL]. 2012 [2016-05-27]. https://www.olcf.ornl.gov/titan/

[3]TOP500.org. Sequoia-blue gene[EB/OL]. 2015 [2016-05-27]. http://www.top500.org/system/177556

[4]Cluster File System, Inc. Lustre: A scalable, high-performance file system[R]. New York: Cluster File System, Inc, 2012

[5]Zhou Enqiang, Zhang Wei, Dong Yong, et al. Research on optimization towards hybrid and hierarchy storage architecture[J]. Journal of National University of Defense Technology, 2015, 37(1): 47-52 (in Chinese)(周恩強, 張偉, 董勇, 等. 面向分層混合存儲架構的協同式突發緩沖技術[J]. 國防科技大學學報, 2015, 37(1): 47-52)

[6]Wang Rong. Build high availability and high performance GPFS cluster[EB/OL]. [2016-05-27]. https://www.ibm.com/developerworks/cn/aix/library/au-gpfsplan/ (in Chinese)(王榮. 構建高可用、高性能的GPFS集群[EB/OL]. [2016-05-27]. https://www.ibm.com/developerworks/cn/aix/library/au-gpfsplan/)

[7]Weil S A, Brandt S A, Miller E L, et al. Crush: Controlled, scalable, decentralized placement of replicated data[C] //Proc of the 2006 ACM/IEEE Conf on Supercomputing (SC’06). New York: ACM, 2006: 1232-1241

[8]Ghemawat S, Gobioff H, Leung S T. The Google file system[C] //Proc of the 19th ACM Conf on Operating Systems Principles (SOSP’03). New York: ACM, 2003: 32-43

[9]Information Sciences Institute. Internet protocol DARPA Internet program protocol specification[S]. Reston, Virginia: Internet Society (ISOC), 1981

[10]Liu Zhong, Zhou Xingming. A metadata management method based on directory path[J]. Journal of Software, 2007, 18(2): 236-245 (in Chinese)(劉仲, 周興銘. 基于目錄路徑的元數據管理方法[J]. 軟件學報, 2007, 18(2): 236-245)

[11]Wu Changxun, Burns R. Handling heterogeneity in shared-disk file systems[C] //Proc of the 2003 ACM/IEEE Conf on Super Computing (SC 2003). Washington: IEEE Computer Society, 2003: 45-55

[12]Chen Tao, Xiao Nong, Liu Fang. Adaptive metadata load balancing for object storage systems[J]. Journal of Software, 2013, 27(2): 331-342 (in Chinese)(陳濤, 肖儂, 劉芳. 對象存儲系統中自適應的元數據負載均衡機制[J]. 軟件學報, 2013, 27(2): 331-342)

[13]Chen Tao, Xiao Nong, Liu Fang, et al. Clustering-based and consistent hashing-aware data placement algorithm[J]. Journal of Software, 2010, 21(12): 3175-3185 (in Chinese)(陳濤, 肖儂, 劉芳, 等. 基于聚類和一致 Hash 的數據布局算法[J]. 軟件學報, 2010, 21(12): 3175-3185)

[14]Dong Yong, Chen Juan, Tang Tao. Power measurements and analyses of massive object storage system[C] //Proc of IEEE Conf on Computer and Information Technology. Washington: IEEE Computer Society, 2010: 21-24

[15]Weil S A, Brandt S A, Miller E L, et al. Ceph: A scalable, high-performance distributed file system[C] //Proc of the 7th Conf on Operating Systems Design and Implementation (OSDI’06). Berkeley, CA: USENIX, 2006: 307-320

[16]Guo Chengcheng, Yan Puliu. A dynamic load-balancing algorithm for heterogeneous Web server cluster[J]. Chinese Journal of Computers, 2005, 28(2): 179-184 (in Chinese)(郭成城, 晏蒲柳. 一種異構Web服務器集群動態負載均衡算法[J]. 計算機學報, 2005, 28(2): 179-184)