More Related Content Similar to 10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage (20) More from Etsuji Nakai (20) 10年効く分散ファイルシステム技術 GlusterFS & Red Hat Storage2. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
自己紹介
中井悦司(なかいえつじ)
– Twitter @enakai00
日々の仕事
– Senior Solution Architect and
Cloud Evangelist at Red Hat K.K. 好評発売中
企業システムでオープンソースの活用を希望される
お客様を全力でご支援させていただきます。
昔とった杵柄
– 素粒子論の研究(超弦理論とか)
– 予備校講師(物理担当)
– インフラエンジニア(Unix/Linux専門)
Open Cloud Campus
5. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
GlusterFSの特徴
コモディティ・ハードウェアを利用して、スケールアウト型の分散ファイ
ルシステムを構築するソフトウェア
– サーバを追加していくことで、ストレージの容量を増やしていける。
– 同時アクセスするクライアントが増えてもパフォーマンスの劣化が少ない。
クラウドプロバイダがクラウド内
Linuxが動くところならどこでも利用可能 部のストレージ領域として使用
– データセンタの物理サーバ/仮想マシン
– クラウド上の仮想マシン
クラウドユーザがクラウド上にプラ
イベートな大容量ストレージを用意
複数のAPIでアクセスが可能
– FUSEマウント(Nativeプロトコル)
– NFSv3(NLM / Network Lock Manager による分散NFSロック対応)
– REST API(OpenStack SWIFT互換) 例えば、モバイル端末アプリから
– Hadoop API(HDFSの代替として利用) RESTでファイルを保存させておき、
サーバ側でまとめてHadoopで処理
するなどの利用法が考えられます。
Open Cloud Campus
6. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
GlusterFSに関するよくある誤解
GlusterFSを使うとファイルアクセスが高速化する???
– GlusterFSは、単一ファイルのアクセス性能を向上するものではありません。
– 1つのファイルは、基本的には1台のサーバで処理されますので、1サーバの物
理性能限界を超えることはあり得ません。
Nativeプロトコルが最も高速???
– FUSEの仕組みに伴うオーバヘッドが発生するので、すべての場合でNativeプ
ロトコルがベストなわけではありません。
– 少数ファイルに書き込みアクセスが集中する時は、NFSの方が高速な場合もあ
ります。
ストライピングを使用した方が高速???
– ストライピングは、1つの巨大なファイルを複数クライアントが同時アクセス
する場合に有効な仕組みです。
– 多数のクライアントがそれぞれ異なるファイルへ同時アクセスする場合は、ス
トライピングしない方が有利です。
Open Cloud Campus
7. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
GlusterFSの歴史
2005年にバンガロールで起業したGluster Inc.が開発/オープンソースとして公開
2011年までの6年間に・・・
・合計ダウンロード数300,000以上
・45カ国で1000システム以上での導入
・2000人以上のユーザー・コミュニティ
自主規制
Open Cloud Campus
8. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
実際にあった会話だそうです。。。
御社ではGlusterFSをダウンロード
して検証中の様ですが・・・。
非常にすばらしいソフトウェアだ。
ありがとうとうございます。
それでは本番導入して、弊社のサポー
トサービスを利用してはいかがでしょ
う?
自主規制
Open Cloud Campus
10. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
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 Hat
Storage Server
商用サポート
とメンテナンス
Open Cloud Campus
11. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NFS Lock対応 / Memory Leak Fix / ボリューム
の動的縮小 / Replication数の動的変更 etc....
http://download.gluster.org/pub/gluster/glusterfs/
Open Cloud Campus
14. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
メタデータノードを持たない分散アーキテクチャ
分散ストレージを構成する各ノードの通常のファイルシステムをバックエンドデバイスとし
て使用します。
– GlusterFSに保存したファイルの実体は、どこかのノードのファイルシステムに保存されます。
ファイル名のハッシュ計算で保存するノードを決定します。
– 各ファイルの保存ノードの情報を別途、どこかにメタデータとして保存しておく必要がありません。
GlusterFS
クライアントからは1つの Nativeクライアント
ファイルシステムに見える
実際には各ノードのファイルシステム
に分散して保存されている
file01, file02, file03 ボリューム
・・・ GlusterFSクラスタ
file01 file02 file03
Open Cloud Campus
15. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
ノード / ブリック / ボリュームの階層構造
ノード: gluster01 ノード: gluster02 ノード: gluster03
ファイルシステム /data
ブリック /data/brick01 /data/brick01 /data/brick01
(単なるディレクトリ)
/data/brick02 /data/brick02 /data/brick02
・・・
・・・
・・・
1つのボリュームは、各ノードが提供する
「ブリック」の集合として作られる
ボリューム vol01
1つのノードが複数のブリックを提供することも可能です。
ノードごとに提供するブリック数、ディレクトリ名などを揃える必要はありません。
ボリュームサイズを拡大/縮小する際は、ボリュームに対するブリックの追加/削除を行います。
Open Cloud Campus
17. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
デモンストレーション
3ノード(gluster01 〜 gluster03)からなるクラスタを構成
各ノードのブリック(/data/brick01)を使用したボリューム(vol01)を作成
Nativeクライアントからボリューム(vol01)をマウント
Open Cloud Campus
18. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
さまざまなボリュームの構成例
node01 node02 node03 node04
GlusterFSクラスタ
ファイル単位で各ブリックに分散保存
/brick01 /brick01 /brick01 /brick01 (1つのファイルはどれか1つのブリックに存在)
ストライピング
/brick02 /brick02 /brick02 /brick02 1つのファイルを各ブリックに分散保存
レプリケーション レプリケーション
node01-node02、node03-node04で
/brick03 /brick03 /brick03 /brick03 それぞれレプリケーション
ストライピング
レプリケーション レプリケーション
レプリケーションとストライピングの
/brick04 /brick04 /brick04 /brick04 組み合わせ
Open Cloud Campus
20. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
DHT: Distributed Hash Table (分散ハッシュテーブル)
分散ハッシュテーブルとは・・・
– ファイル名のハッシュ値によって、どのブリックに保存するかを決定するルール。
– 正確には、ブリックとハッシュレンジの対応表を「ハッシュテーブル」と呼びます。
実際のハッシュ値は32ビットで
0x00000000 〜 0xFFFFFFFF
file01
ファイル名の
ハッシュ値を計算 DHT(分散ハッシュテーブル)
ブリック1 ブリック2 ブリック3 ・・・
127
ハッシュ 0〜99 100〜199 200〜299
該当するハッシュ値を レンジ
受け持つブリックに保存
ハッシュレンジ 0〜99 ハッシュレンジ 100〜199 ハッシュレンジ 200〜299
ブリック1 ブリック2 ブリック3 ・・・
Open Cloud Campus
21. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
GlusterFSにおけるDHTの構造
ボリューム内のディレクトリごとに異なるハッシュテーブルを用意します。
– 同じファイル名でもディレクトリによって、行き先のブリックが変わります。
– ディレクトリごとにハッシュレンジをバラけさせることで、ファイル配置の偏りを低減します。
ブリック1 ブリック2 ブリック3 ・・・
/dir01 0〜99 100〜199 200〜299 ・・・
/dir02 100〜199 400〜499 300〜399 ・・・
/dir03 500〜599 200〜299 100〜199 ・・・
・・・
ブリック1 ブリック2 ブリック3 ・・・
各ブリック/ディレクトリのハッシュレンジは、該当ディレクトリの「拡張属性」に記録さ
れます。
[root@gluster01 ~]# getfattr -d -m . /data/brick01/dir01
getfattr: Removing leading '/' from absolute path names
# file: data/brick01/dir01
trusted.gfid=0shk2IwdFdT0yI1K7xXGNSdA==
trusted.glusterfs.10d3504b-7111-467d-8d4f-d25f0b504df6.xtime=0sT+vTRwADqyI=
trusted.glusterfs.dht=0sAAAAAQAAAAB//////////w==
Open Cloud Campus
22. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NativeクライアントがDHTを利用する仕組み
Nativeクライアントは次の流れで、ディレクトリごとのハッシュテーブルを構成
します。
– 任意のノードを指定してボリュームをマウントすると、該当ボリュームを構成する全
ノード/全ブリックのリストをそのノードから受け取ります。
– ボリューム内のディレクトリに最初にアクセスしたタイミングで、各ブリックの該当
ディレクトリのハッシュレンジを拡張属性から取得して、メモリ上にハッシュテーブル
を構成します。
– それ以降は、メモリ上のハッシュテーブルを参照して、各ファイルを配置ブリックを決
定します。
分かりにくいので絵で説明します・・・。
Open Cloud Campus
23. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NativeクライアントがDHTを利用する仕組み
# mount -t glusterfs gluster01:/vol01
ボリュームvol01は
gluster01〜gluster04が
ご提供いたします。
gluster01 gluster02 gluster03 gluster04
Open Cloud Campus
24. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NativeクライアントがDHTを利用する仕組み
# cat /vol01/dir01/file01
dir01のハッシュレンジは dir01のハッシュレンジは
XXXです。 XXXです。
gluster01 gluster02 gluster03 gluster04
Open Cloud Campus
25. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NativeクライアントがDHTを利用する仕組み
ブリック1 ブリック2 ブリック3 ・・・
dir01 0〜99 100〜199 200〜299
# cat /vol01/dir01/file01
各ノードのdir01のハッシュレンジ
(ハッシュテーブル)を覚えておこう。
dir01のハッシュレンジは dir01のハッシュレンジは
XXXです。 XXXです。
gluster01 gluster02 gluster03 gluster04
Open Cloud Campus
26. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NativeクライアントがDHTを利用する仕組み
ブリック1 ブリック2 ブリック3 ・・・
dir01 0〜99 100〜199 200〜299
# cat /vol01/dir01/file01
ハッシュテーブルによると
file01はgluster02が持っている
file01をどうぞ。
gluster01 gluster02 gluster03 gluster04
Open Cloud Campus
27. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NativeクライアントがDHTを利用する仕組み
ブリック1 ブリック2 ブリック3 ・・・
dir01 0〜99 100〜199 200〜299
# cat /vol01/dir01/file02
ハッシュテーブルによると
file02はgluster03が持っている
file02をどうぞ。
gluster01 gluster02 gluster03 gluster04
Open Cloud Campus
28. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
(参考)ブリックの追加/削除時の動き
既存ボリュームにブリックを追加すると・・・
– 追加直後は、既存のディレクトリは、新しいブリックを使用しません。
– 新規作成したディレクトリは、新しいブリックを含むハッシュテーブルを構成します。
– 「Rebalance処理」を実施することで、既存ディレクトリに新しいブリックを含むハッ
シュテーブルを割り当て直して、ファイルの再配置が行われます。
既存ボリュームからブリックを削除する際は・・・
– 事前に「Remove処理」を実施して、削除対象ブリックを除いた新しいハッシュテーブル
を構成して、ファイルを再配置します。
– ファイルの再配置によって、削除対象ブリックからファイルがなくなった後に、該当ブ
リックを削除します。
– 新規サーバに既存ブリックを移動する場合は、「Migration処理」により、新規ブリック
にファイルを移動することも可能です。
Open Cloud Campus
29. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
(参考)トランスレータ・モジュールについて
複数の「トランスレータ・モジュール」が連携してアクセス処理を行います。
– クライアント側で動くモジュールとサーバ側で動くモジュールがあります。
それぞれのモジュールは異なる役割を持っています。
– 各モジュールは共有ライブラリとして提供されます。
– 独自のモジュールを作成して、プラグインすることも可能です。
[root@gluster01 ~]# ls -l /usr/lib64/glusterfs/3.3.0/xlator/
total 48
drwxr-xr-x 2 root root 4096 Jun 16 15:25 cluster DHT、レプリカなどの機能
drwxr-xr-x 2 root root 4096 Jun 16 15:25 debug
drwxr-xr-x 2 root root 4096 Jun 16 15:25 encryption
drwxr-xr-x 2 root root 4096 Jun 16 15:25 features Quota、ファイルロックなどの機能
drwxr-xr-x 2 root root 4096 Jun 16 15:25 mgmt
drwxr-xr-x 2 root root 4096 Jun 16 15:25 mount
drwxr-xr-x 2 root root 4096 Jun 16 15:25 nfs
drwxr-xr-x 2 root root 4096 Jun 16 15:25 performance キャッシュ、先読みなどの機能
drwxr-xr-x 2 root root 4096 Jun 16 15:25 protocol
drwxr-xr-x 2 root root 4096 Jun 16 15:25 storage 物理ディスクアクセスなどの機能
drwxr-xr-x 2 root root 4096 Jun 16 15:25 system
drwxr-xr-x 3 root root 4096 Jun 16 15:25 testing
Open Cloud Campus
30. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
(参考)トランスレータ・モジュールの組み合わせ例
io-stats 統計情報の記録
md-cache メタデータのキャッシング
quick-read
io-cache データのキャッシング
read-ahead
write-behind
クライアント dht DHTの処理
モジュール(*1)
replicate-1 replicate-2 レプリケーション
client-1 client-2 client-3 client-4 サーバとの通信
server server server server クライアントとの通信
brick brick brick brick
marker marker marker marker
サーバ
モジュール(*2) index index index index
io-threads io-threads io-threads io-threads I/Oスレッドの起動
locks locks locks locks ファイルロック処理
access-control access-control access-control access-control ACL管理
posix posix posix posix ブリックへの物理アクセス
ブリック ブリック ブリック ブリック
Open Cloud Campus
(*1) /var/lib/glusterd/vols/<Vol>/<Vol>-fuse.volで定義 (*2) /var/lib/glusterd/vols/<Vol>/<Vol>.<Node>.<Brick>.volで定義
32. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
NFSマウント
GlusterFSデーモンは独自のNFSサーバ機能を提供しています。
– NFSv3のみ対応です。GlusterFSサーバ自身はNFSクライアントにはなれません。
– クライアントごとに異なるノードにNFS接続しても構いません。
– 分散ロック機能により、NFSロック情報はノード間で共有されます。
# mount -t nfs -o mountvers=3 gluster02:/vol01 /mnt/vol01
# mount -t nfs -o mountvers=3 gluster01:/vol01 /mnt/vol01
NFSクライアント
特定クライアントからの通信は クライアントごとに異なる
特定ノードを経由する ノードに接続してもよい
・・・
gluster01 gluster02
Open Cloud Campus
33. 10年効く分散ファイルシステム技術 GlusterFS&Red Hat Storage
REST API (OpenStack Swift互換API)
GlusterFS対応版のSwiftモジュールを利用すると、Swift互換のREST APIでのア
クセスが可能です。
– 現時点のバージョンでは、認証機能は簡易的な「TempAuth」のみに対応。OpenStackの
統合認証機能(KeyStone)には未対応なので要注意。
RESTクライアント
OpenStack Swiftと同じ
プロトコル
Swift Swift Swift
Module Module Module
・・・
gluster01 gluster02
参考資料:GlusterFS 3.3 Swift APIのセットアップ手順
http://d.hatena.ne.jp/enakai00/20120601/1338534753 Open Cloud Campus
35. オープンクラウド・キャンパス
10年効く分散ストレージ技術で
10年効くエンジニアを目指しましょう!
中井悦司
Twitter @enakai00