Bekannte Probleme und Beschränkungen

Auf dieser Seite werden bekannte Einschränkungen von Google Cloud NetApp Volumes beschrieben.

Allgemeine Probleme

In diesem Abschnitt werden häufige bekannte Probleme von NetApp Volumes beschrieben.

Not found-Fehler beim Ausführen von Sicherungsvorgängen nach der Volume-Erstellung

Problem: Wenn Sie unmittelbar nach dem Erstellen eines Volumes im ONTAP-Modus Sicherungsvorgänge wie CreateBackup, RestoreVolume, oder UpdateBackupConfig ausführen, können die Vorgänge mit einem Not found-Fehler fehlschlagen.

Grund: Nachdem Sie ein Volume erstellt haben, kann es einige Zeit dauern, bis das Volume und die zugehörigen Sicherungsressourcen vollständig für den Sicherungsdienst verfügbar sind. Während dieser Weitergabezeit kann der Sicherungsdienst Sicherungsanfragen weiterleiten, bevor das Volume gefunden werden kann, was zu einem Not found-Fehler führt.

Lösung: Warten Sie nach dem Erstellen des Volumes mindestens drei Minuten, bevor Sie Sicherungsvorgänge ausführen.

Flex File-Volumes reagieren nicht auf Pings

Weitere Informationen zu diesem Problem finden Sie unter Konnektivität zu NetApp Volumes testen.

Zeitweise Verbindungsverluste bei Verwendung überlappender Verbindungen für den Zugriff auf private Dienste

Wenn Sie dienetapp.servicenetworking.goog Verbindung konfigurieren, und der CIDR-Bereich sich mit dem CIDR-Bereich einer anderen Verbindung für den Zugriff auf private Dienste in derselben VPC überschneidet, kann dies zu zeitweisen Verbindungsverlusten der Volume-Mount-Verbindung führen. Verwenden Sie nicht überlappende Bereiche, um dieses Problem zu vermeiden.

Mögliche Unterbrechung des Clientzugriffs auf Volumes, die vom Cloud Volumes-Dienst zu NetApp Volumes migriert wurden, beim Aktualisieren der Einstellungen eines NFS-Volumes

Problem: Es kommt zu einer Unterbrechung des Clientzugriffs auf Volumes, wenn Sie Einstellungen für das Quell- oder Ziel-Volume einer aktiven Volume- Replikation mit einem gespiegelten Übertragungsstatus aktualisieren.

Grund: Durch das Aktualisieren eines Volumes kann die Exportsrichtlinie mit dem Volume des Replikationspartners synchronisiert werden. Wenn das aktualisierte Volume eine falsche oder fehlende Exportsrichtlinie hat, können die Clients, die mit dem Produktionsquell-Volume verbunden sind, den Zugriff verlieren, was möglicherweise zu einem Ausfall führt.

Hintergrund: Wenn sich eine Replikation in einem gespiegelten Zustand befindet, synchronisiert NetApp Volumes automatisch die Exportsrichtlinien der Quell- und Ziel-Volumes. So wird ein konsistenter Clientzugriff ohne manuellen Eingriff des Administrators gewährleistet, da alle Richtlinienänderungen an einem Volume automatisch auf das andere Volume angewendet werden.

In CVS muss der Administrator die Einstellungen für Quell- und Ziel-Volume manuell synchronisieren. Bei der Volume-Migration von CVS zu NetApp Volumes wurden die vorhandenen Exportsrichtlinien ohne Änderungen übertragen, was zu inkonsistenten Exportsrichtlinien in replizierten Volumes führen kann. Wenn Sie die Exportsrichtlinie des Quell- oder Ziel-Volumes in einer Volume-Replikationsbeziehung aktualisieren, werden die Richtlinien auf beiden Volumes automatisch synchronisiert.

Betroffene Volumes

Dieses Problem betrifft Volumes, die alle folgenden Kriterien erfüllen:

  • Volumes, die sich in einer aktiven, gespiegelten Volume-Replikation befinden. Das Problem kann auftreten, wenn Sie die Replikation nach dem Anhalten fortsetzen.

  • Alle NFS-fähigen Volumes mit einer Exportsrichtlinie.

  • Volumes, bei denen sich die Exportsrichtlinie zwischen Quelle und Ziel unterscheidet.

Lösung: Um dieses Problem zu beheben, muss die Exportsrichtlinie von Quell- und Ziel- Volumes einmal synchronisiert werden. Gehen Sie folgendermaßen vor:

  1. Prüfen und vergleichen Sie die Exportsrichtlinien des Quell- und Ziel-Volumes.

    • Wenn die Exportsrichtlinien identisch sind, sind keine Maßnahmen erforderlich.

    • Wenn sich die Exportsrichtlinien unterscheiden, führen Sie die Exportregeln zusammen, um eine Exportsrichtlinie zu erstellen, die alle in beiden Richtlinien angegebenen Hosts zulässt.

  2. Wenden Sie die zusammengeführte Exportsrichtlinie auf das Quell-Volume an. Diese Richtlinie wird auch automatisch auf das Ziel-Volume angewendet.

Durch das Synchronisieren der Exportsrichtlinien können Sie einen konsistenten Zugriff gewährleisten und potenzielle Unterbrechungen für Clients vermeiden.

Fehlermeldung bei der gemeinsamen Verwendung von Cloud Volumes-Dienst- (CVS) und NetApp Volumes-Ressourcen

Möglicherweise wird eine Fehlermeldung angezeigt, dass Sie CVS- und NetApp Volumes-Ressourcen nicht zusammen in einer VPC, einem Projekt oder einer Region verwenden können. Dieses Problem kann auftreten, wenn Sie versuchen, Ressourcen wie Pools und Richtlinien zu erstellen, wenn eine der folgenden Bedingungen für das Projekt zutrifft:

  • Das Projekt wurde zuvor für CVS verwendet.

  • In einem Projekt ohne NetApp Volumes-Ressourcen wurde ein CVS-Ressourcenlisten-Vorgang ausgeführt.

Die folgenden Fehlermeldungen sind häufig:

  • 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.

Wenden Sie sich an den Google Cloud Customer Care, um dieses Problem zu beheben, und fordern Sie eine Zurücksetzung Ihrer spezifischen Projekte oder Regionen an, damit ausschließlich NetApp Volumes-Ressourcen verwendet werden.

Fehler beim Erstellen von Dateien mit den Fehlern No space left on device oder File too large in einem bestimmten Verzeichnis

Problem: Wenn Sie versuchen, neue Dateien oder Unterverzeichnisse auf ein eingebundenes Volume zu schreiben, zu kopieren oder zu erstellen, schlägt der Vorgang mit dem Fehler No space left on device (errno 28 / ENOSPC) oder File too large (errno 27 / EFBIG) fehl.

Dies tritt auch dann auf, wenn clientseitige Speicherplatzabfragen (z. B. df -h) und die Google Cloud Console zeigen, dass das Volume über ausreichend verfügbare logische Kapazität verfügt. Der Fehler ist auf ein bestimmtes Verzeichnis beschränkt. Das Erstellen von Dateien in anderen Verzeichnissen auf demselben Volume ist erfolgreich.

Grund: Dieses Problem tritt auf, wenn ein einzelnes Verzeichnis übermäßig groß wird und interne Limits erreicht, wodurch das Speichersystem keine weiteren Dateien oder Unterverzeichnisse an diesem bestimmten Speicherort indexieren kann.

Überprüfung:

Prüfen Sie, ob Sie die Limits für die Verzeichnisgröße erreicht haben. Führen Sie dazu die folgenden Diagnoseschritte auf einem eingebundenen Client aus:

  1. Lokale Dateierstellung testen: Versuchen Sie, eine Datei in einem völlig anderen, neu erstellten Verzeichnis auf demselben Volume zu erstellen: bash mkdir /mount_point/test_dir && touch /mount_point/test_dir/test_file.txt Wenn dies gelingt, das Schreiben in das ursprüngliche Verzeichnis aber fehlschlägt, wurde wahrscheinlich das Verzeichnislimit erreicht.
  2. Anzahl der Verzeichniseinträge schätzen: Zählen Sie die Anzahl der Einträge im fehlerhaften Verzeichnis: bash find /mount_point/offending_directory -maxdepth 1 | wc -l
  3. Dateigröße des Verzeichnisindex prüfen: Prüfen Sie die Metadaten des Verzeichnisses: bash ls -ld /mount_point/offending_directory Eine außergewöhnlich große Verzeichnisdateigröße deutet auf eine massive Vergrößerung der Verzeichnismetadaten hin.

Lösung:

Um dieses Problem zu beheben und Ihre Verzeichnisstrukturen in gutem Zustand zu halten, implementieren Sie die folgenden Methoden:

  • Verzeichnisse aufteilen: Strukturieren Sie Ihre Anwendung oder Arbeitslast neu, um Dateien auf verschachtelte, hierarchische Unterverzeichnisse zu verteilen (z. B. /aa/bb/filename.txt anstatt eine große Anzahl von Dateien in einem einzelnen flachen Verzeichnis zu speichern).
  • Übermäßig große Verzeichnisse neu erstellen: Wenn Sie einfach Dateien aus einem Verzeichnis löschen, das das Limit überschreitet, werden zwar die Namen der Dateien entfernt, die physische Größe der Verzeichnisindexdatei im zugrunde liegenden Dateisystem wird dadurch aber nicht automatisch verringert. Um den Speicherplatz des Verzeichnisses vollständig freizugeben, kopieren oder verschieben Sie die aktiven Dateien in ein neues Verzeichnis und löschen Sie dann das alte, übermäßig große Verzeichnis.

Probleme bei der Active Directory-Integration

In den folgenden Abschnitten werden bekannte Probleme bei der Active Directory-Integration beschrieben.

Verbindungsprobleme

Verbindungen zu lokalen Domaincontrollern schlagen aufgrund der folgenden Einschränkungen fehl:

  • VPC-Peering: NetApp Volumes kann nur Domaincontroller erreichen, die sich in der Virtual Private Cloud (VPC) des Speicherpools befinden oder über ein VPN damit verbunden sind. NetApp Volumes kann keine Domaincontroller in anderen VPCs erreichen, auch nicht in solchen, die mit der VPC des Speicherpools verbunden sind und eine Verbindung zum Speicherpool herstellen.

  • Firewalls: Die lokale Verbindung schlägt fehl, wenn Sie NetApp Volumes nicht erlauben, Ihre Domaincontroller zu kontaktieren. Weitere Informationen finden Sie unter Firewallregeln für den Active Directory-Zugriff .

Das Ändern der Active Directory-Standorteinstellung einer Active Directory-Richtlinie hat keine Auswirkungen auf Speicherpools mit dem Service-Level „Flex File“. Diese Einstellung funktioniert für Flex Unified-Pools.

NetApp Volumes kann keine Verbindung zu Domaincontrollern auf Basis von Windows 2025 herstellen

Aufgrund einer Regression in Windows 2025 kann NetApp Volumes keine Verbindung zu einer Domain herstellen, die einen Windows 2025-Domaincontroller verwendet.

Am 9. September 2025 hat Microsoft KB5065431 und KB5065426 veröffentlicht, um dieses Problem zu beheben. Windows 2025 unterstützt keine RC4-Verschlüsselung. Sie müssen daher die AES-Verschlüsselung für die Active Directory-Authentifizierung aktivieren.

Weitere Informationen finden Sie unter Die Kommunikation des Domaincontrollers mit Windows 2025 oder früheren Versionen kann aufgrund der Erzwingung von SMB 3.1.1 fehlschlagen.

Die Kommunikation des Domaincontrollers mit Windows 2025 oder früheren Versionen kann aufgrund der Erzwingung von SMB 3.1.1 fehlschlagen

Windows 2025-Domaincontroller erzwingen SMB 3.1.1 für die Kommunikation mit Active Directory-Clients. Die Richtlinie 18.6.7.6 des Center for Internet Security (CIS) empfiehlt außerdem die Verwendung von SMB 3.1.1 für frühere Windows-Versionen.

NetApp Volumes unterstützt zwar SMB 3.1.1 für die Kommunikation zwischen SMB-Clients und dem NetApp Volumes-SMB-Server, aber nur SMB 2.1 und SMB 3.0, wenn eine Verbindung zu Active Directory als Client hergestellt wird.

Wenn Domaincontroller nur SMB 3.1.1-Verbindungen zulassen, kann NetApp Volumes keine Verbindung zu Active Directory herstellen, was zu Dienstunterbrechungen führt.

Um die Kompatibilität aufrechtzuerhalten, empfehlen wir, SMB 2.1 als mindestens unterstützte SMB-Version auf Ihren Domaincontrollern festzulegen. Sie müssen diese Einstellung auf alle Domaincontroller oder auf jeden Domaincontroller in der Active Directory-Site anwenden, wenn Sie standortbasierte Active Directory-Richtlinien verwenden.

Im folgenden Beispiel wird gezeigt, wie Sie SMB 2.1 als mindestens unterstützte SMB-Version festlegen:

 Set-SmbServerConfiguration -Smb2DialectMax SMB311 -Smb2DialectMin SMB210

Weitere Informationen zum Ändern der SMB-Einstellungen mit PowerShell oder Gruppen richtlinien finden Sie unter SMB-Dialekte in Windows und Windows Server 2025 verwalten.

CMEK-Probleme

In den folgenden Abschnitten werden bekannte Probleme bei Vorgängen mit kundenverwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) beschrieben.

ListKmsConfigs gibt den Fehler Invalid value for enum type zurück

Während der Migration eines Volumes von der vom System verwalteten zur kundenverwalteten Verschlüsselung gibt der Befehl ListKmsConfigs gelegentlich den Fehler Invalid value for enum type zurück. Nach Abschluss der Migration funktioniert der Befehl ListKmsConfigs wieder normal.

Fehler beim Erstellen der KmsConfig-Richtlinie

Gelegentlich schlägt die Erstellung der KmsConfig-Richtlinie fehl und Sie können keine weitere Richtlinie erstellen. Wenden Sie sich in diesem Fall an den Google Cloud Customer Care.

Probleme und Einschränkungen bei der Volume-Replikation

In den folgenden Abschnitten finden Sie Details zu bekannten Problemen und Einschränkungen der Volume-Replikationsfunktion.

Quotaeinstellungen für das Ziel-Volume schlagen möglicherweise in einer aktiven Replikation fehl

Wenn Sie Einstellungen für ein Volume in einer aktiven Replikation ändern, werden die Einstellungen sowohl auf das Quell- als auch auf das Ziel-Volume angewendet. Quotaänderungen speziell für Ziel-Volumes werden jedoch bereitgestellt und auf das Ziel-Volume angewendet, sobald die Replikation beendet wird. Gelegentlich schlägt diese Kontingenteinstellung möglicherweise fehl und Sie erhalten am Ende des Vorgangs eine Fehlermeldung. Obwohl der Vorgang Stop erfolgreich ist, wurden möglicherweise nicht alle Quotas auf das Ziel-Volume angewendet. Wenn Sie während eines Stop -Vorgangs einen Kontingentfehler erhalten, vergleichen Sie die Kontingentregeln auf dem Quell- und Ziel-Volume und aktualisieren Sie dann alle fehlenden Kontingentregeln auf dem Ziel-Volume, damit sie mit den Einstellungen des Quell-Volumes übereinstimmen.

Google Cloud In der Console werden Speicherpools ohne zugehörige Active Directory-Richtlinien angezeigt

Wenn Sie in der Google Cloud Console eine Volume-Replikation für ein Quell Volume erstellen, enthält die Liste der Speicherpools, aus denen Sie das Ziel Volume erstellen können, Speicherpools ohne Active Directory-Richtlinie. Wenn Sie einen Speicherpool ohne Active Directory-Richtlinie auswählen, schlägt die Replikation fehl.

Bekannte Probleme bei Volumes mit großer Kapazität

In diesem Abschnitt werden bekannte Probleme der Funktion für Volumes mit großer Kapazität beschrieben.

Nicht kompatible Pools werden angezeigt

Wenn Sie den Speicherpool (Service-Level) ändern, werden in der Google Cloud Console möglicherweise nicht kompatible Pools angezeigt. Wenn Sie versuchen, zu einem nicht kompatiblen Speicherpool zu wechseln, schlägt der Versuch fehl und Sie erhalten eine Fehlermeldung.

CMEK-Migration nicht blockiert

Die CMEK-Migration wird von der Google Cloud Console nicht blockiert und ist auch dann zulässig, wenn Volumes mit großer Kapazität vorhanden sind. Wenn Sie die CMEK-Migration versuchen, wenn Volumes mit großer Kapazität konfiguriert sind, schlägt der Versuch fehl.

FlexCache-Probleme

In diesem Abschnitt werden bekannte Probleme der FlexCache-Funktion beschrieben.

Änderungen an FlexCache-Volumes in der Google Cloud Console schlagen möglicherweise fehl

FlexCache-Volumes können nur über die API oder die Google Cloud CLI geändert werden. FlexCache-Volumes werden nach der Erstellung in der Google Cloud Console angezeigt. Sie können angezeigt oder gelöscht werden. Versuche, sie über die Google Cloud Console zu aktualisieren, schlagen möglicherweise fehl. Verwenden Sie in solchen Fällen die Google Cloud CLI für Änderungen.

Fehler beim Erstellen von FlexCache-Volumes, wenn snapshot-directory auf „true“ gesetzt ist

FlexCache-Volumes unterstützen die Option snapshot-directory nicht. In der API ist dieser Parameter standardmäßig auf false gesetzt, in der Google Cloud CLI auf true. Wenn Sie also ein FlexCache-Volume mit der Google Cloud CLI erstellen, müssen Sie explizit --snapshot-directory false angeben, um zu verhindern, dass die Erstellung fehlschlägt.