Web叢集實作共享存儲的架構演變及MogileFS

本篇部落格從Web叢集中亟需解決的大容量存儲問題引入，分析了幾類常用的共享存儲架構，重點解析了分布式存儲系統的原理及配置實作；

===================================================================

1 共享存儲的架構演變

2 分布式存儲系統

    2.1 基礎知識

    2.2 分類

    2.3 CAP理論

    2.4 協定

3 MogileFS

    3.1 特性

    3.2 架構

    3.3 組成

    3.4 服務安裝及啟動

    3.5 配置部署

    3.6 配置前端代理Nginx

    3.7 通路驗證

    3.8 後續擴充

rsync+inotify：本地各保留一份完整資料，但通過rsync實時同步修改檔案，雙主模型哦

NFS：多節點挂載後性能下降嚴重；存在單點故障，且多個用戶端并發修改同一個檔案時可能出現不一緻的情況；

SAN：存儲區域網絡，不适用于海量高并發的存儲場景，且代價昂貴；可通過軟體實作iSCSI存儲網絡；涉及GFS2/CLVM(LVM2)

MooseFS：分布式檔案系統，适用于海量小檔案存儲；支援FUSE，可被挂載使用；

MogileFS：分布式存儲系統，适用于海量小檔案存儲；不支援FUSE，隻能通過API調用；

2.1 基礎知識

定義：分布式存儲系統是大量普通PC伺服器通過Internet互聯，對外作為一個整體提供存儲服務

特性：

可擴充：分布式存儲系統可以擴充到幾百台至幾千台的叢集規模，且随着叢集規模的增長，系統整體性能表現為線性增長；

低成本：分布式存儲系統的自動容錯、自動負載均衡機制使其可以建構在普通PC機之上；另外，線性擴充能力也使得增加、減少機器非常友善，可以實作自動運維；

高性能：無論是針對整個叢集還是單台伺服器，都要求分布式系統具備高性能；

易用：分布式存儲系統需要能夠提供易用的對外接口；另外，也要求具備完善的監控、運維工具，并能友善的與其他系統內建，如從Hadoop雲計算系統導入資料；

挑戰：在于資料、狀态資訊的持久化，要求在自動遷移、自動容錯、并發讀寫的過程中保證資料的一緻性；

2.2 分類

資料類型大緻可分為非結構化資料(如文本、圖檔、視訊等)，結構化資料(一般存儲在關系型資料庫中)，半結構化資料(如HTML文檔)；根據處理不同類型資料的需求，分布式存儲系統可分為如下4類：

分布式檔案系統：用于存儲Blob對象，如圖檔、視訊等，這類資料以對象的形式組織，對象之間沒有關聯；如GFS，MogileFS等；

分布式鍵值系統：用于存儲關系簡單的半結構化資料，它隻提供基于主鍵的CRUD(Create/Read/Update/Delete)功能；如Memcache，Redis等；

分布式表格系統：用于存儲關系較為複雜的半結構化資料，不僅支援簡單的CRUD操作，還支援掃描某個主鍵範圍；如Google Bigtable、Megastore；

分布式資料庫：用于存儲結構化資料，利用二維表格組織資料；如MySQL Sharding叢集，Google Spanner等；

2.3 CAP理論

來自Berkerly的Eric Brewer教授提出了一個著名的CAP理論：一緻性(Consistency)，可用性(Availability)和分區容忍性(Tolerance of network Partition)三者不能同時滿足：

C：讀操作總是能讀取到之前完成的寫操作結果，滿足這個條件的系統成為強一緻系統，這裡的“之前”一般對同一個用戶端而言；

A：讀寫操作在單台機器發生故障的情況下依然能夠正常執行，而不需要等待發生故障的機器重新開機或者其上的服務遷移到其他機器；

P：機器故障、網絡故障、機房停電等異常情況下仍然能夠滿足一緻性和可用性；

分布式存儲系統要求能夠自動容錯，即分區可容忍性總是需要滿足的，是以，一緻性和寫操作的可用性就不能同時滿足了，需要在這二者間權衡，是選擇不允許丢失資料，保持強一緻，還是允許少量資料丢失以獲得更好的可用性；

2.4 協定

分布式協定涉及的協定很多，例如租約，複制協定，一緻性協定，其中以兩階段送出協定和Paxos協定最具有代表性；

兩階段送出協定(Two-phase Commit，2PC)用以保證跨多個節點操作的原子性，即跨多個節點的操作要麼在所有節點上全部執行成功，要麼全部失敗；

兩個階段的執行過程如下：

階段一：請求階段(Prepare phase)，在請求階段，協調者通知事務參與者準備送出或者取消事務，然後進入表決過程；

階段二：送出階段(Commit phase)；

Paxos協定用于確定多個節點對某個投票(例如哪個節點為主節點)達成一緻；

3.1 特性

工作于應用層：無需特殊的核心元件；

無單點：三大元件(tracker，mogstore，database)皆可實作高可用；

自動檔案複制：複制的最小機關不是檔案，而是class；基于不同的class，檔案可以被自動的複制到多個有足夠存儲空間的存儲節點上；

傳輸中立，無特殊協定：可以通過NFS或HTTP協定進行通信；

簡單的命名空間：檔案通過一個給定的key來确定，是一個全局的命名空間；沒有目錄，基于域實作檔案隔離；

不共享資料：無需通過昂貴的SAN來共享磁盤，每個存儲節點隻需維護自己所屬的儲存設備(device)即可；

3.2 架構

Tracker：MogileFS的核心，是一個排程器；服務程序為mogilefsd；可以做負載均衡排程；

主要職責有：

資料删除；

資料複制；

監控：故障後生成新的資料副本；

查詢；

Database：Tracker通路Database，傳回使用者可用的Storage Node及檔案的存放位置；

mogstored：資料存儲的位置，通常是一個HTTP(WebDAV)伺服器，用于資料的建立、删除、擷取等；不可做負載均衡排程；

3.3 組成

MogileFS由3個部分組成：

server：主要包括mogilefsd和mogstored兩個應用程式。

mogilefsd實作的是tracker，它通過資料庫來儲存中繼資料資訊，包括站點domain、class、host等；

mogstored是存儲節點(store node)，它其實是個WebDAV服務，預設監聽在7500端口，接受用戶端的檔案存儲請求。

Utils（工具集）：主要是MogileFS的一些管理工具，例如mogadm等；

在MogileFS安裝完後，要運作mogadm工具将所有的store node注冊到mogilefsd的資料庫裡，mogilefsd會對這些節點進行管理和監控；

用戶端API：MogileFS的用戶端API很多，例如Perl、PHP、Java、Python等，用這個子產品可以編寫用戶端程式，實作檔案的備份管理功能等；

3.4 服務安裝及啟動

基本架構(在LNMT架構的基礎上改進)

伺服器規劃

服務安裝及啟動

資料庫授權

主機192.168.0.45(mogilefs+mogilestored)

主機192.168.0.46(mogilefs+mogilestored)

同上，直至mogilefsd和mogstored服務都正常啟動

3.5 配置部署(任意一個tracker節點上配置即可，如192.168.0.45)

添加節點

添加裝置

添加domain(域)

添加class(檔案類别)

3.6 配置前端代理Nginx

重新編譯安裝nginx，添加nginx-mogilefs-module-master子產品

配置Nginx，将靜态檔案和圖檔的通路都轉發至後端MogileFS即可

啟動nginx服務

3.7 通路驗證

上傳檔案測試分布式檔案系統MogileFS的功能

說明：直接通路mogilefs提供的檔案存儲路徑，通路正常；

結合Nginx，從前端通路測試

說明：通過前端Nginx通路圖檔和文本檔案一切正常，實作了對前端通路的透明性；

3.8 後續擴充

結合LNMT的架構，再通過Haproxy進行前端排程，就可以使用MogileFS這個分布式存儲系統完全替代NFS，實作對圖檔檔案和文本檔案的存儲和讀寫；

鑒于MogileFS的無目錄性，無法直接挂載使用，故向mogilefs叢集中添加檔案則需要程式通過API調用上傳(upload)檔案，雖然對于運維人員有點不友善，但也保證了一定的高效性；

如果想體驗直接挂載使用分布式檔案系統的樂趣，則可以嘗試使用MooseFS，在此就不多說了！

本文出自 “” 部落格，請務必保留此出處