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 mit NetApp-Volumes beschrieben.

Not found-Fehler beim Ausführen von Sicherungsvorgängen nach dem Erstellen des Volumes

Problem: Wenn Sie Sicherungsvorgänge wie CreateBackup, RestoreVolume oder UpdateBackupConfig unmittelbar nach dem Erstellen eines ONTAP-Modus-Volumes ausführen, können die Vorgänge mit dem Fehler Not found 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 dieses Zeitraums für die Weitergabe kann es sein, dass der Sicherungsdienst Sicherungsanfragen weiterleitet, bevor das Volume erkannt wird. Dies führt zu einem Not found-Fehler.

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

Flex File-Volumes reagieren nicht auf Ping

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

Zeitweiser Verbindungsverlust bei Verwendung sich überschneidender Verbindungen für den Zugriff auf private Dienste

Wenn Sie die netapp.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 einem zeitweiligen Verlust der Verbindung für die Einbindung von Volumes 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: Der Clientzugriff auf Volumes wird unterbrochen, wenn Sie Einstellungen für das Quell- oder Zielvolume einer aktiven Volumereplikation mit einem gespiegelten Übertragungsstatus aktualisieren.

Grund: Wenn ein Volume aktualisiert wird, kann die Exportrichtlinie mit dem Replikationspartner-Volume synchronisiert werden. Wenn das aktualisierte Volume eine falsche oder fehlende Exportrichtlinie hat, kann der Zugriff auf die Clients, die auf das Produktionsquellen-Volume gemountet sind, verloren gehen, was möglicherweise zu einem Ausfall führt.

Hintergrund: Wenn sich eine Replikation in einem gespiegelten Zustand befindet, werden die Exportrichtlinien der Quell- und Zielvolumes automatisch von NetApp Volumes synchronisiert. So wird ein einheitlicher Clientzugriff ohne manuellen Eingriff des Administrators gewährleistet, da jede Richtlinienänderung auf einem Volume automatisch auf das andere Volume angewendet wird.

In CVS muss der Administrator die Einstellungen für Quell- und Zielvolumen manuell synchronisieren. Bei der Umstellung von Volumes von CVS auf NetApp Volumes wurden die vorhandenen Exportrichtlinien ohne Änderungen übertragen. Dies kann zu inkonsistenten Exportrichtlinien in replizierten Volumes führen. Wenn Sie die Exportrichtlinie 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 Volumereplikation befinden. Das Problem kann auftreten, wenn die Replikation nach dem Anhalten fortgesetzt wird.

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

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

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

  1. Sehen Sie sich die Exportrichtlinien sowohl des Quell- als auch des Zielvolumens an und vergleichen Sie sie.

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

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

  2. Wenden Sie die zusammengeführte Exportrichtlinie auf das Quellvolume an. Diese Richtlinie wird auch automatisch auf das Zielvolumen angewendet.

Durch die Synchronisierung der Exportrichtlinien können Sie für konsistenten Zugriff sorgen und potenzielle Unterbrechungen für Clients verhindern.

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

Möglicherweise erhalten Sie eine Fehlermeldung, wenn Sie CVS- und NetApp Volumes-Ressourcen zusammen in einer VPC, einem Projekt oder einer Region verwenden. 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.

Im Folgenden finden Sie die häufigsten Fehlermeldungen:

  • 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 zur Behebung dieses Problems an den Google Cloud Customer Care und fordern Sie an, dass Ihre Projekte oder Regionen zurückgesetzt werden, damit ausschließlich NetApp Volumes-Ressourcen verwendet werden.

Das Erstellen von Dateien schlägt mit No space left on device- oder File too large-Fehlern in einem bestimmten Verzeichnis fehl

Problem: Beim Versuch, neue Dateien oder Unterverzeichnisse auf einem bereitgestellten 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 Anfragen zum Festplattenspeicher (z. B. df -h) und dieGoogle Cloud -Konsole 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 zu groß wird und interne Limits erreicht. Dadurch kann das Speichersystem keine weiteren Dateien oder Unterverzeichnisse an diesem Speicherort indexieren.

Überprüfung:

Prüfen Sie mit den folgenden Diagnoseschritten auf einem bereitgestellten Client, ob Sie die Grenzwerte für die Verzeichnisgröße erreicht haben:

  1. Erstellung lokalisierter Dateien 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 jedoch fehlschlägt, wurde wahrscheinlich das Verzeichnislimit erreicht.
  2. Anzahl der Verzeichniseinträge schätzen: Zählen Sie die Anzahl der Einträge im betreffenden 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 Dateigröße des Verzeichnisses deutet auf eine massive Aufblähung der Verzeichnismetadaten hin.

Lösung:

So beheben Sie das Problem und sorgen für eine intakte Verzeichnisstruktur:

  • Verzeichnis-Sharding implementieren: 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.
  • Überdimensionierte Verzeichnisse neu erstellen: Wenn Sie Dateien aus einem Verzeichnis löschen, das das Limit überschreitet, werden nur die Namen der Dateien entfernt. Die physische Größe der Indexdatei des Verzeichnisses im zugrunde liegenden Dateisystem wird dadurch nicht automatisch verringert. Wenn Sie den Speicherplatz des Verzeichnisses vollständig zurückgewinnen möchten, kopieren oder verschieben Sie die aktiven Dateien in ein neues Verzeichnis und löschen Sie dann das alte, überfüllte Verzeichnis.

Probleme mit 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 können nur auf Domaincontroller zugreifen, die sich in der VPC (Virtual Private Cloud) des Speicherpools befinden oder über ein VPN mit ihr verbunden sind. NetApp-Volumes können 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 nicht zulassen, dass NetApp Volumes Ihre Domaincontroller kontaktiert. 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“.

NetApp-Volumes können nicht mit Windows 2025-basierten Domaincontrollern verbunden werden

Aufgrund einer Regression in Windows 2025 können NetApp Volumes nicht mit einem Windows 2025-Domaincontroller in eine Domain eingebunden werden. Wenn Sie der Domain beitreten möchten, müssen Sie einen Domaincontroller mit einer Windows-Version vor 2025 verwenden, z. B. Windows 2022. Sie können keinen funktionierenden Domaincontroller direkt angeben, da der Dienst DNS-basierte Erkennung verwendet, um Domaincontroller zu finden. Wir empfehlen, nutzbare Domaincontroller vor Windows 2025 in einer dedizierten Active Directory-Website hinzuzufügen und diese Website in der Active Directory-Richtlinie für NetApp Volumes anzugeben.

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

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 ein Volume von der vom System verwalteten zur vom Kunden verwalteten Verschlüsselung migriert wird, gibt der Befehl ListKmsConfigs während der Migration gelegentlich den Fehler Invalid value for enum type zurück. Nach Abschluss der Migration funktioniert der Befehl ListKmsConfigs wieder normal.

KmsConfig Richtlinie kann nicht erstellt werden

Gelegentlich schlägt die Erstellung von KmsConfig-Richtlinien 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 Funktion zur Volumereplikation.

Kontingenteinstellungen für Zielvolumes können bei einer aktiven Replikation fehlschlagen

Wenn Sie die Einstellungen eines Volumes in einer aktiven Replikation ändern, werden die Einstellungen sowohl auf das Quell- als auch auf das Ziel-Volume angewendet. Kontingentänderungen speziell für Ziel-Volumes werden jedoch bereitgestellt und auf das Ziel-Volume angewendet, sobald die Replikation beendet ist. Gelegentlich kann diese Kontingenteinstellung fehlschlagen und Sie erhalten am Ende des Vorgangs eine Fehlermeldung. Der Vorgang Stop wird zwar erfolgreich ausgeführt, aber möglicherweise wurden nicht alle Kontingente auf das Zielvolumen angewendet. Wenn Sie während eines Stop-Vorgangs einen Kontingentfehler erhalten, vergleichen Sie die Kontingentregeln für das Quell- und das Zielvolume und aktualisieren Sie dann alle fehlenden Kontingentregeln für das Zielvolume, damit sie den Einstellungen des Quellvolumes entsprechen.

In derGoogle Cloud -Konsole werden Speicherpools ohne zugeordnete Active Directory-Richtlinien angezeigt.

Wenn Sie in der Google Cloud -Konsole eine Volume-Replikation für ein Quellvolume erstellen, enthält die Liste der Speicherpools, aus denen Sie das Zielvolume 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 mit Volumen mit großen Kapazitäten

Im folgenden Abschnitt werden bekannte Probleme mit der Funktion „Volumes mit großer Kapazität“ beschrieben.

Inkompatible Pools werden angezeigt

Beim Ändern des Speicherpools (Service-Level) werden in der Google Cloud Konsole möglicherweise inkompatible Pools angezeigt. Wenn Sie versuchen, zu einem inkompatiblen Speicherpool zu wechseln, schlägt der Versuch fehl und Sie erhalten eine Fehlermeldung.

CMEK-Migration nicht blockiert

Die CMEK-Migration wird nicht durch die Google Cloud -Konsole blockiert und ist auch bei Volumes mit großer Kapazität zulässig. Wenn Sie versuchen, CMEK-Migrationen durchzuführen, während Volumes mit hoher Kapazität konfiguriert sind, schlägt der Versuch fehl.

FlexCache-Probleme

In diesem Abschnitt werden bekannte Probleme des FlexCache-Features 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 -Konsole angezeigt, können aber nicht aufgerufen oder gelöscht werden. Versuche, sie über dieGoogle Cloud -Konsole zu aktualisieren, schlagen möglicherweise fehl. In solchen Fällen sollten Sie die Google Cloud CLI für Änderungen verwenden.

Erstellen von FlexCache-Volumes schlägt fehl, wenn snapshot-directory auf „true“ gesetzt ist

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