Fehlerbehebung

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

Beeinträchtigte Leistung

Prüfen Sie, ob Sie den empfohlenen Maschinentyp für die Client-VM verwenden.
Wenn auf Ihrer Client-VM Linux ausgeführt wird, prüfen Sie, ob die Standardoptionen für die Bereitstellung angewendet werden.
Hinweis: Bei Verwendung der Clientbereitstellungsoption sync wird die Leistung erheblich reduziert.
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.
Achten Sie darauf, dass die Filestore-Instanz nicht voll oder nahe ist. Wenn die Kapazität fast voll ist, ist der verbleibende Platz knapp fragmentiert, was Lese- und Schreibvorgänge verlangsamt. Wie viel Speicherplatz Sie benötigen, um dieses Szenario zu vermeiden, ist abhängig vom jeweiligen Fall. Wir empfehlen, Benachrichtigungen zu wenig Speicherplatz einzurichten.
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. Das bedeutet, dass die Filestore-Instanz bei den meisten Datenänderungen auf das Commit für den Speicher wartet, bevor die Anfragen der Client-VM verarbeitet werden. Bei vielen Dateien in einem Vorgang verarbeitet der Client die entsprechenden Vorgänge alle synchron, sodass sich die kumulative Latenz erhöht.

Ein Beispiel hierfür ist das Extrahieren eines Archivs für die Dateifreigabe, etwa von TAR-Dateien. TAR führt beim Extrahieren eines Archivs mit vielen Dateien eine große Anzahl synchroner Vorgänge aus. Infolgedessen wird die Leistung erheblich reduziert.

Wenn Sie eine große Anzahl kleiner Dateien in eine Dateifreigabe kopieren möchten, sollten Sie die Dateierstellung mit einem Tool wie gsutil parallel ausführen:

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 wird derzeit sehr langsam ausgeführt. Es gibt dazu bisher keine bekannte Abhilfe.

Latenz beim Bereitstellen und Trennen einer Dateifreigabe

Bei der Bereitstellung einer Dateifreigabe mit den Standardbereitstellungsoptionen wird eine Latenz von drei Sekunden eingeführt. Diese wird durch den Versuch des Bereitstellungsbefehls ausgelöst, die unterstützte Transportmethode der Filestore-Instanz zu ermitteln.

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

Das ist besonders wichtig, wenn Sie mit autofs automatisch bereitstellen.

Filestore reagiert nicht

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

Filestore-Instanzen antworten nicht auf ping- oder traceroute-Anfragen, weil Filestore ICMP nicht zulässt.

Sie können showmount mit dem Client ausführen, um die Konnektivität zu einer Filestore-Instanz zu testen:

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

Wenn Filestore einige Minuten erst nicht reagiert und dann wieder reagiert, ist dies möglicherweise auf ein geplantes Wartungsereignis zurückzuführen. 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. Sie können die Dateifreigabe zurücknehmen und die Filestore-Instanz löschen, wenn sie nicht benötigt wird.

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

Instanz zeigt Status `REPAIRING` an

Die Filestore-Instanz befindet sich in einem fehlerhaften Zustand aufgrund interner Ursachen, die über die Kontrolle des Nutzers hinausgehen und sich automatisch selbst reparieren. Die Instanz ist während dieses Zeitraums nicht verfügbar und Sie müssen keine weiteren Maßnahmen ergreifen.

"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% auf 100 % steht, sind keine kostenlosen inodes vorhanden und Sie können keine weiteren Dateien in der Dateifreigabe speichern, auch wenn Sie die maximal 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.
Wenn noch Inodes vorhanden sind, haben Sie möglicherweise die maximale Anzahl an Einträgen (von Dateien oder von Unterverzeichnissen) für ein Verzeichnis erreicht. Die maximale Anzahl der Einträge in einem Verzeichnis hängt von der Länge des Namens dieser Einträge ab. Das Erreichen dieses Limits wird jedoch als Wahrscheinlichkeit und nicht als feste Grenze behandelt. Sie müssen hierfür die Dateihierarchie tiefer strukturieren und Ihre Einträge in Unterverzeichnisse aufteilen.

Instanz konnte nicht erstellt werden

Fehler `PERMISSION DENIED` beim Erstellen einer Filestore-Instanz

Prüfen Sie, ob die Filestore API aktiviert ist:
```
gcloud services enable file.googleapis.com
```
Prüfen Sie, ob Sie die Rolle roles/file.editor haben. Weitere Informationen finden Sie unter IAM-Rollen und -Berechtigungen.
Wenn der Fehler weiterhin auftritt, wurde möglicherweise die Rolle file.serviceAgent vom Filestore-Dienstkonto entfernt. Dies können Sie mit folgendem Befehl prüfen:
```
gcloud projects get-iam-policy project-name  \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:service-project-id@cloud-filer.iam.gserviceaccount.com"
```
Dabei gilt:
- project-name ist der Name Ihres Google Cloud-Projekts.
- project-id ist die ID-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 --member serviceAccount:service-project-id@cloud-filer.iam.gserviceaccount.com --role roles/file.serviceAgent
```
Dabei ist project-id die ID-Nummer Ihres Google Cloud-Projekts.

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, 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 50 erreicht, können keine neuen internen Netzwerke mehr erstellt werden. Dadurch wird verhindert, dass Sie in neuen VPC-Netzwerken Filestore-Instanzen erstellen können. Bei einem entsprechenden Versuch wird ein Fehler ausgegeben.

Error code 13, message: an internal error has occurred

Die einzige Möglichkeit, die internen Netzwerke zu löschen, besteht darin, die Filestore API zu deaktivieren und dann wieder zu aktivieren. Zum Deaktivieren der API müssen Sie alle Filestore-Ressourcen wie Filestore-Instanzen und -Sicherungen löschen.

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

Wenn dies nicht möglich ist, weil Sie die Filestore-Instanzen benötigen und deshalb nicht löschen können, wenden Sie sich an Ihren Kundenbetreuer, damit die Peering-Netzwerke manuell gelöscht werden.

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

Überprüfen Sie mit folgendem 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 der exportierten Dateisysteme antworten. Stellen Sie dann mit dem folgenden Befehl fest, ob der Client die RPC-Informationen von Filestore aufrufen kann:

sudo rpcinfo -p <filestore-ip>

Wenn die Filestore-Instanz nicht erreichbar ist, liegt dies häufig an falsch konfigurierten Netzwerkeinstellungen oder ACL-Einstellungen oder wenn Sie versuchen, die falsche Instanz bereitzustellen.

Prüfen Sie, ob die IP-basierte Zugriffssteuerung aktiviert ist und prüfen Sie, ob die IP-Adresse des Clients eingeschränkt ist. Hier finden Sie die Details.
Prüfen Sie in Ihren Firewalleinstellungen, ob die erforderlichen Ports geöffnet sind. Weitere Informationen finden Sie unter Firewallregeln konfigurieren.
Wenn Sie über einen GKE-Cluster auf Filestore zugreifen und den Fehler mount.nfs: access denied by server while mounting ... erhalten, lesen Sie Dateizugriff auf GKE-Cluster 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

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 Anleitung dazu finden Sie unter Instanzen bearbeiten.

Eine Dateifreigabe kann nicht in App Engine bereitgestellt werden

Filestore unterstützt App Engine nicht.

Dateifreigabe aus einem GKE-Cluster nicht bereitstellen

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

Auf GKE-Cluster kann nicht zugegriffen werden

Weitere Informationen zur Fehlerbehebung in Kubernetes oder Google Kubernetes Engine finden Sie auch in der offiziellenFehlerbehebung für Kubernetes Fehlerbehebung für GKE auf.

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

Beispiel:

Wenn Ihre Dateifreigabe vol1 heißt und die IP-Adresse der Filestore-Instanz 10.0.0.2 lautet, sollten 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

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