最近アシアルのファイルサーバーに大規模障害が発生し、改めてリカバリ工数の必要性について考えさせられました。今回の主原因がRAIDアレーがデグレードするようなHDDの物理故障であったため復旧まで時間がかかりましたが、これがきっかけとなりサーバー同士でファイルをミラーし合うような仕組みが構築できないかと探した結果、GlusterFSを用いたクラスタ構成を評価する事にいたしました。

○ クラスタファイルシステムとは？

クラスタファイルシステムとは、ファイルシステムがクラスタリング機能を持つものとなります。たとえば、RAID 1やRAID 5といった仕組みでディスクの冗長性を確保するのとは異なり、ファイルシステムでクラスタリングを用意します。

このようなクラスタファイルシステムでは、下記のような仕組みが有名です。
・DRBD → 特別なブロックデバイスを用いて、複数台のマシンでクラスタリングを行う仕組み。
・ZFS → ファイルシステム自体がRAID同様の機能を有する。複数台のマシンでクラスタリングを行うことはできない。
ただし、これらは、OSのレイヤーで動作することから、万一論理故障などによる障害が発生した場合にはその復旧が難しく、導入を見送っておりました。

今回紹介するGlusterFSは、ユーザーレベルでのファイルシステムクラスタを実現する仕組みとなります。具体的には、LinuxベースのOSと、XFSやEXT4といったファイルシステムで構成されたディスクを用いて、複数台のマシン間でディスクの同期を取ることが可能となります。これは便利、かつシンプル、という事で、この記事ではGlusterFSのインストールまでを説明します。

○ GlusterFSのインストール

この記事では、現在公開中のバージョン3.2を対象としています。

インストールといっても、CentOSやDebianの場合、専用のパッケージが用意されています。まずは、公式サイトより、ディストリビューションにあったパッケージをダウンロードしてください。

Debianの場合:

wget http://download.gluster.com/pub/gluster/glusterfs/LATEST/Debian/glusterfs_3.2.3-1_amd64.deb
dpkg -i glusterfs*.deb

インストールすると、GlusterFSのデーモンであるglusterdと、その管理ツールであるglusterコマンド、そしてFUSEを用いてマウントするmount.glusterfsがインストールされます。

GlusterFSのインストールは以上です。非常に簡単ですね。

○ GlusterFSはNFSサーバー

GlusterFSは、共有ストレージをボリュームという単位で管理します。ボリュームはGlusterFSが持つNFSサーバー機能を用いて、各クライアントからマウントすることができます。また、FUSEを用いた専用のglusterfs形式でのマウントも可能です。

たとえ自分のサーバーがglusterdを動作している場合でも、GlusterFSのボリュームにアクセスを行うためにはlocalhostでのマウントを行う必要があります。

○ GlusterFSことはじめ

GlusterFSでは、次の流れでクラスタを作成します
１．ピアの作成
２．ボリュームの作成
３．ボリュームの開始
順を追って説明します。これらはGlusterFSが提供するCLIであるglusterコマンドを通じて操作します。glusterコマンドを実行し、プロンプトを表示してください。

$ fileserver-1:~$ gluster
gluster >

１．ピア（peer）の作成

GlusterFSでは、まずクラスタを構成するサーバーの情報を登録します。

gluster> peer probe [fileserver-2]

ここで、[fileserver-2]には、クラスタを構成する別のサーバーを登録します。登録されたファイルサーバー側には、自動的にピア情報が転送され、ピア情報の共有が開始されます。

２．ボリュームの作成

複数のピアにまたがってボリュームを作成します。ボリュームは下記のモードで選択できます。
１．ストライピング（stripe）
２．レプリカ（replica）
の2種類のモードのいずれか、もしくは組み合わせでボリュームを作成できます。

今回は、冗長化を目的として、サーバー2台のディスクで複製された、1つのボリュームを作成します。

gluster> volume create [VOLUME-NAME] replica 2 transport tcp [fileserver-1:/path/to/brick] [fileserver-2:/path/to/brick]

内容は下記の通りです。
– VOLUME-NAME: ボリューム名、NFSやFUSEでマウントする際の名前に利用されます。
– fileserver-1:/path/to/brick: 1台目のマシンのホスト名と、そのホスト名上の共有スペース置場
– fileserver-2:/path/to/brick: 2台目のマシンのホスト名と、そのホスト名上の共有スペース置場
ここで注意が必要なのは、/path/to/brickで指定されたパスは、実際のデータの格納に用いられるもので、新たなディレクトリを指定する必要があります。

３．ボリュームの開始

作成したボリュームは、volume startコマンドで開始する必要があります。これをしないでFUSEやNFSでマウントすると、エラーが発生したり、マウントは成功するもののファイルにアクセスできないといった現象になります。

gluster> volume start [VOLUME-NAME]

実際に開始したことの確認は、

gluster> volume info all

Volume Name: VOLUME-NAME
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: fileserver-1:/path/to/brick
Brick2: fileserver-2:/path/to/brick

で確認が可能です。

○ マウントする

先述の通り、マウントはNFSやFUSEクライアントを利用できます。先ほど例では、それぞれ下記のようなコマンドとなります。

# mount -t nfs fileserver-1:/VOLUME-NAME /mnt/hoge
# mount -t glusterfs fileserver-1:/VOLUME-NAME /mnt/hoge

マニュアルには、速度やフェイルオーバー対策のために、FUSEを用いたマウントが推奨されています。CIFS（Windowsのファイル共有形式）にも対応していますが、こちらは用いたことがありません。

○ パフォーマンスは？

きちんとしたパフォーマンスについては、近々検証してみたいと思います。ざっと確認した限り、Duplicateモードでボリュームを作成した場合、各サーバーの同期が取られるため、ネットワーク速度がボトルネックとなる様子です。

○ その他良いところ

GlusterFSでは、Geo-Replication機能も備わっています。これは、定期的にrsyncコマンドを自動発行する形で、SSH経由などで外部サーバーへのレプリケーションを実施してくれるものです。

GlusterFSの所感としては、非常にシンプルで分かりやすい仕組みだと感じました。DRBDのようなOSレベルのレイヤーがなく、万が一glusterdに問題が発生した場合も、OSのファイルシステムレベルではファイルが残っている安心感があります。インストールや管理が簡単なのもポイント高です。

別のエントリとなりますが、パフォーマンス検証の結果についても報告したいと思います。