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