今度は４台のサーバでストライプ構成を作成してみます。
このストライプボリュームについて補足します。このボリュームは１つのファイルを分割し複数台のノードで保持して読み書きを行う為、処理が分散され高速化が期待できます。
ただし、この複数台のノードのうちのたった１つのノードでも落ちた場合、ファイルへのアクセスができなくなってしまう為、可用性がガクンと下がってしまいますので注意して下さい。
効果が高いのは大きな動画等のキャッシュ用のディレクトリ等が考えられます。
本章はとにかくはじめる（４台のサーバでミラー構成）か本章のいずれかだけを読んだ場合でも問題なく読み進められるようにほぼ同じ内容となっても掲載することにしています。ほぼ重複した内容が存在することをご容赦下さい。
他のサーバを承認する
GlusterFS では各ノードを連結する為に承認というプロセスを利用します。既に存在するどこかのノード（1台）で他のノードを承認することでノード間の連結が完了します。
この連結が完了したノード群をトラステッドプール（trusted pool）と呼びます。それでは gluster peer probe を使って他のノードを承認してみましょう。このコマンドはどれか 1台のサーバでのみ実行します。自分自身のノードに対して実行する必要はありません。
# gluster peer probe server02
# gluster peer probe 192.168.33.30 # IP 指定も可能
# gluster peer probe server04承認した後、 gluster peer status コマンドを使ってノードの状態を見てみます。
# gluster peer status
Number of Peers: 3
Hostname: server02
Uuid: e46a8961-7cd4-41bf-aebc-c9d357508882
State: Peer in Cluster (Connected)
Hostname: 192.168.33.30
Uuid: 1b232e41-ab35-40c7-a5bd-0765f2a164c4
State: Peer in Cluster (Connected)
Hostname: server04
Uuid: d4a31d8b-8eaa-4833-913e-3d5d45552d0e
State: Peer in Cluster (Connected)このノードのステータスには自分自身のノードは含まれません。UUID は GlusterFS が一意に振ったノードの ID になります。ステータスを確認した時に自分が登録したノードが全て表示されていれば問題ありません。
なお gluster peer probe コマンド実行時に “Probe returned with unknown errono 107” と表示された場合、それは通信に失敗していることを意味します。この場合ファイアウォールの設定ミスやそもそも通信ができているかを再確認して下さい。
ボリュームを作成する
ボリューム作成時はそれぞれのノードに共有先のディレクトリが必要になります。今回はこの共有ディレクトリを /srv/test-vol という名前で各サーバに作成します。
# sudo mkdir -p /srv/test-vol次にボリュームを作成します。
# gluster volume create test-vol stripe 4 transport tcp server01:/srv/test-vol server02:/srv/test-vol server03:/srv/test-vol server04:/srv/test-volこれでボリューム作成は完了です。このボリュームを確認してみましょう。
# gluster volume info test-vol
Volume Name: test-vol
Type: Stripe
Volume ID: 0e4adcb7-9857-407b-954d-f7d47d331cc3
Status: Started
Number of Bricks: 1 x 4 = 4
Transport-type: tcp
Bricks:
Brick1: server01:/srv/test-vol
Brick2: server02:/srv/test-vol
Brick3: server03:/srv/test-vol
Brick4: server04:/srv/test-volボリュームを開始する
ボリュームは作成されましたが、このままではまだ動いていない状態です。 gluster volume start コマンドを使ってボリュームを開始しましょう。
# gluster volume start test-volこれでボリュームが開始されました。
ストライプが行われたか見てみる
次にストライプが設定されたことを確認します。ストライプは一つのファイルが複数のノードに分割される構成ですが、１つのノード上のファイルの中で他のノードで保持されている箇所はスパース（穴）と呼ばれる空白のバイトで埋められます。
今回はこの空白を確かめた上で該当ファイルにアクセスできることを確認してみます。
まずは最初にファイルを作ります。GlusterFS では 128Kbyte 単位で１つのファイルが各ノードに分割される為、1Mbyte のファイルをランダムな文字列で作成します。
$ dd if=/dev/urandom of=/mnt/test-vol/share001/test.img count=1 bs=1Mこれで test.img という 1Mbyte のランダムバイトのファイルが作成されました。
次に、以下の２種類のファイルの８進数ダンプを取得します。
- マウント経由のファイルアクセス:スパースのない完全な状態のファイル
- エクスポート経由のファイルアクセス:GlusterFS の共有元ディレクトリを直接参照したスパース付きのファイル
$ od /mnt/test-vol/share001/test.img > /tmp/mounted_test.txt
$ od /srv/test-vol/share001/test.img > /tmp/exported_test.txtそしてこれらのダンプファイルを比べて見ます。
$ vimdiff /tmp/mounted_test.txt /tmp/exported_test.txtスパース部分は０で埋められていることが分かると思います。
最後にこのファイルのチェックサムを取得し、を他の NFS クライアントでもチェックサムが同じであることを確認してみます。
まず、GlusterFS ネイティブクライアント上でチェックサムを取得します。
$ cd /mnt/test-vol/share001
$ md5sum test.img
9f12851c8a9b3fc8a344671bf771e6b9 test.imgこのチェックサムを元に別のサーバ（クライアント）で NFS 経由でチェックサムを比べてみます。
$ cd /mnt/test-vol/share001
$ echo "9f12851c8a9b3fc8a344671bf771e6b9 test.img" | md5sum -c
test.img: OKこれでチェックサムが一致しました。