7.4. クラスタリング
クラスター化されたストレージはクラスター内の全サーバーに一貫性のあるファイルシステムイメージを提供し、サーバーによる単一の共有ファイルシステムの読み取り/書き込みを可能にします。これは、アプリケーションのインストールやパッチングといったタスクを 1 つのファイルシステムに限定することで、ストレージ管理を簡素化します。クラスター全体のファイルシステムは、アプリケーションデータの冗長コピーの必要性も排除し、バックアップおよび障害回復を簡素化します。
Red Hat の High Availability アドオンは、Red Hat Global File System 2 (Resilient Storage アドオンの一部) と共に、クラスター化されたストレージを提供します。
7.4.1. Global File System 2
Global File System 2 (GFS2) はネイティブのファイルシステムで、Linux カーネルファイルシステムと直接相互作用します。また、複数コンピューター (ノード) が同時にクラスター内の同一ストレージデバイスを共有できるようにします。GFS2 ファイルシステムは、ほぼ自動チューニングですが、手動のチューニングも可能です。このセクションでは、手動でパフォーマンスチューニングを行う際のパフォーマンスの留意点を説明します。
Red Hat Enterprise Linux 6.5 では、GFS2 に Orlov ブロックアロケーターが含まれています。これにより管理者は、ディスク上のブロック割り当てを分散させ、ディレクトリーのコンテンツをディスク上のディレクトリーの近くに配置することが可能になります。これは通常、これらのディレクトリー内での書き込み速度を速めます。
GFS2 マウントポイントのトップレベルディレクトリーに作成されたディレクトリーはすべて、自動的に間隔があけられます。別のディレクトリーをトップレベルとして扱うには、そのディレクトリーに
T 属性のマークを付けます。以下のようになります。
chattr +T directory
これで、マークが付けられたディレクトリー内で作成されたサブディレクトリーすべてがディスク上で間隔をあけられます。
Red Hat Enterprise Linux 6.4 では、GFS2 でのファイルの断片化管理が改善されています。Red Hat Enterprise Linux 6.3 およびそれ以前で作成されたファイルは、1 つ以上のプロセスで同時に複数のファイルが書き込まれた場合、ファイルの断片化が起こりがちでした。この断片化により、大きいファイルが関係するワークロードの場合は特にスピードが遅くなっていました。Red Hat Enterprise Linux 6.4 では、同時書き込みを行うとファイルの断片化が減るため、このワークロードのパフォーマンスが向上します。
Red Hat Enterprise Linux では GFS2 向けのデフラグツールはありませんが、filefrag ツールでファイルを識別して一時ファイルにコピーし、この一時ファイルの名前を変更することでオリジナルファイルを置き換えるという手順を踏んで、個別ファイルをデフラグすることができます (この手順は、書き込みが連続して行われている限り Red Hat Enterprise Linux 6.4 よりも前のバージョンでも可能です)。
GFS2 は、クラスターのノード間の通信が必要となるかもしれないグローバルロッキングメカニズムを使用するので、これらノード間のファイルおよびディレクトリー競合を回避するようにシステムが設計されていると、最高のパフォーマンスが達成されます。競合の回避方法の例を以下に挙げます。
- 可能な場合に
fallocateでファイルおよびディレクトリーを事前に割り当て、割り当てプロセスを最適化するとともにソースページをロックする必要性を回避します。 - 複数ノード間で共有されるファイルシステムのエリアを最小化し、ノード間キャッシュの無効化を最小限にするとともにパフォーマンスを改善します。例えば、複数のノードが同一ファイルシステムをマウントしても、異なるサブディレクトリーにアクセスすると、あるサブディレクトリーを別のファイルシステムに移動することでパフォーマンスが向上する可能性が高まります。
- 最適なリソースグループのサイズと数を選択します。これは、典型的なファイルサイズとシステム上で利用可能なツリースペースによって異なります。また、複数ノードがあるリソースグループを同時に使用しようと試みる可能性に影響を与えます。リソースグループが多すぎると、割り当てスペースを探す間にブロックの割り当てが遅くなります。一方で、リソースグループが少なすぎると、解放中にロック競合を引き起こす可能性があります。通常は、複数の設定を試して、ワークロードに最適なものを決定するのがよい方法です。
ただし、GFS2 ファイルシステムのパフォーマンスに影響を与えるのは競合問題だけではありません。全体的なパフォーマンスを改善するベストプラクティスの例を以下に挙げます。
- クラスターノードから予測される I/O パターンおよびファイルシステムのパフォーマンス要件にしたがってストレージハードウェアを選択します。
- 可能な場合はソリッドステートストレージを使用してシーク時間を短縮します。
- ワークロードに適したサイズのファイルシステムを作成し、ファイルシステムが容量の 80% を超えないようにします。より小さいファイルシステムではバックアップ時間は大きさに比例して短くなり、ファイルシステムのチェックに要する時間とメモリが少なくなりますが、ワークロードに対して小さすぎると断片化が進む傾向があります。
- メタデータ集約型のワークロードの場合、もしくはジャーナル化されたデータを使用する場合に、ジャーナルサイズを大きく設定します。これはより多くのメモリを使用しますが、書き込みが必要となる前により多くのジャーナリングスペースがデータ保存に使えることから、パフォーマンスが改善します
- GFS2 ノード上のクロックが確実に同期して、ネットワーク化されたアプリケーションとの問題を回避するようにします。NTP (Network Time Protocol) の使用が推奨されます。
- アプリケーションの操作でファイルまたはディレクトリーのアクセス時間がクリティカルでないならば、ファイルシステムに
noatimeとnodiratimeのマウントオプションをマウントします。注記
Red Hat は GFS2 でnoatimeオプションを使用することを強く推奨します。 - クォータを使用する必要がある場合は、クォータ同期処理の頻度を下げるか、fuzzy クォータ同期を使用して継続的なクォータファイル更新から発生するパフォーマンス問題を防止します。
注記
Fuzzy quota accounting を使うと、ユーザーやグループはクォータの制限値を若干超えることが許されます。この問題を最小化するために、ユーザーもしくはグループがクォータ制限値に近づくと、GFS2 は動的に同期期間を引き下げます。
GFS2 パフォーマンスチューニングの各側面に関する詳細情報は 『Global File System 2』 ガイドを参照してください。これは http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ から入手できます。
