検索

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

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

重要

Red Hat High Availability Add-On の導入が実際のニーズを満たすのか、また導入環境が対応可能であるのか必ず確認してください。導入する前に、Red Hat 認定の担当者と構成の検証を行ってください。

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

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

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

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

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

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

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

GFS2 では、ファイルシステムをマウントする必要のあるクラスター内の 1 ノードにつき 1 ジャーナルが必要になります。たとえば、16 ノードで構成されるクラスターがあるとします。ファイルシステムをマウントさせるのは 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 オプションを使用するとデフォルトを無効にすることができます。
最適なリソースグループサイズは、ファイルシステムの使用法によって左右されます。使用率はどの程度になるか、極度に断片化されるかどうかなどの点を考慮してください。
最適なパフォーマンスとなるサイズを判断するためにはいろいろなサイズで試してみる必要があります。完全な実稼働環境に導入を行う前に、こうしたテストをテスト用クラスターで行って最適なサイズを確定するのが最良の方法となります。
使用するファイルシステムのリソースグループ数が多すぎると (リソースグループのサイズが小さすぎる)、空きブロックの検索を大量のリソースグループに対して行わねばならずブロック割り当てに無駄な時間がかかりすぎてしまう場合があります。ファイルシステムの使用率が高いほど、検索対象となるリソースグループも多くなり、そのリソースグループそれぞれにクラスター全体のロックが必要となるためパフォーマンス低下の原因となります。
しかし、ファイルシステムのリソースグループ数が少なすぎると (リソースグループのサイズが大きすぎる)、同じリソースグループをロックしようとブロック割り当ての競合が頻繁に発生する可能性があり、パフォーマンスにも影響を及ぼします。例えば、10GB の大きさのファイルシステムを 5 個のリソースグループ (2GB サイズ X 5) に分割した場合と 320 個のリソースグループ (32MB サイズ x 320) に分割した場合とで比較してみます。クラスター内のノードの競合がより激しくなるのは 5 個のリソースグループの方です。また、ブロック割り当ての度、数が少ないリソースグループ内で空きブロックがあるリソースグループを探そうとするため、ファイルシステムがほぼ満杯の状態になるとさらに問題は悪化します。GFS2 ではこのような問題を以下の 2 種類の方法で軽減しようとします。
  • 第 1 の方法は、リソースグループが完全に満杯になった場合、GFS2 はその情報を記憶してそれ以降からの割り当てではそのリソースグループを検索しないようにします (ブロックが解放されるまで)。ファイルの削除をまったく行わなければ競合度は緩和されます。ただし、ブロックの削除と新規ブロックの割り当てを絶えず行っているアプリケーションがあり、この動作がほぼ満杯状態のファイルシステムで行われると競合度が極めて高くなり、パフォーマンスに深刻な悪影響を及ぼすことになります。
  • 第 2 の方法は、新しいブロックが既存ファイルに追加されると (ファイルへの書き込み追加など)、GFS2 では新しいブロックをそのファイルの一部として同じリソースグループ内にまとめようとします。こうすることでパフォーマンスの向上を図ります。つまり回転しているディスクではブロック同士が物理的に近い距離にあった方が検索にかかる時間も少なくなるということです。
最悪の事例は、全ノードがファイルの作成を行う中心的なディレクトリーがひとつある場合です。この場合、すべてのノードが同じリソースグループを常にロックしようと競合してしまいます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.