3.3. とにかくはじめる(4台のサーバでミラー構成) – GlusterFS Community ではじめる分散ファイルシステム

インストールが完了したら今度は実際にボリュームを構築します。本ステップでは本章で紹介する「4台のサーバでミラー構成」の他に「とにかくはじめる(4台のサーバでストライプ構成)」も紹介します。

ただ、構築の多くの段階は重複した内容となります。その為、どちらの章を読まれても(読まなくても)構いません。両者の相違点はボリューム作成時のオプションと確認方法のみになります。

また、本手順は4台のインストールが完了していることが前提となります。まだ完了していない場合は、GlusterFS をインストールするを参照して実施して下さい。

はじめる前に構成の説明

本章では「4台のサーバでミラー構成」としていますが厳密にはディストリビューテッドレプリケーテッドボリュームという構成を使用します。

純粋なミラーという意味だと本来レプリケーテッドボリュームが該当するのですが、これを今回用意した4台のサーバで実現した場合、4つのレプリカ(複製)を使って4台それぞれのサーバに同じファイルを置くことになります。

この場合、可用性は高い(4つのうち1つでもノードが生きていればアクセス可能)のですが、ここまでの可用性が期待されるシステムはそうないと考えられます。また、ハードディスク容量としても4つのサーバのうちの一番少ないものが採用され、今後容量拡張もできなくなります。

そこで2つのレプリカを使い4台のサーバのいずれかにこのレプリカの組みを分散させる方法が今回採用する「ディストリビューテッドレプリケーテッドボリューム」になります。

この構成では1つのノードが落ちてしまってもそのレプリカが残っていれば問題なくアクセスすることができます。また、サーバ台数を増やすことで容量拡張もできるようになります(これはディストリビューテッド構成の特徴)。

今回はこのレプリカを2つにして4台の構成で「ディストリビューテッドレプリケーテッドボリューム」を構成します。

他のサーバを承認する

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 という名前で各サーバに作成します。

# mkdir -p /srv/test-vol

次にボリュームを作成します。

<p>これでボリューム作成は完了です。このボリュームを確認してみましょう。</p>

<div>::CODECOLORER_BLOCK_3::</div>

<p>サーバの構成によっては &#8220;The brick server01:/srv/test-vol is being created in the root partition.&#8221; のようなエラーが出る場合があります。これはその OS 内の /(root)パーティション内を共有しようとしている為に出るエラーです。root パーティションを使うことは非推奨ですがどうしても使いたい場合はコマンドの一番最後に &#8220;--force&#8221; というオプションを付けて実行して下さい。</p>
</div>
<div class="section" id="id5">
<h2>ボリュームを開始する</h2>
<p>ボリュームは作成されましたが、このままではまだ動いていない状態です。 <strong class="command">gluster volume start</strong> コマンドを使ってボリュームを開始しましょう。</p>
<code># gluster volume start test-vol

これでボリュームが開始されました。

マウントする

続いて今度はクライアント側の作業になります。今回はこの4台のサーバに GlusterFS ネイティブクライアントと呼ばれる GlusterFS が提供するクライアント(性能が良い)とせっかくなので NFS クライアントでマウントしてみます。

# mkdir -p /mnt/test-vol
# mount -t glusterfs server01:/test-vol /mnt/test-vol

mount -t glusterfs <ノード>:/<ボリューム> <マウント先> のようにコマンドを実行しますが、特に <ボリューム> には気をつけてください。スラッシュの後にボリュームを記載します(ボリューム Create 時に指定したノードのディレクトリ(ブリック)ではありません)。

また、<ノード> を直接指定している点にも注目して下さい。ここでノードを指定しているので「このノードが落ちたら使えなくなるのではないか?」と思ってしまいますがそうではありません。

このノードは最初の接続先を示すもので実際にこのノードが落ちてしまっても他のノードが生きている限り、今回のようにレプリカ構成の場合であればレプリカが生きている限り読み書き共に問題なく利用可能です。

GlusterFS のコマンド出力結果だけでは何が起きているのか判断がつかないこともあります。例えばこの mount に失敗していても実際にはマウントはできていない場合も多々あります。この場合 /var/log/glusterfs/mnt-<ボリューム>.log を見てエラー(E のラベルが付けられた行)が出ていないかを確認して下さい。

OS 起動時に自動でマウントする

マウントするで示した方法はその場でマウントすることは可能ですが OS が停止して再度起動した時にももう一度実行する必要が出てしまいます。

OS 起動時も一緒にマウントするには /etc/fstab に記載しておく必要があります。例えば以下のように記載します。

# server01:/test-vol /mnt/test-vol glusterfs _netdev,defaults 0 0

なお、Ubuntu についてはこの設定に加えて以下のコマンドで OS 起動時のモジュールに fuse も加える必要があります。

# sh -c &#8220;echo fuse &gt;&gt; /etc/modules&#8221;

また、今回は NFS 経由でのマウントも行なっています。NFS 経由のマウントは次のように実行します(GlusterFS では nfs バージョン3 しか対応していません)。

# mount -t nfs -o vers=3 server01:/test-vol /mnt/test-vol

ミラーが行われたか見てみる

セットアップが無事完了したら、実際に使ってみましょう。

今回はファイルの共有とミラーリングの確認を行います。2つのクライアントを通して同じファイルが書き込めれば十分ですね。

最初に GlusterFS ネイティブクライアントを使って次のようにファイルを書き込みます。

# mkdir -p /mnt/test-vol/share001 # テスト用のディレクトリ
# chown foo:foo /mnt/test-vol/share001 # 所有者を自分に
# date | tee /mnt/test-vol/share001/date.txt
2014年  2月 12日 水曜日 18:33:11 JST

次に NFS クライアントを使ってネイティブクライアントで作成した date.txt を確認し、新しく date2.txt を作ってみます。

# /mnt/test-vol/share001
# cat date.txt # ネイティブクライアントで作成したファイルを確認
2014年  2月 12日 水曜日 18:33:11 JST
$ date | tee date2.txt
2014年  2月 12日 水曜日 23:40:13 JST

最後にもう一度 GlusterFS ネイティブクライアントで NFS クライアントで作成したファイルを確認します。

$ cat /mnt/test-vol/share001
2014年  2月 12日 水曜日 23:40:13 JST

これでファイル間の同期(ミラー)が行われたことが確認できました。

No Comments - Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

*