分布式文件系統(tǒng)元數據服務模型方案
發(fā)布時間:2012-8-14隨著非結構化數據的爆炸，分布式文件系統(tǒng)進入了發(fā)展的黃金時期，從高性能計算到數據中心，從數據共享到互聯(lián)網應用，已經滲透到數據應用的各方各面。對于大多數分布式文件系統(tǒng)(或集群文件系統(tǒng)，或并行文件系統(tǒng))而言，通常將元數據與數據兩者獨立開來，即控制流與數據流進行分離，從而獲得更高的系統(tǒng)擴展性和I/O并發(fā)性。因而，元數據管理模型顯得至關重要，直接影響到系統(tǒng)的擴展性、性能、可靠性和穩(wěn)定性等。存儲系統(tǒng)要具有很高的Scale-Out特性，最大的挑戰(zhàn)之一就是記錄數據邏輯與物理位置的映像關系即數據元數據，還包括諸如屬性和訪問權限等信息。特別是對于海量小文件的應用，元數據問題是個非常大的挑戰(zhàn)�？傮w來說，分布式文件系統(tǒng)的元數據管理方式大致可以分為三種模型，即集中式元數據服務模型、分布式元數據服務模型和無元數據服務模型。在學術界和工業(yè)界，這三種模型一直存在爭議，各有優(yōu)勢和不足之處，實際系統(tǒng)實現中也難分優(yōu)劣。實際上，設計出一個能夠適用各種數據應用負載的通用分布式文件系統(tǒng)，這種想法本來就是不現實的。從這個意義上看，這三種元數據服務模型都有各自存在的理由，至少是在它適用的數據存儲應用領域之內。
集中式元數據服務模型
分布式文件系統(tǒng)中，數據和I/O訪問負載被分散到多個物理獨立的存儲和計算節(jié)點，從而實現系統(tǒng)的高擴展性和高性能。對于一組文件，如果以文件為單位進行調度，則不同的文件會存儲在不同的節(jié)點上；或者以Stripe方式進行存儲，則一個文件會分成多個部分存放在多個節(jié)點。顯然，我們面臨的一個關鍵問題就是如何確保對數據進行正確定位和訪問，元數據服務正是用來解決這個問題的。元數據服務記錄數據邏輯名字與物理信息的映射關系，包含文件訪問控制所需要的所有元數據，對文件進行訪問時，先向元數據服務請求查詢對應的元數據，然后通過獲得的元數據進行后續(xù)的文件讀寫等I/O操作。
出于簡化系統(tǒng)設計復雜性的考慮，并且由于大量的歷史遺留系統(tǒng)等原因，大多數分布式文件系統(tǒng)采用了集中式的元數據服務，如Lustre, PVFS, StorNext, GFS等。集中式元數據服務模型，通常提供一個中央元數據服務器負責元數據的存儲和客戶端查詢請求，它提供統(tǒng)一的文件系統(tǒng)命名空間，并處理名字解析和數據定位等訪問控制功能。傳統(tǒng)的NAS系統(tǒng)中，I/O數據流需要經過服務器，而分布式文件系統(tǒng)中，I/O數據流不需要經過元數據服務器，由客戶端與存儲節(jié)點直接交互。這個架構上的變革，使得控制流與數據流分離開來，元數據服務器和存儲服務器各司其職，系統(tǒng)擴展性和性能上獲得了極大的提升。顯而易見，集中式元數據服務模型的最大優(yōu)點就是設計實現簡單，本質上相當于設計一個單機應用程序，對外提供網絡訪問接口即可，如Socket, RPC, HTTP REST或SOAP等。元數據服務設計實現的關鍵是OPS吞吐量，即單位時間處理的操作數，這對集中式元數據服務模型尤其關鍵，因為會受到系統(tǒng)Scale-Up方面的限制。為了優(yōu)化OPS，該模型對CPU、內存、磁盤要求較高，條件允許的情況下盡量使用高性能CPU、大內存和高速磁盤，甚至后端存儲可考慮使用高端磁盤陣列或SSD。在軟件架構方面設計，應該考慮多進程/線程(池)、異步通信、Cache、事件驅動等實現機制。至于分布式文件系統(tǒng)名字空間的設計實現，請參考“分布式文件系統(tǒng)名字空間實現研究”一文，這里不再討論。實際上，集中式元數據服務模型的缺點同樣突出，其中兩個最為關鍵的是性能瓶頸和單點故障問題。
性能瓶頸，這種模型下元數據服務器在負載不斷增大時將很快成為整個系統(tǒng)性能的瓶頸。根據Amdahl定律，系統(tǒng)性能加速比最終受制于串行部分的比重，這決定了系統(tǒng)使用并行手段所能改進性能的潛力。這里，元數據服務器就是串行的部分，它直接決定著系統(tǒng)的擴展規(guī)模和性能。文件元數據的基本特性要求它必須同步地進行維護和更新，任何時候對文件數據或元數據進行操作時，都需要同步更新元數據。例如，文件的訪問時間，即使是讀操作或列目錄都需要對它進行更新�？蛻舳嗽L問分布式文件系統(tǒng)時，都需要先與元數據服務器進行交互，這包括命名空間解析、數據定位、訪問控制等，然后才直接與存儲節(jié)點進行I/O交互。隨著系統(tǒng)規(guī)模不斷擴大，存儲節(jié)點、磁盤數量、文件數量、客戶端數據、文件操作數量等都將急劇增加，而運行元數據服務器的物理服務器性能畢竟終究有限，因此集中式元數據服務器將最終成為性能瓶頸。對于眾所周知的LOSF(Lots of Small Files)應用，文件數量眾多而且文件很小，通常都是幾KB至幾十KB的小文件，比如CDN和生命科學DNA數據應用，集中式元數據服務模型的性能瓶頸問題更加嚴重。LOSF應用主要是大量的元數據操作，元數據服務器一旦出現性能問題，直接導致極低的OPS和I/O吞吐量。目前，以這種模型實現的分布式文件系統(tǒng)都不適合LOSF應用，比如Lustre, PVFS, GFS。
實際上，性能瓶頸問題沒有想像中的那么嚴重，Lustre, StorNext, GFS等在大文件應用下性能極高，StorNext甚至在小文件應該下性能也表現良好。一方面，首先應該盡量避免應用于LOSF，除非對性能要求極低。其次，對于大文件應用，更加強調I/O數據吞吐量，元數據操作所占比例非常小。文件很大時，元數據數量將顯著降低，而且系統(tǒng)更多時間是在進行數據傳輸，元數據服務器壓力大幅下降。這種情形下，基本上不存在性能瓶頸問題了。再者，如果出現性能瓶頸問題，在系統(tǒng)可以承載的最大負載前提下，可以對元數據服務器進行性能優(yōu)化。優(yōu)化最為直接的方法是升級硬件，比如CPU、內存、存儲、網絡，摩爾定律目前仍然是有效的。系統(tǒng)級優(yōu)化通常也是有效的，包括OS裁剪和參數優(yōu)化，這方面有很大提升空間。元數據服務器設計本身的優(yōu)化才是最為關鍵的，它可以幫助用戶節(jié)約成本、簡化維護和管理，優(yōu)化的方法主要包括數據局部性、Cache、異步I/O等，旨在提高并發(fā)性、減少磁盤I/O訪問、降低請求處理時間。因此，在非常多的數據應用下，集中式元數據服務器的性能并不是大問題，或者通過性能優(yōu)化可以解決的。
單點故障(SPOF，Single Point of Failure)，這個問題看上去要比性能瓶頸更加嚴重。整個系統(tǒng)嚴重依賴于元數據服務器，一旦出現問題，系統(tǒng)將變得完全不可用，直接導致應用 中斷并影響業(yè)務連續(xù)性。物理服務器所涉及的網絡、計算和存儲部件以及軟件都有可能發(fā)生故障，因此單點故障問題潛在的，采用更優(yōu)的硬件和軟件只能降低發(fā)生的概率而無法避免。目前，SPOF問題主要是采用HA機制來解決，根據可用性要求的高低，鏡像一個或多個元數據服務器(邏輯的或物理的均可)，構成一個元數據服務HA集群。集群中一臺作為主元數據服務器，接受和處理來自客戶端的請求，并與其他服務器保持同步。當主元數據服務器發(fā)生問題時，自動選擇一臺可用服務器作為新的主服務器，這一過程對上層應用是透明的，不會產生業(yè)務中斷。HA機制能夠解決SPOF問題，但同時增加了成本開銷，只有主服務器是活動的，其他服務器均處于非活動狀態(tài)，對性能提升沒有任何幫助。
分布式元數據服務模型
自然地有人提出了分布式元數據服務模型，顧名思義就是使用多臺服務器構成集群協(xié)同為分布式文件系統(tǒng)提供元數據服務，從而消除集中式元數據服務模型的性能瓶頸和單點故障問題。這種模型可以細分為兩類，一為全對等模式，即集群中的每個元數據服務器是完全對等的，每個都可以獨立對外提供元數據服務，然后集群內部進行元數據同步，保持數據一致性，比如ISILON、LoongStore、CZSS等。另一類為全分布模式，集群中的每個元數據服務器負責部分元數據服務(分區(qū)可以重疊)，共同構成完整的元數據服務，比如PanFS, GPFS, Ceph等。分布式元數據服務模型，將負載分散到多臺服務器解決了性能瓶頸問題，利用對等的服務器或冗余元數據服務分區(qū)解決了單點故障問題。分布式看似非常完善，然而它大大增加了設計實現上的復雜性，同時可能會引入了新的問題，即性能開銷和數據一致性問題。
性能開銷，分布式系統(tǒng)通常會引由于節(jié)點之間的數據同步而引入額外開銷，這是因為同步過程中需要使用各種鎖和同步機制，以保證數據一致性。如果節(jié)點同步問題處理不當，性能開銷將對系統(tǒng)擴展性和性能產生較大影響，和集中式元數據模型一樣形成性能瓶頸，這就對分布式元數據服務器的設計提出了更高的要求。這種性能開銷會抵消一部分采用分布式所帶來的性能提升，而且隨著元數據服務器數量、文件數量、文件操作、存儲系統(tǒng)規(guī)模、磁盤數量、文件大小變小、I/O操作隨機性等增加而加劇。另外，元數據服務器規(guī)模較大時，高并發(fā)性元數據訪問會導致同步性能開銷更加顯著。目前，一些分布式文件系統(tǒng)采用高性能網絡(如InfiniBand, GibE等)、SSD固態(tài)硬盤或SAN磁盤陣列、分布式共享內存(SMP或ccNUMA)等技術進行集群內部的元數據同步和通信。這的確可以明顯提高系統(tǒng)性能以抵消同步開銷，不過成本方面也徒然增加許多。
數據一致性，這是分布式系統(tǒng)必須面對的難題。分布式元數據服務模型同樣面臨潛在的系統(tǒng)發(fā)生錯誤的風險，雖然一部分元數據節(jié)點發(fā)生故障不會致使整個系統(tǒng)宕機，但卻可能影響整個系統(tǒng)正常運行或出現訪問錯誤。為了保證高可用性，元數據會被復制到多個節(jié)點位置，維護多個副本之間的同步具有很高的風險。如果元數據沒有及時同步或者遭受意外破壞，同一個文件的元數據就會出現不一致，從而導致訪問文件數據的不一致，直接影響到上層數據應用的正確性。這種風險發(fā)生的概率隨著系統(tǒng)規(guī)模的擴大而大幅增加，因此分布式元數據的同步和并發(fā)訪問是個巨大的挑戰(zhàn)。使用同步方法對元數據進行同步，再結合事務或日志，自然可以解決數據一致性問題，然而這大大降低了系統(tǒng)的并發(fā)性，違背了分布式系統(tǒng)的設計初衷。在保證元數據一致性的前提下，盡可能地提高并發(fā)性，這就對同步機制和算法設計方面提出了嚴格要求，復雜性和挑戰(zhàn)性不言而喻。
無元數據服務模型
既然集中式或分布式元數據服務模型都不能徹底地解決問題，那么直接去掉元數據服務器，是否就可以避免這些問題呢？理論上，無元數據服務模型是完全可行的，尋找到元數據查詢定位的替代方法即可。理想情況下，這種模型消除了元數據的性能瓶頸、單點故障、數據一致性等一系列相關問題，系統(tǒng)擴展性顯著提高，系統(tǒng)并發(fā)性和性能將實現線性擴展增長。目前，基于無元數據服務模型的分布式文件系統(tǒng)可謂鳳毛麟角，Glusterfs是其中最為典型的代表。
對于分布式系統(tǒng)而言，元數據處理是決定系統(tǒng)擴展性、性能以及穩(wěn)定性的關鍵。GlusterFS另辟蹊徑，徹底摒棄了元數據服務，使用彈性哈希算法代替?zhèn)鹘y(tǒng)分布式文件系統(tǒng)中的集中或分布式元數據服務。這根本性解決了元數據這一難題，從而獲得了接近線性的高擴展性，同時也提高了系統(tǒng)性能和可靠性。GlusterFS使用算法進行數據定位，集群中的任何服務器和客戶端只需根據路徑和文件名就可以對數據進行定位和讀寫訪問。換句話說，GlusterFS不需要將元數據與數據進行分離，因為文件定位可獨立并行化進行。GlusterFS獨特地采用無元數據服務的設計，取而代之使用算法來定位文件，元數據和數據沒有分離而是一起存儲。集群中的所有存儲系統(tǒng)服務器都可以智能地對文件數據分片進行定位，僅僅根據文件名和路徑并運用算法即可，而不需要查詢索引或者其他服務器。這使得數據訪問完全并行化，從而實現真正的線性性能擴展。無元數據服務器極大提高了GlusterFS的性能、可靠性和穩(wěn)定性。(Glusterfs更深入地分析請參考“Glusterfs集群文件系統(tǒng)研究”一文)。
無元數據服務器設計的好處是沒有單點故障和性能瓶頸問題，可提高系統(tǒng)擴展性、性能、可靠性和穩(wěn)定性。對于海量小文件應用，這種設計能夠有效解決元數據的難點問題。它的負面影響是，數據一致問題更加復雜，文件目錄遍歷操作效率低下，缺乏全局監(jiān)控管理功能。同時也導致客戶端承擔了更多的職能，比如文件定位、名字空間緩存、邏輯卷視圖維護等等，這些都增加了客戶端的負載，占用相當的CPU和內存。
三種元數據服務模型比較
對Scale-Out存儲系統(tǒng)而言，最大的挑戰(zhàn)之一就是記錄數據邏輯與物理位置的映像關系，即數據元數據。傳統(tǒng)分布式存儲系統(tǒng)使用集中式或布式元數據服務來維護元數據，集中式元數據服務會導致單點故障和性能瓶頸問題，而分布式元數據服務存在性能開銷、元數據同步一致性和設計復雜性等問題。無元數據服務模型，消除了元數據訪問問題，但同時增加了數據本身管理的復雜性，缺乏全局監(jiān)控管理功能，并增加了客戶端的負載。由此可見，這三種模型都不是完美的，分別有各自的優(yōu)點和不足，沒有絕對的優(yōu)劣與好壞之分，實際選型要根據具體情況選擇合適的模型，并想方設法完善其不足之處，從而提高分布式文件系統(tǒng)的擴展性、高性能、可用性等特性。集中式元數據服務模型的代表是Lustre, StorNext, GFS等，分布式元數據服務模型的典型案例有ISILON, GPFS, Ceph等，Glustrefs是無元數據服務模型的經典。以上這些都是非常強大的分布式文件系統(tǒng)，它們是非常好的設計典范。這也足以說明，架構固然非常關鍵，但具體實現技術卻往往決定最后的結局。
補充閱讀
[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
【返回】
