第2章 GFS2 の設定および操作における考慮事項

GFS2 は、64-bit アーキテクチャーをベースにしており、理論的には 8 EB (エクサバイト) の大きさのファイルシステムの収容が可能です。ただし、64 ビットのハードウェア用の最大サイズとして現在対応しているのは 100 TB になります。また、32 ビットのハードウェアの場合は 16 TB になります。

GFS2 の大型ファイルシステムは可能ですが、それが推奨されるということではない点に注意してください。大ざっぱに言えばサイズは小さいほど好ましいとされています。つまり、10 TB のファイルシステムを 1 つ用意するつもりなら、1 TB のファイルシステムを 10 用意した方がよいということです。

GFS2 ファイルシステムのサイズを小さくとどめることが推奨される理由として、以下の点があげられます。

また、メンテナンス対象となるリソースグループが少なくなればなるほどパフォーマンスも向上します。

GFS2 ファイルシステムのサイズを小さくしすぎると当然、容量不足による不具合が発生する可能性があります。まず使用環境におけるユースケースを考慮してからサイズを決定するようにしてください。

Red Hat Enterprise Linux 6 リリースからはデバイスのトポロジーに応じた最適なブロックサイズの算出が mkfs.gfs2 コマンドにより試行されます。一般的には Linux のデフォルトページのサイズ (メモリー) が 4K のため、4K のブロックが推奨のブロックサイズになります。他のファイルシステムとは異なり、GFS2 では大半の操作が 4K カーネルバッファーを使用して実行されます。このため、ブロックサイズを 4K にするとカーネル側でのバッファー操作の作業負担が緩和されることになります。

パフォーマンスを最適化するには、デフォルトのブロックサイズを使用することを推奨します。デフォルト以外のブロックサイズを使用する必要があるのは、極めて小さなファイルを多数格納する効率性の高いストレージを必要としている場合のみでしょう。

GFS2 では、ファイルシステムをマウントする必要のあるクラスター内の 1 ノードにつき 1 ジャーナルが必要になります。たとえば、16 ノードで構成されるクラスターがあるとします。ファイルシステムをマウントさせるのは 16 ノードのうち 2 ノードのみの場合、必要となるジャーナル数も 2 つのみです。3 つ目のノードでマウントさせる必要が生じた場合は gfs2_jadd コマンドを使用すればいつでもジャーナルを追加することができます。GFS2 ではジャーナルを臨機応変に追加することができます。

mkfs.gfs2 コマンドを実行して GFS2 ファイルシステムを作成する際には、ジャーナルのサイズを指定することができます。サイズを指定しなかった場合には、デフォルトで 128 MB に設定されます。これは大半のアプリケーションで最適な値です。

一部のシステム管理者は、128 MB は大きすぎると考えて、ジャーナルのサイズを最小限の 8 MB に縮小したり、より慎重となって 32 MB に指定しようとする場合があります。このような値に指定しても機能はするかもしれませんが、パフォーマンスに深刻な影響を及ぼす可能性があります。多くのジャーナリングシステムと同様に、GFS2 がメタデータの書き込みを行う際には毎回、メタデータは配置される前にジャーナルにコミットされます。これにより、ファイルがクラッシュしたり、電源が切断された場合でも、マウント時にジャーナルが自動再生される際に全メタデータが確実に復旧されます。しかし、ファイルシステムアクティビティがそれほど大量でなくとも 8 MB ジャーナルは満たされてしまい、ジャーナルが満杯になると、GFS2 はストレージへの書き込みを待つ必要があるため、パフォーマンスが低下してしまいます。

通常は、128 MB のデフォルトジャーナルサイズを使用することを推奨します。使用するファイルシステムが極めて小型 (例: 5 GB) の場合には、128 MB のジャーナルは実用的でない可能性があります。使用するファイルシステムが大型で、十分な容量がある場合には、256 MB のジャーナルを使用するとパフォーマンスが向上するでしょう。

GFS2 ファイルシステムを mkfs.gfs2 コマンドで作成すると、ストレージが均一のサイズに分割されます。この分割された部分それぞれがリソースグループと呼ばれます。このリソースグループに最適なサイズの算出はコマンドによって試行されます (32MB から 2GB の範囲)。mkfs.gfs2 コマンドの-r オプションを使用するとデフォルトを無効にすることができます。

最適なリソースグループサイズは、ファイルシステムの使用法によって左右されます。使用率はどの程度になるか、極度に断片化されるかどうかなどの点を考慮してください。

最適なパフォーマンスとなるサイズを判断するためにはいろいろなサイズで試してみる必要があります。完全な実稼働環境に導入を行う前に、こうしたテストをテスト用クラスターで行って最適なサイズを確定するのが最良の方法となります。

使用するファイルシステムのリソースグループ数が多すぎると (リソースグループのサイズが小さすぎる)、空きブロックの検索を大量のリソースグループに対して行わねばならずブロック割り当てに無駄な時間がかかりすぎてしまう場合があります。ファイルシステムの使用率が高いほど、検索対象となるリソースグループも多くなり、そのリソースグループそれぞれにクラスター全体のロックが必要となるためパフォーマンス低下の原因となります。

しかし、ファイルシステムのリソースグループ数が少なすぎると (リソースグループのサイズが大きすぎる)、同じリソースグループをロックしようとブロック割り当ての競合が頻繁に発生する可能性があり、パフォーマンスにも影響を及ぼします。例えば、10GB の大きさのファイルシステムを 5 個のリソースグループ (2GB サイズ X 5) に分割した場合と 320 個のリソースグループ (32MB サイズ x 320) に分割した場合とで比較してみます。クラスター内のノードの競合がより激しくなるのは 5 個のリソースグループの方です。また、ブロック割り当ての度、数が少ないリソースグループ内で空きブロックがあるリソースグループを探そうとするため、ファイルシステムがほぼ満杯の状態になるとさらに問題は悪化します。GFS2 ではこのような問題を以下の 2 種類の方法で軽減しようとします。

最悪の事例は、全ノードがファイルの作成を行う中心的なディレクトリーがひとつある場合です。この場合、すべてのノードが同じリソースグループを常にロックしようと競合してしまいます。