分布式文件系統的寫性能優化

董曉明，李小勇，程 煜

0 引言

如今，人類已經邁入云時代，信息總量正以幾何級數的方式迅速增長，基于對象存儲技術的大規模分布式存儲系統由于其在容量和可擴展性等方面的優勢，逐漸替代了以NFS為代表的傳統存儲方案，越來越受到企業界、學術界的青睞。在近十年內，大量新型的分布式文件系統被研制開發出來，比如 GFS[1]，HDFS[2]，KFS[3]，GlusterFS[4]等等，它們在存儲領域都有著廣泛的應用，不過讓人遺憾的是，這些分布式文件系統雖然有著很大的容量，很好的可擴展性，但是它們的讀寫性能卻遠遠沒有達到網絡上限。而且，隨著計算技術的迅猛發展，應用程序對用戶文件的存取能力也有著越來越嚴格的要求。因此，提高分布式文件系統的讀寫性能不僅有學術意義，還有其實踐意義。

常用的分布式文件系統的優化寫性能的方法主要是寫合并。寫合并是將應用程序要寫的數據先緩存到文件系統客戶端的緩沖區中，等到緩沖區的數據堆積到一定數量后再將數據發送到服務器端。這種方法確實有助于提高文件系統的寫性能，我們的BlueOcean分布式文件系統也采用了這種方法，但是這種方法對寫性能的提升有限，遠遠沒有達到應用程序對寫性能的要求，所以我們必須從其他的方面來對BlueOcean分布式文件系統的寫性能進行優化。本文以我們設計實現的BlueOcean大規模分布式文件系統為基礎，對其寫性能進行了三個方面的優化。

文章的剩余部分組織如下：第 2節介紹了 BlueOcean分布式文件系統的整體架構；第3節介紹了FUSE部分的寫性能優化；第4節介紹了零拷貝；第5節介紹了應用程序寫客戶端文件緩沖區與客戶端寫數據服務器的并行化；第 6節列出了寫性能優化前后的實驗數據；第7節對本文工作進行了簡要的總結。

1 BlueOcean系統架構

BlueOcean是我們實驗室設計開發的基于對象存儲的大規模分布式存儲系統，其架構類似于GFS、HDFS和KFS，它由一個元數據結點，一個備份結點（可選），多個數據結點和若干個客戶端組成。其中元數據結點主要用于管理文件元數據信息，并負責負載均衡和租約管理等；備份結點用于在元數據結點停止服務（比如掉電，或網絡不通等）后，接管元數據結點的功能，保證元數據結點功能的可靠性；數據結點負責保存數據，并以線程池的方式高并發的處理來自客戶端的IO請求；我們使用FUSE在用戶態開發客戶端文件系統，客戶端采用了單線程異步的框架，與元數據結點進行元數據交互，與數據結點進行數據交互。

在我們開發的 BlueOcean分布式文件系統中，用戶存儲的文件被分割成多個固定大小的 chunk存儲在數據結點上，用戶可以根據具體應用為每個chunk設置一份或者多份副本，以提高系統的可靠性，保證系統的可用性。

BlueOcean存儲系統的架構圖，如圖1所示：

圖1 系統的架構圖

2 FUSE部分的寫性能優化

使用FUSE在用戶態開發客戶端文件系統是現有的分布式存儲系統客戶端的常用的實現方案，例如 GlusterFS。該方法實現起來比較簡單，而且FUSE還提供了POSIX語義的接口，通用性強，更由于其在用戶態運行，這就保證了客戶端程序的安全性和穩定性。BlueOcean分布式文件系統的客戶端也是使用FUSE開發的，但是，使用FUSE帶來的負面影響就是會比較嚴重的影響文件系統的寫性能。

在對FUSE部分的寫性能進行優化之前，我們首先來介紹兩個比較重要的概念，模式切換和上下文切換。眾所周知，大多數的進程都至少支持兩種執行模式：內核模式和用戶模式，模式切換就是進程由一種模式切換到另外一種模式，通常情況下，模式切換的代價是比較小的。上下文切換就是將CPU的控制權由一個進程轉移到另外一個進程，不僅需要保存住當前進程的運行狀態，并且還要恢復將要執行的進程的狀態。一次上下文切換的代價是來自很多方面的，CPU寄存器需要被保存和重新載入，TLB表項需要被重新載入，CPU上的流水線也需要被刷掉。雖然影響上下文切換的因素有很多，比如CPU性能，負載情況以及進程的內存訪問模式等等，但是顯而易見，與模式切換相比，上下文切換的代價是相當巨大的。

在應用程序使用本地文件系統（例如EXT3或者EXT4）的時候，每個文件系統的操作都會產生兩次內核態/用戶態的模式切換（應用程序進程會先從非特權的用戶態切換到特權的內核態，然后再從特權的內核態切換到非特權的用戶態），并不會產生上下文切換。而在使用FUSE的時候，每一個FUSE請求不僅會有上面的兩次模式切換，還引入了兩次上下文切換（從用戶態的應用程序進程切換到用戶態的libfuse進程，再從用戶態的 libfuse進程切換到用戶態的應用程序進程），所以執行一次FUSE寫請求是要耗費很大代價的。

BlueOcean客戶端在執行文件系統寫操作的時候，是將寫操作先組織成4K大小的FUSE寫請求[5]，然后再傳遞給libfuse進程進行處理的。這就產生了一個問題，如果應用程序寫操作的數據塊的大小超過了4K，那么FUSE是如何處理的呢？目前看來，FUSE在處理數據塊大小超過4K的寫操作時，是將寫操作分割成多個4K大小的FUSE寫請求，然后將這些FUSE寫請求串行的傳遞給libfuse進程進行處理。很明顯，這種處理方式有著其顯著的缺點，就是它可能會將原本一次 FUSE寫請求就可以執行完的操作分割成了多個FUSE寫請求，產生了額外的上下文切換，嚴重影響文件系統的寫性能。

通過研究我們發現，大多數的應用，包括linux的cp,tar等命令，它們使用的數據塊的大小都是大于4K而小于128K的，如果繼續保持4K大小的FUSE請求是沒有任何意義的，而且還會產生性能上的問題。所以我們將FUSE寫請求的大小由原來的 4K增加到128K，這樣做將上下文切換的次數降低到了原來的 1/32，避免了原來大量的無謂的上下文切換，使得BlueOcean文件系統的寫性能有著顯著的提高。

3 零拷貝

在大多數的分布式文件系統中，為了提高寫性能，大都會將要寫的數據先存放到客戶端的緩沖區中，等到數據積攢到了一定的數量后，再集中將數據發送出去。這樣做可以有效地降低客戶端與數據服務器的交互次數，提升系統的寫性能。BlueOcean分布式文件系統在客戶端也采用了這種優化方式，但是在實現這種優化的時候卻多引入了兩次內存拷貝。

在 BlueOcean分布式文件系統中，客戶端寫操作數據的大致走向，如圖2所示：

圖2 客戶端數據的走向

1) 應用程序要寫的數據會被分割成128K大小的塊拷貝到FUSE的緩沖區進行處理。

2) FUSE在接收到應用程序發送來的數據后，會再將這些數據拷貝到 BlueOcean文件系統客戶端的文件緩沖區中。

3) 當文件緩沖區填滿或者文件關閉的時候，客戶端程序會將文件緩沖區內的數據再拷貝給客戶端的網絡模塊，并由網絡模塊將這些數據通過網絡接口發送出去。

眾所周知，內存拷貝屬于 CPU密集型操作，在 CPU性能不高，系統高負載等情況下，很容易成為系統瓶頸，會嚴重影響文件系統的寫性能。因此我們在優化系統寫性能的時候，引入零拷貝的概念，實現了FUSE到文件緩沖區的數據零拷貝和文件緩沖區到網絡模塊的數據零拷貝。

為了實現零拷貝，我們對char類型的數據塊進行了封裝。使得數據在由FUSE傳遞到文件緩沖區和由文件緩沖區傳遞到網絡模塊的傳遞過程中，并不執行數據的實際拷貝，而只是執行 char*指針的傳遞。如果文件緩沖區的大小設置為4M，那么兩次數據拷貝會引入8M的數據拷貝量；而char*類型的指針只占 4到 8個字節，兩次指針拷貝只會引入 8到16字節的數據拷貝量。很顯然，指針拷貝的寫性能會遠遠高于數據拷貝的寫性能。

實現了零拷貝的后，客戶端的寫操作數據的大致走向，如圖3所示：

圖3 實現零拷貝后，客戶端數據的走向

1) 應用程序要寫的數據會被分割成128K大小的塊拷貝到FUSE的緩沖區進行處理。

2) FUSE在接收到用戶應用程序發送來的數據后，再將這些數據以零拷貝的方式傳遞到 BlueOcean客戶端的文件緩沖區中。

3) 當文件緩沖區填滿或者文件關閉的時候，客戶端程序會將文件緩沖區內的數據再以零拷貝的方式傳遞給客戶端的網絡模塊，并由網絡模塊將這些數據通過網絡接口發送出去。

4 并行化

我們對BlueOcean文件系統的順序寫流程進行了分析，發現順序寫的整個過程可以大致分為如下三個時間消耗階段。

第一階段是客戶端將應用程序發送來的數據寫到客戶端的文件緩沖區里，我們稱這個階段為寫緩沖區階段。BlueOcean文件系統將客戶端的文件緩沖區設置為 8M 大小，而在第3節中提到過，我們已經將FUSE的寫請求大小設置為128K，所以FUSE是需要至少發送64次FUSE寫請求才能將客戶端的文件緩沖區填滿。這個階段由于要進行大量的數據拷貝，模式切換以及上下文切換，因此整個過程是相當耗時的。

第二階段是客戶端將文件緩沖區內的數據通過TCP/IP協議以寫請求的方式發送給 BlueOcean分布式文件系統的數據服務器，我們稱這個階段為網絡傳輸階段。在BlueOcean分布式文件系統中，向數據服務器發送寫請求只是將要發送的數據推送到數據服務器，客戶端并不需要等待接收來自數據服務器的對于寫請求的應答，所以發送寫請求的時間實際上就是網絡推送寫請求的時間。由于數據服務器在接收到來自客戶端的寫請求后，會立刻進行磁盤調度，將接收到的數據寫磁盤，所以客戶端發送的寫請求的數據量越小，開始進行磁盤調度的時間就越早。因此，BlueOcean客戶端會限制發送給數據服務器的寫請求的大?。梢詾?128K或者256K），那么客戶端文件緩沖區內的數據會被分割成多個寫請求發送給數據服務器。這樣做實際上是以流水線的方式實現了網絡傳輸與磁盤IO的并行化?？蛻舳宋募彌_區內8M的數據會被分成64個或者32個寫請求，順序發送給數據服務器。

第三階段是客戶端向數據服務器發送同步寫請求后，等待接收數據服務器返回寫同步請求應答的階段，我們稱這個階段為同步寫階段。在第二階段的寫請求全部發送完以后，客戶端會立即向數據服務器發送一個包含所有寫請求的校驗和的同步寫請求，只有數據服務器將接收到的所有寫請求的數據全部寫到磁盤以后，才會向客戶端返回一個同步寫請求的應答，這意味著客戶端文件緩沖區內的數據已經寫成功了，可以接收來自應用程序的寫數據了。這個過程主要依賴數據服務器端磁盤IO的性能，磁盤IO越高，這個階段所花費的時間就越短。

上述3個階段的數據交互流程大致，如圖4所示：

圖4 寫數據交互流程

分析上圖不難發現，寫緩沖區階段和網絡傳輸階段以及同步寫階段是串行執行的，這就說明整個順序寫流程是有性能提升的空間的，通過將整個串行流程改成并行流程可以實現延遲隱藏，達到提高文件系統寫性能的目的。實際上，通過上圖還可以發現，網絡傳輸階段與寫同步階段合并在一起就是網絡傳輸與磁盤IO實現兩階段流水線以后的整個流水線階段，所以我們將網絡傳輸階段與同步寫階段統稱為寫服務器階段。

一種簡單的并行化的實現方案是將寫緩沖區階段與寫服務器階段做一個兩階段的流水線處理，實現寫緩沖區與寫服務器的并行化。眾所周知，實現階段間的流水化，就必須獨立這些階段。所以為了獨立寫緩沖區階段與寫服務器階段，客戶端必須為每一個文件多申請一個文件緩沖區，這樣當一個緩沖區用于向數據服務器發送數據的時候，另一個緩沖區可以接收來自應用程序的數據。

實現了寫緩沖區與寫數據服務器并行化的寫數據交互流程，如圖5所示：

圖5 兩階段流水的寫數據交互流程

很顯然，這種實現方案會消耗大量的內存，使得客戶端的文件打開數量的上限減少為原來的一半。如果客戶端的內存大小為2G，文件緩沖區的大小為8M，那么優化之前，客戶端文件打開數量的上限為256個；而以這種方案優化之后，客戶端的文件打開數量就變成了128個，這是很不合理的。所以我們否定了這種方案，并且提出了一種既可以提高順序寫的性能，又不產生額外的內存消耗的方案。

我們知道，BlueOcean分布式文件系統已經將網絡傳輸與磁盤 IO進行了流水線處理，實現了網絡傳輸與磁盤 IO的并行化，而我們提出的這種優化方案就是將寫緩沖區階段也納入到網絡傳輸與磁盤IO的流水線中，實現寫文件緩沖區，網絡傳輸與磁盤IO這三個階段的并行處理。

在我們的優化方案中，一個文件仍然只有一個文件緩沖區，大小仍然為8M，但是客戶端程序并不是要等到文件緩沖區寫滿以后才向數據服務器發送寫請求，而是只要文件緩沖區內尚未發送的數據量達到 128K，我們就會先把這128K的數據以寫請求的方式發送給數據服務器。

我們為客戶端的文件緩沖區關聯了一個計數器，該計數器記錄了緩沖區當前已發送的數據的數量（我們用 Q表示）。在每次應用程序寫完緩沖區以后，客戶端程序都會更新緩沖區的數據總量（我們用T表示），并且計算出緩沖內尚未發送的數據量（Q-T），設（Q-T）/（128K）= N，如果N大于0，就說明客戶端緩沖區內尚未發送的數據量已經達到128K，就會向數據服務器發送N個寫請求，并且更新Q= Q+N*128K；如果N等于0,則說明客戶端緩沖區內尚未發送出去的數據還沒有128K，就直接返回，并不向數據服務器發送寫請求。只有當緩沖區當前已發送的數據總量（Q）等于 8M（即 Q=T=8M），或者文件被關閉了，才會向數據服務器發送一個寫同步請求，同步那些已經發送給數據服務器的寫請求。該方案的大致交互流程，如圖6所示：

圖6 三階段流水的寫數據交互流程

比較圖6和圖4不難發現，我們的優化方案將原來只實現了網絡傳輸與磁盤IO的兩階段流水線優化成了應用程序寫客戶端文件緩沖區、網絡傳輸以及磁盤IO的三階段流水線，大大降低了客戶端向數據服務器寫8M數據所需要的總的時間延遲，實現了寫緩沖區、網絡傳輸與磁盤IO三個階段的完全并行化，顯著地提高了分布式文件系統的寫性能。

5 性能測試

5.1 測試環境

本次性能測試，使用了 5臺高性能服務器，一臺作為元數據結點，一臺作為客戶端，另外三臺作為數據結點。所有的服務器都通過一臺千兆交換機相連。所有的服務器都采用了雙網卡綁定技術，每個服務器的兩個網卡被設置成load-balance模式。

元數據結點的配置信息，如表1所示：

表1 元數據結點配置信息

數據結點和客戶端的配置信息，如表2所示：

表2 數據結點和客戶端的配置信息

5.2 測試內容

測試1：使用iozone測試工具，在chunk副本數為3的前提下，對優化前后的文件系統的寫性能做測試對比。

測試集：文件大小為8G，chunk副本數為3，iozone塊大小為16K，32K，64K，128K，256K，512K，1024K。

測試結果，如圖7所示：

圖7 三副本下，優化前后的系統吞吐量

測試2：使用iozone測試工具，在chunk副本數為1的前提下，對優化前后的文件系統的寫性能做測試對比。

測試集：文件大小為8G，chunk副本數為1，iozone塊大小為16K，32K，64K，128K，256K，512K，1024K。

測試結果，如圖8所示：

圖8 單副本下，優化前后的系統吞吐量

測試3：使用linux的top命令，對優化前后的客戶端程序的內存使用量做測試對比，內存使用量，如圖9所示：

圖9 優化前后客戶端程序的內存使用量

5.3 結果分析

1) 單副本的系統吞吐量比三副本的高。這是因為推送三個副本時，網絡傳輸和磁盤IO的時間明顯增加。

2) 雖然，僅采用零拷貝對系統吞吐量的提升并不是特別大，但是它降低了在執行寫操作時客戶端的內存使用量，降低了系統高負載時對寫性能的影響。

6 小結

本文對 BlueOcean分布式文件系統的寫交互流程進行了詳細的分析，指出了影響BlueOcean文件系統寫性能的關鍵因素，并從3個方面對寫性能進行了優化。最后通過對優化前后的寫性能的對比測試，證明了優化后的文件系統的寫性能確實大大提高了。

[1]Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung.The Google File System[C]. Proceedings of the 19thACM Symposium on Operating Systems Principles. Lake George, NY , October, 2003.

[2]Konstantin Shvachko, Hairong Kuang and sanjay Radia.The Hadoop Distributed File System[C]. Proceedings of 26thIEEE International Sysposium on Mass Storage System and Technologies (MSST’10). pages 1-10,2010.

[3]Kosmos. http://kosmosfs.sourceforge.net.

[4]Gluster. http://www.gluster.org.

[5]Aditya Rajgarhia, Ashish Gehani.Performance and extension of user space file systems[C]. Proceedings of the 2010 ACM Symposium on Applied Computing. New York, 2010, 206-213.