2.9.2. GFS2 によるパフォーマンス調整
通常は、問題を引き起こすアプリケーションのデータ格納方法を変更すると、パフォーマンスを大幅に向上させることができます。
問題を引き起こすアプリケーションの典型的な例が Email サーバーです。各ユーザー用ファイルを含むスプールディレクトリー (
mbox)、または各メッセージ用のファイルを格納する各ユーザー用のディレクトリー (maildir) などで構成されているのが一般的です。IMAP 経由で要求が到着した場合、特定のノードに対するアフィニティを各ユーザーに提供するのが理想的な設定となります。 これにより、Email メッセージの表示と削除の要求は、その単一ノードのキャッシュから提供される傾向になります。そのノードに障害が発生した場合は、当然、別のノードでセッションを再起動させることができます。
メールが SMTP 経由で到着した場合も、デフォルトで特定のユーザーのメールが特定のノードに渡されるようノードを個別に設定することが可能です。デフォルトのノードが稼働していない場合、メッセージは受信ノードによりユーザーのメールスプールに直接保存されます。これも、通常の場合には特定のファイルセットが単一のノードにキャッシュされ、そのノードの障害時には直接アクセスができるようにすることを目的として設計されています。
この設定により GFS2 のページキャッシュを最大限に活用し、
imap または smtp にかかわらず、アプリケーションに対して障害の発生を透過的にすることができます。
バックアップは、難しいことが多いもう一つの領域です。可能であれば、特定の inode セットをキャッシュしているノードから直接、各ノードの作業セットをバックアップしておくことを強く推奨します。定時に実行するバックアップスクリプトを使用していて、それが GFS2 で実行しているアプリケーションの応答時間の急増と同時に発生している場合には、クラスターがページキャッシュを効率的に使用していない可能性が高くなります。
当然ながら、バックアップを実行するためにアプリケーションを停止することができるような優位な立場にある場合は問題はありません。しかし、バックアップがひとつのノードだけで実行される場合、そのバックアップが完了するとファイルシステムの大部分がそのノードにキャッシュされ、その後に他のノードからのアクセスする際のパフォーマンスが低下します。この問題は、次のコマンドでバックアップ完了後にバックアップノードにある VFS ページキャッシュを削除することにより、ある程度軽減することができます。
echo -n 3 >/proc/sys/vm/drop_caches
ただしこの方法は、各ノードの作業セットが、大半は読み取り専用としてクラスター全体で共有される、もしくは大部分が単一のノードからアクセスされるかのいずれかとなるように注意するほどは、よい解決策ではありません。
