2.5.5. GFS2 で NFS をセットアップする
GFS2 のロックサブシステムの複雑性とクラスター化の特性のため、GFS2 での NFS のセットアップには充分な事前準備と細心の注意を払う必要があります。本セクションでは、GFS2 ファイルシステムで NFS サービスを設定するにあたって考慮すべき注意事項について説明します。
警告
GFS2 ファイルシステムが NFS のエクスポートで、かつ NFS クライアントアプリケーションが POSIX ロックを使用する場合、
localflocks オプションを使用してファイルシステムをマウントする必要があります。これが意図する効果は、各サーバーからの POSIX ロックがローカル (つまり、クラスター化されず、相互に独立した状態) となるように強制することです (GFS2 が NFS から クラスターのノード全体に POSIX ロックの実装を試みると数多くの問題があります)。NFS クライアント上で稼働するアプリケーションでは、2 台のクライアントが異なるサーバーからマウントしている場合、ローカライズされた POSIX ロックにより、それら 2 台のクライアントが同じロックを同時に保持できるということになります。すべてのクライアントが単一のサーバーから NFS をマウントしている場合、複数のサーバーが同じロックを別々に許可するという問題はなくなります。localflocks オプションでファイルシステムをマウントするべきかどうかがわからない場合には、このオプションは使用しない方がよいでしょう。ロックはクラスターベースで機能する方が安全です。
GFS2 システム上で NFS サービスを設定する際には、ロックについて考慮する以外に、以下のような点も検討する必要があります。
- Red Hat で対応しているのは、以下のような特性を持つアクティブ/パッシブ構成のロックを備えた NFSv3 を使用する Red Hat High Availability Add-On 設定のみになります。
- バックエンドファイルシステムは、2 〜 16 ノードのクラスター上で稼働する GFS2 ファイルシステムです。
- NFSv3 サーバーは、単一クラスターノードから GFS2 ファイルシステム全体を一度にエクスポートするサービスとして定義されます。
- NFS サーバーは、一つのクラスターノードから他のクラスターノードへのフェイルオーバーが可能です (アクティブ/パッシブ構成)。
- NFS サーバー経由 以外の GFS2 ファイルシステムへのアクセスは許可されません。これには、ローカルの GFS2 ファイルシステムアクセスと、Samba または クラスター化された Samba を介したアクセスの両方が含まれます。
- システム上で NFS クォータはサポートされていません。
この構成では、ノードに障害が発生しても、NFS サーバーがノードからノードへフェイルオーバーすることにより、fsckコマンドを実行する必要は生じないため、ファイルシステムに高可用性を提供し、システムダウンタイムを削減します。 fsid=NFS オプションは、GFS2 の NFS エクスポートには必須です。- クラスターに問題が生じた場合 (例: クラスタが定足数に達せず、フェンシングが失敗した場合) には、クラスター化された論理ボリュームと GFS2 ファイルシステムはフリーズされ、クラスターが定足数を満たすようになるまではアクセスできません。この手順で説明したような、単純なフェイルオーバー解決方法がご使用のシステムに最も適切かどうかを判断する際には、この可能性を考慮する必要があります。
