1. 程式人生 > >分散式檔案系統GlusterFS

分散式檔案系統GlusterFS

GlusterFS是一個高層次的分散式檔案系統解決方案。通過增加一個邏輯層,對上層使用者掩蓋了下面的實現,使用者不用瞭解也不需知道,檔案的儲存形式、分佈。

內部實現是整合了許多儲存塊(server)通過Infiniband RDMA或者 Tcp/Ip方式互聯的一個並行的網路檔案系統,這樣的許多儲存塊可以通過許多廉價的x86主機,通過網路搭建起來。

其相對於傳統NAS SANRaid的優點就是:

1.容量可以按比例的擴充套件,且效能卻不會因此而降低。

   2.廉價且使用簡單,完全抽象在已有的檔案系統之上。

   3.擴充套件和容錯設計的比較合理,複雜度較低。擴充套件使用translator

方式,擴充套件排程使用scheduling介面,容錯交給了本地的檔案系統來處理。

   4.適應性強,部署方便,對環境依賴低,使用,除錯和維護便利。

支援主流的linux系統發行版,包括 fcubuntudebiansuse等,並已有若干成功應用。


[轉:GlusterFS原始碼分析後隨筆 http://www.cnblogs.com/thinkinlove/archive/2007/11/20/966195.html ]

Glusterfs是一個儲存空間和訪問效率都可以線性增加的一個分散式檔案系統,網上資料除了gluster.org以外,幾乎沒有什麼有關的介紹了。

通過對原始碼的審閱,個人感覺,比較主要的是把程式的整體結構理清,擴充套件方式弄明白在向下看具體的實現是比較好的。

該系統擴充的方式是使用了translator的模式,具體我還參考了《現代作業系統》中分散式檔案系統章節和GNU/HURD 中解釋translator的部分,後者主要是在gnu的網站上。

數 據結構上講,整個檔案系統中節點構成了一棵樹,而且每個節點的操作是通過某個translator來工作的,一個節點可以附著很多的 translator。所有的translator都要實現xlator結構體和相關的xlator_fops、xlator_mops兩個“成員函式的 結構體”,

Hurd 另一個重要的概念就是所謂的 translator。您可以將 translator 視為您熟習的 UNIX 其檔案系統特色的實現,像 是 mount points、devices 還有 symbolic links。在 Hurd 檔案系統中,每個檔案都被連結到一個 叫 "translator" 的程式。當使用者程式存取這個檔案時,控制權就轉交給 translator 來處理。如果存取動作是讀取 disk 中 真正的檔案,則這種檔案系統格式的 translator 會向 disk 要求資料,並傳回應用程式。如果存取的是 device,則這 個 device 的 driver 會處理。同樣的,在存取 symbolic link 時,translator 會直接導向到指定的位置,或是其 它的檔案架構。

目前為止,translator 做到了標準 UNIX 系統無法達到的功能,它提供了 files、 device 與 symbolic link 一致的存取動作。Hurd 的 translator 還可以應用於任何種類的資料。以 FTP 存取為 例,對方系統中的檔案可以直接對應至您的檔案結構中 (像是 /ftp/ftp.mydomain.com/pub/myfile),您可使用原有的工具 進來拷貝、刪除或是編輯。Translator 會轉換到對應 FTP 動作。您可以想像其它的 translator 有那些功用,像是您可以使 用 cat 或是 ls 等工具透過 translator 來流覽資料庫的內容。或是網管工具可以寫成 translator,網路內所有的電腦可以對 應到一個目錄。Cat 可以列出網路的資料,像是機器的 IP 位址。Gateway 可以視為目錄,所以執行 cd 到一個 gateway 時,可以 看到這個 gateway 下子網域所有的機器。與 server 相同的一點,translator 不要須額外的許可權。任何人都可以開發自己 的 translator,除錯並嘗試完成,讓其它使用者也可以一起使用。

從xlator “繼承”下來的操作如果不自己定義,那麼就會使用預設的設定,這個在default.c裡面定義。當然自己定義的操作並賦值,這個過程有些象子類覆蓋父類 的操作,平行來看也就是多型。當然這是從面向物件角度來看的,該系統很多地方都使用了面向物件的思想來設計的,這個和linux 2.6以後的核心模組設計是異曲同工的。

那麼一般可以這樣識別一個用c實現的Class關鍵字的類:

例(對原始檔有些修改):

struct A {

char *name;

char *type;                   //成員

struct A *this;                 //this 指標

struct xlator_fops *fops;     //成員操作結構體1

struct xlator_mops *mops;        //成員操作結構體 2

void (*fini) (struct A *this);   // 解構函式,垃圾清理

int32_t (*init) (struct A *this);//建構函式,初始化

event_notify_fn_t notify;     //成員。。

dict_t *options;

glusterfs_ctx_t *ctx;

inode_table_t *itable;

char ready;

void *private;

};

    1.一個struct 定義裡面包含一個指標 該指標的型別是該struct定義的型別。2.上面的struct內部成員中含有其他結構體的指標,象xlator_fops就是這裡提到的其他結構體的指標,該結構體裡面全部都是指向函式的指標,也就是成員函式 了。

當然此處也可以把xlator_fops裡面的成員都釋放到struct A裡面, 但是這樣這個struct就顯得有些臃腫了,,畢竟成員函式還是不少的。上面這個例子還有兩個只有類才具備的解構函式,和建構函式。

glusterfs_ctx 控制了全域性的資訊,很多地方傳輸都是使用它來傳遞的,一個典型的環境類。初始化些東西也是針對它來做的。

Redhat GFS和Glusterfs的目的類似,都是以全域性在一個名稱空間下而通過訪問其他節點獲取資料的。此處沒有效能比較。

Lustre也是一個開源基於GNU lisence的叢集檔案系統,網站資源比較豐富,開發者的資源也比較多,中文資料也不少,sun公司收購了clusterfs公司,擁有了此技術。

下面地址顯示的是lustre 與glusterfs做相當命令所需時間的比較:

下面的地址是NFS與glusterfs效能的測試對比:

Ok - I just spent the last 2 hours on IRC with the glusterFS dev team -- they are definitely around and active. They have been thinking/working on glusterFS for about a year and half, the first active commit was back in September. It is very active. These guys are very responsive and very intrigued by S3 and EC2. Some of them come from old VA Linux days, and they say they have a good relationship with the Amazon folks -- anyone from Amazon want to jump in?? 

The whole glusterFS framework is designed to be "pluggable" through "translators". Their line was "why write a filesystem when you can write a translator". So by writing a storage/s3 translator, the rest of glusterFS just "works" and you/me don't have to reinvent the wheel for all the rest of the filesystem details. That is what we are working through now. (They took a lunch break hehe). 

Let me do my best to answer the questions I've seen so far: 

Q: Did you get it running within EC2? 
A: Yes -- I use the CentOS4.4 AMI as my base. After adding fuse.ko and the Fuse rpms, I was able to build and install gluster on some storage "brick" instances and a client glusterfs instance quite easily. Performance was way faster than my muckFS. They also suggested I build a custom fuse.ko using their code instead of the stock fuse kernel for even better performance. 


Q: Does GlusterFS aggregate storage across all connected nodes (i.e. Machine1 has 1GB, Machine2 has 1GB, Machine3 has 1GB, does the totalvolume that can be mounted equal 3GB)? 
A: Yes -- in my test config of 1 client and 2 server bricks, my client sees the aggregate of the 2 server bricks as: 
$ df -h 
Filesystem            Size Used Avail Use% Mounted on 
/dev/sda1             4.0G 2.0G 1.8G 54% / 
/dev/sda2             147G 206M 140G   1% /mnt 
glusterfs:28845       294G 520M 279G   1% /mnt/glusterfs 

Q: Can volumes/bricks be added "on the fly", for example if you bring anew node/brick online can the volume be dynamically expanded or reducedbased upon adding or deleting bricks, respectively? 
A: At this point, it sounds like you would need to do a remount, although they discussed the idea of on-the-fly in the future. This is part of the larger reason for my muckOS project -to manage the distribution of config files and restarting of services when adding nodes to clusters for things like glusterFS or MySQL etc. 

Q: Does GlusterFS support any type of parity or RAID-style architecture, in the event a node/brick goes down? 
A: They are releasing the Automatic File Replication "translator" in 15 days for RAID 1 type mirroring. You can configure how many times a file should be replicated - even my file type. Also, the distribution of files to "bricks" has 4 different "translator" plugin options - random, round robin, NUFA (ie NUMA for files) and ALU - a least usage algorithm. 

Q: How active is the project? 
A: while the list may not be active, the IRC channel sure is -- a good chunk of their development team spent the morning with me. 

I know there are more questions, but those are the ones I have answers for so far. 

These guys seem very interested in writing a storage/s3 "translator" for glusterFS.   Since glusterFS is already async in its writes, dealing with S3 as async persistent storage is not a problem. 

More info to come as I learn it... :)