Windows NFSv3.0の主な問題、対処方法、ベストプラクティス

ONTAP サポートの制限： 

Microsoft WindowsネイティブのNFSクライアント実装は、現在サポートされているすべてのData ONTAP 7-Modeシステムでサポートされています。また、8.2.3以降のclustered Data ONTAP 8.2リリースもサポートされます。 また、  8.3.1以降のclustered Data ONTAP 8.3リリースもサポートされます。 

問題：

問題1：

「Network Status Monitor（NSM）」プロトコルがサポートされないと、Windows NFSクライアントでIOが中断されます。

概要：現在の設計では、Windows NFSv3クライアントはNSMプロトコルをサポートしていません。そのため、LIFのフェイルオーバー（テイクオーバー/ギブバック、パニックギブバック、リバートなど）やストレージ移動処理（vol move / aggregate relocate）を含むストレージフェイルオーバー処理では、クライアントからの共有ロックとバイト範囲ロックが失われます。その結果、クライアントのIOが中断されます。「 Error no.59 (unexpected network error)のようなエラーメッセージが表示される場合があります。

回避策：なし

問題2：

ストレージフェイルオーバー/モビリティ処理を使用したI/O時に、Windows NFSクライアントで次のエラーメッセージが報告され
ます。' winerror=158-The segment is already unlocked'

nfs：NFSサーバは、クライアントから送信された冪等でない操作の再生キャッシュを維持します概要。この再生キャッシュは、クライアントからの元の冪等でない操作に対する応答を保持します。これは、要求を再送信するために同じ応答を提供するために必要です。再送信された要求を再度処理すると、結果が異なり、予期しない結果になります。

たとえば、リプレイキャッシュがない場合、リンク解除操作は最初は成功しますが、   再送信された要求ではENOENT エラーが発生する可能性があります。Data ONTAPでは、再生キャッシュは永続的ではありません。そのため、ストレージをあるノードから別のノードに移動したStorage Failover（SFO；ストレージフェイルオーバー）/ Aggregate Relocate（ARL；アグリゲートの再配置）などのイベントでは、そのストレージでのNFS処理の再生キャッシュが失われます。再送信されたNFS処理では、SFO / ARLイベントの直後に再生キャッシュが保護されません。

回避策：なし

問題3：

"Network Error - 53" WindowsにNFS共有をマウントしようとしているとき

概要：お客様がWindowsへのNFSv3マウントを試みていますが、汎用の"Network Error - 53" を受け取っています。
コマンドの例：
C:\Users\admin> mount 10.0.0.1:\share Z:

回避策：
1.コマンドの構文を確認する
正しい構文は こちらにあります。
2.クライアントとサーバ3のNFSバージョンが一致しません
。Last回避策は こちらからご覧いただけます。

ベストプラクティス： 

1. Windows NFSv3を有効にするには、Storage Virtual Machine （SVM）の設定が必要です。
   Storage Virtual Machine（SVM）でWindows vserver nfs modify -vserver svm_name -v3-ms-dos-client enabled
 -enable-ejukebox and -v3-connection-drop   NFSv3クライアントを有効にするには、次のコマンドを実行します。
   Windows NFSv3クライアントをサポートするすべてのSVMで、次のコマンドを実行して パラメータを無効にします。また、ボリュームを無停止で移動できます。
   vserver nfs modify -vserver vserver_name -enable-ejukebox false -v3-connection-drop disabled 
2. Windows NFSv3クライアントは、デフォルトでソフトマウントを使用します。ただし、Windows NFSv3クライアントからストレージシステムにエクスポートをマウントする場合は、必ず -o mtype=hard  オプションを指定してハードマウントを使用してください。
3. 計画的なストレージフェイルオーバーの前に、すべてのWindows NFSクライアントがアンマウントされていることを確認してください。これにより、クラスタ内に未処理のNLMロックが残るのを防ぐことができます。
4. 計画外のストレージ障害が発生した場合は、Windows NFSクライアントを再マウントします。この処理を実行すると   、クライアントによって作成された古いNLMロックがクライアントに適切にクリーンアップされます。
5. clustered Data ONTAP 8.3以降では、  エクスポート \IPaddress_or_hostnameROOT-pathjunction_path を適切にマウントするために、Windows NFSv3クライアントでIPアドレスまたはホスト名とジャンクションパスの間に文字列ROOT-path を含める必要があります。
   例： mount -o mtype=hard  \10.53.33.10ROOT-pathvol1 z：
     Data ONTAP 8.3.1ではルートパスに言及する必要はありません。
   例： mount -o mtype=hard \10.53.33.10volvol1 z：
6. clustered Data ONTAP 8.3リリース以降では showmount ストレージシステムで 機能を使用できます。 nfs server modify -vserver NFS83-showmount enable実行し て有効にします。有効にすると、作成された新しいボリュームまたはqtreeは showmount -e <dataip>、クライアント上の コマンドの出力に反映されます。以前に作成したボリュームまたはqtreeを表示するには、cache clear export-policy cache flush -vserver SVM -cache showmount  コマンドを実行します。
    showmount の使用の詳細については、 TR-4067：『clustered Data ONTAP NFSベストプラクティスおよび実装ガイド』の51ページを参照してください。