10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage

Ver1.1 2012/07/02中井悦司 (Twitter @enakai00)

オープンクラウド・キャンパス

10年効く分散ストレージ技術GlusterFS & Red Hat Storage

Open Cloud Campus

10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage

自己紹介

中井悦司（なかいえつじ）– Twitter @enakai00

日々の仕事– Senior Solution Architect and

Cloud Evangelist at Red Hat K.K.企業システムでオープンソースの活用を希望されるお客様を全力でご支援させていただきます。

昔とった杵柄– 素粒子論の研究（超弦理論とか）– 予備校講師（物理担当）– インフラエンジニア（Unix/Linux専門）

好評発売中

Open Cloud Campus


Contents

GlusterFSの基本 GlusterFSのアーキテクチャみんな大好きDHT（Distributed Hash Table）その他のアクセス方法

GlusterFSの基本

Open Cloud Campus


GlusterFSの特徴

コモディティ・ハードウェアを利用して、スケールアウト型の分散ファイルシステムを構築するソフトウェア

– サーバを追加していくことで、ストレージの容量を増やしていける。– 同時アクセスするクライアントが増えてもパフォーマンスの劣化が少ない。

Linuxが動くところならどこでも利用可能– データセンタの物理サーバ／仮想マシン– クラウド上の仮想マシン

複数のAPIでアクセスが可能– FUSEマウント（Nativeプロトコル）– NFSv3（NLM / Network Lock Manager による分散NFSロック対応）– REST API（OpenStack SWIFT互換）– Hadoop API（HDFSの代替として利用）

クラウドプロバイダがクラウド内部のストレージ領域として使用

クラウドユーザがクラウド上にプライベートな大容量ストレージを用意

例えば、モバイル端末アプリからRESTでファイルを保存させておき、サーバ側でまとめてHadoopで処理するなどの利用法が考えられます。

Open Cloud Campus


GlusterFSに関するよくある誤解

GlusterFSを使うとファイルアクセスが高速化する？？？– GlusterFSは、単一ファイルのアクセス性能を向上するものではありません。– 1つのファイルは、基本的には1台のサーバで処理されますので、1サーバの物

理性能限界を超えることはあり得ません。

Nativeプロトコルが最も高速？？？– FUSEの仕組みに伴うオーバヘッドが発生するので、すべての場合でNativeプ

ロトコルがベストなわけではありません。– 少数ファイルに書き込みアクセスが集中する時は、NFSの方が高速な場合もあります。

ストライピングを使用した方が高速？？？– ストライピングは、１つの巨大なファイルを複数クライアントが同時アクセス

する場合に有効な仕組みです。– 多数のクライアントがそれぞれ異なるファイルへ同時アクセスする場合は、ス

トライピングしない方が有利です。

Open Cloud Campus


自主規制

GlusterFSの歴史 2005年にバンガロールで起業したGluster Inc.が開発／オープンソースとして公開

2011年までの6年間に・・・

・合計ダウンロード数300,000以上・45カ国で1000システム以上での導入・2000人以上のユーザー・コミュニティ

Open Cloud Campus


実際にあった会話だそうです。。。

御社ではGlusterFSをダウンロードして検証中の様ですが・・・。

非常にすばらしいソフトウェアだ。

ありがとうとうございます。それでは本番導入して、弊社のサポートサービスを利用してはいかがでしょう？

自主規制

Open Cloud Campus


と思っていたら。。。

http://itpro.nikkeibp.co.jp/article/NEWS/20111005/370187/

自主規制

Open Cloud Campus


GlusterFSとRed Hat Storageの関係

GlusterFSは、コミュニティメンバーによるオープンソースプロジェクトとして開発を継続します。

GlusterFS Advisory Board Member (as of 2012/04) Richard Wareing, Storage Engineer, Facebook Jeff Darcy, Filesystem Engineer, Red Hat; Founder, HekaFS Project AB Periasamy, Co-Founder, GlusterFS project Ewan Mellor, Xen Engineer, Citrix; Core contributor, OpenStack project David Nalley, CloudStack Community Manager, Citrix; Member, Fedora Advisory Board Louis Zuckerman, Sr. System Administrator, Picture Marketing Joe Julian, Sr. System Administrator, Ed Wyse Beauty Products Greg DeKoenigsberg, Community VP, Eucalyptus; co-founder, Fedora project John Mark Walker, Gluster.org Community Guy (Chair)

GlusterFS

Red HatStorage Server

新機能の開発

商用サポートとメンテナンス

Open Cloud Campus


http://download.gluster.org/pub/gluster/glusterfs/

NFS Lock対応 / Memory Leak Fix / ボリュームの動的縮小 / Replication数の動的変更 etc....

Open Cloud Campus


自主規制

本題に入る前に１つだけ・・・

GlusterFSのアーキテクチャ

Open Cloud Campus


メタデータノードを持たない分散アーキテクチャ

分散ストレージを構成する各ノードの通常のファイルシステムをバックエンドデバイスとして使用します。

– GlusterFSに保存したファイルの実体は、どこかのノードのファイルシステムに保存されます。

ファイル名のハッシュ計算で保存するノードを決定します。– 各ファイルの保存ノードの情報を別途、どこかにメタデータとして保存しておく必要がありません。

file01 file02 file03

・・・ GlusterFSクラスタ

file01, file02, file03

GlusterFSNativeクライアント

ボリューム

クライアントからは1つのファイルシステムに見える

実際には各ノードのファイルシステムに分散して保存されている

Open Cloud Campus


ノード / ブリック / ボリュームの階層構造

・・

・

ボリューム vol01

ファイルシステム /data

/data/brick02

/data/brick01　ブリック（単なるディレクトリ）

・・

・/data/brick02

/data/brick01

・・

・

/data/brick02

/data/brick01

1つのボリュームは、各ノードが提供する「ブリック」の集合として作られる

ノード: gluster01

１つのノードが複数のブリックを提供することも可能です。ノードごとに提供するブリック数、ディレクトリ名などを揃える必要はありません。ボリュームサイズを拡大／縮小する際は、ボリュームに対するブリックの追加／削除を行います。

ノード: gluster02 ノード: gluster03

Open Cloud Campus


要するに・・・「ブリック = 元気玉」

自主規制

Open Cloud Campus


デモンストレーション

3ノード（gluster01 〜 gluster03）からなるクラスタを構成各ノードのブリック（/data/brick01）を使用したボリューム（vol01）を作成 Nativeクライアントからボリューム（vol01）をマウント

Open Cloud Campus


/brick01

/brick02

/brick03

/brick04

/brick01

/brick02

/brick03

/brick04

/brick01

/brick02

/brick03

/brick04

さまざまなボリュームの構成例

/brick01

/brick02

/brick03

/brick04

GlusterFSクラスタ

ファイル単位で各ブリックに分散保存（1つのファイルはどれか1つのブリックに存在）

node01-node02、node03-node04でそれぞれレプリケーション

1つのファイルを各ブリックに分散保存

レプリケーションレプリケーション

ストライピング

レプリケーションレプリケーション

ストライピング

レプリケーションとストライピングの組み合わせ

node01 node02 node03 node04

みんな大好きDHT

Open Cloud Campus


DHT: Distributed Hash Table （分散ハッシュテーブル）

分散ハッシュテーブルとは・・・– ファイル名のハッシュ値によって、どのブリックに保存するかを決定するルール。– 正確には、ブリックとハッシュレンジの対応表を「ハッシュテーブル」と呼びます。

file01

ブリック１

ハッシュレンジ 0〜99

ファイル名のハッシュ値を計算

ブリック２


・・・

127

該当するハッシュ値を受け持つブリックに保存

ブリック３


実際のハッシュ値は32ビットで0x00000000 〜 0xFFFFFFFF

ブリック1 ブリック2 ブリック3 ・・・

ハッシュレンジ

0〜99 100〜199 200〜299

DHT（分散ハッシュテーブル）

Open Cloud Campus


GlusterFSにおけるDHTの構造

ボリューム内のディレクトリごとに異なるハッシュテーブルを用意します。– 同じファイル名でもディレクトリによって、行き先のブリックが変わります。– ディレクトリごとにハッシュレンジをバラけさせることで、ファイル配置の偏りを低減します。

各ブリック／ディレクトリのハッシュレンジは、該当ディレクトリの「拡張属性」に記録されます。

ブリック１

[root@gluster01 ~]# getfattr -d -m . /data/brick01/dir01getfattr: Removing leading '/' from absolute path names# file: data/brick01/dir01trusted.gfid=0shk2IwdFdT0yI1K7xXGNSdA==trusted.glusterfs.10d3504b-7111-467d-8d4f-d25f0b504df6.xtime=0sT+vTRwADqyI=trusted.glusterfs.dht=0sAAAAAQAAAAB//////////w==


/dir01 0〜99 100〜199 200〜299 ・・・

/dir02 100〜199 400〜499 300〜399 ・・・

/dir03 500〜599 200〜299 100〜199 ・・・

・・・

ブリック２ブリック３・・・

Open Cloud Campus


NativeクライアントがDHTを利用する仕組み

Nativeクライアントは次の流れで、ディレクトリごとのハッシュテーブルを構成します。

– 任意のノードを指定してボリュームをマウントすると、該当ボリュームを構成する全ノード／全ブリックのリストをそのノードから受け取ります。

– ボリューム内のディレクトリに最初にアクセスしたタイミングで、各ブリックの該当ディレクトリのハッシュレンジを拡張属性から取得して、メモリ上にハッシュテーブルを構成します。

– それ以降は、メモリ上のハッシュテーブルを参照して、各ファイルを配置ブリックを決定します。

分かりにくいので絵で説明します・・・。

Open Cloud Campus



# mount -t glusterfs gluster01:/vol01

ボリュームvol01はgluster01〜gluster04が

ご提供いたします。

gluster01 gluster02 gluster03 gluster04

Open Cloud Campus



# cat /vol01/dir01/file01


dir01のハッシュレンジはXXXです。


Open Cloud Campus






各ノードのdir01のハッシュレンジ（ハッシュテーブル）を覚えておこう。



dir01 0〜99 100〜199 200〜299

Open Cloud Campus





ハッシュテーブルによるとfile01はgluster02が持っている

file01をどうぞ。


dir01 0〜99 100〜199 200〜299

Open Cloud Campus





ハッシュテーブルによるとfile02はgluster03が持っている

file02をどうぞ。


dir01 0〜99 100〜199 200〜299

Open Cloud Campus


（参考）ブリックの追加／削除時の動き

既存ボリュームにブリックを追加すると・・・– 追加直後は、既存のディレクトリは、新しいブリックを使用しません。– 新規作成したディレクトリは、新しいブリックを含むハッシュテーブルを構成します。–「Rebalance処理」を実施することで、既存ディレクトリに新しいブリックを含むハッ

シュテーブルを割り当て直して、ファイルの再配置が行われます。

既存ボリュームからブリックを削除する際は・・・– 事前に「Remove処理」を実施して、削除対象ブリックを除いた新しいハッシュテーブル

を構成して、ファイルを再配置します。– ファイルの再配置によって、削除対象ブリックからファイルがなくなった後に、該当ブ

リックを削除します。– 新規サーバに既存ブリックを移動する場合は、「Migration処理」により、新規ブリック

にファイルを移動することも可能です。

Open Cloud Campus


（参考）トランスレータ・モジュールについて

複数の「トランスレータ・モジュール」が連携してアクセス処理を行います。– クライアント側で動くモジュールとサーバ側で動くモジュールがあります。

それぞれのモジュールは異なる役割を持っています。– 各モジュールは共有ライブラリとして提供されます。– 独自のモジュールを作成して、プラグインすることも可能です。

[root@gluster01 ~]# ls -l /usr/lib64/glusterfs/3.3.0/xlator/total 48drwxr-xr-x 2 root root 4096 Jun 16 15:25 clusterdrwxr-xr-x 2 root root 4096 Jun 16 15:25 debugdrwxr-xr-x 2 root root 4096 Jun 16 15:25 encryptiondrwxr-xr-x 2 root root 4096 Jun 16 15:25 featuresdrwxr-xr-x 2 root root 4096 Jun 16 15:25 mgmtdrwxr-xr-x 2 root root 4096 Jun 16 15:25 mountdrwxr-xr-x 2 root root 4096 Jun 16 15:25 nfsdrwxr-xr-x 2 root root 4096 Jun 16 15:25 performancedrwxr-xr-x 2 root root 4096 Jun 16 15:25 protocoldrwxr-xr-x 2 root root 4096 Jun 16 15:25 storagedrwxr-xr-x 2 root root 4096 Jun 16 15:25 systemdrwxr-xr-x 3 root root 4096 Jun 16 15:25 testing

DHT、レプリカなどの機能

Quota、ファイルロックなどの機能

キャッシュ、先読みなどの機能

物理ディスクアクセスなどの機能

Open Cloud Campus


（参考）トランスレータ・モジュールの組み合わせ例io-stats

md-cache

quick-read

io-cache

read-ahead

write-behind

dht

replicate-1 replicate-2

server

brick

marker

index

io-threads

locks

access-control

posix

server

brick

marker

index

io-threads

locks

access-control

posix

server

brick

marker

index

io-threads

locks

access-control

posix

server

brick

marker

index

io-threads

locks

access-control

posix

client-1 client-2 client-3 client-4

クライアントモジュール(*1)

サーバモジュール(*2)

ブリック

統計情報の記録

メタデータのキャッシング

データのキャッシング

DHTの処理

レプリケーション

サーバとの通信

クライアントとの通信

I/Oスレッドの起動

ファイルロック処理

ACL管理

ブリックへの物理アクセス

ブリックブリックブリック

(*1) /var/lib/glusterd/vols/<Vol>/<Vol>-fuse.volで定義 (*2) /var/lib/glusterd/vols/<Vol>/<Vol>.<Node>.<Brick>.volで定義

その他のアクセス方法

Open Cloud Campus


NFSマウント

GlusterFSデーモンは独自のNFSサーバ機能を提供しています。– NFSv3のみ対応です。GlusterFSサーバ自身はNFSクライアントにはなれません。– クライアントごとに異なるノードにNFS接続しても構いません。– 分散ロック機能により、NFSロック情報はノード間で共有されます。

・・・

# mount -t nfs -o mountvers=3 gluster01:/vol01 /mnt/vol01

NFSクライアント

gluster01 gluster02

特定クライアントからの通信は特定ノードを経由する

# mount -t nfs -o mountvers=3 gluster02:/vol01 /mnt/vol01

クライアントごとに異なるノードに接続してもよい

Open Cloud Campus


REST API (OpenStack Swift互換API）

GlusterFS対応版のSwiftモジュールを利用すると、Swift互換のREST APIでのアクセスが可能です。

–現時点のバージョンでは、認証機能は簡易的な「TempAuth」のみに対応。OpenStackの統合認証機能（KeyStone）には未対応なので要注意。

・・・

RESTクライアント

gluster01 gluster02

Swift Module

Swift Module

Swift Module

OpenStack Swiftと同じプロトコル

参考資料：GlusterFS 3.3 Swift APIのセットアップ手順http://d.hatena.ne.jp/enakai00/20120601/1338534753

Open Cloud Campus


QA

中井悦司Twitter @enakai00

オープンクラウド・キャンパス

10年効く分散ストレージ技術で10年効くエンジニアを目指しましょう！

Technology

10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage