4.1. ブリックとトランスレータ – GlusterFS Community ではじめる分散ファイルシステム

4.1. ブリックとトランスレータ

ブリックとその集合

GlusterFS はブリックを集めて一つの(仮想的な)ボリュームとして見せることで分散ファイルシステムを構築しています。

ボリュームはクライアントからはただのファイルシステム(ディレクトリ)のように見えます。これは NFS を使ってマウントした時と同じ状態です。あるいは Windows エクスプローラからネットワーク上のコンピュータにアクセスした時とも同じです(GlusterFS は CIFS をサポートしている為、これも可能)。

ブリックはサーバが共有(NFS ではエクスポートと呼びます)する一つのディレクトリを指します。ボリュームにブリックを指定する時は [Host]:[ディレクトリ] のように指定しこの情報はそのまま GlusterFS に保存されます(gluster volume info で確認できます)。

ボリュームにはファイルが置かれますが、このファイルは GlusterFS の内部でデフォルトで 128Kbyte のファイルに分けられてそれぞれのブリックに保存されます。

ストライプドボリュームの場合、各ブリックには 128Kbyte 単位のスパースと呼ばれる 0(ヌル)のデータが保存され実際のファイルシステムの容量を使わないような工夫がされています。

トランスレータ

GlusterFS はマスタレスな分散ファイルシステムです。マスタが存在しない為、どのノードが落ちてもファイルにアクセスできなくなるということはありません(ボリュームオプションによっては一部ファイルへのアクセスは不可能になります)。

この構成を実現する為に GlusterFS ではクライアント側でも多くの機能が実装されています。これらの機能は動的に変更可能なモジュールとして実装されており、トランスレータと呼ばれます。

トランスレータはノード(サーバ)側でもクライアント側でも使われており、各トランスレータが実現する機能への設定変更も動的に変更可能です。

GlusterFS で設定を行う場合はこのトランスレータに対して行います。例えば次のコマンドのように performance.read-ahread(先読み機能)を Off に設定したとします。

# gluster volume set test-vol performance.read-ahead off
Set volume successful

この場合、read-ahead トランスレータの機能が Off になります。GlusterFS で機能追加が行われる時はこのトランスレータ単位の追加となることも多くこの機能が中心的な役割をしています。

4. ステップ3 GlusterFS を理解する – GlusterFS Community ではじめる分散ファイルシステム

このステップでは GlusterFS を理解することを目的として次のような内容を説明します。

  • ブリックやトランスレータ:GlusterFS の機能構成を理解することでボリュームオプション等の設定が理解することができます。
  • ボリュームオプション:利用者が選択する中で一番重要な要素はボリュームオプションです。GlusterFS では様々なボリュームオプションが用意されていますがこれらの特徴を理解することでシステム要件に合わせた性能や可用性を満たすことができるようになります
  • スケールとブリック追加・削除:GlusterFS ではブリックを追加することで性能向上を図りますがその際の注意点や前提条件について理解することができます。

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

今度は4台のサーバでストライプ構成を作成してみます。

このストライプボリュームについて補足します。このボリュームは1つのファイルを分割し複数台のノードで保持して読み書きを行う為、処理が分散され高速化が期待できます。

ただし、この複数台のノードのうちのたった1つのノードでも落ちた場合、ファイルへのアクセスができなくなってしまう為、可用性がガクンと下がってしまいますので注意して下さい。

効果が高いのは大きな動画等のキャッシュ用のディレクトリ等が考えられます。

本章はとにかくはじめる(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 という名前で各サーバに作成します。

# 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

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

ストライプが行われたか見てみる

次にストライプが設定されたことを確認します。ストライプは一つのファイルが複数のノードに分割される構成ですが、1つのノード上のファイルの中で他のノードで保持されている箇所はスパース(穴)と呼ばれる空白のバイトで埋められます。

/wp-content/uploads/2016/07/image_1393666319.png

今回はこの空白を確かめた上で該当ファイルにアクセスできることを確認してみます。

まずは最初にファイルを作ります。GlusterFS では 128Kbyte 単位で1つのファイルが各ノードに分割される為、1Mbyte のファイルをランダムな文字列で作成します。

$ dd if=/dev/urandom of=/mnt/test-vol/share001/test.img count=1 bs=1M

これで test.img という 1Mbyte のランダムバイトのファイルが作成されました。

次に、以下の2種類のファイルの8進数ダンプを取得します。

  • マウント経由のファイルアクセス:スパースのない完全な状態のファイル
  • エクスポート経由のファイルアクセス: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

スパース部分は0で埋められていることが分かると思います。

最後にこのファイルのチェックサムを取得し、を他の 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

これでチェックサムが一致しました。

5.6. ボリュームをクライアントからマウントする – GlusterFS Community ではじめる分散ファイルシステム

Windows エクスプローラからマウントする

Windows エクスプローラのアドレスバーに以下の形式でアドレスを入力します。

\\<ホスト>\<ボリューム名>

入力例

\\192.168.33.10\test-vol

GlusterFS では CIFS には対応していますが、WINS サーバや NetBIOS ネームサーバの機能は存在しません。その為、ネットワークに自動的に GlusterFS のボリュームが表示されたりコンピュータ名でアクセスすることはできません。

あくまでもアドレスを直接入力してアクセスする必要があります。

NFS からマウントする

構文

mount -t nfs -o vers=3 <ホスト名>:/<ボリューム名> <マウント先>

利用例

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

GlusterFS へ NFS クライアントからアクセスする時はオプションにバージョン3を指定する必要があります(バージョン4には未対応)。

NFS クライアントを使う場合、GlusterFS 関連のパッケージは1つもインストールする必要がありません。GlusterFS サーバが NFS サーバの機能も代替し稼働します(その分、GlusterFS クライアントに比べて性能が劣化)。

Note

接続先はホスト名:/ボリューム名となっていることにも注意して下さい。ブリック(ホスト名:共有ディレクトリ)ではありません。

OS 起動時に自動的にマウントしたい場合は /etc/fstab に以下の行を追加します。

構文

<ホスト名>:/<ボリューム名> <マウント先> nfs defaults,_netdev,vers=3 0 0

利用例

server01:/test-vol /mnt/test-vol nfs defaults,_netdev,vers=3 0 0

/etc/fstab に定義した場合は mount -a コマンドを実行し、きちんとマウントできることを確認して下さい。定義に失敗したまま OS を再起動した場合、起動できなくなる可能性があります。

その他、オプションとして指定している _netdev はネットワーク接続が開始された後にマウントを開始することを意味しています。

Note

接続先にホストをしていますが、このサーバが落ちてもクライアントからの接続が切れることはありません。

GlusterFS クライアントからマウントする

構文

mount -t glusterfs <ホスト名>:/<ボリューム名> <マウント先>

利用例

# mount -t glusterfs piett:/test-vol /mnt/test-vol

GlusterFS クライアント(ネイティブクライアント)を使ってマウントする場合はこのコマンドになります。

Note

接続先は ホスト名:/ボリューム名 となっていることにも注意して下さい。ブリック(ホスト名:共有ディレクトリ)ではありません。

Note

接続先にホストをしていますが、このサーバが落ちてもクライアントからの接続が切れることはありません。

OS 起動時にも自動的にマウントしたい場合は /etc/fstab に以下の行を追加します。

構文

<ホスト名>:/<ボリューム名> <マウント先> glusterfs _netdev,defaults 0 0

利用例

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

/etc/fstab に定義した場合は mount -a コマンドを実行し、きちんとマウントできることを確認して下さい。定義に失敗したまま OS を再起動した場合、起動できなくなる可能性があります。

5.5. GlusterFS を起動・停止する – GlusterFS Community ではじめる分散ファイルシステム

GlusterFS を起動する

構文

Ubuntu の場合

service glusterfs-server start

CentOS(Redhat 系) の場合

service glusterd start

利用例

Ubuntu の場合

# service glusterfs-server start

CentOS(Redhat 系) の場合

# service glusterd start

GlusterFS ではサーバ(ブリックを提供する側)とクライアントが存在し、クライアントではサービスを起動しておく必要はありませんが、サーバ側は全てのノードで GlusterFS サーバを起動しておく必要があります。

その為、OS 起動と同時に起動しておくのが一番ですが手動で起動する場合は上のようなコマンドを実行します。

GlusterFS が稼働しているか確認する

構文

Ubuntu の場合

service glusterfs-server status

CentOS(Redhat 系) の場合

service glusterd status

利用例

Ubuntu の場合

# service glusterfs-server status
glusterfs-server start/running, process 462

CentOS(Redhat 系) の場合

# service glusterd status
glusterd (pid  1088) を実行中...

GlusterFS サーバが稼働しているか確認する場合は Ubuntu や CentOS ディストリビューションに付属の service コマンド経由で glusterfs-serverglusterd を指定して確認します。

GlsuterFS を停止する

構文

Ubuntu の場合

service glusterfs-server stop

CentOS(Redhat 系) の場合

service glusterd stop

利用例

Ubuntu の場合

# service glusterfs-server stop

CentOS(Redhat 系) の場合

# service glusterd stop

GlusterFS の停止も起動同様 service コマンドを使って行います。サーバは1台停止しても残りのブリックが存在していればクライアントからの接続は保持されます。

OS 起動時も GlusterFS を起動する

構文

Ubuntu の場合

update-rc.d glusterfs-server defaults

CentOS(Redhat 系) の場合

chkconfig glusterd on

利用例

Ubuntu の場合

# update-rc.d glusterfs-server defaults

CentOS(Redhat 系) の場合

# chkconfig glusterd on

OS 起動と同時に GlusterFS も起動しておきたい場合はディストリビューションごとの起動登録コマンド(update-rc.dchkconfig)を使います。

Ubuntu の場合はインストールと同時に登録されます。また、起動を解除したい場合は次のようなコマンドを使います。

構文

Ubuntu の場合

update-rc.d glusterfs-server remove

CentOS(Redhat 系) の場合

chkconfig glusterd off

利用例

Ubuntu の場合

# update-rc.d glusterfs-server remove

CentOS(Redhat 系) の場合

# chkconfig glusterd off

5.4. ボリュームを開始・停止する – GlusterFS Community ではじめる分散ファイルシステム

ボリュームを開始する

構文

gluster volume start <ボリューム名>

利用例

# gluster volume start test-vol

GlusterFS でボリュームの利用を開始するには gluster volume start コマンドを使います。ボリュームを開始しない限りクライアントからマウントすることができません。

ボリュームを停止する

構文

gluster volume stop <ボリューム名>

利用例

# gluster volume stop test-vol

ボリュームの停止は gluster volume stop コマンドで行います。停止しない場合は、force をつけて強制停止することも可能です。

ボリューム停止時は全てのクライアントからこのボリュームが切断される為、注意して下さい。

5.3. ボリュームを変更する – GlusterFS Community ではじめる分散ファイルシステム

ボリュームを変更する

GlusterFS ではボリュームを作成し、運用している最中にボリュームへブリックを追加・削除したりボリュームオプション(レプリケートをディストリビューテッドレプリケートへ変更する等)を変えることも可能です。

ブリックの追加は性能・可用性・拡張性を上げることになる為、可能な限り実施しておくことが好ましいのですが、最初に作成したボリュームオプションにより1度に追加可能なブリック数が変わってきます。

stripereplica を指定している場合はこの倍の数のブリックを1度に追加する必要があります。また、安易な追加はボリュームオプションの変更を伴うことにも注意して下さい。

例えば、2つの stripe を持ったストライプドボリュームに対して2つのブリックを指定した場合、4台のブリック上で2つの stripe を持ったディストリビューテッドストライプドボリュームへ変化してしまいます。

これらの詳細や考え方はブリック追加・削除とリバランスを参照して下さい。

ブリックを追加する

構文

gluster volume add-brick <ボリューム名> [<stripe|replica> <数>] <新しいブリック>...

利用例

# gluster volume add-brick replica 2 server01:/srv/test-vol1 server02:/srv/test-vol1 server03:/srv/test-vol1 server04:/srv/test-vol1

ブリックの追加は gluster volume add-brick コマンドを用いて行います。また、ボリュームオプションの変更も行われてしまう可能性がある為、実施前にブリック追加・削除とリバランスも確認して下さい。

ブリックの追加を行った後はリバランスも忘れずに実行する必要があります。これについてはブリック追加・削除とリバランスを参照して下さい。

ブリックを削除する

構文

gluster volume remove-brick <ボリューム名> [replica <数>] <ブリック>...

利用例

# gluster volume remove-brick server01:/srv/test-vol1 server02:/srv/test-vol1

ブリックの削除は gluster volume remove-brick コマンドを用いて行います。この場合もブリック追加・削除とリバランス様でボリュームオプションの変更が行われる可能性があります。

また、ブリック削除後もリバランスを実施しておく必要があることにも注意して下さい。

ブリック削除した後に削除したサーバの共有していたディレクトリをボリュームとして再利用したい場合はボリュームを作る・削除するの “ディレクトリを再利用したい場合” を参考にしてメタ情報を削除して下さい。

5.2. ボリュームを作る・削除する – GlusterFS Community ではじめる分散ファイルシステム

ボリュームを作る

構文

gluster volume create <ボリューム名> [stripe <分割する数>] [replica <複製する数>] [transport [tcp | rdma | tcp,rdma]] <ブリック>

ボリュームを作る時は次のような情報をオプションに指定します。

  • ボリューム名:これから作成したいボリューム名。ディレクトリとして利用可能な文字であればどんなものでも可
  • stripe:分割する数を指定
  • replica:複製する数を指定
  • transport:ネットワーク通信(rpc)を使った tcp か InfiniBand を使った rdma のどちらかを指定。指定しない場合は tcp
  • ブリック:ブリックを指定。ブリックは <ホスト名>:<共有したいディレクトリ> の形式で指定し複数指定可能

また、stripe や replica を指定した場合、ボリュームの特性が変わってきます。これらの詳細についてはさまざまなボリュームオプション(その1)から始まる各ボリュームオプションを参考にして下さい。

ボリュームを作成しただけではボリュームを使うことはできません。ボリュームを使うにはこの後、ボリュームを開始・停止するを実行する必要があります。

以下にそれぞれのボリュームを作る場合のコマンド例を示します。

ディストリビューテッドボリューム

構文

gluster volume create <ボリューム名> [transport [tcp | rdma | tcp,rdma]] <ブリック>...

利用例

# gluster volume create test-vol server01:/srv/test-vol 192.168.33.20:/srv/test-vol server03:/srv/test-vol server04:/srv/test-vol

レプリケーテッドボリューム

構文

gluster volume create <ボリューム名> replica <複製する数> [transport [tcp | rdma | tcp,rdma]] <ブリック>...

利用例

# gluster volume create test-vol replica 2 server01:/srv/test-vol 192.168.33.20:/srv/test-vol

ストライプドボリューム

構文

gluster volume create <ボリューム名> stripe <分割する数> [transport [tcp | rdma | tcp,rdma]] <ブリック>...

利用例

# gluster volume create test-vol stripe 2 server01:/srv/test-vol 192.168.33.20:/srv/test-vol

ディストリビューテッドストライプドボリューム

構文

gluster volume create <ボリューム名> stripe <分割する数> [transport [tcp | rdma | tcp,rdma]] <ブリック>...

ブリックは stripe に指定した数の倍の数を指定します。

利用例

# gluster volume create test-vol stripe 2 server01:/srv/test-vol 192.168.33.20:/srv/test-vol server03:/srv/test-vol server04:/srv/test-vol

ディストリビューテッドレプリケーテッドボリューム

構文

gluster volume create <ボリューム名> replica <複製する数> [transport [tcp | tdma | tcp,rdma]] <ブリック>...

ブリックは replica に指定した数の倍の数を指定します。

利用例

# gluster volume create test-vol replica 2 server01:/srv/test-vol 192.168.33.20:/srv/test-vol server03:/srv/test-vol server04:/srv/test-vol

ストライプドレプリケーテッドボリューム

構文

gluster volume create <ボリューム名> stripe <分割する数> replica <複製する数> [transport [tcp | rdma | tcp,rdma]] <ブリック>...

ブリックは stripe と replica を倍にした数を指定します。

利用例

# gluster volume create test-vol stripe 2 replica 2 server01:/srv/test-vol 192.168.33.20:/srv/test-vol server03:/srv/test-vol server04:/srv/test-vol

ディストリビューテッドストライプドレプリケーテッドボリューム

構文

gluster volume create <ボリューム名> stripe <分割する数> replica <複製する数> [transport [tcp | rdma | tcp,rdma]] <ブリック>…

ブリックは stripe と replica の倍のさらに倍数を指定します。

利用例

# gluster volume create test-vol stripe 2 replica 2 server01:/srv/test-vol 192.168.33.20:/srv/test-vol server03:/srv/test-vol server04:/srv/test-vol 192.168.33.60:/srv/test-vol 192.168.33.70:/srv/test-vol 192.168.33.80:/srv/test-vol 192.168.33.90:/srv/test-vol

ボリュームを削除する

利用例

ボリュームを削除する場合、ボリュームのみを指定して gluster volume delete を実行します。この時承認したピアは承認したまま残ります。また、削除前にボリュームを停止しておく必要があります(もちろん削除時に停止することも可能です)。

ディレクトリを再利用したい場合

構文

gluster volume delete <ボリューム名>

利用例

# gluster volume delete test-vol

削除したボリューム内にブリックとして含まれていたディレクトリを再利用したい場合は単純にはいきません。

GlusterFS ではボリュームとして共有したディレクトリに属性としていくつかのパラメータを付与し、一番上のディレクトリに.glusterfsという隠しディレクトリも作成します。

このパラメータや隠しディレクトリが存在したままの状態で他のボリュームのブリックとして追加(作成)しようとしても次のようなエラーが表示されて失敗してしまいます。

<ディレクトリのパス> or a prefix of it is already part of a volume

このパラメータは次のようなコマンドで確認することができます。

getfattr -d -m - <ディレクトリのパス>

そしてこのディレクトリを再度利用したい場合は次のようなコマンドを実行します。

setfattr -x trusted.glusterfs.volume-id <ディレクトリのパス>
setfattr -x trusted.gfid <ディレクトリのパス>
rm -rfv <ディレクトリのパス>/.glusterfs

最後の rm コマンドはディレクトリ自体を削除しないように注意して下さい。次のような利用例になります。

$ setfattr -x trusted.glusterfs.volume-id /srv/test-vol
$ setfattr -x trusted.gfid /srv/test-vol
$ rm -rfv /srv/test-vol/.glusterfs

この後、GlusterFS 自体の再起動も必要かもしれません。GlusterFS の再起動はGlusterFS を起動・停止するを参考にして下さい。

5.1. ノードを承認する・拒否する – GlusterFS Community ではじめる分散ファイルシステム

ノードを承認する

構文

gluster peer probe <ホスト>

利用例

# gluster volume peer probe server02
# gluster volume peer probe 192.168.33.30

GlusterFS ではボリュームを作る前に互いのノードを承認しておく必要があります。これはノードの承認と呼びいずれか1つのノード上で他のノードに対して行います。

ホストの指定はホスト名でも IP アドレスでも構いませんが、承認したノード(peer:ピアと呼びます)の一覧を表示する際にこの情報がそのまま表示されます(ホスト名で指定したならホスト、IP アドレスであれば IP アドレス)。

なお、ボリューム作成時にブリックとしてホストを指定しますが、このホストはホスト名でも IP アドレスでもどちらでも構いません。

ノードの承認を解除する

構文

gluster peer detach <ホスト>

利用例

# gluster peer detach server02
# gluster peer detach 192.168.33.30

ピアとなったノードを解除する場合はノードを承認する同様いずれか1つのノード上で他のノードに対して行います。

既に何らかのボリュームが作成されそのボリュームのブリックに承認を解除したいノードが存在している場合はそのノードのブリックをボリュームから削除しておく必要があります。

ブリックをボリュームから削除するにはボリュームを作る・削除するを参照して下さい。

承認ノードの一覧を表示する

構文

gluster peer status

利用例

# gluster peer status
Number of Peers: 3
Hostname: 192.168.33.20
Uuid: d4a31d8b-8eaa-4833-913e-3d5d45552d0e
State: Peer in Cluster (Connected)

Hostname: server03
Uuid: 1b232e41-ab35-40c7-a5bd-0765f2a164c4
State: Peer in Cluster (Connected)

Hostname: server04
Uuid: e46a8961-7cd4-41bf-aebc-c9d357508882
State: Peer in Cluster (Connected)

承認したピアの一覧を見るには gluster peer status コマンドを使います。ノードを承認するでも記載しましたが、ピアとして承認した時にホスト名で指定していればホスト名が、IP アドレスで指定していれば IP アドレスが表示されます。

gluster peer status コマンドを実行した時の各項目の説明は次の通りです。

  • Hostname:ホスト(ホスト名か IP アドレス)
  • Uuid:GlusterFS が一意にホストにつける ID
  • State:承認可否と接続ができているか

5. ステップ4 GlusterFS をもっと使う – GlusterFS Community ではじめる分散ファイルシステム

このステップでは GlusterFS を利用する為の具体的な操作を記載します。