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 Befehl Mount schlägt fehl

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

Häufige Ursachen und Maßnahmen:

Die Erlaubnis wurde für Dateioperationen verweigert

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

Häufige Ursachen und Maßnahmen:

Intelligentes Leserouting funktioniert nicht

S3 Files führt intelligentes Lese-Routing durch, da Leseanforderungen automatisch an die für sie am besten geeignete Speicherebene weitergeleitet werden, wobei die vollständige Dateisystemsemantik einschließlich Konsistenz, Sperren und POSIX-Berechtigungen beibehalten wird. Kleine, zufällige Lesevorgänge aktiv verwendeter 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 aus Ihrem S3-Bucket bereitgestellt, um einen hohen Durchsatz zu erzielen, ohne dass für das Dateisystem Datengebü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 konsistent einen NFS-Serverfehler zurück

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

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 unter Planen und Abbrechen der Schlüssellöschung im AWS Key Management Service Developer Guide.

Wenn der Schlüssel aktiviert ist und weiterhin Probleme auftreten, 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 wartet eine Zeit der Inaktivität beim Schreiben (60 Sekunden), bevor Änderungen zurück in Ihren S3-Bucket exportiert werden. Wenn das Objekt nach diesem Zeitraum immer noch nicht angezeigt wird, ist der Export möglicherweise fehlgeschlagen. In einem solchen Fall sehen Sie, 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 nie ein S3-Objekt mit der Datei verknüpft wurde.

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

S3 Files versucht automatisch, fehlgeschlagene Exporte erneut zu versuchen. ExportErrorwird nur für Fehler angezeigt, die nicht wiederholt werden können.

S3-Objekt ist im Dateisystem nicht sichtbar

Ein Objekt ist in Ihrem S3-Bucket vorhanden, erscheint aber nicht im Dateisystem. Der Objektschlüsselname entspricht möglicherweise keinem gültigen POSIX-Dateipfad. S3-Dateien unterstützen nicht den Zugriff auf S3-Schlüsselnamen mit leeren Pfadkomponenten (foo//bar), relativen Pfadkomponenten (foo/./bar,foo/../bar), Schlüsselnamen, die Null-Bytes enthalten, oder Schlüsselnamen, bei denen eine Pfadkomponente 255 Byte überschreitet. Objekte mit inkompatiblen Schlüsselnamen werden nicht in das Dateisystem importiert.

Dateien, die im Verzeichnis „Verloren und gefunden“ erscheinen

Dateien wurden in dem .s3files-lost+found-file-system-id Verzeichnis im Stammverzeichnis Ihres Dateisystems angezeigt. In diesem Fall sehen Sie, wie sich die LostAndFoundFiles CloudWatch Metrik erhöht. Dies tritt auf, wenn ein Synchronisierungskonflikt auftritt. Ein Konflikt tritt auf, wenn dieselbe Datei über das 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 Informationsquelle, verschiebt die widersprüchliche Datei in das Verzeichnis Lost & Found und importiert die neueste Version aus dem S3-Bucket in das Dateisystem.

Identifizieren von Dateien im Verzeichnis „Verloren und gefunden“

Wenn S3 Files eine Datei in das Verzeichnis „Verloren und gefunden“ verschiebt, wird dem Dateinamen eine hexadezimale ID vorangestellt, um mehrere Versionen derselben Datei zu unterscheiden, die im Laufe der Zeit verschoben werden können. 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 „Verloren und gefunden“ 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 „Verloren und gefunden“ löschen oder die Datei aus dem Verzeichnis „Verloren und gefunden“ zurück in ihren ursprünglichen Pfad kopieren, um die S3-Version zu überschreiben.

Die Synchronisation gerät ins Hintertreffen

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

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

Client-Debug-Protokolle aktivieren

Wenn Sie Mount-, Verbindungs- oder Lesebypass-Probleme beheben, können Sie die Protokollierung auf Debug-Ebene auf dem S3 Files-Client aktivieren, um weitere Details zu erfassen.

Mount-Helper- und Watchdog-Protokolle

Bearbeiten /etc/amazon/efs/s3files-utils.conf und ändern Sie die Protokollierungsstufe 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

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

Proxy-Protokolle (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. In die Proxyprotokolle werden geschrieben. /var/log/amazon/efs/

TLS-Tunnel-Protokolle (Stunnel)

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

[mount]
stunnel_debug_enabled = true

Um alle Stunnel-Logs für ein Dateisystem in einer einzigen Datei zu speichern, entkommentieren Sie auch die stunnel_logs_file Zeile:

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

Größenbeschränkungen für Logs

Protokolldateien werden automatisch rotiert. Sie können die maximale Größe und Anzahl der rotierten 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, maximal 10 MB pro Protokolltyp.

Protokolle mit dem AWS Support teilen

Wenn Sie den AWS Support kontaktieren, sammeln Sie die Client-Protokolle 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 dies Ihrem Support-Fall bei.