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.
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 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.
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
Prüfen Sie, ob die Filestore API aktiviert ist:
gcloud services enable file.googleapis.com
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.
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. 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.
- Prüfen Sie, ob die IP-basierte Zugriffssteuerung aktiviert ist und ob die IP-Adresse des Clients eingeschränkt ist. Weitere Informationen
- Prüfen Sie in den Firewalleinstellungen, ob die erforderlichen Ports geöffnet sind. Weitere Informationen finden Sie unter Firewallregeln konfigurieren.
- 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.