首頁公司簡介公司動態產品介紹客戶留言網上訂單人才招聘聯繫我們
公司動態  

分布式文件系統元數據服務模型方案

發佈時間:2012-8-14

随着非結構化數據的爆炸,分布式文件系統進入了發展的黃金時期,從高性能計算到數據中心,從數據共享到互聯網應用,已經滲透到數據應用的各方各面。對于大多數分布式文件系統(或集群文件系統,或并行文件系統)而言,通常将元數據與數據兩者獨立開來,即控制流與數據流進行分離,從而獲得更高的系統擴展性和I/O并發性。因而,元數據管理模型顯得至關重要,直接影響到系統的擴展性、性能、可靠性和穩定性等。存儲系統要具有很高的Scale-Out特性,最大的挑戰之一就是記錄數據邏輯與物理位置的映像關系即數據元數據,還包括諸如屬性和訪問權限等信息。特别是對于海量小文件的應用,元數據問題是個非常大的挑戰。總體來說,分布式文件系統的元數據管理方式大緻可以分爲三種模型,即集中式元數據服務模型、分布式元數據服務模型和無元數據服務模型。在學術界和工業界,這三種模型一直存在争議,各有優勢和不足之處,實際系統實現中也難分優劣。實際上,設計出一個能夠适用各種數據應用負載的通用分布式文件系統,這種想法本來就是不現實的。從這個意義上看,這三種元數據服務模型都有各自存在的理由,至少是在它适用的數據存儲應用領域之内。

 

 

集中式元數據服務模型

分布式文件系統中,數據和I/O訪問負載被分散到多個物理獨立的存儲和計算節點,從而實現系統的高擴展性和高性能。對于一組文件,如果以文件爲單位進行調度,則不同的文件會存儲在不同的節點上;或者以Stripe方式進行存儲,則一個文件會分成多個部分存放在多個節點。顯然,我們面臨的一個關鍵問題就是如何确保對數據進行正确定位和訪問,元數據服務正是用來解決這個問題的。元數據服務記錄數據邏輯名字與物理信息的映射關系,包含文件訪問控制所需要的所有元數據,對文件進行訪問時,先向元數據服務請求查詢對應的元數據,然後通過獲得的元數據進行後續的文件讀寫等I/O操作。

 

出于簡化系統設計複雜性的考慮,并且由于大量的曆史遺留系統等原因,大多數分布式文件系統采用了集中式的元數據服務,如Lustre, PVFS, StorNext, GFS等。集中式元數據服務模型,通常提供一個中央元數據服務器負責元數據的存儲和客戶端查詢請求,它提供統一的文件系統命名空間,并處理名字解析和數據定位等訪問控制功能。傳統的NAS系統中,I/O數據流需要經過服務器,而分布式文件系統中,I/O數據流不需要經過元數據服務器,由客戶端與存儲節點直接交互。這個架構上的變革,使得控制流與數據流分離開來,元數據服務器和存儲服務器各司其職,系統擴展性和性能上獲得了極大的提升。顯而易見,集中式元數據服務模型的最大優點就是設計實現簡單,本質上相當于設計一個單機應用程序,對外提供網絡訪問接口即可,如Socket, RPC, HTTP REST或SOAP等。元數據服務設計實現的關鍵是OPS吞吐量,即單位時間處理的操作數,這對集中式元數據服務模型尤其關鍵,因爲會受到系統Scale-Up方面的限制。爲了優化OPS,該模型對CPU、内存、磁盤要求較高,條件允許的情況下盡量使用高性能CPU、大内存和高速磁盤,甚至後端存儲可考慮使用高端磁盤陣列或SSD。在軟件架構方面設計,應該考慮多進程/線程(池)、異步通信、Cache、事件驅動等實現機制。至于分布式文件系統名字空間的設計實現,請參考“分布式文件系統名字空間實現研究”一文,這裏不再讨論。實際上,集中式元數據服務模型的缺點同樣突出,其中兩個最爲關鍵的是性能瓶頸和單點故障問題。

 

性能瓶頸,這種模型下元數據服務器在負載不斷增大時将很快成爲整個系統性能的瓶頸。根據Amdahl定律,系統性能加速比最終受制于串行部分的比重,這決定了系統使用并行手段所能改進性能的潛力。這裏,元數據服務器就是串行的部分,它直接決定着系統的擴展規模和性能。文件元數據的基本特性要求它必須同步地進行維護和更新,任何時候對文件數據或元數據進行操作時,都需要同步更新元數據。例如,文件的訪問時間,即使是讀操作或列目錄都需要對它進行更新。客戶端訪問分布式文件系統時,都需要先與元數據服務器進行交互,這包括命名空間解析、數據定位、訪問控制等,然後才直接與存儲節點進行I/O交互。随着系統規模不斷擴大,存儲節點、磁盤數量、文件數量、客戶端數據、文件操作數量等都将急劇增加,而運行元數據服務器的物理服務器性能畢竟終究有限,因此集中式元數據服務器将最終成爲性能瓶頸。對于衆所周知的LOSF(Lots of Small Files)應用,文件數量衆多而且文件很小,通常都是幾KB至幾十KB的小文件,比如CDN和生命科學DNA數據應用,集中式元數據服務模型的性能瓶頸問題更加嚴重。LOSF應用主要是大量的元數據操作,元數據服務器一旦出現性能問題,直接導緻極低的OPS和I/O吞吐量。目前,以這種模型實現的分布式文件系統都不适合LOSF應用,比如Lustre, PVFS, GFS。

 

實際上,性能瓶頸問題沒有想像中的那麽嚴重,Lustre, StorNext, GFS等在大文件應用下性能極高,StorNext甚至在小文件應該下性能也表現良好。一方面,首先應該盡量避免應用于LOSF,除非對性能要求極低。其次,對于大文件應用,更加強調I/O數據吞吐量,元數據操作所占比例非常小。文件很大時,元數據數量将顯著降低,而且系統更多時間是在進行數據傳輸,元數據服務器壓力大幅下降。這種情形下,基本上不存在性能瓶頸問題了。再者,如果出現性能瓶頸問題,在系統可以承載的最大負載前提下,可以對元數據服務器進行性能優化。優化最爲直接的方法是升級硬件,比如CPU、内存、存儲、網絡,摩爾定律目前仍然是有效的。系統級優化通常也是有效的,包括OS裁剪和參數優化,這方面有很大提升空間。元數據服務器設計本身的優化才是最爲關鍵的,它可以幫助用戶節約成本、簡化維護和管理,優化的方法主要包括數據局部性、Cache、異步I/O等,旨在提高并發性、減少磁盤I/O訪問、降低請求處理時間。因此,在非常多的數據應用下,集中式元數據服務器的性能并不是大問題,或者通過性能優化可以解決的。

 

單點故障(SPOF,Single Point of Failure),這個問題看上去要比性能瓶頸更加嚴重。整個系統嚴重依賴于元數據服務器,一旦出現問題,系統将變得完全不可用,直接導緻應用 中斷并影響業務連續性。物理服務器所涉及的網絡、計算和存儲部件以及軟件都有可能發生故障,因此單點故障問題潛在的,采用更優的硬件和軟件隻能降低發生的概率而無法避免。目前,SPOF問題主要是采用HA機制來解決,根據可用性要求的高低,鏡像一個或多個元數據服務器(邏輯的或物理的均可),構成一個元數據服務HA集群。集群中一台作爲主元數據服務器,接受和處理來自客戶端的請求,并與其他服務器保持同步。當主元數據服務器發生問題時,自動選擇一台可用服務器作爲新的主服務器,這一過程對上層應用是透明的,不會産生業務中斷。HA機制能夠解決SPOF問題,但同時增加了成本開銷,隻有主服務器是活動的,其他服務器均處于非活動狀态,對性能提升沒有任何幫助。

 

分布式元數據服務模型

自然地有人提出了分布式元數據服務模型,顧名思義就是使用多台服務器構成集群協同爲分布式文件系統提供元數據服務,從而消除集中式元數據服務模型的性能瓶頸和單點故障問題。這種模型可以細分爲兩類,一爲全對等模式,即集群中的每個元數據服務器是完全對等的,每個都可以獨立對外提供元數據服務,然後集群内部進行元數據同步,保持數據一緻性,比如ISILON、LoongStore、CZSS等。另一類爲全分布模式,集群中的每個元數據服務器負責部分元數據服務(分區可以重疊),共同構成完整的元數據服務,比如PanFS, GPFS, Ceph等。分布式元數據服務模型,将負載分散到多台服務器解決了性能瓶頸問題,利用對等的服務器或冗餘元數據服務分區解決了單點故障問題。分布式看似非常完善,然而它大大增加了設計實現上的複雜性,同時可能會引入了新的問題,即性能開銷和數據一緻性問題。

 

性能開銷,分布式系統通常會引由于節點之間的數據同步而引入額外開銷,這是因爲同步過程中需要使用各種鎖和同步機制,以保證數據一緻性。如果節點同步問題處理不當,性能開銷将對系統擴展性和性能産生較大影響,和集中式元數據模型一樣形成性能瓶頸,這就對分布式元數據服務器的設計提出了更高的要求。這種性能開銷會抵消一部分采用分布式所帶來的性能提升,而且随着元數據服務器數量、文件數量、文件操作、存儲系統規模、磁盤數量、文件大小變小、I/O操作随機性等增加而加劇。另外,元數據服務器規模較大時,高并發性元數據訪問會導緻同步性能開銷更加顯著。目前,一些分布式文件系統采用高性能網絡(如InfiniBand, GibE等)、SSD固态硬盤或SAN磁盤陣列、分布式共享内存(SMP或ccNUMA)等技術進行集群内部的元數據同步和通信。這的确可以明顯提高系統性能以抵消同步開銷,不過成本方面也徒然增加許多。

 

數據一緻性,這是分布式系統必須面對的難題。分布式元數據服務模型同樣面臨潛在的系統發生錯誤的風險,雖然一部分元數據節點發生故障不會緻使整個系統宕機,但卻可能影響整個系統正常運行或出現訪問錯誤。爲了保證高可用性,元數據會被複制到多個節點位置,維護多個副本之間的同步具有很高的風險。如果元數據沒有及時同步或者遭受意外破壞,同一個文件的元數據就會出現不一緻,從而導緻訪問文件數據的不一緻,直接影響到上層數據應用的正确性。這種風險發生的概率随着系統規模的擴大而大幅增加,因此分布式元數據的同步和并發訪問是個巨大的挑戰。使用同步方法對元數據進行同步,再結合事務或日志,自然可以解決數據一緻性問題,然而這大大降低了系統的并發性,違背了分布式系統的設計初衷。在保證元數據一緻性的前提下,盡可能地提高并發性,這就對同步機制和算法設計方面提出了嚴格要求,複雜性和挑戰性不言而喻。

 

無元數據服務模型

既然集中式或分布式元數據服務模型都不能徹底地解決問題,那麽直接去掉元數據服務器,是否就可以避免這些問題呢?理論上,無元數據服務模型是完全可行的,尋找到元數據查詢定位的替代方法即可。理想情況下,這種模型消除了元數據的性能瓶頸、單點故障、數據一緻性等一系列相關問題,系統擴展性顯著提高,系統并發性和性能将實現線性擴展增長。目前,基于無元數據服務模型的分布式文件系統可謂鳳毛麟角,Glusterfs是其中最爲典型的代表。

 

對于分布式系統而言,元數據處理是決定系統擴展性、性能以及穩定性的關鍵。GlusterFS另辟蹊徑,徹底摒棄了元數據服務,使用彈性哈希算法代替傳統分布式文件系統中的集中或分布式元數據服務。這根本性解決了元數據這一難題,從而獲得了接近線性的高擴展性,同時也提高了系統性能和可靠性。GlusterFS使用算法進行數據定位,集群中的任何服務器和客戶端隻需根據路徑和文件名就可以對數據進行定位和讀寫訪問。換句話說,GlusterFS不需要将元數據與數據進行分離,因爲文件定位可獨立并行化進行。GlusterFS獨特地采用無元數據服務的設計,取而代之使用算法來定位文件,元數據和數據沒有分離而是一起存儲。集群中的所有存儲系統服務器都可以智能地對文件數據分片進行定位,僅僅根據文件名和路徑并運用算法即可,而不需要查詢索引或者其他服務器。這使得數據訪問完全并行化,從而實現真正的線性性能擴展。無元數據服務器極大提高了GlusterFS的性能、可靠性和穩定性。(Glusterfs更深入地分析請參考“Glusterfs集群文件系統研究”一文)。

 

無元數據服務器設計的好處是沒有單點故障和性能瓶頸問題,可提高系統擴展性、性能、可靠性和穩定性。對于海量小文件應用,這種設計能夠有效解決元數據的難點問題。它的負面影響是,數據一緻問題更加複雜,文件目錄遍曆操作效率低下,缺乏全局監控管理功能。同時也導緻客戶端承擔了更多的職能,比如文件定位、名字空間緩存、邏輯卷視圖維護等等,這些都增加了客戶端的負載,占用相當的CPU和内存。

 

三種元數據服務模型比較

對Scale-Out存儲系統而言,最大的挑戰之一就是記錄數據邏輯與物理位置的映像關系,即數據元數據。傳統分布式存儲系統使用集中式或布式元數據服務來維護元數據,集中式元數據服務會導緻單點故障和性能瓶頸問題,而分布式元數據服務存在性能開銷、元數據同步一緻性和設計複雜性等問題。無元數據服務模型,消除了元數據訪問問題,但同時增加了數據本身管理的複雜性,缺乏全局監控管理功能,并增加了客戶端的負載。由此可見,這三種模型都不是完美的,分别有各自的優點和不足,沒有絕對的優劣與好壞之分,實際選型要根據具體情況選擇合适的模型,并想方設法完善其不足之處,從而提高分布式文件系統的擴展性、高性能、可用性等特性。集中式元數據服務模型的代表是Lustre, StorNext, GFS等,分布式元數據服務模型的典型案例有ISILON, GPFS, Ceph等,Glustrefs是無元數據服務模型的經典。以上這些都是非常強大的分布式文件系統,它們是非常好的設計典範。這也足以說明,架構固然非常關鍵,但具體實現技術卻往往決定最後的結局。

 

補充閱讀

[1] Ceph, http://www.ibm.com/developerworks/cn/linux/l-ceph/index.html?ca=drs-

[2] Glusterfs, http://blog.csdn.net/liuben/article/details/6284551

[3] 集群NAS技術架構,http://blog.csdn.net/liuben/article/details/6422700

 




【返回】

首頁 » 公司動態 »
»
»
WAPMobile