歡迎光臨
每天分享高質量文章

分佈式檔案系統設計,該從哪些方面考慮?

一、概述

分佈式檔案系統是分佈式領域的一個基礎應用,其中最著名的毫無疑問是 HDFS/GFS。如今該領域已經趨向於成熟,但瞭解它的設計要點和思想,對我們將來面臨類似場景 / 問題時,具有借鑒意義。並且,分佈式檔案系統並非只有 HDFS/GFS 這一種形態,在它之外,還有其他形態各異、各有千秋的產品形態,對它們的瞭解,也對擴展我們的視野有所俾益。本文試圖分析和思考,在分佈式檔案系統領域,我們要解決哪些問題、有些什麼樣的方案、以及各自的選擇依據。

二、過去的樣子

在幾十年以前,分佈式檔案系統就已經出現了,以 Sun 在 1984 年開發的“Network File System (NFS)”為代表,那時候解決的主要問題,是網絡形態的磁盤,把磁盤從主機中獨立出來。這樣不僅可以獲得更大的容量,而且還可以隨時切換主機,還可以實現資料共享、備份、容災等,因為資料是電腦中最重要的資產。NFS 的資料通信圖如下。

部署在主機上的客戶端,通過 TCP/IP 協議把檔案命令轉發到遠程檔案 Server 上執行,整個過程對主機用戶透明。

到了互聯網時代,流量和資料快速增長,分佈式檔案系統所要解決的主要場景變了,開始需要非常大的磁盤空間,這在磁盤體繫上垂直擴容是無法達到的,必須要分佈式,同時分佈式架構下,主機都是可靠性不是非常好的普通服務器,因此容錯、高可用、持久化、伸縮性等指標,就成為必須要考量的特性。

三、對分佈式檔案系統的要求

對一個分佈式檔案系統而言,有一些特性是必須要滿足的,否則就無法有競爭力。主要如下:

  • 應該符合 POSIX 的檔案接口標準,使該系統易於使用,同時對於用戶的遺留系統也無需改造;

  • 對用戶透明,能夠像使用本地檔案系統那樣直接使用;

  • 持久化,保證資料不會丟失;

  • 具有伸縮性,當資料壓力逐漸增長時能順利擴容;

  • 具有可靠的安全機制,保證資料安全;

  • 資料一致性,只要檔案內容不發生變化,什麼時候去讀,得到的內容應該都是一樣的。

除此之外,還有些特性是分佈式加分項,具體如下:

  • 支持的空間越大越好;

  • 支持的併發訪問請求越多越好;

  • 性能越快越好;

  • 硬體資源的利用率越高越合理,就越好。

四、架構模型

從業務模型和邏輯架構上,分佈式檔案系統需要這幾類組件:

  • 儲存組件:負責儲存檔案資料,它要保證檔案的持久化、副本間資料一致、資料塊的分配 / 合併等等;

  • 管理組件:負責 meta 信息,即檔案資料的元信息,包括檔案存放在哪台服務器上、檔案大小、權限等,除此之外,還要負責對儲存組件的管理,包括儲存組件所在的服務器是否正常存活、是否需要資料遷移等;

  • 接口組件:提供接口服務給應用使用,形態包括 SDK(Java/C/C++ 等)、CLI 命令列終端、以及支持 FUSE 掛載機制。

而在部署架構上,有著“中心化”和“無中心化”兩種路線分歧,即是否把“管理組件”作為分佈式檔案系統的中心管理節點。兩種路線都有很優秀的產品,下麵分別介紹它們的區別。

有中心節點

以 GFS 為代表,中心節點負責檔案定位、維護檔案 meta 信息、故障檢測、資料遷移等管理控制的職能,下圖是 GFS 的架構圖。

該圖中 GFS master 即為 GFS 的中心節點,GF chunkserver 為 GFS 的儲存節點。其操作路徑如下:

  • Client 向中心節點請求“查詢某個檔案的某部分資料”;

  • 中心節點傳回檔案所在的位置 (哪台 chunkserver 上的哪個檔案) 以及位元組區間信息;

  • Client 根據中心節點傳回的信息,向對應的 chunk server 直接發送資料讀取的請求;

  • chunk server 傳回資料。

在這種方案里,一般中心節點並不參與真正的資料讀寫,而是將檔案 meta 信息傳回給 Client 之後,即由 Client 與資料節點直接通信。其主要目的是降低中心節點的負載,防止其成為瓶頸。這種有中心節點的方案,在各種儲存類系統中得到了廣泛應用,因為中心節點易控制、功能強大。

無中心節點

以 ceph 為代表,每個節點都是自治的、自管理的,整個 ceph 集群只包含一類節點,如下圖 (最下層紅色的 RADOS 就是 ceph 定義的“同時包含 meta 資料和檔案資料”的節點)。

無中心化的最大優點是解決了中心節點自身的瓶頸,這也就是 ceph 號稱可以無限向上擴容的原因。但由 Client 直接和 Server 通信,那麼 Client 必須要知道,當對某個檔案進行操作時,它該訪問集群中的哪個節點。ceph 提供了一個很強大的原創演算法來解決這個問題——CRUSH 演算法。

五、持久化

對於檔案系統來說,持久化是根本,只要 Client 收到了 Server 儲存成功的回應之後,資料就不應該丟失。這主要是通過多副本的方式來解決,但在分佈式環境下,多副本有這幾個問題要面對。

  • 如何保證每個副本的資料是一致的?

  • 如何分散副本,以使災難發生時,不至於所有副本都被損壞?

  • 怎麼檢測被損壞或資料過期的副本,以及如何處理?

  • 該傳回哪個副本給 Client?

如何保證每個副本的資料是一致的

同步寫入是保證副本資料一致的最直接的辦法。當 Client 寫入一個檔案的時候,Server 會等待所有副本都被成功寫入,再傳回給 Client。

這種方式簡單、有保障,唯一的缺陷就是性能會受到影響。假設有 3 個副本,如果每個副本需要 N 秒,則可能會阻塞 Client 3N 秒的時間,有幾種方式,可以對其進行優化:

  • 並行寫:由一個副本作為主副本,並行發送資料給其他副本;

  • 鏈式寫:幾個副本組成一個鏈 (chain),並不是等內容都接受到了再往後傳播,而是像流一樣,邊接收上游傳遞過來的資料,一邊傳遞給下游。

還有一種方式是採用 CAP 中所說的 W+R>N 的方式,比如 3 副本 (N=3) 的情況,W=2,R=2,即成功寫入 2 個就認為成功,讀的時候也要從 2 個副本中讀。這種方式通過犧牲一定的讀成本,來降低寫成本,同時增加寫入的可用性。這種方式在分佈式檔案系統中用地比較少。

如何分散副本,以使災難發生時,不至於所有副本都被損壞

這主要避免的是某機房或某城市發生自然環境故障的情況,所以有一個副本應該分配地比較遠。它的副作用是會帶來這個副本的寫入性能可能會有一定的下降,因為它離 Client 最遠。所以如果在物理條件上無法保證夠用的網絡帶寬的話,則讀寫副本的策略上需要做一定考慮。可以參考同步寫入只寫 2 副本、較遠副本異步寫入的方式,同時為了保證一致性,讀取的時候又要註意一些,避免讀取到異步寫入副本的過時資料。

怎麼檢測被損壞或資料過期的副本,以及如何處理

如果有中心節點,則資料節點定期和中心節點進行通信,彙報自己的資料塊的相關信息,中心節點將其與自己維護的信息進行對比。如果某個資料塊的 checksum 不對,則表明該資料塊被損壞了;如果某個資料塊的 version 不對,則表明該資料塊過期了。

如果沒有中心節點,以 ceph 為例,它在自己的節點集群中維護了一個比較小的 monitor 集群,資料節點向這個 monitor 集群彙報自己的情況,由其來判定是否被損壞或過期。

當發現被損壞或過期副本,將它從 meta 信息中移除,再重新創建一份新的副本就好了,移除的副本在隨後的回收機制中會被收回。

該傳回哪個副本給 Client

這裡的策略就比較多了,比如 round-robin、速度最快的節點、成功率最高的節點、CPU 資源最空閑的節點、甚至就固定選第一個作為主節點,也可以選擇離自己最近的一個,這樣對整體的操作完成時間會有一定節約。

六、伸縮性

儲存節點的伸縮

當在集群中加入一臺新的儲存節點,則它主動向中心節點註冊,提供自己的信息,當後續有創建檔案或者給已有檔案增加資料塊的時候,中心節點就可以分配到這台新節點了,比較簡單。但有一些問題需要考慮。

  • 如何儘量使各儲存節點的負載相對均衡?

  • 怎樣保證新加入的節點,不會因短期負載壓力過大而崩塌?

  • 如果需要資料遷移,那如何使其對業務層透明?

如何儘量使各儲存節點的負載相對均衡

首先要有評價儲存節點負載的指標。有多種方式,可以從磁盤空間使用率考慮,也可以從磁盤使用率 +CPU 使用情況 + 網絡流量情況等做綜合判斷。一般來說,磁盤使用率是核心指標。

其次在分配新空間的時候,優先選擇資源使用率小的儲存節點;而對已存在的儲存節點,如果負載已經過載、或者資源使用情況不均衡,則需要做資料遷移。

怎樣保證新加入的節點,不會因短期負載壓力過大而崩塌

當系統發現當前新加入了一臺儲存節點,顯然它的資源使用率是最低的,那麼所有的寫流量都路由到這台儲存節點來,那就可能造成這台新節點短期負載過大。因此,在資源分配的時候,需要有預熱時間,在一個時間段內,緩慢地將寫壓力路由過來,直到達成新的均衡。

如果需要資料遷移,那如何使其對業務層透明?

在有中心節點的情況下,這個工作比較好做,中心節點就包辦了——判斷哪台儲存節點壓力較大,判斷把哪些檔案遷移到何處,更新自己的 meta 信息,遷移過程中的寫入怎麼辦,發生重命名怎麼辦。無需上層應用來處理。

如果沒有中心節點,那代價比較大,在系統的整體設計上,也是要考慮到這種情況,比如 ceph,它要採取邏輯位置和物理位置兩層結構,對 Client 暴露的是邏輯層 (pool 和 place group),這個在遷移過程中是不變的,而下層物理層資料塊的移動,只是邏輯層所取用的物理塊的地址發生了變化,在 Client 看來,邏輯塊的位置並不會發生改變。

中心節點的伸縮

如果有中心節點,還要考慮它的伸縮性。由於中心節點作為控制中心,是主從樣式,那麼在伸縮性上就受到比較大的限制,是有上限的,不能超過單台物理機的規模。我們可以考慮各種手段,儘量地抬高這個上限。有幾種方式可以考慮:

以大資料塊的形式來儲存檔案——比如 HDFS 的資料塊的大小是 64M,ceph 的的資料塊的大小是 4M,都遠遠超過單機檔案系統的 4k。它的意義在於大幅減少 meta data 的數量,使中心節點的單機記憶體就能夠支持足夠多的磁盤空間 meta 信息。


中心節點採取多級的方式——頂級中心節點只儲存目錄的 meta data,其指定某目錄的檔案去哪台次級總控節點去找,然後再通過該次級總控節點找到檔案真正的儲存節點;


中心節點共享儲存設備——部署多臺中心節點,但它們共享同一個儲存外設 / 資料庫,meta 信息都放在這裡,中心節點自身是無狀態的。這種樣式下,中心節點的請求處理能力大為增強,但性能會受一定影響。iRODS 就是採用這種方式。

七、高可用性

中心節點的高可用

中心節點的高可用,不僅要保證自身應用的高可用,還得保證 meta data 的資料高可用。

meta data 的高可用主要是資料持久化,並且需要備份機制保證不丟。一般方法是增加一個從節點,主節點的資料實時同步到從節點上。也有採用共享磁盤,通過 raid1 的硬體資源來保障高可用。顯然增加從節點的主備方式更易於部署。

meta data 的資料持久化策略有以下幾種方式。

  • 直接儲存到儲存引擎上,一般是資料庫。直接以檔案形式儲存到磁盤上,也不是不可以,但因為 meta 信息是結構化資料,這樣相當於自己研發出一套小型資料庫來,複雜化了。

  • 儲存日誌資料到磁盤檔案 (類似 MySQL 的 binlog 或 Redis 的 aof),系統啟動時在記憶體中重建成結果資料,提供服務。修改時先修改磁盤日誌檔案,然後更新記憶體資料。這種方式簡單易用。

當前記憶體服務 + 日誌檔案持久化是主流方式。一是純記憶體操作,效率很高,日誌檔案的寫也是順序寫;二是不依賴外部組件,獨立部署。

為瞭解決日誌檔案會隨著時間增長越來越大的問題,以讓系統能以儘快啟動和恢復,需要輔助以記憶體快照的方式——定期將記憶體 dump 儲存,只保留在 dump 時刻之後的日誌檔案。這樣當恢復時,從最新一次的記憶體 dump 檔案開始,找其對應的 checkpoint 之後的日誌檔案開始重播。

儲存節點的高可用

在前面“持久化”章節,在保證資料副本不丟失的情況下,也就保證了其的高可用性。

八、性能優化和快取一致性

這些年隨著基礎設施的發展,局域網內千兆甚至萬兆的帶寬已經比較普遍,以萬兆計算,每秒傳輸大約 1250M 位元組的資料,而 SATA 磁盤的讀寫速度這些年基本達到瓶頸,在 300-500M/s 附近,也就是純讀寫的話,網絡已經超過了磁盤的能力,不再是瓶頸了,像 NAS 網絡磁盤這些年也開始普及起來。

但這並不代表,沒有必要對讀寫進行優化,畢竟網絡讀寫的速度還是遠慢於記憶體的讀寫。常見的優化方法主要有:

  • 記憶體中快取檔案內容;

  • 預加載資料塊,以避免客戶端等待;

  • 合併讀寫請求,也就是將單次請求做些積累,以批量方式發送給 Server 端。

快取的使用在提高讀寫性能的同時,也會帶來資料不一致的問題:

  • 會出現更新丟失的現象。當多個 Client 在一個時間段內,先後寫入同一個檔案時,先寫入的 Client 可能會丟失其寫入內容,因為可能會被後寫入的 Client 的內容改寫掉;

  • 資料可見性問題。Client 讀取的是自己的快取,在其過期之前,如果別的 Client 更新了檔案內容,它是看不到的;也就是說,在同一時間,不同 Client 讀取同一個檔案,內容可能不一致。

這類問題有幾種方法:

  • 檔案只讀不改:一旦檔案被 create 了,就只能讀不能修改。這樣 Client 端的快取,就不存在不一致的問題;

  • 通過鎖:用鎖的話還要考慮不同的粒度。寫的時候是否允許其他 Client 讀? 讀的時候是否允許其他 Client 寫? 這是在性能和一致性之間的權衡,作為檔案系統來說,由於對業務並沒有約束性,所以要做出合理的權衡,比較困難,因此最好是提供不同粒度的鎖,由業務端來選擇。但這樣的副作用是,業務端的使用成本抬高了。

九、安全性

由於分佈式檔案儲存系統,肯定是一個多客戶端使用、多租戶的一個產品,而它又儲存了可能是很重要的信息,所以安全性是它的重要部分。

主流檔案系統的權限模型有以下這麼幾種。

DAC: 全稱是 Discretionary Access Control,就是我們熟悉的 Unix 類權限框架,以 user-group-privilege 為三級體系,其中 user 就是 owner,group 包括 owner 所在 group 和非 owner 所在的 group、privilege 有 read、write 和 execute。這套體系主要是以 owner 為出發點,owner 允許誰對哪些檔案具有什麼樣的權限。

MAC: 全稱是 Mandatory Access Control,它是從資源的機密程度來劃分。比如分為“普通”、“機密”、“絕密”這三層,每個用戶可能對應不同的機密閱讀權限。這種權限體系起源於安全機構或軍隊的系統中,會比較常見。它的權限是由管理員來控制和設定的。Linux 中的 SELinux 就是 MAC 的一種實現,為了彌補 DAC 的缺陷和安全風險而提供出來。關於 SELinux 所解決的問題可以參考 What is SELinux?

RBAC: 全稱是 Role Based Access Control,是基於角色 (role) 建立的權限體系。角色擁有什麼樣的資源權限,用戶歸到哪個角色,這對應企業 / 公司的組織機構非常合適。RBAC 也可以具體化,就演變成 DAC 或 MAC 的權限模型。

市面上的分佈式檔案系統有不同的選擇,像 ceph 就提供了類似 DAC 但又略有區別的權限體系,Hadoop 自身就是依賴於操作系統的權限框架,同時其生態圈內有 Apache Sentry 提供了基於 RBAC 的權限體系來做補充。

十、其他

空間分配

有連續空間和鏈表空間兩種。連續空間的優勢是讀寫快,按順序即可,劣勢是造成磁盤碎片,更麻煩的是,隨著連續的大塊磁盤空間被分配滿而必須尋找空洞時,連續分配需要提前知道待寫入檔案的大小,以便找到合適大小的空間,而待寫入檔案的大小,往往又是無法提前知道的 (比如可編輯的 word 文件,它的內容可以隨時增大);

而鏈表空間的優勢是磁盤碎片很少,劣勢是讀寫很慢,尤其是隨機讀,要從鏈表首個檔案塊一個一個地往下找。

為瞭解決這個問題,出現了索引表——把檔案和資料塊的對應關係也儲存一份,存在索引節點中 (一般稱為 i 節點),操作系統會將 i 節點加載到記憶體,從而程式隨機尋找資料塊時,在記憶體中就可以完成了。通過這種方式來解決磁盤鏈表的劣勢,如果索引節點的內容太大,導致記憶體無法加載,還有可能形成多級索引結構。

檔案刪除

實時刪除還是延時刪除? 實時刪除的優勢是可以快速釋放磁盤空間;延時刪除只是在刪除動作執行的時候,置個標識位,後續在某個時間點再來批量刪除,它的優勢是檔案仍然可以階段性地保留,最大程度地避免了誤刪除,缺點是磁盤空間仍然被占著。在分佈式檔案系統中,磁盤空間都是比較充裕的資源,因此幾乎都採用邏輯刪除,以對資料可以進行恢復,同時在一段時間之後 (可能是 2 天或 3 天,這引數一般都可配置),再對被刪除的資源進行回收。

怎麼回收被刪除或無用的資料? 可以從檔案的 meta 信息出發——如果 meta 信息的“檔案 – 資料塊”映射表中包含了某個資料塊,則它就是有用的;如果不包含,則表明該資料塊已經是無效的了。所以,刪除檔案,其實是刪除 meta 中的“檔案 – 資料塊”映射信息 (如果要保留一段時間,則是把這映射信息移到另外一個地方去)。

面向小檔案的分佈式檔案系統

有很多這樣的場景,比如電商——那麼多的商品圖片、個人頭像,比如社交網站——那麼多的照片,它們具有的特性,可以簡單歸納下:

  • 每個檔案都不大;

  • 數量特別巨大;

  • 讀多寫少;

  • 不會修改。

針對這種業務場景,主流的實現方式是仍然是以大資料塊的形式儲存,小檔案以邏輯儲存的方式存在,即檔案 meta 信息記錄其是在哪個大資料塊上,以及在該資料塊上的 offset 和 length 是多少,形成一個邏輯上的獨立檔案。這樣既復用了大資料塊系統的優勢和技術積累,又減少了 meta 信息。

檔案指紋和去重

檔案指紋就是根據檔案內容,經過演算法,計算出檔案的唯一標識。如果兩個檔案的指紋相同,則檔案內容相同。在使用網絡雲盤的時候,發現有時候上傳檔案非常地快,就是檔案指紋發揮作用。雲盤服務商通過判斷該檔案的指紋,發現之前已經有人上傳過了,則不需要真的上傳該檔案,只要增加一個取用即可。在檔案系統中,通過檔案指紋可以用來去重、也可以用來判斷檔案內容是否損壞、或者對比檔案副本內容是否一致,是一個基礎組件。

檔案指紋的演算法也比較多,有熟悉的 md5、sha256、也有 google 專門針對文本領域的 simhash 和 minhash 等。

十一、總結

分佈式檔案系統內容龐雜,要考慮的問題遠不止上面所說的這些,其具體實現也更為複雜。本文只是儘量從分佈式檔案系統所要考慮的問題出發,給予一個簡要的分析和設計,如果將來遇到類似的場景需要解決,可以想到“有這種解決方案”,然後再來深入研究。

同時,市面上也是存在多種分佈式檔案系統的形態,下麵就是有研究小組曾經對常見的幾種分佈式檔案系統的設計比較。

幾種分佈式檔案系統的比較

從這裡也可以看到,選擇其實很多,並不是 GFS 論文中的方式就是最好的。在不同的業務場景中,也可以有更多的選擇策略。

作者介紹

張軻,目前任職於杭州大樹網絡技術有限公司,擔任首席架構師,負責系統整體業務架構以及基礎架構,轉載請聯繫作者。


文章推薦:

溫馨提示:

請搜索“ICT_Architect”“掃一掃”二維碼關註公眾號,點擊原文鏈接獲取電子書詳情

求知若渴, 虛心若愚

赞(0)

分享創造快樂