電信運營商“互聯網+”業務中的分布式存儲技術研究

聯通系統集成有限公司 北京 100032

1 分布式存儲技術概述

1.1 分布式存儲概念

運用分布式計算技術把大量標準X86服務器的本地存儲介質進行聚合，將這些存儲資源通過網絡整合為一個既具備傳統SAN/NAS的企業級功能和特性又具有良好擴展性、低成本、高可靠、易用的存儲系統，形成全新的產品類型。目前，市場上絕大部分分布式存儲產品都是由上述形態構成，我們將這一類產品稱為Server SAN。

1.2 分布式存儲的特點

1)良好的擴展性。它可以擴展到幾百臺甚至幾千臺的集群規模，容量達PB級，而且，其擴展的方式是漸進式的，隨著規模的增長，系統整體性能表現為線性增長。

2)低成本。由成本低廉的PC服務器組成的集群在性能方面能夠達到或超越中高端存儲的性能，在成本上遠低于中高端存儲。這也是分布式存儲最吸引人之處。但成本低廉的PC服務器在硬件可靠性方面與大型機相比相去甚遠，于是分布式系統由軟件來對硬件進行容錯，通過軟件來保證整體系統的高可靠性。

3)高可靠性。通過把數據分成2-3個副本負載分散到眾多的機器上，單個節點故障最多只會使一個副本丟失，而其它副本不會受任何影響。理想條件下，某一時刻如果有1/3的節點出現故障，存儲仍能繼續工作，只不過損失1/3的性能。另外，線性擴展能力也使得增加、減少機器非常方便，可以實現自動運維。

4)易用性。分布式存儲需要能夠提供易用的對外接口，另外，也要求具備完善的監控、運維工具，并能夠方便地與其他系統集成[1]。

1.3 分布式存儲的關鍵技術

對于大多數分布式文件系統，通常將元數據(inode)與數據(block)兩者獨立開來，即將控制流與數據流進行分離，從而獲得更高的系統擴展性和I/O并發性。因而，元數據管理架構顯得至關重要，直接影響到系統的擴展性、性能、可靠性和穩定性等。存儲系統要具有很高的Scale-Out(橫向擴展)特性，最大的挑戰之一就是記錄數據邏輯與物理位置的映像關系即數據元數據，還包括諸如屬性和訪問權限等信息。特別是對于海量小文件的應用，元數據問題是個非常大的挑戰。總體來說，分布式文件系統的元數據管理大致可以分為三種架構，即集中式元數據架構(如Lustre、PVFS、StorNext、GFS等)、分布式元數據架構(如PanFS、GPFS、Ceph等)和無元數據架構(最典型的就是GlusterFS)。這三種架構各有優勢和不足之處，實際系統實現中也難分優劣，三種元數據架構都有各自存在的理由。[2]

1.4 分布式存儲的主流產品

目前，市場上絕大部分Server SAN類型的分布式存儲產品都是由開源的或自研的分布式文件系統+標準X86服務器+存儲管理軟件來實現的。其中，分布式文件系統包括Ceph、GlusterFS、HDFS、GFS、OpenStack swift、MogileFS、FastDFS、MooseFS以及NFS等，根據不同應用場景，選擇不同分布式文件系統；標準X86服務器一般會選用硬盤槽位較多的服務器；存儲管理軟件主要有兩個作用，一是封裝多種協議供前端設備訪問，例如iSCSI(塊設備)、NFS(文件服務)、Amazon S3(對象存儲)等，第二是根據每個廠商的自身技術實力，開發企業級的存儲功能，例如提升性能的SSD加速、存儲自動分層，數據負載均衡功能，增強可靠性的多副本、糾刪碼、自動修復功能，提高利用率的去重、壓縮、精簡配置等功能。

2 海量小文件問題

通常我們稱小于1MB的文件為小文件，百萬級數量及以上稱為海量，由此量化定義海量小文件問題[3]。海量小文件在目前實際中越來越常見，如社交網站、電子商務、廣電、網絡視頻、高性能計算，例如以下幾個場景。

1)社交網站Facebook存儲了600億張以上的圖片，推出專門針對海量小圖片定制優化的Haystack進行存儲。

2)淘寶作為最大的C2C電子商務網站，存儲超過200億張圖片，平均大小僅為15KB，也推出了針對小文件優化的TFS文件系統存儲這些圖片。

3)歌華有線可以進行圖書和視頻的在線點播，圖書每頁會掃描成一個幾十KB大小的圖片，總圖片數量能夠超過20億。

從上述數據和近幾年的統計結果來看，非結構化數據的增長趨勢明顯已經超過了結構化數據。未來，企業勢必要選擇一種更適合的存儲非結構化數據的存儲設備，這種存儲設備必須具備良好的橫向擴展能力、高可靠性，還要支持大數據類的應用，并能夠構建云計算基礎，同時，它還必須得在合理的成本之內。分布式存儲正迅速成為一種可行的方案，因為其擴展的上限比集中存儲要高，而且成本更低。

2.1 聯通集團應用系統現狀

目前，聯通集團內部眾多系統也面臨著海量小文件的問題，以電子商城系統為例，電子商城系統屬于核心系統，其中存儲了眾多用戶信息的圖片文件，文件大小在100k～200k之間，數量為億級，整體容量約20TB左右。商城系統架構如圖1所示。

圖1 聯通集團電子商城架構圖

電子商城系統目前分為商城前置機和商城主存儲兩個部分，商城前置機部分共有31臺PC服務器作為前置機，分別存儲不同營業廳上傳的近半年的文件，圖片主存儲部分由2臺PC服務器和1臺終端存儲構成，存儲的是過期半年的圖片文件。商城系統的文件上傳和調閱過程如下。

1)上傳過程。營業廳的客戶端在上傳時，需要輸入唯一的身份證號，核心系統的應用程序會以身份證號碼作為唯一標識并根據上傳文件的營業廳編碼、日期信息生成一個目錄索引，然后核心系統應用程序會將目錄索引寫入到核心系統數據庫中。之后核心系統應用程序會將圖片按照目錄索引寫入到對應的前置機中存儲起來。由于前置機的存儲容量有限，6個月之后，前置機會將6個月以前的數據遷移至圖片主存儲中，并通過核心系統應用程序修改數據中的目錄索引。

2)調閱過程。營業廳的客戶端在查閱某一圖片文件時，首先，根據唯一的身份證號標識將向核心系統應用程序發起請求，應用程序會在核心系統數據庫中查詢圖片的目錄索引。之后，核心系統應用程序會根據索引讀取存在前置機上或圖片主存儲上的用戶信息文件，并緩存在自己的內容緩存中，供客戶端查看。

目前，聯通電子商城系統主要存在的問題是系統主存儲調閱時性能不高，主存儲使用的是一臺中低端HDS存儲，本身性能不強，并且還存儲了上億的圖片小文件，而傳統存儲對于海量小文件的支持并不好，因此在查閱主存儲上的文件時性能不是很好，由于文件數量巨大，從查詢請求發起到接收到最終結果，會有3～5秒左右的延遲，這對前端業務人員的耐心是一種考驗。

2.2 傳統存儲無法解決海量小文件問題

傳統存儲解決不好海量小文件問題主要有兩方面原因。第一，作為傳統存儲主要使用的存儲介質，機械硬盤本身就不適合隨機小文件I/O讀寫，機械硬盤最適合的是順序的大文件I/O讀寫，這是由存儲介質自身特性決定的，也是傳統存儲在海量小文件場景下性能表現不佳的最根本原因。第二，傳統存儲大都使用本地文件系統，比如XFS/EXT4、EXT3、EXT2、JFS2、ZFS，這些文件系統是針對機械硬盤適合大文件I/O特性而設計的，在I/O訪問流程、空間利用率和元數據管理方面都側重大文件，而在應對海量小文件時，由于文件數量多，傳統文件系統中無法緩存所有inode信息，因此，系統將進行頻繁的I/O，這會使讀寫數據的速率降低。

2.3 分布式存儲如何解決海量小文件問題

海量小文件由于數量巨大，又通常需要進行共享和并發訪問，目前主流的解決方案是采用分布式存儲技術，包括分布式文件系統和分布式對象存儲系統，每個存儲節點底層采用本地文件系統進行管理。

對于分布式存儲而言，通常將元數據與數據兩者獨立開來，即控制流與數據流進行分離。元數據節點處理控制流，通常稱為MDC。通過擴展元數據節點，可以擴展元數據的存儲容量、提高元數據的并發訪問能力，從而提升整個系統的I/O并發能力。數據節點處理數據流，通過擴展數據節點，可以將數據I/O訪問分散到多個數據節點，從而實現容量和性能的整體提升。

相比傳統存儲，分布式存儲可以靈活地調整元數據節點和數據節點的配比，從而提高空間利用率；對于海量小文件的情況，還可以將元數據緩存在多個節點的SSD或內存中，從而提高元數據的訪問效率；同時，分布式存儲還可以進一步優化I/O訪問流程，提升I/O效率。總體上來說，分布式存儲與傳統存儲相比，對海量小文件的優化可以更加靈活，有更多可優化的手段去適配海量小文件的場景。

分布式存儲邏輯架構如圖2所示。

3 如何提高分布式存儲的性能

根據上述內容中對海量小文件問題根源的剖析，結合Facebook Haystack、淘寶TFS等分布式存儲在海量小文件應用方面的優化實踐，我們認為硬件優化、Cache管理優化、小文件合并存儲、元數據管理優化等是幾種行之有效的優化方法。

圖2 分布式存儲邏輯架構圖

3.1 提高硬件配置

分布式存儲雖然在擴展性和靈活性方面比傳統存儲要好，但其由于各個節點之間必須通過網絡通信，因此，增加了數據訪問的開銷。例如，分布式存儲系統的客戶端與元數據服務器和I/O服務器之間的網絡通常為TCP/IP網絡，網絡開銷較大，增大了文件訪問的延時。其他方面，服務器的CPU、內存、硬盤等硬件配置也或多或少地會對分布式存儲系統產生影響。

如果不考慮成本問題，硬件優化是最為直接有效的優化方法，可以采用更高性能的硬件來提高分布式存儲系統的性能。1)使用速度更快的SSD作為全部或部分存儲介質，部署時采用數據分層存儲或Cache加速，可以顯著提高隨機讀寫場景下的IOPS性能；2)采用處理能力更強或更多的CPU，可以提高系統的I/O處理速度和并發性；3)配置更大容量的內存，有效提高數據緩存命中率；4)采用延遲更小、帶寬更高的網絡設備優化網絡傳輸效率，比如萬兆網絡或Inf i niBand網絡。

擴展硬件設備時需要注意，硬件設備在性能上要做到匹配，尤其是磁盤速率和網絡速率要匹配，例如萬兆網絡中理論帶寬為1.28GB，SATA3理論速率為600MB左右，如果采用萬兆網絡+SATA盤，此時系統瓶頸在硬盤處，如果換成SSD盤，就可以消除硬盤的瓶頸。必要時需要調節操作系統內核參數，以優化通過網絡接收和發送數據的效率，如表1所示(各參數的具體數值需要按照實際項目需求來定)。

表1 操作系統優化參數

3.2 提高元數據管理效率

分布式存儲系統架構大致分兩種，即有中心架構和無中心架構。在有中心架構的分布式存儲系統中，通常有一個元數據服務器來統一管理元數據。而在無中心的架構中，元數據會分散存儲于各個存儲節點上，通過哈希算法進行管理和定位。客戶端在讀寫小文件數據前，需要通過與元數據服務器(有中心架構)或存儲節點(無中心架構)進行通信，以獲取位置信息，這一過程相當于額外增加一次網絡傳輸開銷和元數據服務訪問開銷。對小文件I/O來說，開銷影響非常大；因此，對于有中心架構，元數據管理主要從減少元數據量、減少元數據訪問次數、提高元數據檢索效率幾個方面著手。

在分布式存儲系統中，可以根據實際應用需求，對元數據進行適當精簡，只保留需要的元數據信息即可，從而達到減少元數據的目的。例如，在文件命名時，可以加入位置信息；對象存儲系統可以不設置訪問日期、訪問權限等元數據信息，這樣可以減少元數據的存儲量。需要注意的是，精簡元數據信息雖然可以帶來性能上的提升，但也會帶來管理上的不便，需要應用系統在開發時統一格式，并且開發人員要嚴格遵守制度，從管理上杜絕可能造成的混亂。

另外，元數據操作在小文件整個I/O過程中占了大部分時間，可以對多個RPC請求進行合并，從而大幅減少對元數據訪問次數。還可以在客戶端對元數據進行緩存，利用Cache機制顯著減少元數據訪問次數。

在元數據服務器上或存儲節點上，元數據最終持久化存儲在數據庫上或磁盤文件系統目錄上，甚至是單個文件中。為達到高效的元數據檢索，需要使用大容量內存和更快速度的磁盤(例如SSD磁盤)，同時，還可以通過多級索引、BloomFilter等減少元數據操作過程的I/O訪問次數，進一步加快元數據訪問速度。

3.3 優化數據布局和I/O訪問模式

對于大文件的處理：分布式文件系統往往采用條帶化技術對大文件進行切片，并在多個數據服務器上進行存儲，從而提高用戶對文件訪問的并發性。

對于小文件的處理：由于小文件不利于條帶化，一般采用將單個文件存儲在單個數據服務器上的策略。但當小文件數量達到一定程度后，對小文件的大量重復訪問將會給數據服務器帶來性能上的負擔。分布式存儲采用將小文件合并存儲的方式來優化海量小文件訪問的問題。該策略通過多個邏輯文件共享同一個物理文件，將多個小文件合并存儲到一個大文件中，實現高效的小文件存儲。這種方式將大量的小文件存儲到一個大文件中，把大量的小文件數據變成大文件數據，減少了文件數量，從而減少元數據數量，提高了元數據的檢索和查詢效率，性能得以顯著提升。小文件的元數據和數據會一并存儲在大文件中，并形成索引文件，訪問時通過索引進行定位。索引文件采用預加載到Cache的策略，可以實現隨機讀寫小文件只需要一次I/O。

眾多小文件合并存儲后實際上相當于一個微型文件系統，這種機制對于“一次寫，多次讀”模式的分布式存儲系統非常合適，但不適合“多次寫”的存儲系統。因為文件改寫和刪除操作會使大文件內部產生碎片，如何進行空間管理并在合適的時候執行碎片整理，實現起來比較復雜，并會產生額外開銷。如果不對碎片進行處理，則會導致數據分布的不連續，訪問數據時會增加I/O的次數，導致性能下降。

3.4 提高Cache管理效率

Cache技術主要通過空間換時間的策略，利用數據訪問的時間和空間局部性，盡量提高數據訪問的緩存命中率，從而提高系統的性能。

分布式存儲系統中，多個存儲節點、元數據服務以及客戶端都通過物理網絡互聯，客戶端和服務器端都會進行數據緩存。根據節點上Cache資源工作方式的不同，分布式存儲系統中的Cache分為分布獨立式Cache和協作式Cache。

分布獨立式Cache中，每個存儲節點上的文件系統Cache只負責緩存本節點上的I/O數據，Cache中數據的一致性和Cache資源分配等工作由本節點上的Cache管理器負責。這種Cache管理簡單，不影響系統的整體結構。增刪存儲節點后，也不需要做額外的Cache配置和管理工作。

協作式Cache中，每個存儲節點上的Cache不僅負責緩存本節點上的I/O數據，還負責緩存其他節點上的Cache數據。協作式Cache需要各節點之間能夠快速的通信，因此，存儲節點之間的網絡帶寬必須足夠大。協作式Cache能夠充分利用Cache資源，構造全局的“Cache Fusion”，以實現更高的Cache命中率。

兩種Cache方式相比較，分布獨立式Cache簡單、擴展性高，協作式Cache管理復雜、對網絡要求高，但是Cache命中率能夠大幅提高，對分布式存儲系統整體性能提高更加明顯。

通過以上幾方面的分析我們可以看出，分布式文件系統的海量小文件問題主要包括元數據管理、數據布局、Cache管理、I/O訪問流程、網絡開銷等幾個方面；因此，想要用好分布式文件系統，必須要針對問題的根源進行特定的優化措施。優化思路大體分為兩種：一是減少數據訪問次數，二是減少數據訪問時間。具體來講，可以從合并小文件、增大Cache命中率、優化元數據管理等方面提高訪問效率，進而達到優化海量小文件存儲的效果。同時，可以結合硬件和應用優化，進一步增強優化效果。

4 聯通集團應用系統問題的解決

4.1 成功案例

Facebook和淘寶都面臨著百億級的小文件存儲，兩家公司都根據自身應用特點設計相應解決方案。Facebook采用的是Haystack[4]，淘寶采用TFS，而它們都不約而同地采用分布式存儲的設計思想，并對分布式存儲的不足進行了改進。

Facebook設計的Haystack與淘寶設計的TFS思路相仿：將元數據與文件實際內容分開處理，元數據保存在主控節點的內存中，文件實際內容合并成大文件再保存在存儲集群的磁盤中，存儲節點通過內存索引檢索文件實際內容。Facebook使用Haystack來應付海量圖片的讀取更新，如圖3所示。

圖3 Haystack架構圖

該系統由三個核心部分組成：存儲節點、目錄節點和緩存系統。當用戶訪問某個頁面時，目錄節點會為其中的每個圖片構造一個URL，根據該URL，瀏覽器會先訪問對應的CDN，如無命中則訪問高速緩存，再無命中則訪問存儲節點。Haystack適配海量小文件的秘密在存儲節點上：存儲節點的磁盤空間被劃分為幾個100GB左右的大文件，圖片依次寫入這些大文件，存儲節點在內存為每個圖片建立索引，并實時備份到磁盤，機器宕機后仍能根據磁盤上的備份迅速恢復該內存索引表。Haystack使用專門的目錄服務節點處理圖片的元數據。

淘寶也開發了類似Haystack的系統TFS來存儲非結構化數據[5]，主要是針對海量的小圖片文件。TFS能有效處理淘寶“雙十一購物狂歡節”的驚人并發量。TFS的整體架構如圖4所示，是由一個NameServer(名稱服務器)與眾多數據節點組成的主從結構。為防止單點問題，NameServer使用了HA結構(High Availability)：兩臺NameServer互為熱備，實現主從復制，從機器只提供讀功能；從機器可以在需要時迅速切換為主機器，以便持續工作；心跳代理負責監控這一切換過程。

4.2 問題的解決

之前聯通集團電子商城系統的瓶頸主要集中在圖片存儲服務器和圖片主存儲這里，圖片索引、核心應用集群、前置機等部分沒有性能瓶頸，因此，主要針對圖片服務器和圖片主存儲部分進行改進。改進后的效果如圖5所示。

針對之前提到的聯通電子商城系統中存在的主要問題，參考淘寶和Facebook解決方案案例，我們來對聯通集團電子商城系統架構進行改進。

我們采用有元數據的架構，首先將兩臺圖片存儲服務器利舊，作為分布式存儲的名稱節點，配置為HA結構，使兩臺服務器互為熱備，并且實現主從復制；從設備提供讀功能；心跳代理監控主從之間的狀態。之后，采購多臺大容量硬盤服務器作為圖片存儲節點，所有服務器之間采用萬兆以太網方式連接。

圖4 TFS整體架構圖

圖5 改進后效果圖

架構確定以后，我們針對分布式存儲系統進行了優化，包括：Cache管理優化、小文件合并存儲、元數據管理優化等。另外，對于圖片存儲服務器和圖片存儲節點，我們還要對操作系統進行優化，例如修改I/O調度算法為DeadLine方式；修改BDP(Bandwidth Delay Product，帶寬和延遲的乘積)大小，以擴大TCP Socket緩沖區大小；調大TCP滑動窗口；調整TCP Socket創建和保持參數等。

經過這些改進，聯通集團電子商城系統性能有了大幅提升。傳統存儲系統中從查詢請求發起到接收到最終結果，會有3～5秒左右的延遲，在我們的分布式存儲系統中，這一時間被控制在了1秒以內，業務人員實際體驗較好。

5 結束語

中國聯通分布式存儲系統的建設，對集團內部海量小文件應用系統建設起到了指導作用，在數據存儲、數據處理、數據傳輸等方面提高了效率。為聯通邁向大數據時代奠定了基礎。

參考文獻

[1]楊傳輝.大規模分布式存儲系統：原理解析與架構實戰[M].北京：機械工業出版社,2013

[2]劉愛貴.GlusterFS分布式文件系統[EB/OL].(2014-12-27)[2016-07-15]. http：//vdisk.weibo.com/s/HPecIjqX8sc

[3]李其力.適配海量小文件的分布式文件系統關鍵技術研究及系統實現[EB/OL].[2016-07-15].http：//cdmd.cnki.com.cn/Article/CDMD-10561-1015987694.htm

[4]王鈴惠,李小勇,張軼彬.海量小文件存儲系統研究綜述[J].計算機應用及軟件,2012,29(8)：106-109

[5]阿里云Code[EB/OL].(2011-09-29)[2016-07-15].http：//code.tobao.org/p/tfs/wiki/intro/