既知の問題と制限事項

このページでは、Google Cloud NetApp Volumes の既知の制限事項について説明します。

一般的な問題

このセクションでは、NetApp Volumes の一般的な既知の問題について説明します。

Flex Unified サービスレベルでの RFC 1918 以外の（PUPI）クライアント IP アドレスのサポートに関する問題

問題: Flex Unified サービスレベルでは、RFC 1918 以外の（PUPI） クライアント IP アドレスはサポートされていません。

理由: この制限は、VSA テナント プロジェクト内のファイアウォール ルールの制約によるものです。

解決策: この問題を解決するには、次のオプションを検討してください。

  • RFC 1918 IP アドレスを割り当てる: RFC 1918 プライベート IP アドレスを使用するようにクライアントを構成します。

  • 別のサービスレベルを使用する: Standard、Premium、Extreme、Flex File など、PUPI クライアント IP アドレスをサポートするサービスレベルを使用します。

  • 手動でのファイアウォール構成をリクエストする: 一時的な回避策として、お客様はGoogle Cloud カスタマーケアに連絡して、PUPI クライアント範囲の上り（内向き）ファイアウォール ルールを手動で設定できます。手動構成では、継続的なサポートが必要になる場合があります。このオプションを使用するには、次の情報を記載してサポート リクエストを送信してください。

    • クライアントの PUPI IP 範囲（例: 100.64.0.0/10）

    • 必要なプロトコル ポート（NFS、SMB、iSCSI）

    • ターゲット リージョンとストレージ プールの名前

ボリューム作成後にバックアップ オペレーションを実行すると Not found エラーが発生する

問題: ONTAP モードのボリュームを作成した直後に CreateBackup、RestoreVolume、 または UpdateBackupConfig などのバックアップ オペレーションを実行すると、 オペレーションが失敗し、Not found エラーが発生することがあります。

理由: ボリュームを作成した後、ボリュームとその バックアップ関連リソースがバックアップ サービスで完全に利用可能になるまでに時間がかかることがあります。 この伝播期間中に、バックアップ サービスはボリュームが検出可能になる前にバックアップ リクエストをルーティングすることがあり、Not found エラーが発生します。

解決策: ボリュームを作成してから少なくとも 3 分待ってから、 バックアップ関連のオペレーションを実行してください。

Flex File ボリュームが ping に応答しない

この問題の詳細については、NetApp Volumes への接続をテストするをご覧ください。

重複するプライベート サービス アクセス接続を使用すると、接続が断続的に失われる

構成接続を構成するときに、CIDR 範囲が同じ VPC 上の別のプライベート サービス アクセス接続で使用されている netapp.servicenetworking.googCIDR 範囲と重複すると、ボリューム マウント接続が断続的に失われる可能性があります。この問題を回避するには、重複しない範囲を使用してください。

NFS ボリュームの設定を更新すると、Cloud Volumes Service から NetApp Volumes に移行したボリュームへのクライアント アクセスが中断される可能性がある

問題: ミラーリングされた転送ステータスでアクティブなボリューム レプリケーションのソース ボリュームまたは宛先ボリュームの設定を更新すると、ボリュームへのクライアント アクセスが中断されます。

理由: ボリュームを更新すると、そのエクスポート ポリシーがレプリケーション パートナー ボリュームと同期される可能性があります。更新されたボリュームにエクスポート ポリシーが正しくないか、エクスポート ポリシーがない場合、本番環境のソース ボリュームにマウントされているクライアントがアクセスできなくなり、停止が発生する可能性があります。

背景: レプリケーションがミラーリング状態の場合、 NetApp Volumes は ソース ボリュームと宛先ボリュームのエクスポート ポリシーを自動的に同期します。これにより、一方のボリュームのポリシー変更がもう一方のボリュームに自動的に適用されるため、管理者が手動で介入することなく、クライアント アクセスの一貫性を確保できます。

CVS では、管理者がソース ボリュームと宛先ボリュームの設定を手動で同期する必要があります。CVS から NetApp Volumes へのボリューム移行中に、既存のエクスポート ポリシーが変更されずに転送されたため、レプリケートされたボリュームのエクスポート ポリシーが不整合になる可能性があります。ボリューム レプリケーション関係でソース ボリュームまたは宛先ボリュームのエクスポート ポリシーを更新すると、両方のボリュームのポリシーが自動的に同期されます。

影響を受けるボリューム

この問題は、次のすべての条件を満たすボリュームに適用されます。

  • アクティブなミラーリングされたボリューム レプリケーション内のボリューム。停止後にレプリケーションを再開すると、問題が発生する可能性があります。

  • エクスポート ポリシーを持つすべての NFS 対応ボリューム。

  • ソースと宛先でエクスポート ポリシーが異なるボリューム。

解決策: この問題を解決するには、ソース ボリュームと宛先 ボリュームのエクスポート ポリシーを一度同期する必要があります。次の手順を行います。

  1. ソース ボリュームと宛先ボリュームの両方のエクスポート ポリシーを確認して比較します。

    • エクスポート ポリシーが同じ場合は、何もする必要はありません。

    • エクスポート ポリシーが異なる場合は、エクスポート ルールをマージして、両方のポリシーで指定されたすべてのホストを許可するエクスポート ポリシーを作成します。

  2. マージされたエクスポート ポリシーをソース ボリュームに適用します。このポリシーは、宛先ボリュームにも自動的に適用されます。

エクスポート ポリシーを同期することで、一貫したアクセスを確保し、クライアントの中断を防ぐことができます。

Cloud Volumes Service（CVS）と NetApp Volumes のリソースを一緒に使用するとエラー メッセージが表示される

VPC、プロジェクト、リージョン内で CVS と NetApp Volumes のリソースを一緒に使用すると、エラー メッセージが表示されることがあります。この問題は、プロジェクトで次のいずれかに該当する場合に、プールやポリシーなどのリソースを作成しようとすると発生する可能性があります。

  • このプロジェクトは以前 CVS で使用されていました。

  • NetApp Volumes リソースがないプロジェクトで CVS リソースリスト オペレーションが実行されました。

一般的なエラー メッセージは次のとおりです。

  • Host project and service project must be using the same service。

  • Resources from CVS and NetApp Volumes may not be used together in a single region。

  • Cannot share VPC between 3P and 1P networks。

この問題を解決するには、 Google Cloud カスタマーケアに連絡して、特定のプロジェクトまたはリージョンをリセットして、 NetApp Volumes リソースのみを使用するようにリクエストしてください。

特定のディレクトリで No space left on device または File too large エラーが発生してファイルの作成に失敗する

問題: マウントされたボリュームに新しいファイルまたは サブディレクトリを書き込み、コピー、作成しようとすると、オペレーションが失敗し、 No space left on device（errno 28 / ENOSPC）または File too large（errno 27 / EFBIG）エラーが発生します。

これは、クライアント側のディスク容量クエリ （df -hなど）と Google Cloud コンソールで、ボリュームに十分な論理容量があることが示されている場合でも発生します。 エラーは特定のディレクトリにローカライズされます。同じボリューム上の他のディレクトリでは、ファイルの作成は成功します。

理由: この問題は、単一のディレクトリが 過度に大きくなり、内部制限に達した場合に発生します。これにより、 ストレージ システムは、その特定のロケーションでファイルやサブディレクトリのインデックスを作成できなくなります。

確認:

マウントされたクライアントで次の診断手順を実行して、ディレクトリ サイズの上限に達しているかどうかを確認します。

  1. ローカライズされたファイルの作成をテストする: まったく異なる、新しく作成されたディレクトリに、まったく同じボリュームにファイルを作成しようとします。bash mkdir /mount_point/test_dir && touch /mount_point/test_dir/test_file.txtこれが成功し、元のディレクトリへの書き込みが失敗する場合は、ディレクトリの上限に達している可能性があります。
  2. ディレクトリ エントリ数を推定する: 問題のあるディレクトリ内の エントリ数をカウントします: bash find /mount_point/offending_directory -maxdepth 1 | wc -l
  3. ディレクトリ インデックス ファイルのサイズを検査する: ディレクトリのメタデータのフットプリントを確認します: bash ls -ld /mount_point/offending_directory ディレクトリ ファイルのサイズが非常に大きい場合は、 ディレクトリ メタデータが大幅に肥大化していることを示します。

ソリューション:

この問題を解決し、ディレクトリ構造を正常に保つには、次の方法を実装します。

  • ディレクトリ シャーディングを実装する: アプリケーションまたはワークロードを再構築して、ネストされた階層型サブディレクトリ（/aa/bb/filename.txt単一のフラット ディレクトリに大量のファイルを保持するのではなく）にファイルを分散します。
  • 肥大化したディレクトリを再構築する: 上限を超えるディレクトリからファイルを削除しても、名前は削除されますが、基盤となるファイル システムのディレクトリ インデックス ファイルの物理サイズは自動的に縮小されません。ディレクトリのスペースを完全に再利用するには、アクティブなファイルを新しいディレクトリにコピーまたは移動してから、古い肥大化したディレクトリを削除します。

Active Directory の統合に関する問題

次のセクションでは、Active Directory の統合に関する既知の問題について説明します。

接続に関する問題

次の制限により、オンプレミスのドメイン コントローラへの接続が失敗します。

  • VPC ピアリング: NetApp Volumes は、ストレージ プールの Virtual Private Cloud（VPC）上にあるドメイン コントローラ、または VPN で接続されているドメイン コントローラにのみ到達できます。NetApp Volumes は、ストレージ プールの VPC とピアリングされ、ストレージ プールに接続するドメイン コントローラなど、他の VPC のドメイン コントローラに到達できません。

  • ファイアウォール: NetApp Volumes がドメイン コントローラに接続できない場合、オンプレミス接続は失敗します。詳細については、 Active Directory アクセスのファイアウォール ルールをご覧ください。

Active Directory ポリシーの Active Directory サイト設定を変更しても、Flex File サービスレベルのストレージ プールには影響しません。この設定は、Flex Unified プールで機能します。

NetApp Volumes が Windows 2025 ベースのドメイン コントローラに参加できない

Windows 2025 の回帰により、NetApp Volumes は Windows 2025 ドメイン コントローラを使用してドメインに参加できません。

2025 年 9 月 9 日の時点で、Microsoft はこの問題に対処するために KB5065431 と KB5065426 をリリースしています。Windows 2025 は RC4 暗号化をサポートしていないため、Active Directory 認証の AES 暗号化を有効にする必要があります 。

詳細については、SMB 3.1.1 の適用により、Windows 2025 以前のバージョンとのドメイン コントローラ通信が失敗する可能性があるをご覧ください。

SMB 3.1.1 の適用により、Windows 2025 以前のバージョンとのドメイン コントローラ通信が失敗する可能性がある

Windows 2025 ドメイン コントローラは、Active Directory クライアントとの通信に SMB 3.1.1 を適用します。Center for Internet Security（CIS）ポリシー 18.6.7.6 では、 以前の Windows バージョンで SMB 3.1.1 を使用することも推奨しています。

NetApp Volumes は、SMB クライアントと NetApp Volumes SMB サーバー間の通信に SMB 3.1.1 をサポートしていますが、クライアントとして Active Directory に接続する場合は SMB 2.1 と SMB 3.0 のみをサポートしています。

ドメイン コントローラが SMB 3.1.1 接続のみを許可する場合、NetApp Volumes は Active Directory に接続できず、サービスが中断されます。

互換性を維持するため、ドメイン コントローラでサポートされる最小 SMB バージョンとして SMB 2.1 を設定することをおすすめします。この設定は、すべてのドメイン コントローラに適用する必要があります。サイトベースの Active Directory ポリシーを使用する場合は、Active Directory サイト内のすべてのドメイン コントローラに適用する必要があります。

次の例は、サポートされる最小 SMB バージョンを 2.1 に設定する方法を示しています。

 Set-SmbServerConfiguration -Smb2DialectMax SMB311 -Smb2DialectMin SMB210

PowerShell またはグループ ポリシーを使用して SMB 設定を変更する方法の詳細については、Windows および Windows Server 2025 で SMB ダイアレクトを管理するをご覧ください。

CMEK に関する問題

次のセクションでは、カスタマー マネージド暗号鍵（CMEK）オペレーションの既知の問題について説明します。

ListKmsConfigs が Invalid value for enum type エラーを返す

ボリュームがシステム マネージド暗号化からカスタマー マネージド暗号化に移行する際に、移行中に ListKmsConfigs コマンドが Invalid value for enum type エラーを返すことがあります。移行が完了すると、ListKmsConfigs コマンドは正常に動作するようになります。

KmsConfig ポリシーの作成が失敗する

KmsConfig ポリシーの作成が失敗し、別のポリシーを作成できなくなることがあります。この場合は、Google Cloud カスタマーケアにお問い合わせください。

ボリューム レプリケーションに関する問題と制限事項

次のセクションでは、ボリューム レプリケーション機能の既知の問題と制限事項について説明します。

アクティブなレプリケーションで宛先ボリュームの割り当て設定が失敗する可能性がある

アクティブなレプリケーションでボリュームの設定を変更すると、設定は ソース ボリュームと宛先ボリュームの両方に適用されます。 ただし、宛先ボリュームに固有の割り当ての変更はステージングされ、レプリケーションが停止すると宛先ボリュームに適用されます。この割り当て設定が失敗し、オペレーションの最後にエラー メッセージが表示されることがあります。停止オペレーションは成功しますが、すべての割り当てが宛先ボリュームに適用されていない可能性があります。 停止オペレーション中に割り当てエラーが発生した場合は、ソース ボリュームと宛先ボリュームの両方の割り当てルールを比較し、宛先ボリュームに不足している割り当てルールを更新して、ソース ボリュームの設定と一致させます。

Google Cloud コンソールに、関連付けられた Active Directory ポリシーのないストレージ プールが表示される

コンソール Google Cloud で、ソース ボリュームのボリューム レプリケーションを作成すると、宛先 ボリュームの作成に使用できるストレージ プールのリストに、Active Directory ポリシーのないストレージ プールが含まれます。 Active Directory ポリシーのないストレージ プールを選択すると、レプリケーションが失敗します。

大容量ボリュームの既知の問題

次のセクションでは、大容量ボリューム機能の既知の問題について説明します。

互換性のないプールが表示される

ストレージ プール（サービスレベル）を変更すると、 Google Cloud コンソールに 互換性のないプールが表示されることがあります。互換性のないストレージ プールに変更しようとすると、失敗してエラー メッセージが表示されます。

CMEK の移行がブロックされない

コンソール Google Cloud では CMEK の移行はブロックされず、 大容量ボリュームが存在する場合でも許可されます。大容量ボリュームが構成されているときに CMEK の移行を試みると、失敗します。

FlexCache に関する問題

このセクションでは、FlexCache 機能の既知の問題について説明します。

コンソール Google Cloud での FlexCache ボリュームの変更が失敗する可能性がある

FlexCache ボリュームは、API または Google Cloud CLI を使用してのみ変更できます。 FlexCache ボリュームは作成後に Google Cloud コンソールに表示されますが、 表示または削除できます。コンソールを使用して更新しようとすると、 Google Cloud 失敗する可能性があります。このような場合は、Google Cloud CLI を使用して変更します。

snapshot-directory が true に設定されていると、FlexCache ボリュームの作成が失敗する

FlexCache ボリュームは snapshot-directory オプションをサポートしていません。API では、このパラメータのデフォルト値は false ですが、Google Cloud CLI ではデフォルト値は true です。 そのため、Google Cloud CLI を使用して FlexCache ボリュームを作成する場合は、作成の失敗を防ぐために --snapshot-directory false を明示的に含める必要があります。