Azure NetApp Files の NFS に関するよくあるご質問

  • [アーティクル]

この記事では、Azure NetApp Files の NFS プロトコルに関するよくあるご質問 (FAQ) に回答します。

Azure VM が起動または再起動されたときに、ボリュームが自動的にマウントされるようにしたいと考えています。 NFS の永続ボリュームのホストを構成するにはどうすればよいですか?

VM の起動または再起動時に NFS ボリュームを自動的にマウントする場合は、ホスト上の /etc/fstab ファイルにエントリを追加します。

詳細については、「Windows または Linux 仮想マシンのボリュームをマウントする」を参照してください。

Azure NetApp Files でサポートされている NFS のバージョンを何ですか?

Azure NetApp Files では、NFSv3 および NFSv4.1 がサポートされています。 いずれかの NFS バージョンを使用してボリュームを作成できます。

Azure NetApp Files では NFSv4.2 が正式にサポートされていますか?

現在、Azure NetApp Files では、NFSv4.2 もその補助機能 (スパース ファイル操作、拡張属性、セキュリティ ラベルなど) も正式にはサポートされていません。 ただし、NFSv4.1 が使われていると、NFS サーバーに対してその機能が有効になります。つまり、NFS クライアントは、次の 2 つの方法のいずれかで NFSv4.2 プロトコルを使ってマウントできます。

  • マウントのオプションで vers=4.2、nfsvers=4.2、または nfsvers=4,minorversion=2 を明示的に指定します。
  • マウントのオプションでは NFS のバージョンを指定せず、NFS クライアントがサポートされている最も高い NFS バージョンにネゴシエートできるようにします。

ほとんどの場合、クライアントが NFSv4.2 を使ってマウントしても、問題は発生しません。 ただし、一部のクライアントが NFSv4.2 または NFSv4.2 拡張属性機能を完全にサポートしていない場合は、問題が発生する可能性があります。 さらに、NFSv4.2 は現在 Azure NetApp Files ではサポートされていないため、NFSv4.2 に関する問題はスコープに含まれません。

クライアントで NFSv4.2 のマウントに関する問題が発生しないようにして、サポート可能性に準拠するには、マウント オプションで NFSv4.1 バージョンが指定されていること、またはクライアントの NFS クライアント構成で NFS のバージョンを NFSv4.1 に制限するように設定されていることを確認します。

ルート スカッシュを有効にするにはどうすればよいですか?

ボリュームのエクスポート ポリシーを使用して、ルート アカウントがボリュームにアクセスできるかどうかを指定できます。 詳細については、「NFS ボリュームのエクスポート ポリシーを構成する」を参照してください。

複数のボリュームに同じファイル パスを使用できますか?

次の場合に、同じファイル パスを使用できます。

  • 異なるリージョンにデプロイされたボリューム
  • 同じリージョン内の異なる可用性ゾーンにデプロイされたボリューム

使っているプロトコル:

  • リージョン ボリューム (可用性ゾーンなし)、または
  • 同じ可用性ゾーン内のボリューム

同じファイル パスを使用できますが、ファイル パスは、委任された各サブネット内で一意であるか、委任された異なるサブネットに割り当てられている必要があります。

詳しくは、「Azure NetApp Files の NFS ボリュームを作成する」または「Azure NetApp Files のデュアルプロトコル ボリュームを作成する」をご覧ください。

Windows クライアントを使用して NFS ボリュームにアクセスしようとすると、クライアントによるフォルダーやサブフォルダーの検索に時間がかかるのはなぜですか?

フォルダーとサブフォルダーの検索を高速化するために、Windows クライアントで CaseSensitiveLookup が有効になっていることを確認します。

  1. 次の PowerShell コマンドを使用して CaseSensitiveLookup を有効にします。
    Set-NfsClientConfiguration -CaseSensitiveLookup 1
  2. Windows サーバーでそのボリュームをマウントします。
    例:
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

Azure NetApp Files では NFSv4.1 のファイル ロックはどのようにサポートされますか?

NFSv 4.1 クライアントの場合、Azure NetApp Files では、リース ベースのモデルですべてのファイル ロックの状態を維持する NFSv4.1 ファイル ロック メカニズムをサポートします。

RFC 3530 に基づき、Azure NetApp Files では、NFS クライアントによって保持されるすべての状態に対して 1 つのリース期間を定義します。 定義された期間内にクライアントによってリースが更新されない場合、クライアントのリースに関連付けられているすべての状態がサーバーによって解放されます。

たとえば、ボリュームをマウントするクライアントがタイムアウトを超えて応答しなくなったりクラッシュしたりすると、ロックが解放されます。 クライアントでは、ファイルの読み取りなどの操作を実行することで、明示的または暗黙的にリースを更新できます。

猶予期間とは、クライアントがサーバーの回復中にロック状態を回収できるようにする特別な処理の期間を定義するものです。 リースの既定のタイムアウトは 30 秒で、猶予期間は 45 秒です。 その期間が経過すると、クライアントのリースが解放されます。

Azure NetApp Files では、ファイル ロックの解除もサポートされています。

Azure NetApp Files のファイル ロックの詳細については、「ファイル ロック」を参照してください。

.snapshot ディレクトリが NFSv4.1 ボリュームでは表示されないのに、NFSv3 ボリュームでは表示されるのはなぜですか?

設計上、.snapshot ディレクトリは NFSv4.1 クライアントからは見えません。 既定で、NFSv3 クライアントからは .snapshot ディレクトリが見えます。 NFSv3 クライアントから .snapshot ディレクトリが見えないようにするには、スナップショット パスが非表示になるようにボリュームのプロパティを編集します。

Oracle dNFS

dNFS で必要な Oracle パッチはありますか?

重要

Oracle 19c 以降を使用している場合は、Oracle バグ 32931941 のパッチが適用されていることを確認する必要があります。 Oracle ユーザーが現在使用しているパッチ バンドルのほとんどには、このパッチが含まれていません。 このパッチは最近のパッチ バンドルのサブセットにのみ含まれています。

データベースがこのバグの影響を受けやすくなっている場合にネットワークが中断されると、高い確率でブロックが破損します。 ネットワークを中断するイベントには、ストレージ エンドポイントの再配置、ボリュームの再配置、ストレージ サービスのメンテナンスなどが含まれます。 破損はただちに検出されるとは限りません。

この破損は ONTAP のバグではないし、Azure NetApp Files サービス自体のバグでもなく、Oracle dNFS のバグの結果です。 特定のネットワーク中断イベントやネットワーク再構成イベントでの NFS IO への応答が、誤って処理されます。 データベースでは、書き込み時に更新されていたブロックが誤って書き込まれます。 その同じブロックを後で上書きしたとき、破損したブロックが自動的に修正されることがあります。 そうでない場合、最終的に Oracle データベース プロセスによって検出されます。 アラート ログにエラーが記録され、Oracle インスタンスが終了する可能性があります。 さらに、dbv 操作と RMAN 操作で破損が検出されることもあります。

Oracle が公開しているドキュメント 1495104.1 では、推奨される dNFS パッチが継続的に更新されています。 データベースで dNFS が使用されている場合は、DBA チームがこのドキュメントで更新プログラムをチェックしているかを確認してください。

重要

Azure NetApp Files ボリュームで Oracle dNFS と NFSv4.1 を使用しているお客様は、「NFSv4.1 で Oracle dNFS を使用するために必要なパッチはありますか?」にある措置を必ず取る必要があります。

NFSv4.1 で Oracle dNFS を使用するために必要なパッチはありますか?

重要

データベースで NFSv4.1 と Oracle dNFS を併用している場合は、Oracle のバグ 33132050 と 33676296 のパッチを適用する必要があります。 場合によっては、他のバージョンの Oracle のバックポートを要求する必要があります。 たとえば、執筆時点では、19.11 にはこれらのパッチが提供されていますが、19.3 にはまだです。 サポート ケースでこれらのバグ番号を挙げれば、Oracle のサポート エンジニアには必要な対応がわかります。

この要件は、オンプレミスの ONTAP と Azure NetApp Files の両方を含む、ONTAP ベースのシステムとサービス全般に当てはまります。

これらのパッチが適用されていないと、次のような問題が発生する可能性があります。

  1. バックエンド ストレージ エンドポイントを移動するときにデータベースがハングします。
  2. Azure NetApp Files サービスのメンテナンス イベントでデータベースがハングします。
  3. 通常の操作で Oracle が短時間ハングします (気付かれる場合とそうでない場合があります)。
  4. Oracle のシャットダウンに時間がかかります (シャットダウン プロセスを監視すると、dNFS I/O がタイムアウトするときに一時停止が複数回発生して数分の遅れが生じることがわかります)。
  5. 読み取りで dNFS 応答キャッシュが正しく動作しないためにデータベースがハングします。

これらの問題は、パッチに含まれている dNFS セッション管理と NFS 応答キャッシュの変更によって解決されます。

この 2 つのバグのパッチを適用できない場合は、dNFS と NFSv4.1 を併用しないでください。 dNFS を無効にするか、NFSv3 に切り替えることができます。

Oracle dNFS と NFSv4.1 でマルチパスを使用できますか?

NFSv4.1 を使用している場合、dNFS で複数のパスを使用できません。 複数のパスが必要な場合、NFSv3 を使用する必要があります。 dNFS で複数のパスを使用するには、NFSv4.1 のクラスター全体を対象とした clientID と sessionID のトランキングが必要ですが、これは Azure NetApp Files ではサポートされていません。 結果として、dNFS の起動中にハングが発生します

次のステップ