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

.

4.2. さまざまなボリュームオプション（その１）

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

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

<th class="head">
  該当する RAID
</th>

<td>
  JBOD
</td>

<td>
  RAID 1
</td>

<td>
  RAID 0
</td>

<td>
  RAID 0 & JBOD
</td>

<td>
  RAID 1 & JBOD
</td>

<td>
  RAID 1+0
</td>

<td>
  RAID 1+0 & JBOD
</td>

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

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

<th class="head">
  可用性
</th>

<th class="head">
  性能
</th>

<th class="head">
  拡張性
</th>

<td>
  ×
</td>

<td>

</td>

<td>
  ☆☆☆
</td>

<td>
  ☆☆☆
</td>

<td>

</td>

<td>
  ×
</td>

<td>
  ×
</td>

<td>
  ☆☆☆
</td>

<td>
  ☆☆
</td>

<td>
  ×
</td>

<td>
  ☆☆
</td>

<td>
  ☆☆
</td>

<td>
  ☆☆
</td>

<td>

</td>

<td>
  ☆☆
</td>

<td>
  ☆
</td>

<td>
  ☆☆
</td>

<td>

</td>

<td>
  ☆
</td>

<td>
  ☆☆
</td>

<td>
  ☆
</td>

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

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

長所

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

短所

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

効果的なシステム

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

ボリュームの作り方

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

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

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

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

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

長所

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

短所

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

効果的なシステム

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

ボリュームの作り方

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

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

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

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

ストライプドボリューム

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

長所

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

短所

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

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

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

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

効果的なシステム

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

ボリュームの作り方

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

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

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

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