第2章 GFS2 の設定および操作における考慮事項
Global File System 2 (GFS2) ファイルシステムにより、単一クラスター内の複数のコンピューター (ノード) が同じストレージを協調的に共有することが可能となります。このような連携を実現して複数ノード間におけるデータの一貫性を維持するには、ノードで、ファイルシステムリソースを対象にクラスター全体にわたるロックスキームを採用する必要があります。このロックスキームは、TCP/IP などの通信プロトコルを使用して、ロック情報を交換します。
本章に記載の推奨事項にしたがって、パフォーマンスを向上させることができます。これには、GFS2 ファイルシステムの作成、使用、メンテナンスに関する内容が含まれます。
重要
Red Hat High Availability Add-On の導入がお客様のニーズを満たし、サポート対象であることを確認してください。Red Hat 認定担当者に相談して設定を確認してからデプロイするようにしてください。
2.1. フォーマットに関する考慮事項
本セクションでは、パフォーマンスを最適化するための GFS2 ファイルシステムのフォーマット方法についての推奨事項を取り上げます。
2.1.1. ファイルシステムサイズ: 小さい方が好ましい
GFS2 は、理論的には 8 EB のファイルシステムに対応できる 64 ビットアーキテクチャーに基づいています。ただし、64 ビットハードウェア用で現在対応している GFS2 ファイルシステムの最大サイズは 100 TB です。
GFS2 のファイルシステムは大きくても構いませんが、推奨されているわけではありません。GFS2 の経験則から、小さい方がよいとされています。10 TB のファイルシステムを 1 つ用意するより、1 TB のファイルシステムを 10 個用意するほうがよいとされています。
GFS2 ファイルシステムのサイズを小さくとどめることが推奨される理由として、以下の点があげられます。
- 各ファイルシステムのバックアップ所要時間が短縮されます。
- fsck.gfs2 コマンドでファイルシステムをチェックする必要がある場合の所要時間が短縮されます。
- fsck.gfs2 コマンドでファイルシステムをチェックする必要がある場合は、必要なメモリーが少なくなります。
また、メンテナンス対象となるリソースグループが少なくなることにより、パフォーマンスが向上します。
当然ながら、GFS2 ファイルシステムのサイズを小さくしすぎると、容量が不足し、それ自体に影響が及ぶ可能性があります。サイズを決定する前に、どのように使用されるかを考慮してください。
2.1.2. ブロックサイズ: デフォルト (4K) ブロックを推奨
mkfs.gfs2 コマンドは、デバイストポロジーに基づいて最適なブロックサイズの算出を試みます。一般的には、4K ブロックが推奨ブロックサイズです。これは、4K が Linux のデフォルトのページサイズ (メモリー) であるためです。その他の一部のファイルシステムとは異なり、GFS2 は 4K カーネルバッファーを使用して多くの操作を実行します。ブロックサイズが 4K であれば、カーネルによるバッファー操作の作業数が減ります。
パフォーマンスを最大にするためにも、デフォルトのブロックサイズを使用することが推奨されます。小さいファイルが大量にある効率的なストレージが必要な場合のみ、別のブロックサイズを使用してください。
2.1.3. ジャーナル数: マウントするノードにつき 1 つ
GFS2 では、ファイルシステムのマウントを必要とするクラスターの各ノードにジャーナルが必要になります。たとえば、16 ノードのクラスターがあり、2 つのノードからファイルシステムのみをマウントする必要がある場合は、2 つのジャーナルのみが必要になります。第 3 のノードからマウントする必要がある場合には、gfs2_jadd コマンドでジャーナルを追加することができます。GFS2 では、オンザフライでジャーナルを追加することが可能です。
2.1.4. ジャーナルサイズ: 通常はデフォルト (128 MB) が最適
mkfs.gfs2 コマンドを実行して GFS2 ファイルシステムを作成する際には、ジャーナルのサイズを指定することができます。サイズを指定しないと、デフォルトの 128 MB になります。これは、ほとんどのアプリケーションに最適です。
一部のシステム管理者は、128 MB では過剰と考え、ジャーナルのサイズを最低レベルの 8 MB まで、あるいはより従来的な 32MB まで縮小することを望んでいます。動作に問題が起きない場合でも、パフォーマンスに重大な影響を与える可能性があります。多くのジャーナリングファイルシステムと同様に、GFS2 がメタデータを書き込むたびに、メタデータの配置前にジャーナルにコミットされます。これにより、システムがクラッシュしたり、停電したりした場合に、ジャーナルがマウント時に自動的に再生される時に、すべてのメタデータが復元します。ただし、ファイルシステムのアクティビティーでは 8 MB のジャーナルが簡単に埋まってしまいます。ジャーナルがいっぱいになると、GFS2 がストレージへの書き込みを待つ必要があるため、パフォーマンスが低下します。
通常、デフォルトのジャーナルサイズである 128 MB を使用することが推奨されます。ファイルシステムが非常に小さい (例: 5GB) 場合、128 MB のジャーナルでは非現実的である可能性があります。より大きなファイルシステムがあり、容量に余裕があれば、256 MB のジャーナルを使用するとパフォーマンスが向上する可能性があります。
2.1.5. リソースグループのサイズおよび数
GFS2 ファイルシステムが mkfs.gfs2 コマンドで作成されると、ストレージが均一のサイズに分割されます。最適なリソースグループサイズ (32MB から 2GB) の推定値を計算しようとします。最適のリソースグループのサイズ (32MB から 2GB) を推測しようと試行します。mkfs.gfs2 コマンドに-r オプションをつけることで、デフォルトより優先させることができます。
最適なリソースグループのサイズは、ファイルシステムの使用方法によって異なります。どの程度いっぱいになるか、または著しく断片化されるかどうかを考慮してください。
どのサイズが最適なパフォーマンスになるかを確認するには、異なるリソースグループのサイズで実験する必要があります。GFS2 を完全な実稼働環境にデプロイする前に、テストクラスターを試すのがベストプラクティスと言えます。
使用するファイルシステムのリソースグループ数が多過ぎる (各リソースグループが小さい) 場合には、ブロック割り当てで何万 (または何十万) にも及ぶリソースグループを対象に空きブロックを検索するため、多大な時間の無駄となる場合があります。ファイルシステムが満杯になるほど、検索されるリソースグループが増え、そのすべてにクラスター全体のロックが必要になります。その結果、パフォーマンスが低下します。
しかし、ファイルシステムの中のリソースグループが少なすぎる (各リソースグループが大きすぎる) 場合、頻繁に、同じリソースグループをロックしようとブロックの割り当てが競合する可能性があり、パフォーマンスにも影響を及ぼします。たとえば、2 GB の 5 つのリソースに分けられた 10GB のファイルがある場合、クラスター内のノードは、同じファイルシステムが 32 MB の 320 個のリソースグループに分けられている場合よりも頻繁に 5 つのリソースグループを奪おうとします。空きブロックを持つリソースグループを見つける前に、各ブロックの割り当てが複数のリソースグループを参照する必要があるため、ファイルシステムがほぼ満杯になると、この問題は悪化します。GFS2 は、次のいずれかの方法でこの問題を軽減しようとします。
- 第 1 の方法は、リソースグループが完全に満杯になった場合に、GFS2 はその情報を記憶し、以降の割り当てでは、(ブロックが解放されるまで) そのリソースグループをチェックしないようにします。ファイルを削除しなければ、競合は少なくなります。ただし、アプリケーションがブロックを継続的に削除し、ほぼ満杯のファイルシステムに新しいブロックを割り当てる場合は、競合が非常に高くなり、パフォーマンスに深刻な影響を及ぼします。
- 第 2 の方法は、新しいブロックが既存ファイルに追加されると (例: 添付)、GFS2 は同じリソースグループ内で、ファイルとして新しいブロックを結合しようとします。こうすることで、パフォーマンスの向上を図ります。つまりディスクが回転している場合は、物理的に距離が短いほうが検索にかかる時間が短縮されます。
最悪のシナリオとしては、集約ディレクトリーが 1 つあり、その中のノードがすべてファイルを作成しようとする場合などです。これは、全ノードが同じリソースグループをロックしようと常に競合するためです。
