Fehlerbehebung

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 die volle Kapazität erreicht oder fast erreicht. Wenn die Kapazität fast voll ist, ist der verbleibende Speicherplatz stark fragmentiert, was Lese- und Schreibvorgänge verlangsamt. Wie viel freien Speicherplatz Sie benötigen, um dieses Szenario zu vermeiden, hängt vom jeweiligen Fall ab. Wir empfehlen, Benachrichtigungen für 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, bis die Daten per Commit im Speicher gespeichert wurden, bevor auf Anfragen von der Client-VM geantwortet wird. Wenn an einem Vorgang viele Dateien beteiligt sind, führt der Client eine lange Reihe von synchronen Vorgängen aus und die kumulative Latenz erhöht sich.

Ein Beispiel für dieses Szenario ist das Extrahieren eines Archivs in die Dateifreigabe, wie z. B. TAR-Dateien. TAR führt viele synchrone Vorgänge in einer Reihe aus, wenn ein Archiv mit vielen Dateien extrahiert wird. Daher wird die Leistung reduziert.

Wenn Sie versuchen, viele kleine Dateien in eine Dateifreigabe zu kopieren, können 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 langsam. Es gibt dazu bisher keine bekannte Abhilfe.

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, wodurch eine Latenz von drei Sekunden entsteht.

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 eine automatische Bereitstellung mit autofs durchführen.

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.

Wenn Sie die Konnektivität zu einer Filestore-Instanz testen möchten, 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 den 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 einiger Zeit reagiert Filestore für einige Minuten nicht mehr und reagiert aufgrund eines geplanten Wartungsereignisses. Informationen zum SLA von Filestore finden Sie auf der Seite SLA.

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 Bereitstellung der Dateifreigabe aufheben und sie 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 hat den Status REPAIRING

Die Filestore-Instanz befindet sich in einem fehlerhaften Zustand, da es außerhalb der Kontrolle des Nutzers liegt und sich automatisch selbst repariert. 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 maximal zugewiesene Kapazität nicht erreicht haben. Die Anzahl der Inodes skaliert mit der Kapazität. Wenn Sie weitere Inodes hinzufügen möchten, müssen Sie mehr Kapazität hinzufügen.

Die Befehle "df" und "du" melden unterschiedliche Speicherplatzmengen

Wenn eine Datei, die von einem laufenden Prozess geöffnet wird, gelöscht wird, wird der von der Datei genutzte Speicherplatz erst freigegeben, nachdem 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 bei der Berechnung besteht darin, dass der Befehl du oft mehr freien Speicherplatz als df anzeigt.

Führen Sie den folgenden Befehl aus, um die gelöschten Dateien anzuzeigen, 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. Prüfen Sie, ob Sie die Rolle roles/file.editor haben. Weitere Informationen finden Sie unter IAM-Rollen und -Berechtigungen.

  3. Sollte der Fehler weiterhin auftreten, wurde möglicherweise die Rolle file.serviceAgent des Filestore-Dienstkontos entfernt. Führen Sie folgenden Befehl aus, um dies zu überprüfen:

    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 ist 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

Beim Erstellen einer Instanz wird Fehlercode 13 ausgegeben

Das Auftreten von Fehlercode 13 bei der Instanzerstellung kann verschiedene Ursachen haben. Der häufigste Grund ist, dass Filestore ein internes Netzwerkkontingent erreicht hat.

Für jedes VPC-Netzwerk, in dem Sie eine Filestore-Instanz erstellen, muss Filestore ein internes Netzwerk erstellen, das eine Peering-Verbindung zu diesem Netzwerk herstellt. Diese internen Netzwerke bleiben erhalten, auch wenn die zugehörigen Filestore-Instanzen und VPC-Netzwerke gelöscht werden.

Sobald die Anzahl der internen Netzwerke für ein Projekt 49 erreicht ist, kann Filestore keine neuen internen Netzwerke mehr erstellen, sodass Sie in neuen VPC-Netzwerken keine Filestore-Instanzen erstellen können. Bei einem entsprechenden Versuch wird ein Fehler ausgegeben.

Error code 13, message: an internal error has occurred

Sie können die internen Netzwerke nur löschen, indem Sie die Filestore API deaktivieren und dann wieder aktivieren. Bevor Sie die API deaktivieren können, müssen Sie alle Filestore-Ressourcen löschen, z. B. Filestore-Instanzen und Sicherungen.

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 benötigen, und nicht löschen können, wenden Sie sich an Ihren Kundenbetreuer, um die Peering-Netzwerke manuell löschen zu lassen.

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.

  • Durchlaufen Sie einen Pool von maximal 49 VPC-Netzwerken, anstatt sie zu löschen und anschließend neu zu erstellen.

Dateifreigabe kann nicht bereitgestellt werden

Mein VM- oder GKE-Pod kann nicht auf Filestore zugreifen

Bestätigen 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 eine Liste der exportierten Dateisysteme ausgeben. Prüfen Sie dann, ob der Client die RPC-Informationen von Filestore erreichen kann. Führen Sie dazu folgenden Befehl aus:

sudo rpcinfo -p <filestore-ip>

Wenn die Filestore-Instanz nicht erreichbar ist, liegt dies häufig daran, dass die Netzwerk- oder ACL-Einstellungen falsch konfiguriert sind oder dass 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 die Firewalleinstellungen. Achten Sie darauf, dass die erforderlichen Ports geöffnet sind. Weitere Informationen finden Sie unter Firewallregeln konfigurieren.
  3. Wenn Sie über einen GKE-Cluster auf Filestore zugreifen und der Fehler mount.nfs: access denied by server while mounting ... angezeigt wird, finden Sie weitere Informationen unter Über GKE-Cluster nicht auf Dateifreigabe zugreifen.

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

Dabei gilt:

  • 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 aus einem GKE-Cluster kann nicht bereitgestellt werden

Sie können Cloud Filestore-Dateifreigaben nicht direkt für GKE-Cluster bereitstellen. Stattdessen müssen Sie ein PV und PVC konfigurieren.

Von GKE-Clustern aus kann nicht auf Dateifreigabe zugegriffen werden

Weitere Informationen zur Fehlerbehebung von Kubernetes oder Google Kubernetes Engine finden Sie auch in der offiziellenKubernetes-Anleitung zur Fehlerbehebung und dieAnleitung zur Fehlerbehebung in GKE auf Ihrem Mobilgerät.

Fehler: Ausgabe: mount.nfs: Zugriff vom Server verweigert, während xxxx:/file-share-name bereitgestellt wird

Achten Sie darauf, dass die Werte der PV spec.nfs.path und spec.nfs.server 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 hat, müssen der PV spec.nfs.path und spec.nfs.server mit diesen Werten übereinstimmen:

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

Alle Filestore-bezogenen Ressourcen wie Filestore-Instanzen und Sicherungen müssen 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 ausgeschöpft 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 Ausschöpfung des IP-Adressbereichs.