アーキテクチャ(2)

トランスレータモジュール

NativeクライアントがGlusterFSサーバにアクセスする際は、クライアント側、サーバ側、それぞれの「トランスレータモジュール」群が連携してアクセス処理を行います。

下図は、4ノードからなるクラスタ上にレプリケーション構成（レプリカ数２）のボリュームを作成してアクセスする場合に使用されるトランスレータモジュール群の例です。例えば、1つのファイルを2ノードに複製保存する処理は、クライアント側の「replicate-X」モジュール（レプリケーションモジュール）が行います。

各トランスレータモジュールは、共有ライブラリ形式で提供されており、典型的なインストール環境では、/usr/lib64/glusterfs/<version>/xlator/以下に保存されます。また、各ボリュームが使用するトランスレータは、サーバ上のボリューム定義ファイル、/var/lib/glusterd/vols/<Vol>/<Vol>-fuse.vol（クライアントモジュール）、/var/lib/glusterd/vols/<Vol>/<Vol>.<Node>.<Brick>.vol（サーバモジュール）に記載されています。

※ 上記のボリューム定義ファイルを手で編集することは禁止されています。ボリュームの設定変更は必ずCLIから行なってください。

レプリケーション動作の詳細

上図の例でクライアント上のアプリケーションがボリュームにファイルを書き込むと、レプリケーションモジュールが1つのサーバにファイルを書き込んだ時点で、アプリケーションに対しては、書き込み完了の応答が返ります。その後、レプリケーションモジュールはバックグランドで、もう一方のサーバにファイルの書き込みを行います。

逆にファイルを読み込む際は、レプリケーションモジュールは、どちらか一方のサーバからファイルを読み込んでアプリケーションに受け渡します。どちらのサーバを使用するかは、パフォーマンスを考慮して、ヒューリスティックに決定されます。

ストライピングボリュームのデータ配置

例えば、ストライピングボリュームにファイル「file01」を配置すると、対応する各ブリック内には、同名のファイル「file01」が作成されます。ただし、各ファイルの内容は、「該当ブリックが担当するチャンク部分のみに実データが書き込まれ、その他の部分はヌル文字（0）が並んだもの」になります。このファイルは、スパース形式（ヌル文字の連続部分は圧縮されて、実際にはディスク領域を消費しない形式）で作成されるので、下図のような状況になります。

この図では、2個のブリックでストライピングしたボリュームに768KBのファイルを配置しています。デフォルトのチャンクサイズは128KBなので、128KBごとに2つのブリックにデータが分散配置されます。ブリック内のファイルをlsコマンドで見ると、元のファイルと同じサイズ（768KB）に見えますが、ブリックの実使用容量はこれよりも小さくなります。

この時、スパース形式による圧縮率は、ブリックに使用するファイルシステムの種類に依存します。ext4やXFSなど、プリアロケーション機能を持つファイルシステムでは、将来、圧縮部分にデータが書き込まれた際のフラグメンテーションを低減するために、意図的に圧縮率を下げる場合があります。

ただし、ストライピングボリュームのブリックとして使用する場合は、圧縮部分にデータが書き込まることは一切ありませんので、この動作はブリックを無駄に消費することになります。特に、XFSのデフォルト設定では、スパース形式による圧縮はほとんど行われないため、ボリューム全体の容量は、1つのブリックの容量が上限となります。このXFSに固有の問題は、ファイルシステムのマウントオプション「allocsize=128k」（128kの部分はボリュームのチャンクサイズに合わせます）を指定することで回避できます。

下記は、2個のブリックでストライピングしたボリュームに1GBのファイル（file01）を作成した例です。マウントオプション「allocsize=128k」を使用しており、最後のlsコマンドの結果を見ると、ブリック内のfile01のサイズは1GBと表示されていますが、ブリック全体の使用容量は513MBになっています。

# gluster vol info vol01

Volume Name: vol01

Type: Stripe

Volume ID: 6c3cbfc5-3bac-4a34-aa1b-bcae959913cb

Status: Started

Number of Bricks: 1 x 2 = 2

Transport-type: tcp

Bricks:

Brick1: rhs20-01:/data/brick01

Brick2: rhs20-02:/data/brick01

# cat /etc/fstab | grep xfs

/dev/vda5 /data xfs defaults,allocsize=128k 0 0

# df -h /data /mnt/vol01

Filesystem Size Used Avail Use% マウント位置

/dev/vda5 2.8G 545M 2.3G 20% /data

localhost:/vol01 5.6G 1.1G 4.6G 20% /mnt/vol01

# ls -lh /mnt/vol01

合計 1.1G

-rw-r--r-- 1 root root 1.0G 11月 4 23:25 2012 file01

# ls -lh /data/brick01/

合計 513M

-rw-r--r-- 2 root root 1.0G 11月 4 23:25 2012 file01

（注意）

ストライピング以外のボリュームとしてブリックを使用する場合、allocsizeマウントオプションを指定するとファイルシステムの性能が低下する場合があります。ストライピングボリュームを使用する場合は、専用のブリックを用意して、allocsizeマウントオプションを指定することをおすすめします。

また、この問題は、GlusterFS3.4で根本的に解決される（allocsizeを指定しなくても十分な圧縮が行われるようになる）予定ですが、この際、GlusterFS3.3で作成したストライピングボリュームとの互換性がなくなる可能性があります。GlusterFS3.4にアップデート予定の場合は、ご注意ください。