Share via

WSFC 環境の NFS サーバーに対して 40 台以上のクライアントがロックを解放しないままフェールオーバーすると STOP エラー 0x9e が発生することがある

  • Article

こんにちは。Windows プラットフォーム サポートです。

本稿では、WSFC 環境の NFS サーバーで特定の条件下においてフェールオーバーした場合、STOP エラー 0x9e が発生する現象について確認しております。

[現象]
Windows (Storage) Server 2012/Windows (Storage) Server 2012 R2/Windows (Storage) Server 2016 の Windows Server フェールオーバー クラスタリング (WSFC) 環境で、NFS サーバーに対して、40 台以上の NFS クライアントからロックを保持し、正しくロックを解放しないまま疎通が取れなくなった状態で、NFS サーバーのフェイルオーバーを連続して 2 回実施した場合、STOP エラー 0x9e (USER_MODE_HEALTH_MONITOR) が発生する可能性があります。

 

[原因]
この現象は以下のシナリオで発生します。

1. NFS クライアントからクラスター ノード A 上の NFS サーバーにアクセスし、ファイルをロックします。
その後ファイルのロックを解放しないままネットワークから切断します。このような端末が 40 台存在すると想定します。
2. ノード A からノード B に NFS サーバーをフェイルオーバーします。
3. ノード B で NFS サーバーが起動後、ロックを保持する各 NFS クライアントに UDP 111 番ポートでの通信を試みます。
4. さらにノード B で NFS サーバーを別のノードにフェイルオーバーします。

上記の項番 3 でファイルのロックを解放しなかったクライアントに通信を試行してレスポンスを待機する間、項番 4 で NFS サーバーをオフラインにしようとする処理が項番 3 の完了待ちとなります。
この完了待ちにて 20 分以上時間を要した場合、クラスターの Health Monitoring のタイムアウト (20 分間) により STOP エラー 0x9e (USER_MODE_HEALTH_MONITOR) が発生します。
これは、ロックを未解放のクライアントに対して一台当たり最大 30 秒待機するため、NFS サーバーから疎通できないクライアントが約 40 台存在すると 20 分処理以上の時間を要するために発生します。

 

[回避策]
フェールオーバーの実施前に NFS サーバーで保持されているロックを強制的に解放することで回避できます。

- 現在オープン中のロックを確認するコマンド

Get-NfsClientLock

- 全てのロックを解放するコマンド

Revoke-NfsClientLock -Path *

- 影響について

上記回避策を実施した場合、NFS サーバー側ではロックが強制的に解放され、クライアントで側はロックを保持していると認識された状態となります。
この場合、別のクライアントが同一のファイルに対するロックを要求した際には、別のクライアントがロックを保持することができます。
また、最初にロックを保持していたクライアントから、そのファイルへのアクセスを行った場合に、クライアントアプリケーションによってはエラーが発生する等の影響が考えられます。
既にオフラインになっているクライアントについては、ロックの強制解放を行っても影響はありません。

 

[状況]
・Windows (Storage) Server 2012 および Windows (Storage) Server 2012 R2 について：
本現象が発生する懸念がある場合、事前に回避策の実施を検討ください。

・Windows (Storage) Server 2016 について：
対応策について検討中です。
なお、Windows (Storage) Server 2012 および Windows (Storage) Server 2012 R2 と同様に、本現象が発生する懸念がある場合、事前に回避策の実施を検討ください。

 

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。