Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Problembehandlung bei S3-Dateien

Auf dieser Seite können Sie häufig auftretende Probleme mit S3-Dateien diagnostizieren und lösen.

Der Mount-Befehl schlägt fehl

Der mount -t s3files Befehl schlägt mit einem Fehler fehl.

Häufige Ursachen und Maßnahmen:

Zugriff auf Dateioperationen verweigert

Sie können das Dateisystem mounten, erhalten aber beim Lesen, Schreiben oder Zugreifen auf Dateien die Fehlermeldung „Zugriff verweigert“ oder „Vorgang nicht erlaubt“.

Häufige Ursachen und Maßnahmen:

Intelligentes Leserouting funktioniert nicht

S3 Files führt intelligentes Leserouting durch, indem es Leseanforderungen automatisch an die für sie am besten geeignete Speicherebene weiterleitet und dabei die vollständige Dateisystemsemantik einschließlich Konsistenz, Sperren und POSIX-Berechtigungen beibehält. Kleine, zufällige Lesevorgänge von aktiv verwendeten Dateien werden aus dem Hochleistungsspeicher bereitgestellt, um eine geringe Latenz zu gewährleisten. Große sequentielle Lese- und Lesevorgänge von Daten, die sich nicht im Dateisystem befinden, werden direkt von Ihrem S3-Bucket aus ausgeführt, um einen hohen Durchsatz zu gewährleisten, ohne dass für das Dateisystem Gebühren anfallen.

Intelligentes Lese-Routing funktioniert möglicherweise nicht, wenn eine der Client-Konnektivitätsmetriken (NFSConnectionAccessibleS3BucketAccessible, undS3BucketReachable) 0 anzeigt oder wenn Sie nicht den erwarteten Lesedurchsatz sehen.

Häufige Ursachen und Maßnahmen:

Das Dateisystem gibt durchweg einen NFS-Serverfehler zurück

Ein verschlüsseltes Dateisystem gibt ständig NFS-Serverfehler zurück. Diese Fehler können auftreten, wenn S3 Files Ihren KMS-Schlüssel aus einem der folgenden Gründe nicht von AWS KMS abrufen kann:

Maßnahme

Vergewissern Sie sich zunächst, dass der AWS KMS-Schlüssel aktiviert ist. Sie können Ihre Schlüssel in der AWS KMS-Konsole einsehen. Weitere Informationen finden Sie unter Anzeigen von Schlüsseln im Entwicklerhandbuch für AWS Key Management Service.

Wenn der Schlüssel nicht aktiviert ist, aktivieren Sie ihn. Weitere Informationen finden Sie unter Aktivieren und Deaktivieren von Schlüsseln im Entwicklerhandbuch für AWS Key Management Service.

Wenn der Schlüssel noch gelöscht werden muss, brechen Sie den Löschvorgang ab und aktivieren Sie den Schlüssel erneut. Weitere Informationen finden Sie im Key Management Service Developer Guide unter Planen und Abbrechen der AWS Schlüssellöschung.

Wenn der Schlüssel aktiviert ist und Sie weiterhin Probleme haben, wenden Sie sich an den AWS Support.

Fehlendes Objekt im S3-Bucket nach dem Schreiben im Dateisystem

Sie haben eine Datei über das Dateisystem geschrieben und erwartet, dass sie als Objekt in Ihrem S3-Bucket erscheint, aber das Objekt ist nicht da. S3 Files stapelt Änderungen für etwa 60 Sekunden, bevor sie nach S3 kopiert werden. Wenn das Objekt immer noch nicht angezeigt wird, ist der Export möglicherweise fehlgeschlagen. In einem solchen Fall werden Sie feststellen, dass die FailedExports CloudWatch Metrik zunimmt.

Maßnahme

Überprüfen Sie den Exportstatus der Datei mithilfe erweiterter Attribute:

getfattr -n "user.s3files.status;$(date -u +%s)" missing-file.txt --only-values

Der Zeitstempel im Attributnamen stellt sicher, dass Sie den neuesten Status erhalten. Beispielausgabe:

S3Key: s3://bucket/prefix/missing-file.txt
ExportError: PathTooLong

ExportErrorwird nicht angezeigt, wenn kein Exportfehler vorliegt. S3Keyist leer, wenn ein S3-Objekt nie mit der Datei verknüpft wurde.

In der folgenden Tabelle sind alle möglichen ExportError Werte aufgeführt:

S3 Files wiederholt automatisch fehlgeschlagene Exporte. ExportErrorwird nur bei Fehlern angezeigt, die nicht erneut versucht werden können.

Dateien, die im Verzeichnis Lost and Found erscheinen

Dateien wurden in dem .s3files-lost+found-file-system-id Verzeichnis im Stammverzeichnis Ihres Dateisystems angezeigt. In diesem Fall sehen Sie einen Anstieg der LostAndFoundFiles CloudWatch Metrik. Dies tritt auf, wenn ein Synchronisationskonflikt auftritt. Ein Konflikt tritt auf, wenn dieselbe Datei im Dateisystem geändert wird und sich das entsprechende S3-Objekt ändert, bevor S3 Files die Dateisystemänderungen wieder mit S3 synchronisiert. S3 Files behandelt den S3-Bucket als Quelle der Wahrheit, verschiebt die widersprüchliche Datei in das Verzeichnis Lost and Found und importiert die neueste Version aus dem S3-Bucket in das Dateisystem.

Identifizieren von Dateien im Verzeichnis Lost and Found

Wenn S3 Files eine Datei in das Verzeichnis Lost and Found verschiebt, wird dem Dateinamen eine hexadezimale Kennung vorangestellt, um mehrere Versionen derselben Datei zu unterscheiden, die im Laufe der Zeit möglicherweise verschoben werden. Dateinamen, die länger als 100 Zeichen sind, werden gekürzt, um Platz für diesen Bezeichner zu schaffen. Der ursprüngliche Verzeichnispfad der Datei wird im Verzeichnis Lost and Found nicht beibehalten.

Maßnahme

Rufen Sie den ursprünglichen Pfad der Datei und den entsprechenden S3-Objektschlüssel ab:

getfattr -n "user.s3files.status;$(date -u +%s)" .s3files-lost+found-fs-12345678/abcdef1234_report.csv --only-values

Beispielausgabe:

S3Key: s3://bucket/prefix/report.csv
FilePath: /data/report.csv

Sie können dann entweder die neueste Version aus Ihrem S3-Bucket behalten und die Datei aus dem Verzeichnis Lost and Found löschen, oder Sie können die Datei aus dem Lost & Found-Verzeichnis zurück in ihren ursprünglichen Pfad kopieren, um die S3-Version zu überschreiben.

Die Synchronisation gerät ins Hintertreffen

Die PendingExports CloudWatch Zahl wächst, was darauf hindeutet, dass Ihr Workload Änderungen schneller generiert, als S3 Files sie mit S3 synchronisieren kann.

Das bedeutet, dass Ihre Arbeitslast möglicherweise die Synchronisierungsrate überschreitet. S3 Files exportiert bis zu 800 Dateien pro Sekunde pro Dateisystem. Erwägen Sie, die Anzahl der Dateiänderungen zu reduzieren oder die Arbeit auf mehrere Dateisysteme zu verteilen. Überwachen Sie die PendingExports Metrik im Laufe der Zeit. Wenn sie sich stabilisiert oder abnimmt, holt S3 Files auf. Wenn es weiter wächst, wenden Sie sich an den AWS Support.

Debug-Logs für Clients aktivieren

Wenn Sie Probleme mit der Bereitstellung, der Konnektivität oder der Umgehung von Lesevorgängen beheben möchten, können Sie die Protokollierung auf Debug-Ebene auf dem S3 Files-Client aktivieren, um mehr Details zu erfassen.

Mounten Sie die Helper- und Watchdog-Protokolle

Bearbeiten /etc/amazon/efs/s3files-utils.conf und ändern Sie die Protokollierungsebene von INFO auf DEBUG:

[DEFAULT]
logging_level = DEBUG

Hängen Sie das Dateisystem aus und hängen Sie es erneut ein, damit die Änderung wirksam wird:

sudo umount /mnt/s3files
sudo mount -t s3files file-system-id:/ /mnt/s3files

Protokolle werden in geschrieben. /var/log/amazon/efs/ Das Mount Helper-Protokoll istmount.log.

Proxyprotokolle (efs-proxy)

Der Proxy verarbeitet den NFS-Verkehr und den S3-Lesebypass. Um die Debug-Protokollierung für den Proxy zu aktivieren, bearbeiten Sie: /etc/amazon/efs/s3files-utils.conf

[proxy]
proxy_logging_level = DEBUG

Hängen Sie das Gerät aus und hängen Sie es erneut ein, damit die Änderung wirksam wird. Proxyprotokolle werden in geschrieben. /var/log/amazon/efs/

TLS-Tunnelprotokolle (Stunnel)

TLS-Tunnelprotokolle sind standardmäßig deaktiviert. Um sie zu aktivieren, bearbeiten /etc/amazon/efs/s3files-utils.conf und stellen Sie Folgendes ein:

[mount]
stunnel_debug_enabled = true

Um alle Stunnel-Logs für ein Dateisystem in einer einzigen Datei zu speichern, entfernen Sie auch das Kommentarzeichen aus der stunnel_logs_file Zeile:

stunnel_logs_file = /var/log/amazon/efs/{fs_id}.stunnel.log

Größenbeschränkungen für Protokolle

Protokolldateien werden automatisch rotiert. Sie können die maximale Größe und Anzahl rotierter Dateien konfigurieren ins3files-utils.conf:

[DEFAULT]
logging_max_bytes = 1048576
logging_file_count = 10

Die Standardeinstellung ist 1 MB pro Protokolldatei mit 10 rotierten Dateien, also maximal 10 MB pro Protokolltyp.

Logs mit dem AWS Support teilen

Wenn Sie sich an den AWS Support wenden, sammeln Sie die Client-Logs und die Konfiguration in einem einzigen Archiv:

sudo tar -czf /tmp/s3files-support-logs.tar.gz \
  /var/log/amazon/efs/ \
  /etc/amazon/efs/s3files-utils.conf

Fügen /tmp/s3files-support-logs.tar.gz Sie es Ihrer Support-Anfrage bei.