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

分散ファイルシステム「GlusterFS」の検証その2

前回の記事では、分散ファイルシステムであるGlusterFSを利用するに当たり、初期設定を行った。今回はこれらのシステムを利用してテストを行おう。

テスト環境の確認

実際のテストを開始する前に、前回構築したテスト環境のブロック図を紹介しておこう。

GlusterFSサーバー群は、FUSE機構でマウント可能なストレージ領域を提供している。GlusterFSクライアント群は、これらのストレージをマウントし、subversionリポジトリ、gitリポジトリ等を設置し、アプリケーションサーバーとしての役目を果たしている。アプリケーションクライアント群は、GlusterFSクライアントに接続し、subversionリポジトリ、gitリポジトリ等にアクセスしている。

なお、前回の記事ではアプリケーションクライアントの構築は行っていなかった。また、GlusterFSサーバーも3台で構成し、4台目は利用していなかった。

アプリケーションクライアントについては、今回の記事の最初で構築を行う。4台目のGlusterFSサーバーについては、ストレージ容量追加のテストの際に構築を行う。

アプリケーションクライアントの設定

最初にアプリケーションクライアントの設定を行おう。これらの機器は、GlusterFSクライアントが提供するサービスを利用するシステムであり、具体的には subversion と gitの作業ディレクトリを運用する。実働システムにおいては、PC等に相当するシステムだ。

ホスト名設定

アプリケーションクライアントのホスト名は、”app-cl-01″ とした。hostnameコマンドで以下のように設定する

# hostname gluster-cl-01

恒久的に利用できるように、 /etc/suscopngif/network の設定も変更しておこう。

名前解決

GlusterFSサーバーとGlusterFSクライアントの名前が解決できるように、以下の設定を行った。各IPアドレスは、それぞれの環境に従って変更して欲しい。

10.156.58.117 gluster-01
10.158.171.177 gluster-02
10.148.10.54 gluster-03
10.146.99.117 gluster-cl-01
10.146.43.81 gluster-cl-02

今回はGlusterFSサーバーの名前解決もできるように設定したが、これらはテスト目的でのみ必要な物だ。GlusterFSサーバーに直接アクセスする場合と、GlusterFSクライアントを経由して利用した場合でストレージへのアクセス速度にどの程度の差が発生するか等を確認するため、アプリケーションクライアントから直接GlusterFSサーバーに接続する必要があったためだ。

実働環境においては、GlusterFSクライアントの名前だけが解決できれば良い。

アプリケーションのインストール

subversionとgitでテストを行うため、以下のコマンドでアプリケーションをインストールした。

yum install -y subversion
yum install -y git

また、必要最小限の初期設定として、以下のコマンドを実行した。

[ec2-user@app-cl-01 ~]$ git config --global user.name testuser-01
[ec2-user@app-cl-01 ~]$ git config --global user.email testuser-01@domain

テストの準備

今回は主にバージョン管理システムとしての動作を検証する事にした。まず最初にGlusterFSクライアントにリポジトリを作成し、アプリケーションクライアントからアクセスできる環境を整える事にしよう。

GlusterFSクライアントでの準備

subversion および gitの管理用コマンドを利用し、それぞれのリポジトリを作成した。さまざまなテスト用に、subversion、gitそれぞれで、4つのリポジトリを用意している。実行したコマンドは以下の通りだ。

[root@gluster-cl-01 ~]# svnadmin create /mnt/svnrepo-01
[root@gluster-cl-01 ~]# chown -R ec2-user:ec2-user /mnt/svnrepo-01
[root@gluster-cl-01 ~]# svnadmin create /var/svnrepo-02
[root@gluster-cl-01 ~]# chown -R ec2-user:ec2-user /var/svnrepo-02
[root@gluster-cl-01 ~]# svnadmin create /mnt/svnrepo-03
[root@gluster-cl-01 ~]# chown -R ec2-user:ec2-user /mnt/svnrepo-03
[root@gluster-cl-01 ~]# svnadmin create /var/svnrepo-04
[root@gluster-cl-01 ~]# chown -R ec2-user:ec2-user /var/svnrepo-04

[root@gluster-cl-01 mnt]# git init --bare /mnt/git-01
[root@gluster-cl-01 mnt]# chown -R ec2-user:ec2-user /mnt/git-01
[root@gluster-cl-01 mnt]# git init --bare /var/git-02
[root@gluster-cl-01 mnt]# chown -R ec2-user:ec2-user /var/git-02
[root@gluster-cl-01 mnt]# git init --bare /mnt/git-03
[root@gluster-cl-01 mnt]# chown -R ec2-user:ec2-user /mnt/git-03
[root@gluster-cl-01 mnt]# git init --bare /var/git-04
[root@gluster-cl-01 mnt]# chown -R ec2-user:ec2-user /var/git-04
[root@gluster-cl-01 mnt]#

svnrepo-02, svnrepo-04, git-02, git-04 は、GlsuterFSクライアントのローカルストレージ上に作成したリポジトリだ。これらはGlusterFSのボリュームと比較した場合の検証用として用意している。 svnrepo-01, svnrepo-03, git-01, git-03は、FUSE機構を利用してマウントした、GlusterFSのボリューム上に配置している。

アプリケーションクライアントでの準備

アプリケーションクライアントではバージョン管理システムに登録するソースファイルが必要だ。今回は apacheのソースコードを利用する事にした。以下のコマンドで取得し、アーカイブファイルを展開している。

[ec2-user@app-cl-01 ~]$ wget http://ftp.meisei-u.ac.jp/mirror/apache/dist//httpd/httpd-
2.4.3.tar.bz2
[ec2-user@app-cl-01 ~]$ tar xjfv httpd-2.4.3.tar.bz2

テストの実行

ロックテスト

NFS等の分散ファイルシステムを利用する時、まず最初に気になるのがファイルのロック機構が正しく実装されているかどうかだ。GlusterFSでも気になる所であり、まずはその辺からテストしてみよう。

今回は簡単なPHPスクリプトを利用してテストする事にした。スクリプトの内容は以下の通りである。

< ?php
$fn = '/mnt/testfile1';
$fp = fopen($fn, 'w');
print "Lock Waiting...";
flock($fp, LOCK_EX);
print "\nLock Complete.\n";
sleep(10);
?>

このスクリプトでは、 /mnt/testfile1 をオープンし、排他的ロックを実行する。その後10秒間待ってからスクリプトを終了している。ロックが正しく実装されているファイルシステムにおいては、2台のクライアントマシンから時間をずらして上記スクリプトを実行した場合、先に実行した方が終了してから後に実行した方で”Lock Complete.”が表示されるはずである。なぜなら先に実行した方がファイルをロックしている最中は、後に実行した方が解除されるまで待たなければならないからだ。

テストは2台のGlusterFSクライアントで実行した。テスト内容は以下の通りである。

gluster-cl-01 で上記スクリプトを実行する
5秒待つ
gluster-cl-02 で上記スクリプトを実行する

結果は以下の通りである。

手順1の実行直後に、gluster-cl-01において”Lock Waiting…” および “Lock Complete.”がすぐに表示された
手順3の実行直後に、gluster-cl-02において”Lock Waiting…” が表示された
手順1の実行から約10秒後に、gluster-cl-01 のスクリプトが終了した
結果3とほぼ同時に、gluster-cl-02において”Lock Complete.”が表示された
結果4から約10秒後に、gluster-cl-02 のスクリプトが終了した

上記結果を見る限り、ロック機構は正しく動作していると言えるだろう。より詳細なテストとしては多数のクライアントから同時にロックを行った場合の検証等があるが、今回は実行していない。

import テスト

アプリケーションサーバーからimportコマンドを実行し、GlusterFSクライアントのリポジトリに登録するテストを行ってみよう。

アプリケーションクライアントから以下のコマンドを実行した。

[ec2-user@app-cl-01 ~]$ time svn import httpd-2.4.3 svn+ssh://gluster-cl-01:/mnt/svnrepo-01 -m
http-source
...
Committed revision 1.
real 4m2.144s
user 0m8.669s
sys 0m0.424s
[ec2-user@app-cl-01 ~]$ time svn import httpd-2.4.3 svn+ssh://gluster-cl-01:/var/svnrepo-02 -m
http-source
...
Committed revision 1.
real 0m24.324s
user 0m8.061s
sys 0m0.412s
[ec2-user@app-cl-01 ~]$ time svn import httpd-2.4.3 svn+ssh://gluster-cl-01:/mnt/svnrepo-03 -m
http-source
...
Committed revision 1.
real 4m3.785s
user 0m8.281s
sys 0m0.360s
[ec2-user@app-cl-01 ~]$ time svn import httpd-2.4.3 svn+ssh://gluster-cl-01:/var/svnrepo-04 -m
http-source
...
Committed revision 1.
real 0m23.489s
user 0m8.933s
sys 0m0.456s
[ec2-user@app-cl-01 ~]$

クライアント側のキャッシュの影響を考慮し、計4つのリポジトリに対し交互に2回ずつ実行した。上記のコマンドは2回目以降の結果であり、登録するソースファイルはキャッシュされている状態での実行結果と思ってもらいたい。

実行結果を表にまとめると以下の通りだ。

subversion リポジトリへの登録時間

	GlusterFS	ローカルストレージ
1回目	4m2.144s	0m24.324s
2回目	4m3.785s	0m23.489s

GlusterFSのストレージ上に構築されたリポジトリへは、apacheのソースファイルをインポートするのに約4分程度掛かっている。これに対し、ローカルストレージの場合は25秒未満で完了した。約10倍の差がある事が分かる。なお、ここで言うローカルストレージとは、GlusterFSクライアントのローカルストレージという意味であり、アプリケーションクライアントのローカルストレージでは無い。従ってアプリケーションクライアントとGlusterFSクライアント間の通信量はほぼ同じだ。

次にgitでテストしてみよう。

実行したコマンドは以下の通りである。

[ec2-user@app-cl-01 ~]$ git clone ssh://gluster-cl-01/mnt/git-01
[ec2-user@app-cl-01 ~]$ cd git-01/
[ec2-user@app-cl-01 git-01]$ cp -pr ../httpd-2.4.3 .
[ec2-user@app-cl-01 git-01]$ git add httpd-2.4.3
[ec2-user@app-cl-01 git-01]$ git commit -m "httpd commit"
[ec2-user@app-cl-01 git-01]$ time git push origin master
Counting objects: 2213, done.
Compressing objects: 100% (2164/2164), done.
Writing objects: 100% (2213/2213), 6.73 MiB | 3.08 MiB/s, done.
Total 2213 (delta 921), reused 0 (delta 0)
To ssh://gluster-cl-01/mnt/git-01
* [new branch] master -> master
real 0m10.500s
user 0m3.608s
sys 0m0.292s
[ec2-user@app-cl-01 git-01]$
[ec2-user@app-cl-01 git-01]$ cd ~
[ec2-user@app-cl-01 ~]$ git clone ssh://gluster-cl-01/var/git-02
[ec2-user@app-cl-01 ~]$ cd git-02/
[ec2-user@app-cl-01 git-02]$ cp -pr ../httpd-2.4.3 .
[ec2-user@app-cl-01 git-02]$ git add httpd-2.4.3
[ec2-user@app-cl-01 git-02]$ git commit -m "httpd commit"
[ec2-user@app-cl-01 git-02]$ time git push origin master
Counting objects: 2213, done.
Compressing objects: 100% (2164/2164), done.
Writing objects: 100% (2213/2213), 6.73 MiB | 3.91 MiB/s, done.
Total 2213 (delta 921), reused 0 (delta 0)
To ssh://gluster-cl-01/var/git-02
* [new branch] master -> master
real 0m4.202s
user 0m3.536s
sys 0m0.208s
[ec2-user@app-cl-01 git-02]$ cd ~
[ec2-user@app-cl-01 ~]$ git clone ssh://gluster-cl-01/mnt/git-03
[ec2-user@app-cl-01 ~]$ cd git-03/
[ec2-user@app-cl-01 git-03]$ cp -pr ../httpd-2.4.3 .
[ec2-user@app-cl-01 git-03]$ git add httpd-2.4.3
[ec2-user@app-cl-01 git-03]$ git commit -m "httpd commit"
[ec2-user@app-cl-01 git-03]$ time git push origin master
Counting objects: 2213, done.
Compressing objects: 100% (2164/2164), done.
Writing objects: 100% (2213/2213), 6.73 MiB | 2.53 MiB/s, done.
Total 2213 (delta 921), reused 0 (delta 0)
To ssh://gluster-cl-01/mnt/git-03
* [new branch] master -> master
real 0m10.952s
user 0m3.500s
sys 0m0.212s
[ec2-user@app-cl-01 git-03]$
[ec2-user@app-cl-01 git-03]$ cd ~
[ec2-user@app-cl-01 ~]$ git clone ssh://gluster-cl-01/var/git-04
[ec2-user@app-cl-01 ~]$ cd git-04/
[ec2-user@app-cl-01 git-04]$ cp -pr ../httpd-2.4.3 .
[ec2-user@app-cl-01 git-04]$ git add httpd-2.4.3
[ec2-user@app-cl-01 git-04]$ git commit -m "httpd commit"
[ec2-user@app-cl-01 git-04]$ time git push origin master
Counting objects: 2213, done.
Compressing objects: 100% (2164/2164), done.
Writing objects: 100% (2213/2213), 6.73 MiB | 3.69 MiB/s, done.
Total 2213 (delta 921), reused 0 (delta 0)
To ssh://gluster-cl-01/var/git-04
* [new branch] master -> master
real 0m4.621s
user 0m3.616s
sys 0m0.216s
[ec2-user@app-cl-01 git-04]$

実行結果をまとめると以下の通りだ。

git リポジトリへの登録時間

	GlusterFS	ローカルストレージ
1回目	0m10.500s	0m4.202s
2回目	0m10.952s	0m4.621s

subversionの場合と比較すると、かなり高速に動作している。GlusterFS上のリポジトリに登録する場合でも約10秒で完了した。ただし、ローカルストレージへの登録の方が速い事に変わりなく、約4秒程度で終了している。ただし、subversionにおいては10倍の性能差が確認されたが、gitの場合は約2.5倍の性能差に留まっている。

この結果は、subversionとgitを比較した場合のソフトウェアの仕様や性能差等からも強い影響を受けていると言えるだろう。

brickの追加テスト

事前準備

今度はbrickの追加について、動作を確認してみよう。まず、事前準備として、現在のストレージの状態を確認する。以下はimportテストを行った直後のストレージの状態だ。

[root@Gluster-01 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8256952 957552 7215544 12% /
tmpfs 848480 0 848480 0% /dev/shm
/dev/xvdf5 20635668 195616 19391816 1% /var/bricks
[root@Gluster-01 ~]#

[root@Gluster-02 ~]# df
Filesystem 1K- %
/dev/xvda1 8256952 957560 7215536 12% /
tmpfs 848480 0 848480 0% /dev/shm
/dev/xvdf5 20635668 195236 19392196 1% /var/bricks
[root@Gluster-02 ~]#

[root@gluster-03 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8256952 957432 7215664 12% /
tmpfs 848480 0 848480 0% /dev/shm
/dev/xvdf5 20635668 201220 19386212 2% /var/bricks
[root@gluster-03 ~]#

[root@gluster-cl-01 mnt]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8256952 1036504 7136592 13% /
tmpfs 304368 0 304368 0% /dev/shm
gluster-01:test001 61906944 592128 58170112 2% /mnt
[root@gluster-cl-01 mnt]#

3台のGlusterFSサーバーはそれぞれ20GBの領域をブリック領域として持っており、/var/bricksにマウントされている。それぞれ約200MB程度利用されているようだ。

一方、GlusterFSクライアントから見てみると、マウント領域は約60GBの領域として認識されており、利用されている領域も約600MBとなっている。

3台のGlusterFSのブリック領域が、束ねられている様子が見てとれると言えるだろう。

GlusterFSサーバーの追加

ブリック追加のために、4台目のGlusterFSサーバーを準備しよう。基本的な作成手順は前回の「GlusterFSサーバーのインストールと設定」で行った方法と一緒だ。名前は、gluster-04 とした。gluster-04の基本設定が完了したら、gluster-01からgluster-03までのGlusterFSサーバー、およびGlusterFSクライアントで名前解決ができるように/etc/hostsファイルを変更して欲しい。

構築が完了したら、信頼関係の追加を行う。信頼関係の追加はどのGlusterFSサーバーで行ってもよいが、gluster-01で行った。

まず、現在の状態を確認する。以下の通りとなった。

[root@Gluster-01 ~]# gluster peer status
Number of Peers: 2
Hostname: gluster-02
Uuid: 8701de7b-e947-4efe-92ac-c3ac47315c3d
State: Peer in Cluster (Connected)
Hostname: gluster-03
Uuid: 7e7aa2c5-97af-49a3-831e-4063108640e8
State: Peer in Cluster (Connected)

Gluster-01, Gluster-02, gluster-03の3台のサーバーで信頼関係が構築されている事が分かる。ここに gluster-04を追加してみよう。

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

上記コマンドを実行したら、再度ステータスを確認してみよう。以下の通りだ。

[root@Gluster-01 ~]# gluster peer status
Number of Peers: 3
Hostname: gluster-02
Uuid: 8701de7b-e947-4efe-92ac-c3ac47315c3d
State: Peer in Cluster (Connected)
Hostname: gluster-03
Uuid: 7e7aa2c5-97af-49a3-831e-4063108640e8
State: Peer in Cluster (Connected)
Hostname: gluster-04
Uuid: 8b3a909a-f70b-4bd7-884a-788532656989
State: Peer in Cluster (Connected)
[root@Gluster-01 ~]#

4台のサーバーで信頼関係が構築された様子が分かる。

ブリックの追加

次にブリックの追加を実行するのだが、これも実行の前に現在の状態を確認しておこう。以下の通りである。

[root@Gluster-01 ~]# gluster volume status
Status of volume: test001
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick gluster-01:/var/bricks/test001 24009 Y 19695
Brick gluster-02:/var/bricks/test001 24009 Y 19751
Brick gluster-03:/var/bricks/test001 24009 Y 19543
NFS Server on localhost 38467 Y 19701
NFS Server on gluster-04 38467 Y 1636
NFS Server on gluster-03 38467 Y 19549
NFS Server on gluster-02 38467 Y 19757

3つのブリックが認識されている事が分かるだろう。この状態を確認したら、以下のコマンドでブリックの追加を行なおう。

[root@Gluster-01 ~]# gluster volume add-brick test001 gluster-04:/var/bricks/test001
Add Brick successful

再び状態を確認すると以下の通りだ。

[root@Gluster-01 ~]# gluster volume status
Status of volume: test001
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick gluster-01:/var/bricks/test001 24009 Y 19695
Brick gluster-02:/var/bricks/test001 24009 Y 19751
Brick gluster-03:/var/bricks/test001 24009 Y 19543
Brick gluster-04:/var/bricks/test001 24009 Y 1642
NFS Server on localhost 38467 Y 20304
NFS Server on gluster-02 38467 Y 20295
NFS Server on gluster-03 38467 Y 20091
NFS Server on gluster-04 38467 Y 1648
[root@Gluster-01 ~]#

4つのブリックが認識されている。ではこれをクライアント側から確認するとどうなるだろうか。結果は以下の通りだ。

[ec2-user@gluster-cl-01 ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8256952 1036516 7136580 13% /
tmpfs 304368 0 304368 0% /dev/shm
gluster-01:test001 61906944 592128 58170112 2% /mnt
[ec2-user@gluster-cl-01 ~]$

ブリック追加前と結果は変わっていない。しかし数秒待ってから再実行したら、以下のようになった。

[ec2-user@gluster-cl-01 ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8256952 1036516 7136580 13% /
tmpfs 304368 0 304368 0% /dev/shm
gluster-01:test001 82542592 768256 77581440 1% /mnt
[ec2-user@gluster-cl-01 ~]$

上記の通り、ブリックの追加によりストレージ容量が増えているのが分かる。結果が反映されるまでには数秒を要するようなので、あわてずしばらく様子を見てみよう。

ファイルの設置と確認

容量を拡大したストレージ領域に、実際にファイルを設置してみよう。GlusterFSクライアントから、複数のファイルを作成し、その様子を確認してみた。実行したコマンドは以下の通りである。

[root@gluster-cl-01 ~]# cd /mnt
[root@gluster-cl-01 mnt]# touch file6 file7 file8 file9 file10 file11
[root@gluster-cl-01 mnt]# ls -l
total 64
-rw-r--r-- 1 root root 0 Nov 30 01:22 file1
-rw-r--r-- 1 root root 0 Nov 30 03:54 file10
-rw-r--r-- 1 root root 0 Nov 30 03:54 file11
-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
-rw-r--r-- 1 root root 0 Nov 30 03:54 file6
-rw-r--r-- 1 root root 0 Nov 30 03:54 file7
-rw-r--r-- 1 root root 0 Nov 30 03:54 file8
-rw-r--r-- 1 root root 0 Nov 30 03:54 file9
drwxr-xr-x 2 ec2-user ec2-user 16384 Nov 30 03:53 git-01
drwxr-xr-x 7 ec2-user ec2-user 16384 Nov 30 03:53 git-03
drwxr-xr-x 6 ec2-user ec2-user 16384 Nov 30 03:53 svnrepo-01
drwxr-xr-x 6 ec2-user ec2-user 16384 Nov 30 03:53 svnrepo-03
-rw-r--r-- 1 root root 0 Nov 30 01:32 testfile1
[root@gluster-cl-01 mnt]#

新しく追加されたファイルが存在している事が分かる。なお、file1 から file5、および testfile1は、これまでのテストで作成したファイルだ。git-01, git-03, svnrepo-01, svnrepo-03も、以前に作成したバージョン管理システム用のリポジトリである。

GlusterFSクライアントからファイルを追加したら、新規に追加したgluster-04でどのようになっているか確認してみよう。

[root@gluster-04 ~]# ls -l /var/bricks/test001/
total 16
drwxr-xr-x 2 ec2-user ec2-user 4096 Nov 30 03:53 git-01
drwxr-xr-x 2 ec2-user ec2-user 4096 Nov 30 03:53 git-03
drwxr-xr-x 2 ec2-user ec2-user 4096 Nov 30 03:53 svnrepo-01
drwxr-xr-x 2 ec2-user ec2-user 4096 Nov 30 03:53 svnrepo-03
[root@gluster-04 ~]#

ブリックの中を覗いてみたが、特にファイルが増えている様子は無い。しかし、リポジトリのディレクトリだけは存在しているようだった。ディレクトリの中にどのようなファイルが設置されているか見てみよう。

[root@gluster-04 ~]# find /var/bricks/test001/
/var/bricks/test001/
/var/bricks/test001/git-03
/var/bricks/test001/git-01
/var/bricks/test001/.glusterfs
/var/bricks/test001/.glusterfs/00
/var/bricks/test001/.glusterfs/00/00
/var/bricks/test001/.glusterfs/00/00/00000000-0000-0000-0000-000000000001
/var/bricks/test001/.glusterfs/70
/var/bricks/test001/.glusterfs/70/eb
/var/bricks/test001/.glusterfs/70/eb/70ebb424-1e81-41e9-b886-c8fcded970c3
/var/bricks/test001/.glusterfs/4f
/var/bricks/test001/.glusterfs/4f/79
/var/bricks/test001/.glusterfs/4f/79/4f793973-950e-4da7-a0da-86c1df505fc9
/var/bricks/test001/.glusterfs/ed
/var/bricks/test001/.glusterfs/ed/aa
/var/bricks/test001/.glusterfs/ed/aa/edaa0684-b8b3-47c9-8c24-24c1194a152f
/var/bricks/test001/.glusterfs/30
/var/bricks/test001/.glusterfs/30/f0
/var/bricks/test001/.glusterfs/30/f0/30f0d1e0-7874-4dd5-8380-93de712d3407
/var/bricks/test001/svnrepo-01
/var/bricks/test001/svnrepo-03
[root@gluster-04 ~]#

findコマンドで列挙された物は、いずれもディレクトリであり、一般ファイルは存在していない。どうやらボリュームの追加直後はディレクトリだけが追加され、ファイルは追加されないようだ。

リバランスの実行

実はGlusterFSでは、新規に追加されたブリックは、そのままでは有効利用されない。GlusterFSクライアントから有効に利用されるようにするためには、リバランスが必要である。以下はそのコマンドだ。

[root@Gluster-01 ~]# gluster volume rebalance test001 start
Starting rebalance on volume test001 has been successful
[root@Gluster-01 ~]#

リバランスは状況によっては数時間かかる場合もあるが、今回は設置されているファイルも少ないためにすぐに終了した。リバランス終了後に再び gluster-04のブリックの様子を見ると以下のようになっていた。

[root@gluster-04 ~]# ls -l /var/bricks/test001/
total 16
-rw-r--r-- 2 root root 0 Nov 30 03:54 file11
-rw-r--r-- 2 root root 0 Nov 30 03:54 file7
drwxr-xr-x 7 ec2-user ec2-user 4096 Nov 30 03:59 git-01
drwxr-xr-x 7 ec2-user ec2-user 4096 Nov 30 03:59 git-03
drwxr-xr-x 6 ec2-user ec2-user 4096 Nov 30 03:59 svnrepo-01
drwxr-xr-x 6 ec2-user ec2-user 4096 Nov 30 03:59 svnrepo-03
[root@gluster-04 ~]#

リバランス後の性能評価

リバランス後に新たなリポジトリを作成し、その時間を計測してみた。まず、GlusterFSクライアントで以下のコマンドを実行し、新規リポジトリを作成した。

[root@gluster-cl-01 ~]# svnadmin create /mnt/svnrepo-05
[root@gluster-cl-01 ~]# chown -R ec2-user:ec2-user /mnt/svnrepo-05

この状態でアプリケーションサーバーからimportコマンドを実行してみた。

[ec2-user@app-cl-01 ~]$ time svn import httpd-2.4.3 svn+ssh://gluster-cl-01:/mnt/svnrepo-05 -m
http-source
...
Committed revision 1.
real 4m50.667s
user 0m8.225s
sys 0m0.364s

ブリック追加前には4分程度で終了していたが、同じコマンドの実行結果が4分50秒程かかるようになってしまったようだ。

exportテスト

次に、GlusterFSクライアントからの読み込み性能を検証してみよう。subversionのexportコマンド、および gitの pullコマンドをテストに使用してみた。実行したコマンドは以下の通りである。

subversion

time svn export svn+ssh://gluster-cl-01:/mnt/svnrepo-01 test1

git

time git pull ssh://gluster-cl-01/mnt/git-01

実行結果は以下の通りだ。

subversion

	GlusterFS	ローカルストレージ
1回目	0m33.844s	0m2.399s
2回目	0m42.661s	0m2.620s

git

	GlusterFS	ローカルストレージ
1回目	0m1.441s	0m1.424s
2回目	0m2.279s	0m1.265s

やはりローカルストレージに比べて性能劣化が存在するが、書き込み時ほどではないようだ。また、gitの場合は大きな性能劣化が見られないのも特徴的である。

subversion のcommitテスト

今度はcommitの実行時間を計測してみよう。apacheの全C言語ソースファイルの末尾にコメントを追加し、commitした時間を測定してみた。実行したコマンドは以下の通りである。

find test11 -path '*.svn/*' -prune -o -type f -a -name '*.c' -exec sh -c 'echo "/*test*/" >> {}' ';'
time svn commit -m 'test' test11 >/dev/null

実行結果は以下の通りだ。

GlusterFS	ローカルストレージ
0m17.011s	0m2.520s

環境をリセットし、何度か実行しているが、大方上記のような結果となった。

ところでsubversionの場合、リポジトリ内の db/transactions というディレクトリを高速なデバイスにシンボリックリンクするとcommit時の性能が上がるというハウツーが存在する。そこでGlusterFSのリポジトリ内にあるこれらのディレクトリを、ローカルストレージにシンボリックリンクし、再計測してみた。結果は以下の通りである。

GlusterFS(db/transactions をローカルにシンボリックリンク)
0m10.723s

かなりの効果があるようだ。subversionのリポジトリとして利用する場合には、是非活用したいテクニックである。

冗長化構成のテスト

次にストレージを冗長化した場合の動作検証を行ってみよう。

冗長化ボリュームの作成とマウント

冗長化したボリュームを作成するには、ボリューム作成時に”replica < レプリケーション数>“を指定する。実行したコマンドは以下の通りだ。

[root@Gluster-01 var]# gluster volume create test003 replica 2 gluster-01:/var/bricks/test003 gluster-02:/var/bricks/test003
Creation of volume test003 has been successful. Please start the volume to access data.

今回は gluster-01 と gluster-02 での冗長化を行った。ボリュームを作成したら、利用可能なようにボリュームの開始を行う。これは従来と同じで以下の通りだ。

[root@Gluster-01 var]# gluster volume start test003
Starting volume test003 has been successful

無事ボリュームが開始したら、GlusterFSクライアントからマウントしよう。さらにテスト用のリポジトリも作成しておきたい。操作内容は以下の通りだ。

[root@gluster-cl-01 /]# mkdir /mnt3
[root@gluster-cl-01 /]# mount -t glusterfs gluster-01:test003 /mnt3
[root@gluster-cl-01 /]# svnadmin create /mnt3/svnrepo-06
[root@gluster-cl-01 /]# chown -R ec2-user:ec2-user /mnt3/svnrepo-06/

テスト

アプリケーションクライアントからsubversionの動作を行い、テストしてみよう。まずは問題なく稼働している状態で、subversionによるimport と export を行った。コマンドは以下の通りであり、正常動作を確認した。

[ec2-user@app-cl-01 ~]$ time svn import httpd-2.4.3 svn+ssh://gluster-cl-01:/mnt3/svnrepo-06 -
m http-source
...
Committed revision 1.
real 8m11.746s
user 0m8.345s
sys 0m0.364s
[ec2-user@app-cl-01 ~]$

[ec2-user@app-cl-01 ~]$ time svn export svn+ssh://gluster-cl-01:/mnt3/svnrepo-06 test1
>/dev/null; rm -fR test1
real 0m30.496s
user 0m0.588s
sys 0m0.264s
[ec2-user@app-cl-01 ~]$

次にGlusterFSサーバーで、1台のサーバーでサービスを停止させてみた。以下のコマンドはgluster-01で行っている。

[root@Gluster-01 test002]# service glusterd stop
Stopping glusterd: [ OK ]
[root@Gluster-01 test002]#

これにより、ボリュームはいわゆる片肺飛行の状態になっているが、その後もアプリケーションクライアントからは正常に利用可能である事を確認した。ただし実行時間は増加しているようだ。以下はこの状態で実行したコマンドの一部である。

[ec2-user@app-cl-01 ~]$ time svn export svn+ssh://gluster-cl-01:/mnt3/svnrepo-06 test1
>/dev/null; rm -fR test1
Exported revision 1.
real 1m50.396s
user 0m0.620s
sys 0m0.336s
[ec2-user@app-cl-01 ~]$
[ec2-user@app-cl-01 ~]$

正常な状態では30秒程度で終了したコマンドだが、異常時においては1分50秒程掛かっているようだ。

壊れたボリュームを修正するためには、”volume replace-brick”コマンドを利用する。以下のコマンドを実行し、使えなくなっている gluster-01のブリックの代わりに、gluster-03のブリックを割り当てている。

[root@Gluster-02 ~]# gluster volume replace-brick test003 gluster-01:/var/bricks/test003 gluster-03:/var/bricks/test003a start
replace-brick started successfully
[root@Gluster-02 ~]#

これによりブリックの入れ替えが行われ、再び正常な状態に戻す事が可能だ。

次回は「AWSを使って分散ファイルシステム「GlusterFS」の検証」のまとめをしたいと思う。

分散ファイルシステム「GlusterFS」の検証 その2