AWSを使って分散ファイルシステム「GlusterFS」の検証〜その1

AWSを使って分散ファイルシステム「GlusterFS」の検証

分散ファイルシステムであるGlusterFSは、複数のサーバーにファイルを分散配置する事で、柔軟な拡張性と堅牢性を実現するファイルシステムだ。

ストレージサーバーの一部に障害が発生してもシステムを停止させる事なく修復が可能であり、またストレージ容量の拡張も簡単に行う事ができる。この記事ではGlusterFSを導入し、その特性やパフォーマンスについてレポートしよう。

GlusterFSの概要

GlusterFS は Gluster, Inc. によって開発され、2011年に RedHat に買収された後は RedHat によって開発されている。RedHat Storage 2.0として販売されている他、CentOS等、いくつかのLinux系OS用パッケージを無償利用できる事は、オープンソースならではの魅力だ。またOpenSolaris や FreeBSD にも対応しており、幅広いOS環境で利用する事ができる。

複数サーバーを束ねてひとつのボリュームを表現する GlusterFS は、それぞれのサーバーにブリック(brick)と呼ばれる領域を定義する。ブリックの実体は単純なディレクトリであり、即ち GlusterFS とは、それぞれのサーバーの指定ディレクトリ以下の記憶領域をネットワークを介して結合し、クライアントにひとつのボリュームとして提供する技術だと言えるだろう。

ブリックの構成には Distributed Volume、Striped Volume、Replicated Volume の3種類があり、それぞれの特徴は以下の通りだ。

ボリューム	説明
Distributed Volume	GlusterFSの基本的な構成であり、ファイルはブリックのいずれかに格納される。ブリックを追加する事で動的にボリュームの容量を拡張可能である。
Striped Volume	ひとつのファイルをストライプサイズ(デフォルトで128KB)に分割し、複数のブリックに配置する。Raid-0によく似た構成である。
Replicated Volume	ひとつのファイルを複数のブリックに配置する。Raid-1によく似た構成である。

これらは組み合わせて利用する事も可能であり、Distributed Striped Volume、Distributed Replicated Volume 等を運用可能だ。

こうして構成されたボリュームはNFSサーバーとして利用可能なので、NFSを利用可能なクライアントならOSを問わない。またクライアントがLinux系OSなら、FUSE機構を利用してマウントする事も可能だ。さらにlibglusterfsを利用すれば、プログラムから直接GlusterFSのボリュームにアクセスしFUSEのオーバーヘッドを回避する事もできる。

記事の目的

この記事ではGlusterFSを導入するまでの経緯を紹介すると供に、パフォーマンスや堅牢性についてレポートしたい。導入レポートは多くの記事やサイトで紹介されている物とほぼ同じ内容になるのではないかと思われるが、いくつかの注意すべき点について重点的に解説したいと思う。

パフォーマンステストについては、Subversion、Git等、主にバージョン管理ソフトウェアのリポジトリとして利用する事を想定し、これらのソフトウェアの実行時間を計測し、GlusterFSを利用する場合とそうでない場合とを比較した。堅牢性のテストについては、小さなプログラムを作成し、ファイルのロック機構が正しく動作しているかをテストしたり、人為的にエラー状態を発生させ、その後のシステムの状態を確認してみたりした。

パフォーマンステストについては、GlusterFSを利用しない時の方が高速に動作するという結論になっている。堅牢性のテストについては、すべて期待した通りの動作になり、高い堅牢性を確認する事ができた。

検証ソフトウェア

今回は以下のパッケージを利用し、各種テストを行った。

glusterfs-3.3.1-1.el6.x86_64.rpm
glusterfs-fuse-3.3.1-1.el6.x86_64.rpm
glusterfs-server-3.3.1-1.el6.x86_64.rpm

GlusterFSサーバーのインストールと設定

GlusterFSはさまざまなハードウェア環境やOSにインストール可能だが、今回はサーバー側コンポーネントを Amazon Web Service (AWS) に導入する事にした。3台のサーバーをテストに利用するので、以下の手順に従い台数分のサーバーを構築して欲しい。

なお、以下の文章では必要なLinuxコマンド等については逐一記載していくが、AWSの基本操作の解説については割愛させて頂いた。AWSで仮想マシンを構築したり、追加ストレージやセキュリティの設定を行う方法等については、各自で調査して頂きたい。

基本設定

利用した仮想ハードウェア環境とOSは以下の通りだ。

項目	説明
OS	Amazon Linux AMI 2012.09 (64bit)
仮想ハードウェア	m1.small
Elastix Block Store (EBS)	20GB(追加ストレージ)

Amazon Linux は CentOSによく似たLinuxディストリビューションであり、yumによるパッケージ管理が利用可能だ。また、m1.smallという仮想マシンのスペックは、以下の通りである。

m1.small のスペック

1.7 GiB のメモリ
1 ECU（1 ECU × 1仮想コア）
160 GB インスタンスストレージ
32ビットまたは64ビットのプラットフォーム
I/O 性能: 標準
EBS 最適化: 使用不可

標準で160GBのストレージ領域が利用可能だが、GlusterFSのブリックには別途用意した追加ストレージを利用する事にした。これは m1.small の基本ストレージは標準的なext4でフォーマットされているため、GlusterFS 3.3.1 のブリックとしては利用できないからだ。ext4でフォーマットされたボリュームをブリックに利用したい場合、予めIノードサイズを512にしなくてはならない。デフォルトは256なので、追加ストレージをext3でフォーマットし、利用する事にした。

EBSで追加ストレージを得たい場合は管理メニューの “ELASTIC BLOCK STORE/Vlumes” から “Create Volume”を利用して欲しい。詳細については割愛する。

追加ストレージをEBSから取得したら、以下の手順でマウントしよう。デバイス名は “/dev/xvdf” を想定して記述してあるが、それぞれの環境の追加デバイス名に置き換えて欲しい。

マウント手順

fdisk /dev/xvdf で拡張領域、論理領域を作成する(論理領域は /dev/xvdf5になる)
mkfs -t ext3 /dev/xvdf5 でフォーマットする
mkdir /var/bricks でマウント先作成
/etc/fstabの最終行に “/dev/xvdf5 /var/bricks ext3 defaults 1 3” を追加
mount -a でマウントする
df でマウントされている事を確認する

なお、Iノードサイズが256のext4のボリュームにブリックを作成しても、エラーメッセージや警告メッセージは表示されない。しかし、ls等、ディレクトリリスティングを利用するコマンドに失敗したり、マウント中にストールしたりして、まったく使い物にならなかった。

GlusterFSの動作が明らかにおかしいと思った場合は、まずはブリックが設置されているボリュームのフォーマットを疑ってみよう。最近のディストリビューションでは、Iノードサイズが256のext4を標準のフォーマットとして導入している事が多いので、まず最初に疑ってみる価値はあるだろう。

セキュリティの設定

GlusterFSでは、以下のポートを利用する

22
111
24007から(24008 + 使用する最大ブリック数)
38465から38467

AWSの管理画面でセキュリティポリシーを設定し、上記のポートを開いておいて欲しい。「利用する最大ブリック数」は今回のテストでは最大で4なので、24007から24012までを開いておけばよい。

なお、Amazon Linuxのデフォルトの状態ではSELinuxは起動していない。SELinuxを利用する場合は標準の設定では利用できないので、オフにするか、適切な設定をして欲しい。

パッケージのインストールとサービスの起動設定

インストール自体は非常に簡単だ。公式サイトから必要な3つのrpmを取得し、yumでインストールすればよい。手順は以下の通りだ。

# yum install -y http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/CentOS/epel-6Server/x86_64/glusterfs-3.3.1-1.el6.x86_64.rpm
# yum install -y  http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/CentOS/epel-6Server/x86_64/glusterfs-fuse-3.3.1-1.el6.x86_64.rpm
# yum install -y  http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/CentOS/epel-6Server/x86_64/glusterfs-server-3.3.1-1.el6.x86_64.rpm

問題なくインストールできたら、OS起動時にGlusterFSのサービスが起動するようにしよう。以下の手順で設定を行う。

# chkconfig glusterd on

3台分の名前解決

これまでの設定を3台のサーバーで行ったら、それぞれのサーバーに名前を付けて、相互に名前解決できるようにしておこう。今回は、3台のサーバーそれぞれに以下の名前を付ける事にする。

gluster-01
gluster-02
gluster-03

以下のコマンドで、名前を変更しよう。3台分、それぞれで設定して欲しい。

# hostname gluster-01

ただしhostnameコマンドを実行しただけでは、再起動時に名前が元に戻ってしまう。恒久的に変更するためには、/etc/sysconfig/network の “HOSTNAME”という項目を変更しておく必要がある。以下は設定例だ。

HOSTNAME=Gluster-01

さらに /etc/hosts に3台のサーバーの設定を追記する。記載例は以下の通りだ。IPアドレスはそれぞれの環境における値と置き換えて欲しい。

10.156.58.117 gluster-01
10.158.171.177 gluster-02
10.148.10.54 gluster-03

ここで極めて重要な事は、自分自身のIPアドレスを 127.0.0.1 にしないという事だ。通常、hostsの設定では命名したサーバー名に対し 127.0.0.1を割り当てる事が多いと思うが、GlusterFSを利用する場合、自分の名前を解決した時に、他のサーバーからアクセス可能なIPアドレスになっていなければならない。

名前解決についてはDNSで行う事も多いと思うが、小規模なサーバー群を制御する場合には、hostsファイルで行ってしまう場合も多いだろう。今回もサーバー間の名前解決はhostsで行うわけだが、上記の通り、他のサーバーからアクセス可能なIPアドレスを設定する事が重要なので注意して欲しい。

GlusterFSの起動

設定が完了したら、いよいよGlusterFSを起動しよう。3台のサーバーで、以下のコマンドを実行して欲しい

# service glusterd start

サービスの初期設定とボリュームの作成

信頼関係の設定

各サーバーでサービスが起動したら、いよいよブリックを設定し、ボリュームを作成する。その前に各サーバー間の信頼関係を設定する必要があるのでやっておこう。gluster-01 にログインし、以下のコマンドを実行しよう。

[root@Gluster-01 ~]# gluster peer probe gluster-02
Probe successful
[root@Gluster-01 ~]# gluster peer probe gluster-03
Probe successful
[root@Gluster-01 ~]#

これで gluster-02 および gluster-03 と信頼関係を結ぶ事ができた。なお、これにより gluster-01 が他のサーバーに対して主導的な立場になるわけではない。3台のサーバーは等価であり、以後解説するコマンドは、どのサーバーから実行した場合も結果は一緒だ。

ボリュームの作成

ブリックの作成は、以下のように行う。

gluster volume create test001 gluster-01:/var/bricks/test001 gluster-02:/var/bricks/test001 gluster-03:/var/bricks/test001

パラメーターの意味は以下の通りだ。

gluster volume create < ボリュームの名前> < ブリックのパス> ...

「ボリュームの名前」は、クライアントからアクセスする際の名前にもなるので注意して命名しよう。「ブリックのパス」は、このボリュームを構成するブリックのパスを「サーバー名:パス」という形式で指定する。1台以上の複数のパスを指定可能だ。今回は3台のサーバーでボリュームを作成するので、上記の通り3つ指定した。

ブリックとして利用するパスは、親ディレクトリまでが存在していれば良い。上記の場合、各サーバーにおいて “/var/bricks” というディレクトリが存在していれば、”/var/bricks/test001″はコマンド実行時に作成される。

「サービスの初期設定とボリュームの作成」でも述べたが、Iノードサイズが256のext4でフォーマットされたボリュームは、ブリックとして利用できないので注意しよう。

このコマンドにより、3台のサーバーにファイルを分散配置する”Distributed Volume”が完成した。

GlusterFSクライアントの設定

次にGlusterFSクライアントの設定を行おう。

これらGlusterFSクライアントには、GlusterFSサーバーが提供するボリュームをマウントする。マウントした領域はバージョン管理システムのリポジトリとして利用する予定だ。よってGlusterFSクライアントはアプリケーションサーバーでもある。

GlusterFSサーバーとGlusterFSクライアント間の通信には、NFS3.0、FUSE機構を利用したマウント、libglusterfsを介したアクセスの3通りあるが、今回はFUSE機構を利用したマウントを行う事にする。

基本設定

利用した仮想ハードウェア環境とOSは以下の通りだ。

項目	説明
OS	Amazon Linux AMI 2012.09 (64bit)
仮想ハードウェア	t1.micro

t1.micro という仮想マシンのスペックは、以下の通りである。

t1.micro のスペック

613 MiB のメモリ
1 ECU（1 ECU × 1仮想コア）
160 GB インスタンスストレージ
32ビットまたは64ビットのプラットフォーム
I/O 性能: 低速
EBS 最適化: 使用不可

ホスト名設定

GlusterFSクライアントのホスト名は、”gluster-cl-01″ とした。hostnameコマンドで以下のように設定する

# hostname gluster-cl-01

また、/etc/sysconfig/network の内容を書き換え、再起動後にもホスト名が維持されるようにした。

なお、今回は2台のGlusterFSクライアントを用意したが、もう一台は”gluster-cl-02″という名前を付けた。gluster-cl-01 と gluster-cl-02 は名前以外はすべての設定が同じなので、以下の設定項目を参考に同じマシンを2台用意して頂きたい。

GlusterFSのインストール

クライアント側でインストールするパッケージは以下の2つだけである。

glusterfs-3.3.1-1.el6.x86_64.rpm
glusterfs-fuse-3.3.1-1.el6.x86_64.rpm

yumコマンドを利用し、以下のようにインストールした。

# yum install -y http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/CentOS/epel-6Server/x86_64/glusterfs-3.3.1-1.el6.x86_64.rpm
# yum install -y  http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/CentOS/epel-6Server/x86_64/glusterfs-fuse-3.3.1-1.el6.x86_64.rpm

その他のソフトウェアのインストール

テストプログラムを作成するためのphp、およびテストの主軸となるバージョン管理システムをインストールする

# yum -y install subversion
# yum install -y php
# yum install -y git

/etc/hosts の設定

GlusterFSクライアントは、利用するGlusterFSサーバーのすべての名前解決ができる必要がある。マウント時等において、GlusterFSクライアントから利用するサーバーは、信頼関係にある物の中からひとつだけを利用すればよい。にも関わらず、すべてのサーバーの名前を解決できる必要があるので十分注意しよう。

10.156.58.117 gluster-01
10.158.171.177 gluster-02
10.148.10.54 gluster-03

GlusterFSは手軽にストレージサーバーを増設できるのが特徴であり、そのために導入すると言っても過言ではない。しかしサーバー増設のたびに全クライアントのhostsファイルを書き換えるのは非常に手間であり管理も面倒だ。実用環境においてはローカルDNS等を用意する事をお勧めしたい。

マウント

ここまでの準備が整えば、GlusterFSのマウントが可能になる。マウントは標準のmountコマンドで可能だ。以下のコマンドでマウントを行った。

# mount -t glusterfs gluster-01:test001 /mnt

簡易テスト

マウントが正常に完了すれば、書き込み可能なボリュームとして利用可能だ。以下のコマンドで簡易テストを行った。

ディレクトリリスティングのテスト

[root@gluster-cl-01 ~]# cd /mnt
[root@gluster-cl-01 mnt]# ls -l
total 0
[root@gluster-cl-01 mnt]# touch file1 file2 file3 file4 file5
[root@gluster-cl-01 mnt]# ls -l
total 0
-rw-r--r-- 1 root root 0 Nov 30 01:22 file1
-rw-r--r-- 1 root root 0 Nov 30 01:22 file2
-rw-r--r-- 1 root root 0 Nov 30 01:22 file3
-rw-r--r-- 1 root root 0 Nov 30 01:22 file4
-rw-r--r-- 1 root root 0 Nov 30 01:22 file5
[root@gluster-cl-01 mnt]#

ファイルシステムの選択が適切でないと、ディレクトリリスティングのテストでいきなり失敗する事になる。標準のext4でフォーマットされたボリュームをブリックに利用していると、上記のテストが失敗し、作成したファイルの一部しかlsコマンドで表示されない。その場合はext3のボリュームを利用する等して、サーバー側の設定を修正しなければならない。

これで GlusterFS の検証環境が完了した。次回は実際の試験を実施した報告をしたい。