Solaris Cluster 環境で Highly Available NFS ファイルシステムを構成する一般的な方法は、HA-NFS エージェント (SUNW.nfs) を使用するものです。SUNW.nfs エージェントは単純に、エクスポートする必要のあるファイルシステムの共有を行います。

SUNW.HAStoragePlus でフェイルオーバーファイルシステムとして ZFS をサポートする場合、ZFS を基盤のファイルシステムとして Highly Available NFS ファイルシステムを構成する方法は 2 つ考えられます。次の 2 つです。

1. zpool のファイルシステムについて ZFS sharenfs プロパティを有効 (つまり、sharenfs=on) にし、SUNW.nfs は使用しない。
2. zpool のファイルシステムについて ZFS sharenfs プロパティを無効 (つまり、sharenfs=off) にし、SUNW.nfs で実際の共有を行う。
   

この 2 つのアプローチのうち、HA-NFS が正常に機能するのは SUNW.nfs エージェントが使用される場合 (つまり、オプション 2) のみです。このブログでは、Cluster 環境で ZFS とともに Highly Available NFS ファイルシステムを構成するには SUNW.nfs が必要となる理由について説明します。

クライアントによるロックの再利用 (NFSv[23])

statd(1M) は、サーバー上でロックを保持するクライアントやプロセスを追跡しています。サーバーはこの情報を使用して、NFS サーバーのリブートまたはフェイルオーバーが発生したときにクライアントがロックを再利用できるようにします。

SUNW.nfs を使用せずに ZFS sharenfs プロパティをオンに設定することでファイルシステムを共有している場合、ロックの情報はホスト固有のローカルファイルシステムである /var/statmon 下に保持されます。そのため、フェイルオーバーが発生すると、サーバーがフェイルオーバーするマシンで格納された情報は使用できません。これにより、サーバーがクライアントにロックを再利用する要求を送信できなくなります。

この問題は、SUNW.nfs エージェントを使用し、監視情報をマルチポートディスク上の安定化ストレージに保持して、すべてのクラスタノードからアクセスできるようにすることで解決できます。

クライアントの状態情報 (NFSv4)

NFSv4 はステートフルプロトコルであり、nfsd(1M) は、安定化ストレージのオープンまたはロックされたファイルと同じように、クライアントのステータスを追跡しています。

ZFS sharenfs プロパティをオンに設定することでファイルシステムを共有している場合、安定化ストレージはクラスタのすべてのノードからはアクセスできない /var/nfs 下に置かれます。この場合、サーバーでフェイルオーバーが発生すると、クライアントの再利用要求が失敗してクライアントアプリケーションが終了する場合があります (クライアントアプリケーションが SIGLOST 信号をキャッチしない場合)。

この問題は、SUNW.nfs エージェントを使用し、状態情報をクラスタノード間で共有される安定化ストレージに保持することで解決できます。これはサーバーがクライアントでステータスを再利用できるようにするのに役立ちます。

次に相違点を図で示します。

SUNW.nfs を使用しない HA-NFS

SUNW.nfs を使用した HA-NFS

 
より正確に言えば、ZFS ファイルシステムの ZFS sharenfs プロパティは Solaris Cluster 環境で機能することを意図していないため、ZFS 上の HA-NFS では SUNW.nfs エージェントの使用が必須となります。

追記:
SUNW.nfs が情報を保持する安定化ストレージは、ZFS の高可用性ファイルシステム (SUNW.nfs リソースタイプの PathPrefix 拡張プロパティの値) 上にあります。

Venkateswarlu Tella (Venku)
Solaris Cluster エンジニアリング