4.7. GlusterFS のスケール – GlusterFS Community ではじめる分散ファイルシステム

スケールアップとは?スケールアウトとは?

ここで GlusterFS の性能を向上させる方法について考えてみたいと思います。

通常分散ファイルシステムに限らず分散化されたシステムで性能向上を考える場合、次のどちらにするか議論が分かれます。

  • スケールアップ:システム自体の性能を向上させる
  • スケールアウト:システム内の処理台数を増やす

スケールアップの場合、CPU 周波数を上げたり、HDD の SATA を SAS あるいは SSD にする等、回転数を上げることでサーバ個々の能力を向上する方法が採られます。

一方でスケールアウトの場合、サーバ台数自体を増やすことでシステム全体の能力向上を図ります。

ただし、一般的にはスケールアップには限界があります。CPU 周波数は既に頭打ちになっており、HDD にしてもミラーリング構成を取るなど RAID 構成を考慮した場合性能向上は難しくなります。またスケールアップ時はそのサーバを一旦停止する必要があることが多くシステムの可用性も落ちてしまう可能性があります。

スケールアウトであれば性能の低いサーバーであっても増やせば増やすだけシステムの処理性能が上がり、多くの場合サーバ停止は必要ありません。これらの理由から最近ではほとんどこちらが好まれています。

ただ、システムをスケールアウトさせるにはアプリケーション側も同じ処理を複数台で行うことを考慮して設計する必要があり、その実装は簡単ではありません。

もちろん GlusterFS では最初からスケールアウトが意識されている為、スケールアップもスケールアウトもボリュームオプションさえ指定しておけば簡単に扱うことができます。

GlusterFS ではスケールアップとスケールアウトのどちらがいいか

では GlusterFS ではスケールアップとスケールアウトのどちらがよいのでしょうか?

スケールアウトが考慮されている分散ファイルシステムの場合、性能の低いサーバであっても追加すればするほど有利になります。

ただ、 GlusterFS は動画や OS のイメージファイルのような大きなファイルを共有した場合、ストライプドボリュームオプション等も有効に効くのですが小さなファイルが大量にある場合(例えばメールファイル、小さな画像等)は NFS よりも性能が落ちるケースがあります。

このため、大きなファイルを共有しているボリュームではサーバ数をどんどん追加しスケールアウトを図っていくのが有効的です。

一方で小さなファイルを大量に共有するような場合はサーバ自身のスループットも高めていくのがよいでしょう。この場合スケールアウトも一緒に行うべきです。

これらのことを加味して以下のように分類できます。

  • 大きなファイルを共有するボリューム:スケールアウト
  • 小さなファイルをたくさん共有するボリューム: スケールアウトとスケールアップ

4.6. ブリック追加・削除とリバランス – GlusterFS Community ではじめる分散ファイルシステム

ブリック追加・削除

GlusterFS ではボリュームを作成した後にオンラインでブリックを追加することが可能です。ブリックの追加は次のように gluster volume add-brick コマンドによって行います。

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

また、ブリックの削除は次のように gluster volume remove-brick コマンドによって行います。

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

ここで重要なのはブリックの追加・削除を行うコマンドで stripe や replica の指定ができることです。GlusterFS ではオンラインである程度のボリュームオプションの変更が行えるようになっています。

通常、いずれかのボリュームオプションでボリュームを作成し、ブリック追加を行った場合、ディストリビューテッドとしてこのブリックが追加されます。ただ、このボリュームオプションが非ディストリビューテッド系であればディストリビューテッドボリュームに変換されます。

また、ブリック追加・削除時に stripe や replica を指定することでストライプド系やレプリケーテッド系ボリュームにストライプを追加したりレプリケートを追加したりできます。

同時にもともとレプリケーテッド系ボリュームでない場合に replica を追加するとレプリケーテッド系ボリュームへ変換されます。一方でストライプド系ボリュームでない場合に stripe を指定することは推奨されません(未サポートです)。

これらの変換についてについては次の図を参考にして下さい。

/wp-content/uploads/2016/07/image_1371285204.png
/wp-content/uploads/2016/07/image_1371289175.png

上の図に関して、ディストリビューテッド系ボリュームに変更するには stripe と replica を掛けた数の倍のブリックを指定する必要があります。

例:stripe x replica = 4 であればブリック数は 8 や 12等
(stripe や replica の指定がない場合は 1と考える)

また、ブリックの削除は図中の矢印が逆になると考えて下さい。

ブリックの追加・削除を行った後は手動でファイル構成を再配置するように指示する必要があります。この再配置をリバランスと言います。

リバランス

ブリックの追加や削除を行った後は手動でファイルの再配置をする必要があります。再配置はリバランスによって実施可能ですがリバランスを行うには2つのステップがあります。

  • レイアウト(layout)の再配置:今後新しく追加されるファイル(やディレクトリ)が新しい構成に配置されるようにする
  • データの再配置:既存のデータを新しい構成に再配置する

これらはレイアウト→データの順にそれぞれコマンドをどれか1つのサーバ上で実行していきます。レイアウトの再配置は次のようなコマンドになります。

gluster volume rebalance <ボリューム名> fix-layout start

レイアウトの再配置を行っただけでは既存のファイルは移動しない為、データの再配置を次のコマンドで行います。

gluster volume rebalance <ボリューム名> start

特にこのデータの再配置には長い時間を要するかもしれません。この時の進捗を含め状態を見るには次のコマンドを使います。

gluster volume rebalance <ボリューム名> status

最後にリバランスを停止するコマンドも用意されています。

gluster volume rebalance <ボリューム名> stop

4.5. ヒーリングとスプリットブレイン – GlusterFS Community ではじめる分散ファイルシステム

ヒーリングデーモン

ヒーリングデーモンは GlusterFS の機能の一つでヒーリングを行うプロセスです。

GlusterFS のレプリケート系ボリュームオプションを利用している時に次のような障害が発生した場合について考えます。

  1. レプリカ構成を取っているノードA と Bのうち、A が落ちた
  2. ノード B には継続して書き込みが行われる
  3. 少したった後、ノード Aが復旧した

この時、ノード A ― B 間のレプリケーションでは不整合が発生(B が最新の状態)しています。GlusterFS ではこの状態の時に復旧を行う必要がありますが、これをヒーリングと呼んでいます。

GlusterFS のヒーリングは Self heal daemon(セルフヒールデーモン)と呼ばれるプロセスが 10分間隔で監視を行い、必要とあれば自動でヒーリングを行います(以前は一度ボリュームを停止し、手動で行う必要がありました)。

スプリットブレイン

ヒーリングと関連した問題としてスプリットブレインもあります。これは GlusterFS というよりもそもそもネットワーク技術の問題でもあります。

ネットワーク内のノードは互いに強調して動作しますが、このノード間の通信が切れてしまった場合、どちらが主導権(マスタ)を取るのか分からず複数のノードが一斉にマスタになってしまったりする場合が発生しえます。これをスプリットブレインと呼びます。

ミドルウェアの起動を管理するクラスタリングソフト(Veritas Cluster Server、CLUSTERPRO等)でもこの問題は存在します。ただ、この状態が発生すると全てがマスタとして動作して障害が起きることを避ける為にクラスタリングソフトでは全てのノードを停止することが多くなっています。

GlusterFS でもノードが分断され、復旧した時、復旧したノードと他のノード間でどちらのファイルが最新か把握ができなくなってしまうケースが発生します。

この場合、GlusterFS では読み書きともにできなくなる場合があります。この対処として GlusterFS 3.4.2 では quorum(クォラム)が実装されました。

quorum

クォラムはネットワーク分断に備えて一定数(通常は過半数以上)のノードが分断時に存在していればそのノードグループが正しいものと考えてサービス継続を行う機能です。

GlusterFS では quorum はボリュームパラメータとして設定します。このパラメータは過半数である 50% 以上のパーセンテージで次のように指定することが可能です。

gluster volume set <ボリューム> cluster.server-quorum-type <none/server>
gluster volume set all cluster.server-quorum-ratio <パーセンテージ>%

利用する時は次のようにコマンドを実行します。

# gluster volume set test-vol cluster.server-quorum-type server
# gluster volume set all cluster.server-quorum-ratio 60%

コマンド中の cluster.server-quorum-type は quorum を有効にするパラメータで、quorum のパーセンテージは cluster.server-quorum-ratio で設定します。

この例だとネットワークが分断されても 60% のノードを保持するノードのグループがいればそのグループを生としてサービスを継続することになります。

この quorum の機能はサービスの信頼性に大きく関係するパラメータですのでぜひとも設定しておくことをお勧めします。

4.4. さまざまなボリュームオプション(その3) – GlusterFS Community ではじめる分散ファイルシステム

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

ストライプドレプリケーテッドボリュームはレプリケート(ミラー)したブリックの上にストライプドボリュームを作るものです。

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

長所

性能向上と可用性が見込め、必要なブリック数も手頃な数(最低4つ)と言えるかもしれません。

短所

このボリュームではあまり拡張性は意識していません。このボリュームに拡張性を追加したいのであればディストリビューテッドストライプドレプリケーテッドボリュームを使います。

注意点

ブリックの数はストライプとレプリカを掛けた数になるように作成します。ブリックの数がこれ以上増えるとディストリビューテッドストライプドレプリケーテッドボリュームとなってしまうことに注意して下さい(この場合もブリックの数はさらに倍数を指定する必要があります)。

ボリュームの作り方

このボリュームを作るには次のようにコマンドを実行します。

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

このコマンドを実際に使うと次のようになります。

# gluster volume create test-vol stripe 2 replica 2 piett:/srv/test-vol motti:/srv/test-vol secura:/srv/test-vol tano:/srv/test-vol

この例の場合、piett と motti、secura と tano でそれぞれ1つのレプリカされたボリュームを作成し、piett&motti と secura&tano でストライプドボリュームを作成します。

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

ディストリビューテッドストライプレプリケーテッドボリュームはレプリケート(ミラー)したブリックをストライプし、さらにブリックをまたいでファイルを配布するボリュームオプションです。

レプリケート→ストライプ→ディストリビューテッドの順に構成され、根本の部分でレプリケートされていることからある程度の信頼性が確保されています。

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

長所

他のオプションのいいとこ取りなボリュームオプションで可用性・性能・拡張性ともにバランスが取れています。

短所

このボリュームを構成する為に多くのブリックを必要とします。ブリックを増やせば増やすほど効果的ですがコストがかかります。

効果的なシステム

どんなシステムでも有用です。

注意点

ブリックはストライプとレプリカを掛けた数の倍数にする必要があります。最低構成のストライプ2つとレプリカ2つでも 8つのブリック を必要とします。

ボリュームの作り方

このボリュームを作るには次のようにコマンドを実行します。

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

このコマンドを実際に使うと次のようになります。

# gluster volume create test-vol stripe 2 replica 2 piett:/srv/test-vol motti:/srv/test-vol secura:/srv/test-vol tano:/srv/test-vol 192.168.1.150:/srv/test-vol 192.168.1.151:/srv/test-vol 192.168.1.152:/srv/test-vol 192.168.1.153:/srv/test-vol

この例の場合、piett と motti、secura と tano、192.168.1.150 と 151、192.168.1.152 と 153 でレプリカを作り、piett&motti と secura&tano、192.168.1.150&151 と 192.168.1.152&153 でストライプを作り、このストライプにランダムにファイルが分散されていきます。

4.3. さまざまなボリュームオプション(その2) – GlusterFS Community ではじめる分散ファイルシステム

4.3. さまざまなボリュームオプション(その2)

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

ディストリビューテッドストライプドボリュームはストライプしたブロック(ファイルの中のブロック)を複数のブリックに分散して配置するボリュームオプションです。

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

長所

ストライプドボリュームディストリビューテッドボリュームを組み合わせることで適度な性能向上と拡張性を備えています。

短所

ブリックが1台利用不可能になっただけでサービスに影響がある点はストライプやディストリビューテッドと同様です(特定のファイルにアクセスできなくなります)。

効果的なシステム

ストライプやディストリビューテッド同様大きな容量のファイルやキャッシュのような消失しても問題がなく、性能・拡張性が求められるようなシステムで効果的です。

注意点

ブリックの数はストライプ(stripe)として指定した数の倍数になるように作成します。

ボリュームの作り方

このボリューム作成時のコマンドはストライプドボリュームとほとんど同じで、ブリックに指定する数がストライプとして指定した数の倍になるという点だけが異なります。ボリュームを作るには次のようにコマンドを実行します。

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

このコマンドを実際に使うと次のようになります。

# gluster volume create test-vol stripe 4 piett:/srv/test-vol1 piett:/srv/test-vol2 motti:/srv/test-vol1 motti:/srv/test-vol2 secura:/srv/test-vol1 secura:/srv/test-vol2 tano:/srv/test-vol1 tano:/srv/test-vol2

この例の場合まず4台のノード、8つのブリック上でボリュームが作成されます。その上で、1つのファイルが4つのブリックにまたがる形で分散されます。次のファイルは別の4つのブリックにまたがる形でまた分散されることになります。

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

ディストリビューテッドレプリケーテッドボリュームはレプリケート(ミラー)したブリックを1つのブリックと考え、これをまたいでファイルを配布するボリュームオプションです。

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

長所

ブリック単位でレプリケートされている為、ノード停止等によって1つのブリックが停止してもファイルアクセスに影響がありません。また拡張性も失われていません。

短所

可用性・拡張性を得る引き換えに多くのブリックが必要になることです。また、1つのブリックは1つのノードで提供されなければ可用性を失います。

効果的なシステム

適度な可用性・拡張性の為にどんなシステムでも有用です。

注意点

ブリックの数はレプリカ(replica)として指定した数の倍数になるように作成します。また、ボリューム作成時に指定するブリックの順序ごとにレプリカが作成される為、レプリカを構成するブリックが同じサーバとならないように注意が必要です。

ボリュームの作り方

このボリューム作成時のコマンドはレプリケーテッドボリュームとほとんど同じで、ブリックに指定する数がレプリカとして指定した数の倍になるという点だけが異なります。ボリュームを作るには次のようにコマンドを実行します。

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

このコマンドを実際に使うと次のようになります。

# gluster volume create test-vol replica 2 piett:/srv/test-vol motti:/srv/test-vol secura:/srv/test-vol tano:/srv/test-vol

この例の場合 piett・motti と secura・tano でそれぞれレプリケートされたブリックが作成され、ファイルはこれらにランダムで配置されていきます。

4.2. さまざまなボリュームオプション(その1) – GlusterFS Community ではじめる分散ファイルシステム

4.2. さまざまなボリュームオプション(その1)

この章からはそれぞれのボリュームオプションの説明に入ります。GlusterFS のボリュームオプションの特徴を理解しシステム要件に合わせたオプションを選ぶことで最大の性能・可用性を引き出すことができます。

RAID を知っている人であれば次のように考えられるかもしれません。

ボリュームオプション 該当する RAID
ディストリビューテッド JBOD
レプリケーテッド RAID 1
ストライプド RAID 0
ディストリビューテッドストライプド RAID 0 & JBOD
ディストリビューテッドレプリケーテッド RAID 1 & JBOD
ストライプドレプリケーテッド RAID 1+0
ディストリビューテッドストライプドレプリケーテッド RAID 1+0 & JBOD

各ボリュームオプションの可用性・性能・拡張性

それぞれのボリュームオプションはそれぞれ可用性・性能・拡張性面が異なります。次の表を参考にして下さい。

ボリュームオプション 可用性 性能 拡張性
ディストリビューテッド ×   ☆☆☆
レプリケーテッド ☆☆☆   ×
ストライプド × ☆☆☆ ☆☆
ディストリビューテッドストライプド × ☆☆ ☆☆
ディストリビューテッドレプリケーテッド ☆☆   ☆☆
ストライプドレプリケーテッド ☆☆  
ディストリビューテッドストライプドレプリケーテッド ☆☆

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

ディストリビューテッドは複数のブリック(同じサーバでも別のサーバでも)をまたいでファイルを配布するボリュームオプションです。RAID 技術で例えた場合、JBOD が該当します。

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

長所

ファイルは各ブリックにランダムに配置・分散され、アクセスも分散される為、ある程度の性能向上が見込めます。また、複数のブリックを1つのファイルシステムとして見せることができる為、巨大な容量のファイルシステムを作ることができます(拡張性の面で有利)。

短所

各ブリックにファイルが分散される為、ブリックが1つでも利用できなくなった時(サーバダウン等)にそのブリックにあるファイルにアクセスできなくなります。また、ランダムにブリックに配置される為、どのファイルにアクセスできなくなるのか予想が付きません。

効果的なシステム

とにかく大きな容量のファイルシステムを作りたいのであれば有効です。それ以外ではあまりお勧めできません。

ボリュームの作り方

このボリュームを作るには次のようにコマンドを実行します。

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

ブリックは <ホスト名 or IP アドレス>:<ディレクトリ> のように指定します。
また、transport は tcp であれば指定は要りません。

このコマンドを実際に使うと次のようになります。

# gluster volume create test-vol piett:/srv/test-vol motti:/srv/test-vol secura:/srv/test-vol tano:/srv/test-vol

単にブリックを並べていくイメージですが、上の例の場合4台のノード上でディストリビューテッドボリュームが作成されます。

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

レプリケーテッドボリュームは複数のブリックに同じファイル(レプリカと呼びます)を置くボリュームオプションです。4台指定されていれば4つの全く同じファイルが作成されることになります。

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

長所

複数台のサーバで複数のブリックを作れば作るほど可用性が増します。どれか1つでもブリックが利用可能であればファイルシステムへのアクセスが可能です。

短所

一番容量の少ないブリックに合わせてサイズが決定される為、ファイルシステムのサイズが小さくなってしまいます。

効果的なシステム

信頼性が重視されるシステムで効果的です。ただし、過度にレプリカを増やしても無駄が多くなります。

ボリュームの作り方

このボリュームを作るには次のようにコマンドを実行します。

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

このコマンドを実際に使うと次のようになります。

# gluster volume create test-vol replica 4 piett:/srv/test-vol motti:/srv/test-vol secura:/srv/test-vol tano:/srv/test-vol

この例の場合4台のノード上でレプリケーテッドボリュームが作成されます。注意が必要なのは replica(レプリカ)で指定している数とブリックの数を合わせることです。

レプリカの数よりブリックの数が少ない場合は単にエラーとなりますが、ブリックの数の方が多くなった場合、それはディストリビューテッドレプリケーテッドボリュームになってしまいます。

ストライプドボリューム

ストライプドボリュームは1つのファイルを分割し、複数のブリックに配置します。ファイルへアクセスする時は複数のブリック(サーバ)から取得する為、処理が分散されます。

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

長所

ファイルへのアクセスが高速です。また、複数のブリックをまたいで使う為、容量の大きなファイルシステムを作ることができます。

短所

1つでもブリックにアクセスできなくなっただけで全てのファイルにアクセスできなくなります。また、複数のブリックにまたいでファイルが分割されますが、小さいファイルの場合は逆に無駄なネットワーク通信を引き起こし性能が遅くなることもあります。

ディストリビューテッドボリュームとの違い

ストライプドボリュームはディストリビューテッドボリュームと混合しがちですが、下記の点で異なります。

  • ストライプドボリュームで利用可能な最大ディスク容量はノード内の一番容量の低いものになる
  • ディストリビューテッドボリュームの場合、ノード一台が落ちてもファイルは生きている可能性がある
  • ディストリビューテッドボリュームの場合、ノードを増やせば増やすだけそのボリュームの最大容量が増える

効果的なシステム

キャッシュファイルのような消失しても問題がなく、なおかつ高速性を求められるシステムで効果的です。特に動画のような大きなファイルの利用が有効です。

ボリュームの作り方

このボリュームを作るには次のようにコマンドを実行します。

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

このコマンドを実際に使うと次のようになります。

# gluster volume create test-vol stripe 4 piett:/srv/test-vol motti:/srv/test-vol secura:/srv/test-vol tano:/srv/test-vol

この例の場合4台のノード上でストライプドボリュームが作成されます。注意が必要なのは stripe(ストライプ)で指定している数とブリックの数を合わせることです。

ストライプの数よりブリックの数が少ない場合は単にエラーとなりますが、ブリックの数の方が多くなった場合、それは ディストリビューテッドストライプドボリューム になってしまいます。

3. ステップ2 とにかく使ってみる – GlusterFS Community ではじめる分散ファイルシステム

3. ステップ2 とにかく使ってみる

このステップ2では実際に GlusterFS をインストールし次の2つの条件で分散ファイルシステム構成を構築するまでをナビゲートします。

  • 4台のサーバでミラー構成
  • 4台のサーバでストライプ構成

本ステップでは各機能や用語等の説明は最小限に抑え「とにかくはじめられる」状態になることを目的としています。これら機能や構成については次のステップの ステップ3 GlusterFS を理解する で説明しますので完全に理解しなくても先に進めることができます。

2. ステップ1 GlusterFS を知る – GlusterFS Community ではじめる分散ファイルシステム

このステップでは GlusterFS についてまず知るところから始めます。

次に GlusterFS Community 版と商用版である Red Hat Storage Server との比較や競合製品である LustreHadoop HDFS との比較を通して GlusterFS の特徴を説明します。

2.1. GlusterFS はどんなもの?
2.2. GlusterFS Community と Red Hat Storage Server の違い
2.3. GlusterFS の要件
2.4. GlusterFS をなぜ使うのか?
2.5. GlusterFS の機能と最近のリリース

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_25::</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

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

3.2. ソースをコンパイルしてインストールする – GlusterFS Community ではじめる分散ファイルシステム

本章では Linux で GlusterFS をコンパイルしてインストールする方法を紹介します。動作は Ubuntu と CentOS で確認していますが、この手順はほとんどの Linux・Unix 系 OS で共通となります。

GlusterFS ソースをダウンロードする

まず GlusterFS をダウンロードして解凍します。

# cd /usr/local/src
# wget http://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.2/glusterfs-3.4.2.tar.gz
# tar zxvf glusterfs-3.4.2.tar.gz

GlusterFS をコンパイルする

次に GlusterFS をコンパイルします。

# cd /usr/local/src/glusterfs-3.4.2
# ./configure
# make
# make install

これで /usr/local/ 配下に GlusterFS がインストールされます。GlusterFS を実際に動かすコマンドである glusterd/usr/local/sbinに置かれます。このパス(/usr/local)は configure コマンドを実行する時に –prefix オプションを付けることで変更することができます。この場合次のようなコマンドになります。

# cd /usr/local/src/glusterfs-3.4.2</p>
# ./configure --prefix=/opt/glusterfs-3.4.2
# make
# make install

上の例を実行すると /opt に GlusterFS がインストールされます。

GlusterFS 起動スクリプトを配置する

CentOS・Redhat 系であれば make install の時に GlusterFS を起動するファイルである /etc/init.d/glusterd も一緒にインストールされます。ただ、インストールされない環境もあります。

その場合 /usr/local/src/glusterfs-|GlusterVersion|/extras/init.d
へ移動し自分にあった環境の起動スクリプトを /etc/init.d/glusterd にコピーして下さい。

# cd /usr/local/src/glusterfs-3.4.2/extras/init.d
# cp -vpir glusterd-Debian /etc/init.d/glusterd

上のコマンドは Ubuntu 等の Debian 系ディストリビューションの例です。

GlusterFS を起動する

GlusterFS の起動方法はコンパイル可否にかかわらず RPM や apt でインストールした時と同じ方法でインストールすることができます。

# /etc/init.d/glusterd start
# /etc/init.d/glusterd status # 起動したかを確認する

Ubuntu の環境で OS 起動時に自動起動したい場合は次のコマンドを実行しておくといいでしょう。

# update-rc.d glusterd defaults

CentOS の環境で OS 起動時に自動起動したい場合は次のコマンドを実行しておくといいでしょう。

# chkconfig glusterd on

これで GlusterFS をソースからコンパイルしてインストールする方法は以上になります。