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

Global File System 2 (GFS2) ファイルシステムにより、単一クラスター内の複数のコンピューター (「ノード」) が同じストレージを協調的に共有することが可能となります。このような連携を実現して複数ノード間におけるデータの一貫性を維持するには、ノードで、ファイルシステムリソースを対象にクラスター全体にわたるロックスキームを採用する必要があります。このロッキングスキームは、TCP/IP などの通信プロトコルを使用してロッキング情報を交換します。
本章に記載の推奨事項にしたがって、パフォーマンスを向上させることができます。これには、GFS2 ファイルシステムの作成、使用、メンテナンスに関する内容が含まれます。

重要

Red Hat High Availability アドオンの導入がニーズを満たし、サポート可能であることを確認してください。Red Hat 認定担当者に相談して設定を確認してからデプロイするようにしてください。

2.1. フォーマットに関する考慮事項

本セクションでは、パフォーマンスを最適化するための GFS2 ファイルシステムのフォーマット方法についての推奨事項を取り上げます。

2.1.1. ファイルシステムサイズ: 小さい方が好ましい

GFS2 は、64 ビットアーキテクチャーをベースにしており、理論的には 8 EB の ファイルシステムに対応可能です。ただし、現在サポートしている GFS2 ファイルシステムの最大サイズは、64 ビットのハードウェアでは 100 TB、32 ビットのハードウェアでは 16 TB です。
GFS2 の大型ファイルシステムは可能ですが、それが推奨されるということではない点に注意してください。GFS2 の経験則では、小さいほど好ましく、10 TB のファイルシステムを 1 つ使用するよりも、1 TB のファイルシステムを 10 使用した方がよいことになります。
GFS2 ファイルシステムのサイズを小さくとどめることが推奨される理由として、以下の点があげられます。
  • 各ファイルシステムのバックアップ所要時間が短縮されます。
  • fsck.gfs2 コマンドでファイルシステムをチェックする必要がある場合の所要時間が短縮されます。
  • fsck.gfs2 コマンドでファイルシステムをチェックする必要がある場合は、必要なメモリーが少なくなります。
また、メンテナンス対象となるリソースグループが少なくなることにより、パフォーマンスが向上します。
当然ながら、GFS2 ファイルシステムのサイズを小さくしすぎた場合には、容量が不足してしまう可能性があり、それが影響をもたらすことになります。サイズを決定する前には、ご使用になる環境独自のユースケースを考慮すべきです。

2.1.2. ブロックサイズ: デフォルト (4K) ブロックを推奨

mkfs.gfs2 コマンドは、デバイストポロジーに基づいて最適なブロックサイズの算出を試みます。一般的には、4K ブロックが推奨ブロックサイズです。これは、Linux のデフォルトのページサイズ (メモリー) が 4K であるためです。GFS2 は他のファイルシステムとは異なり、4K カーネルバッファーを使用して大半の操作を実行します。ブロックサイズが 4K の場合は、カーネルで行う必要のあるバッファー操作の作業が軽減されます。
パフォーマンスを最適化するには、デフォルトのブロックサイズを使用することを推奨します。デフォルト以外のブロックサイズを使用する必要があるのは、極めて小さなファイルを多数格納する効率性の高いストレージを必要としている場合のみでしょう。

2.1.3. ジャーナル数: マウントするノードにつき 1 つ

GFS2 では、クラスター内でファイルシステムをマウントする必要のあるノード 1 つにつき 1 ジャーナルが必要です。たとえば、16 ノードで構成されるクラスターで、2 つのノードのみからファイルシステムをマウントする必要が場合に必要なジャーナルは 2 つのみとなります。第 3 のノードからマウントする必要がある場合には、gfs2_jadd コマンドでジャーナルを追加することができます。GFS2 では、オンザフライでジャーナルを追加することが可能です。

2.1.4. ジャーナルサイズ: 通常はデフォルト (128 MB) が最適

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

2.1.5. リソースグループのサイズと数

GFS2 ファイルシステムが mkfs.gfs2 コマンドで作成されると、ストレージが均一のサイズに分割されます。この分割された部分はリソースグループとして知られています。最適のリソースグループのサイズ (32MB から 2GB) を推測しようと試行します。mkfs.gfs2 コマンドに-r オプションをつけることで、デフォルトより優先させることができます。
最適なリソースグループサイズは、ファイルシステムの使用法によって左右されます。使用率はどの程度になるか、極度に断片化されるかどうかなどの点を考慮してください。
どのサイズが最高のパフォーマスを達成できるか、様々なリソースグループサイズを試してみてください。テストクラスターで試してから、完全な実稼働環境に GFS2 をデプロイすることがベストプラクティスとなっています。
使用するファイルシステムのリソースグループ数が多過ぎる (各リソースグループが小さい) 場合には、ブロック割り当てで何万 (または何十万) にも及ぶリソースグループを対象に空きブロックを検索するため、多大な時間の無駄となる場合があります。ファイルシステムの使用率が高いほど、検索対象となるリソースグループが多くなり、それらのすべてにクラスター全体のロックが必要となってしまい、パフォーマンスの低下をもたらします。
しかし、ファイルシステムの中のリソースグループが少なすぎる (各リソースグループが大きすぎる) 場合、頻繁に、同じリソースグループをロックしようとブロックの割り当てが競合する可能性があり、パフォーマンスにも影響を及ぼします。たとえば、10GB のファイルシステムで 5 つの 2GB リソースグループに分割されている場合、利用しているクラスターのノードは、32MB のリソースグループ 320 個に分割されている場合に比べて、リソースグループの競合が激しくなります。また、ファイルシステムの空きがほぼない場合など、さらに問題が悪化します。理由は、空きがあるブロックが見つかるまでに複数のリソースグループを検索する必要がある場合もあるからです。以下のような 2 種類の方法で、GFS2 はこの問題を軽減しようとしています。
  • 第 1 の方法は、リソースグループが完全に満杯になった場合に、GFS2 はその情報を記憶し、以降の割り当てでは、(ブロックが解放されるまで) そのリソースグループをチェックしないようにします。ファイルは決して削除せず、競合度が低くなります。ただし、ご使用のアプリケーションが、ほぼ満杯のファイルシステムで絶えずブロックを削除して新規ブロックを割り当てている場合にはいる場合には、競合度が極めて高くなり、パフォーマンスに深刻な悪影響を及ぼします。
  • 第 2 の方法は、新しいブロックが既存ファイルに追加されると (例：添付)、GFS2 は同じリソースグループ内で、ファイルとして新しいブロックを結合しようとします。こうすることで、パフォーマンスの向上を図ります。つまりディスクが回転している場合は、物理的に距離が短いほうが検索にかかる時間が短縮されます。
最悪のシナリオとしては、集約ディレクトリーが 1 つあり、その中のノードすべてがファイルを作成しようとする場合などです。これは、全ノードが同じリソースグループをロックしようと常に競合するためです。