最近の分散ファイルシステムの紹介
GlusterFS に入る前に他の分散ファイルシステムについてもちょっと見てみましょう。分散ファイルシステムは下のテーブルに一例として示したように 2014/02/09 現在で多く存在します。
<th>
提供
</th>
<th>
ライセンス
</th>
</tr>
<tr>
<td>
<a href='http://ja.wikipedia.org/wiki/Apache_Hadoop'>Hadoop HDFS</a>
</td>
<td>
Apache ソフトウェア財団
</td>
<td>
<a href='http://ja.wikipedia.org/wiki/Apache_License'>Apache License 2.0</a>
</td>
</tr>
<tr>
<td>
<a href='http://wiki.lustre.org/index.php/Main_Page'>Lustre</a>
</td>
<td>
Open Source Community
</td>
<td>
<a href='http://ja.wikipedia.org/wiki/GNU_General_Public_License'>GPL v2</a>
</td>
</tr>
<tr>
<td>
<a href='http://ceph.com/'>Ceph</a>
</td>
<td>
Open Source Community
</td>
<td>
LGPL
</td>
</tr>
<tr>
<td>
<a href='http://ja.wikipedia.org/wiki/Google_File_System'>Google File System</a>
</td>
<td>
Google
</td>
<td>
非公開
</td>
</tr>
<tr>
<td>
<a href='http://www.drbd.org/ja/home/what-is-drbd/'>DRBD</a>
</td>
<td>
LINBIT
</td>
<td>
GPL v2
</td>
</tr>
※ 上記の情報は 2014/02/09 時点です
- Hadoop HDFS
- Hadoop HDFS は Hadoop で利用する分散ファイルシステムです。Hadoop がもともとクラスタ構成を念頭に置いていることからファイルシステムも一緒に分散化する必要性がありました。ただし、Hadoop 自体は HDFS を必ずしも使う必要はなく HDFS 自体の弱点（ネームノード、後述）を補完する為に様々な代替ファイルシステムが Hadoop 以外からもリリースされています。
- Lustre
- Lustre はメタデータを管理するサーバとコンテンツを保持するノードからなる分散ファイルシステムです。2003年にリリースされ高いパフォーマンスの為、スーパーコンピューターで利用されていることも多くなっています。
- Ceph
- Cephはカリフォルニア大学サンタクルーズ校（UCSC）の博士論文研究プロジェクトとしてスタートしました。Ceph はメタデータを管理するサーバとオブジェクトを管理するノード・管理用のクラスター・モニター等から構成されます。ただ、Ceph についてはまだ安定性の面で疑問の声が伺えます。
- Google File System
- Google File System は Google が自社システムの為に開発・運用している分散ファイルシステムです。ソフトウェア自体が公開されているわけではない為、我々が利用できる訳ではありませんが、仕様が論文として公開されています。非常に大きなサイズのファイルを扱うのを得意としています。
- DRBD
- DRBD はミラーリングが主体となった分散ファイルシステムで、2007年に Linux カーネルに組み込まれました（それまではインストールが煩雑）。バックアップとして利用されるケースも多くなっています。
他のファイルシステムにない強み
色々機能がある中で特に GlusterFS の強みとして考えられるのはやはりマスタレス構成にあります。GlusterFS ではどのノードが落ちてもアクセスできなくなるようなことはありません。
Hadoop で使われる HDFS の場合、ファイルシステムのメタデータや修正ログ等を管理しているネームノードと呼ばれるノードが存在します。
これは シングルポイント（単一障害点）と呼ばれ、このノードが停止するとシステム（ここでは HDFS で利用しているファイルシステム）全体が停止してしまう為、一番の弱点になってしまいます。
通常、分散ファイルシステムを構成する時には次の役割を行うサーバが必要になります。
これらの機能はもちろん GlusterFS でも必要です。では GlusterFS はこの役割を誰が演じているのでしょうか？
GlusterFS ではこれらの役割を GlusterFS クライアントが行なっています。その為、GlusterFS クライアントのモジュール（トランスレータと呼びます）は GlusterFS サーバ（glusterfsd）に負けない位のソースコード量になっています。
マスタレス構成を採用している分散ファイルシステムは最近の分散ファイルシステムの紹介{.reference.internal}に挙げたものの中でも存在しません。
バックの RedHat も後押し
GlusterFS は 2011年に Redhat,Inc が Gluster,Inc を買収したことで自社製品の一つとして組み込みましたが、Redhat 自体はこれを自社のクラウドソリューションの強化に組み入れています。
Redhat はクラウドビジネスを重視しており、その基盤として Red hat Enterprise Linux、KVM を提供しています。また、2011年には Paas として OpenShift（Heroku に近い）も公開されました。
2014/02/09（執筆現在）において、Redhat のページ では Redhat CTO である Brian Stevens 氏のプロフィールが公開されていますが、仮想化・クラウド・ミドルウェアへのリスペクトが高いことが伺えます。
また、この CTO の Office にはもともと Gluster 社で GlusterFS を開発していた生みの親・Anand Babu Periasamy 氏も在籍しています。
GlusterFS は Redhat が提供するクラウドビジネスにおいてなくてはならないものの一つとして考えられているものと予想されます。
GlusterFS の人気は？
では GlusterFS の人気はどれ程なのでしょうか？
2013年 5月時点で下に記したようなソースから分散ファイルシステムと GlusterFS を調査しました。
<th class="head">
HDFS
</th>
<th class="head">
Lustre
</th>
<th class="head">
Ceph
</th>
<th class="head">
GFS
</th>
<th class="head">
DRBD
</th>
<th class="head">
GlusterFS
</th>
<td>
1
</td>
<td>
4
</td>
<td>
1
</td>
<td>
1
</td>
<td>
2
</td>
<td>
1
</td>
<td>
<cite>-</cite>
</td>
<td>
3
</td>
<td>
1
</td>
<td>
<cite>-</cite>
</td>
<td>
3
</td>
<td>
3
</td>
<td>
</td>
<td>
2
</td>
<td>
</td>
<td>
8
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
1
</td>
<td>
</td>
<td>
9
</td>
<td>
</td>
<td>
</td>
<td>
1
</td>
<td>
2
</td>
<td>
</td>
<td>
7
</td>
<td>
</td>
<td>
</td>
<td>
3
</td>
<td>
5
</td>
<td>
</td>
<td>
2
</td>
<td>
</td>
<td>
</td>
<td>
1
</td>
<td>
3
</td>
<td>
</td>
<td>
5
</td>
<td>
1
</td>
<td>
1
</td>
上の結果はそれぞれ 1〜10 の間の数値で示しており 10が人気が高いことを意味しています。
Google File System(GFS) が飛び抜けていますが HDFS のように分散ファイルシステムはこの論文を参考に作っていることが多い為、結果も多くなっているものと想定されます。
また、それぞれのファイルシステムにおいて 2013年から Ceph はかなりの勢いで伸びています。
さて、本書で取り上げている GlusterFS はというとこれの他のファイルシステムに比べると今のところぱっとしていません。ただ、今後は Redhat の後押しも考慮しもっともっと人気が上がっていく事を期待します。
GlusterFS はマスタレスな分散ファイルシステム
GlusterFS はボリュームの中のホストがダウン（ネットワーク断やサーバダウン、GlusterFS プロセスのダウン等）してもボリューム内に他のサーバが存在していれば止まることもアクセスが途切れることもありません（もちろん書き込みも可能）。
特に GlusterFS で素晴らしい点はマスタが存在しない為、どのホストがダウンしても構わないということです。
サーバ＆クライアント方式のミドルウェア（MySQL だったり、bind（DNS）だったり）においてマスタは通常、他の稼働しているサーバを管理するサーバで、マスタがダウンした場合はサービスが止まるか次のマスタを探す必要があります。
このマスタ＆ノード（ノードはエージェント・スレーブ等と呼ばれます）構成はサーバ＆クライアント方式のミドルウェアでは一般的ですが、次のようにいつも問題になっていました。
- 負荷がマスタへ集中する:ノード台数増加はそれらと接続するマスタへのコネクション・処理増加につながりマスタの負荷が高くなってきます。
- マスタの選定が難しい:マスタは通常、スペックの高いものが好ましいのですが、それがどれか判断するのは難しいでしょう（ノード増設時に毎回検討が必要）
- マスタ障害時にサービスが停止する:ネットワークファイルシステムの Samba ではエレクション（選挙）により自動でノードが次のマスタへ昇格する機能がありますが、通常はシステム管理者が選び、マスタ向けに設定し、各ノードの接続先を変更する等の手作業が必要になります。もちろんこの間システムは停止します。
GlusterFS ではボリュームをマウントするクライアントがこのマスタの役割を果たすことでマスタの不要なマスタレス方式を実現し、どのサーバが停止してもそのボリュームが利用できなくなることはありません。
なお、例外としてボリューム内のミラー構成を取っている全てのサーバがダウンしてしまうとそのファイルにはアクセスできなくなります。
GlusterFS が他の分散ファイルシステムに比べて弱い点
今度は GlusterFS の弱みについても考えてみたいと思います。よく GlusterFS で問題として挙げられるのが次の点になります。
- パフォーマンス
- スプリットブレイン
まずパフォーマンスですが、GlusterFS は決して高速とは言えません。一度 30Gbyte 程度の 1Kbyte からなるファイル（ファイル数は 2万程度）でレプリケートボリュームを 4つのサーバで構成したことがあります。
ボリューム生成やボリュームスタート等は高速ですが、ファイルへのアクセスが異常に遅くて 1分立っても ls すら返ってこないということがありました。
また、キャッシュもデフォルトでは効いていないことから 2度目のアクセスも同じように遅く、途方にくれた経験があります。
ただ、同じようなファイル構成で NFS で構築したところほとんど 1〜2秒で ls が返り、もちろん中身の閲覧もストレスを感じることのない程度の速度でした。
もう１つのスプリットブレインですが、これはヒーリングの知識も踏まえて ヒーリングとスプリットブレイン の方で扱います。
- 2.1. GlusterFS はどんなもの？ – GlusterFS Community ではじめる分散ファイルシステム
- 2.2. GlusterFS Community と Red Hat Storage Server の違い – GlusterFS Community ではじめる分散ファイルシステム
- 2.3. GlusterFS の要件 – GlusterFS Community ではじめる分散ファイルシステム
- 2.4. GlusterFS をなぜ使うのか？ – GlusterFS Community ではじめる分散ファイルシステム
- 2.5. GlusterFS の機能と最近のリリース – GlusterFS Community ではじめる分散ファイルシステム