Fehlerbehebung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite werden Schritte zur Fehlerbehebung beschrieben, die bei Problemen mit Filestore hilfreich sein können.

Beeinträchtigte Leistung

  1. Prüfen Sie, ob Sie den empfohlenen Maschinentyp für die Client-VM verwenden.

  2. Wenn auf Ihrer Client-VM Linux ausgeführt wird, prüfen Sie, ob die Standardoptionen für die Bereitstellung angewendet werden.

  3. Prüfen Sie, ob sich die Client-VM in derselben Region wie die Filestore-Instanz befindet. Durch eine regionsübergreifende Bereitstellung sinkt nicht nur die Leistung, sondern es entstehen auch Netzwerkkosten.

  4. Achten Sie darauf, dass Ihre Filestore-Instanz nicht fast oder vollständig ausgelastet ist. Wenn die Kapazität fast erschöpft ist, ist der verbleibende Speicherplatz stark fragmentiert. Dies verlangsamt Lese- und Schreibvorgänge. Der freie Speicherplatz, der für dieses Szenario erforderlich ist, ist fallabhängig. Wir empfehlen, Benachrichtigungen für zu wenig Speicherplatz einzurichten.

  5. Testen Sie die Leistung Ihrer Filestore-Instanz mit dem fio-Tool.

    Wenn die Testergebnisse eine ungewöhnlich niedrige Leistung ergeben, wenden Sie sich an Ihren Kundenbetreuer. Wenn die Testergebnisse eine ähnliche oder bessere Leistung als erwartet dokumentieren, fahren Sie mit dem nächsten Abschnitt fort.

Anwendungsfälle mit Leistungseinbußen

Die folgenden Anwendungsfälle und Szenarien können zu Leistungseinbußen führen:

Arbeitslasten mit einer großen Anzahl kleiner Dateien

Filestore-Dateifreigaben nutzen die Exportoption sync für die Gewährleistung der Datensicherheit und der Compliance mit dem NFS-Protokoll. Bei den meisten Datenänderungsvorgängen wartet die Filestore-Instanz darauf, dass die Daten per Commit in den Speicher übertragen werden, bevor sie auf Anfragen von der Client-VM antwortet. Bei vielen Dateien in einem Vorgang verarbeitet der Client die entsprechenden Vorgänge synchron, sodass sich die kumulative Latenz erhöht.

Ein Beispiel für dieses Szenario ist, wenn Sie ein Archiv in der Dateifreigabe extrahieren, z. B. TAR-Dateien. TAR führt beim Extrahieren eines Archivs mit vielen Dateien viele synchrone Vorgänge aus. Infolgedessen wird die Leistung reduziert.

Wenn Sie viele kleine Dateien in eine Dateifreigabe kopieren möchten, sollten Sie die Dateierstellung mit einem Tool wie gsutil parallelisieren:

mkdir -p /mnt/nfs/many_files_rsync/
time gsutil -m -q rsync -rp many_files /mnt/nfs/many_files_rsync/

Daten zwischen Cloud Storage und Filestore kopieren

  • Das Kopieren von Daten aus Cloud Storage in eine Filestore-Instanz mit gsutil ist bekanntermaßen langsam. Ausführliche Informationen zur Verbesserung der Leistung finden Sie unter Leistung in Google Cloud-Ressourcen verbessern.

Latenz beim Bereitstellen und Trennen einer Dateifreigabe

Wenn Sie eine Dateifreigabe mit den Standardbereitstellungsoptionen bereitstellen, versucht der Bereitstellungsbefehl, die unterstützte Transportmethode der Filestore-Instanz zu ermitteln, was eine Latenz von drei Sekunden verursacht.

Der mountd-Daemon versucht zuerst, UDP zu verwenden, die von Filestore nicht unterstützt werden. Wenn beim ersten Versuch eine Zeitüberschreitung auftritt, kehrt es zu TCP zurück. Wenn Sie diesen Discovery-Prozess umgehen und die zusätzliche Latenz entfernen möchten, können Sie die Bereitstellungsoption tcp angeben. Beispiel:

sudo mount -o tcp 10.0.0.2:/vol1 /mnt/nfs

Diese Bereitstellungsoption ist besonders wichtig, wenn Sie mit autofs automatisch bereitstellen.

Filestore reagiert nicht

Filestore-Instanz reagiert nicht auf ping- oder traceroute-Anfragen

Filestore-Instanzen reagieren nicht auf ping- oder traceroute-Anfragen, da Filestore ICMP nicht zulässt.

Zum Testen der Konnektivität zu einer Filestore-Instanz können Sie showmount über den Client ausführen:

sudo showmount -e filestore-ip

Die Filestore-Instanz antwortet mit dem exportierten Dateisystem. Beispiel:

Export list for 10.139.19.98:
/vol1 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

Sie können auch prüfen, ob der Client die RPC-Informationen von Filestore erreichen kann. Führen Sie dazu folgenden Befehl aus:

sudo rpcinfo -p <filestore-ip>

Die Antwort sieht in etwa so aus:

program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100000    2   tcp    111  portmapper
 100000    4   udp    111  portmapper
 100000    3   udp    111  portmapper
 100000    2   udp    111  portmapper
 100024    1   udp   2046  status
 100024    1   tcp   2046  status
 100003    3   tcp   2049  nfs
 100227    3   tcp   2049
 100021    1   udp   4045  nlockmgr
 100021    3   udp   4045  nlockmgr
 100021    4   udp   4045  nlockmgr
 100021    1   tcp   4045  nlockmgr
 100021    3   tcp   4045  nlockmgr
 100021    4   tcp   4045  nlockmgr
 100005    3   udp   2050  mountd
 100005    3   tcp   2050  mountd

Planmäßige Wartung

Nach einer gewissen Zeit reagiert Filestore einige Minuten lang nicht mehr und reagiert dann aufgrund eines geplanten Wartungsereignisses wieder. Informationen zum SLA von Filestore finden Sie auf der SLA-Seite.

Filestore unterstützt keine vom Kunden definierten Wartungsfenster. Der Zeitplan für Wartungsfenster von Filestore ist ebenfalls nicht für Kunden einsehbar.

Instanz wurde gelöscht, während sie auf dem Client bereitgestellt wurde

Wenn ein Dateivorgang oder ein Unix-Befehl wie df, ls oder ein Lese-/Schreibvorgang nicht mehr reagiert, wurde die Filestore-Instanz wahrscheinlich gelöscht, während sie auf dem Client bereitgestellt wurde.

Prüfen Sie deshalb, ob die Instanz noch vorhanden ist:

    gcloud filestore instances list

Wenn die Instanz nicht mehr aufgeführt wird, können Sie den Vorgang wiederherstellen. Dazu erstellen Sie eine neue Instanz mit der gleichen IP-Adresse und mit dem gleichen Dateifreigabenamen wie die gelöschte Instanz. Wenn die Instanz erstellt ist, wird der nicht reagierende Vorgang mit einem Fehler beendet. Wenn Sie die Filestore-Instanz nicht benötigen, können Sie die Dateifreigabe trennen und löschen.

Damit dieser Fehler in Zukunft nicht mehr auftritt, heben Sie die Bereitstellung der Filestore-Instanz zuerst auf, bevor Sie sie löschen.

Instanz zeigt den Status REPAIRING an

Die Filestore-Instanz befindet sich in einem fehlerhaften Zustand, der interne Ursachen außerhalb der Kontrolle des Nutzers hat, und repariert sich automatisch selbst. Die Instanz ist während dieser Zeit nicht verfügbar und Sie müssen keine weiteren Maßnahmen ergreifen.

Probleme mit der Kapazität

"Kein Speicherplatz mehr auf dem Gerät"

Prüfen Sie mit dem folgenden Befehl auf der Client-VM, ob die Filestore-Instanz ausreichend Inodes hat:

df -i

Der Befehl gibt in etwa Folgendes zurück:

Filesystem           Inodes        IUsed      IFree         IUse%  Mounted on
10.0.0.2:/vol1    134217728        13         134217715     1%     /mnt/test

Jede auf der Dateifreigabe gespeicherte Datei verbraucht einen Inode. Wenn IUse% 100 % erreicht, können Sie keine weiteren Dateien in der Dateifreigabe speichern, auch wenn Sie die maximale zugewiesene Kapazität nicht erreicht haben. Die Anzahl der Inodes wird mit der Kapazität skaliert. Wenn Sie weitere Inodes hinzufügen möchten, müssen Sie die Kapazität erhöhen.

Instanzen der Enterprise- und High-Scale-SSD-Stufe haben eine maximale Kapazitätsauslastung von etwa 89% der bereitgestellten Kapazität. Die verbleibende Kapazität ist für interne Vorgänge und Ressourcen reserviert. Weitere Informationen finden Sie unter Bekannte Probleme.

Die Befehle 'df' und 'du' melden unterschiedliche Mengen an freiem Speicherplatz

Wenn eine Datei gelöscht wird, die durch einen laufenden Prozess geöffnet ist, wird der von der Datei belegte Speicherplatz erst freigegeben, wenn die Datei geschlossen wurde. Der Befehl df berücksichtigt den Speicherplatz, der von gelöschten offenen Dateien belegt wird, der Befehl du jedoch nicht. Dieser Unterschied in der Berechnung ist der Grund dafür, dass der Befehl du oft mehr freien Speicherplatz als df anzeigt.

Führen Sie folgenden Befehl aus, um die gelöschten Dateien anzeigen zu lassen, die noch von einem laufenden Prozess geöffnet sind:

lsof | grep deleted

Instanz konnte nicht erstellt werden

Fehler PERMISSION DENIED beim Erstellen einer Filestore-Instanz

  1. Prüfen Sie, ob die Filestore API aktiviert ist:

    gcloud services enable file.googleapis.com

  2. Jeder Filestore-Instanz muss ein IP-Adressbereich zugeordnet sein, der sich nicht mit einem anderen verwendeten Bereich überschneidet. Eine ausführliche Liste der Einschränkungen finden Sie unter Einen reservierten IP-Adressbereich konfigurieren.

  3. Prüfen Sie, ob Sie die Rolle roles/file.editor haben. Weitere Informationen finden Sie unter IAM-Rollen und -Berechtigungen.

  4. Wenn der Fehler weiterhin auftritt, wurde möglicherweise die Rolle file.serviceAgent vom Filestore-Dienstkonto entfernt. Führen Sie folgenden Befehl aus, um zu prüfen, ob dies der Fall ist:

    gcloud projects get-iam-policy project-id-or-number  \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:service-project-number@cloud-filer.iam.gserviceaccount.com"

    wobei

    • project-id-or-number ist die ID oder Nummer Ihres Google Cloud-Projekts.
    • project-number die Nummer Ihres Google Cloud-Projekts.

    Die Ausgabe sollte in etwa so aussehen:

    ROLE
roles/file.serviceAgent

    Wenn roles/file.serviceAgent nicht aufgeführt ist, können Sie die Rolle durch folgende Eingabe wiederherstellen:

    gcloud projects add-iam-policy-binding project-id-or-number  \
    --member serviceAccount:service-project-number@cloud-filer.iam.gserviceaccount.com  \
    --role roles/file.serviceAgent

System limit for internal resources has been reached-Fehler beim Erstellen einer Instanz

Dieser Fehler wird ausgelöst, wenn Filestore ein internes Netzwerkkontingent erreicht hat. Für jedes VPC-Netzwerk, für das Sie eine Filestore-Instanz erstellen, muss Filestore ein internes Netzwerk anlegen, das per Peering mit diesem VPC-Netzwerk verbunden ist. Diese internen Netzwerke bleiben erhalten, auch wenn die zugehörigen Filestore-Instanzen und VPC-Netzwerke gelöscht werden.

Wenn die Anzahl der internen Netzwerke für ein Projekt 49 erreicht, können keine neuen internen Netzwerke mehr erstellt werden. Dadurch wird verhindert, dass Sie in neuen VPC-Netzwerken Filestore-Instanzen erstellen können. Wenn Sie es dennoch versuchen, wird einer der folgenden Fehler angezeigt:

System limit for internal resources has been reached. Please request to adjust limit here: https://forms.gle/PFPJ2QD4KnCHzYEx9

Um interne Netzwerke zu löschen, deaktivieren Sie die Filestore API und aktivieren sie dann wieder:

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

Wenn Sie die API nicht deaktivieren können, weil Sie Filestore-Instanzen haben, die Sie nicht löschen können, oder weil Sie ein Kontingent, das Ihnen wegen Anfragen zur Kontingenterhöhungen gewährt wurde, nicht verlieren möchten, können Sie folgendes Formular ausfüllen, um die Netzwerklimits anzupassen:

https://forms.gle/PFPJ2QD4KnCHzYEx9

Wenn Sie VPC-Netzwerke und Filestore-Instanzen regelmäßig löschen und erstellen müssen, gibt es zwei Möglichkeiten, das Überschreiten Ihres Netzwerkkontingents zu vermeiden:

  • Sie verwenden beim Erstellen eines VPC-Netzwerks den gleichen Namen wie für ein vorheriges Netzwerk, das für die Erstellung der Filestore-Instanz genutzt wurde.

  • Sie nutzen im Turnus die VPC-Netzwerke in einem Pool von maximal 49 VPC-Netzwerken, anstatt sie zu löschen und neu zu erstellen.

Dateifreigabe kann nicht bereitgestellt werden

Meine VM oder mein GKE-Pod kann nicht auf Filestore zugreifen

Prüfen Sie mit dem folgenden Befehl, ob die Filestore-Instanz erreichbar ist (ping und traceroute werden nicht unterstützt):

sudo showmount -e <filestore-ip>

Der Befehl sollte mit einer Liste exportierter Dateisysteme antworten. Prüfen Sie dann mit dem folgenden Befehl, ob der Client die RPC-Informationen von Filestore erreichen kann:

sudo rpcinfo -p <filestore-ip>

Wenn die Filestore-Instanz nicht erreichbar ist, sind häufig Ursachen falsch konfigurierte Netzwerk- oder ACL-Einstellungen oder Sie versuchen, die falsche Instanz bereitzustellen.

  1. Prüfen Sie, ob die IP-basierte Zugriffssteuerung aktiviert ist und ob die IP-Adresse des Clients eingeschränkt ist. Weitere Informationen
  2. Prüfen Sie in den Firewalleinstellungen, ob die erforderlichen Ports geöffnet sind. Weitere Informationen finden Sie unter Firewallregeln konfigurieren.
  3. Wenn Sie versuchen, von einem GKE-Cluster auf Filestore zuzugreifen, und dabei der Fehler mount.nfs: access denied by server while mounting ... angezeigt wird, finden Sie entsprechende Informationen unter Zugriff auf Dateifreigabe von GKE-Clustern nicht möglich.

Berechtigung beim Bereitstellen einer Dateifreigabe wurde verweigert

Prüfen Sie, ob für die Instanz NFS-Exportoptionen aufgeführt sind:

gcloud filestore instances describe instance-id \
    --zone=zone

wobei

  • instance-id ist die Instanz-ID der Filestore-Instanz.
  • zone ist die Zone, in der sich die Filestore-Instanz befindet.

Der Befehl gibt in etwa Folgendes zurück:

createTime: '2019-10-11T17:28:23.340943077Z'
fileShares:
- capacityGb: '1024'
  name: vol1
  nfsExportOptions:
  - accessMode: READ_WRITE
    ipRanges:
    - 128.0.0.0/29
    squashMode: NO_ROOT_SQUASH
name: projects/yourproject/locations/us-central1-c/instances/nfs-server
networks:
- ipAddresses:
  - 10.0.0.2
  modes:
  - MODE_IPV4
  network: default
  reservedIpRange: 10.0.0.0/29
state: READY
tier: BASIC_HDD

Wenn nfsExportOptions aufgeführt ist, prüfen Sie, ob die IP-Adresse Ihres Clients innerhalb einem der unter ipRanges aufgeführten Bereiche für den erwarteten accessMode liegt. Ist dies nicht der Fall, müssen Sie die NFS-Exportoptionen bearbeiten.

Eine Dateifreigabe kann nicht in App Engine bereitgestellt werden

Filestore unterstützt App Engine nicht.

Dateifreigabe kann nicht über einen GKE-Cluster bereitgestellt werden

Sie können Filestore-Dateifreigaben nicht direkt in GKE-Clustern bereitstellen. Stattdessen müssen Sie ein PV und einen PVC konfigurieren.

Zugriff auf Dateifreigabe von GKE-Clustern nicht möglich

Weitere Informationen zur Fehlerbehebung in Bezug auf Kubernetes oder Google Kubernetes Engine finden Sie im offiziellen Leitfaden zur Fehlerbehebung für Kubernetes und in der Anleitung zur Fehlerbehebung in GKE.

Fehler: Output: mount.nfs: access denied by server while mounting x.x.x.x:/file-share-name

Achten Sie darauf, dass die Werte spec.nfs.path und spec.nfs.server des PV mit dem Namen der Dateifreigabe bzw. der IP-Adresse der Filestore-Instanz übereinstimmen.

Example:

Wenn Ihre Dateifreigabe den Namen vol1 und die IP-Adresse der Filestore-Instanz 10.0.0.2 ist, müssen spec.nfs.path und spec.nfs.server des PV diesen Werten entsprechen:

apiVersion: v1
kind: PersistentVolume
metadata:
 name: fileserver
spec:
 capacity:
   storage: 2T
 accessModes:
 - ReadWriteMany
 nfs:
   path: /vol1
   server: 10.0.0.2

Filestore API kann nicht deaktiviert werden

Achten Sie darauf, dass alle Ihre Filestore-bezogenen Ressourcen, wie Filestore-Instanzen und Sicherungen, gelöscht werden. Sie können die Filestore API nicht deaktivieren, während Filestore-Instanzen bereitgestellt werden.

Fehler: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

Wenn Sie für eine bestimmte private Verbindung den zugewiesenen IP-Adressbereich aufgebraucht haben, gibt Google Cloud diesen Fehler zurück: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

Weitere Informationen zur Behebung dieses Problems finden Sie unter IP-Adressbereich erschöpft.