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.
Wenn Sie Probleme mit Amazon EFS haben, die sich nur schwer beheben lassen, sollten Sie sicherstellen, dass Sie einen aktuellen Linux-Kernel verwenden. Wenn Sie eine Linux-Unternehmensdistribution verwenden, empfehlen wir Folgendes:
-
Amazon Linux 2 mit Kernel 4.3 oder neuer
-
Amazon Linux 2015.09 oder neuer
-
RHEL 7.3 oder neuer
-
Alle Versionen von Ubuntu 16.04
-
Ubuntu 14.04 mit Kernel 3.13.0-83 oder neuer
-
SLES 12 Sp2 oder höher
Wenn Sie eine andere Verteilung oder einen benutzerdefinierten Kernel verwenden, empfehlen wir Kernel-Version 4.3 oder neuer.
Anmerkung
RHEL 6.9 könnte für bestimmte Workloads suboptimal sein aufgrund von Schlechte Leistung beim Öffnen vieler Dateien gleichzeitig.
Themen
Ein EFS-Dateisystem kann nicht erstellt werden
Eine Anfrage zur Erstellung eines EFS-Dateisystems schlägt mit der folgenden Meldung fehl:
User: arn:aws:iam::111122223333:user/
username
is not authorized to perform: elasticfilesystem:CreateFileSystem on the specified resource.
Maßnahme
Überprüfen Sie Ihre AWS Identity and Access Management (IAM-) Richtlinie, um sicherzustellen, dass Sie berechtigt sind, EFS-Dateisysteme mit den angegebenen Ressourcenbedingungen zu erstellen. Weitere Informationen finden Sie unter Identitäts- und Zugriffsmanagement für Amazon EFS.
Zugriff auf zulässige Dateien im NFS-Dateisystem verweigert
Wenn ein Benutzer, dem mehr als 16 Zugriffsgruppen IDs (GIDs) zugewiesen sind, versucht, einen Vorgang in einem NFS-Dateisystem auszuführen, kann ihm der Zugriff auf zulässige Dateien im Dateisystem verweigert werden. Dieses Problem tritt auf, weil das NFS-Protokoll maximal 16 GIDs pro Benutzer unterstützt und alle weiteren Daten aus der NFS-Client-Anfrage gekürzt GIDs werden, wie in RFC 5531 definiert.
Maßnahme
Strukturieren Sie Ihre NFS-Benutzer- und Gruppenzuordnungen neu, sodass jedem Benutzer nicht mehr als 16 Zugriffsgruppen () zugewiesen werden. GIDs
Fehler beim Zugriff auf die Amazon-EFS-Konsole
Dieser Abschnitt beschreibt Fehler, die beim Zugriff auf die Amazon-EFS-Management Console auftreten können.
Fehler bei der Authentifizierung der Anmeldeinformationen für ec2:DescribeVPCs
Die folgende Fehlermeldung wird beim Zugriff auf die Amazon-EFS-Konsole angezeigt:
AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.
Dieser Fehler weist darauf hin, dass Ihre Anmeldeinformationen beim EC2 Amazon-Service nicht erfolgreich authentifiziert wurden. Die Amazon EFS-Konsole ruft den EC2 Amazon-Service in Ihrem Namen auf, wenn Sie EFS-Dateisysteme in der von Ihnen ausgewählten VPC erstellen.
Maßnahme
Stellen Sie sicher, dass die Uhrzeit auf dem Client, der auf die Amazon-EFS-Konsole zugreift, korrekt eingestellt ist.
EC2 Amazon-Instanz hängt
Eine EC2 Amazon-Instance kann hängen bleiben, weil Sie ein Dateisystem-Mount-Ziel gelöscht haben, ohne das Dateisystem zuvor zu deaktivieren.
Maßnahme
Bevor Sie ein Dateisystem-Mounting-Ziel löschen, heben Sie das Mounting des Dateisystems auf. Weitere Informationen zum Unmounten Ihres Amazon-EFS-Dateisystems finden Sie unter Aufheben des Mountings von Dateisystemen.
Anwendung, die große Datenmengen schreibt, bleibt hängen
Eine Anwendung, die eine große Menge an Daten in Amazon EFS schreibt, hängt sich auf und verursacht einen Neustart der Instance.
Maßnahme
Wenn eine Anwendung zu lange braucht, um alle Daten in Amazon EFS zu schreiben, kann es sein, dass Linux neu startet, weil es den Anschein hat, dass der Vorgang nicht mehr reagiert. Diese Verhaltensweise wird von zwei Kernel-Konfigurationsparametern definiert, kernel.hung_task_panic
und kernel.hung_task_timeout_secs
.
Im folgenden Beispiel wird der Status des hängengebliebenen Prozesses vom ps
- Befehl mit D
vor dem Neustart der Instance gemeldet; dies bedeutet, dass der Prozess auf einen E/A-Vorgang wartet.
$ ps aux | grep large_io.py
root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py
/efs/large_file
Um einen Neustart zu verhindern, verlängern Sie den Timeout-Zeitraum, oder deaktivieren Sie die Kernel-Panik, wenn eine Aufgabe hängenbleibt. Der folgende Befehl deaktiviert die Kernel-Panik für hängengebliebene Aufgaben in den meisten Linux-Systemen.
$ sudo sysctl -w kernel.hung_task_panic=0
Schlechte Leistung beim Öffnen vieler Dateien gleichzeitig
Anwendungen, die mehrere Dateien parallel öffnen, können nicht die erwartete Leistungssteigerung der I/O-Parallelisierung nutzen.
Maßnahme
Dieses Problem tritt auf Network File System Version 4 (NFSv4) -Clients und auf RHEL 6-Clients auf, die NFSv4 .1 verwenden, weil diese NFS-Clients die NFS OPEN- und CLOSE-Operationen serialisieren. Verwenden Sie das NFS-Protokoll Version 4.1 und eine der vorgeschlagenen Linux-Distributionen, die dieses Problem nicht haben.
Wenn Sie NFSv4 .1 nicht verwenden können, beachten Sie, dass der Linux 4.0-Client NFSv4 Öffnungs- und Schließanfragen nach Benutzer-ID und Gruppe serialisiert. IDs Diese Serialisierung geschieht auch dann, wenn mehrere Prozesse oder mehrere Threads gleichzeitig Anforderungen ausgeben. Der Client sendet jeweils nur einen Öffnungs- oder Schließvorgang an einen NFS-Server, wenn alle übereinstimmen. IDs Um diese Probleme zu umgehen, können Sie eine der folgenden Aktionen durchführen:
-
Sie können jeden Prozess mit einer anderen Benutzer-ID auf derselben EC2 Amazon-Instance ausführen.
-
Sie können IDs den Benutzer für alle offenen Anfragen unverändert lassen und IDs stattdessen die Gruppe ändern.
-
Sie können jeden Prozess von einer separaten EC2 Amazon-Instance aus ausführen.
Benutzerdefinierte NFS-Einstellungen verursachen Schreibverzögerungen
Sie haben benutzerdefinierte NFS-Client-Einstellungen und es dauert bis zu drei Sekunden, bis eine EC2 Amazon-Instance einen Schreibvorgang auf einem Dateisystem von einer anderen EC2 Amazon-Instance aus sieht.
Maßnahme
Wenn dieses Problem auftritt, können Sie sie auf eine der folgenden Weisen lösen:
-
Wenn für den NFS-Client auf der EC2 Amazon-Instance, die Daten liest, das Attribut-Caching aktiviert ist, hängen Sie Ihr Dateisystem aus. Mounten Sie es dann erneut mit der Option
noac
, um die Attributzwischenspeicherung zu deaktivieren. Das Attribut-Caching in NFSv4 .1 ist standardmäßig aktiviert.Anmerkung
Die Deaktivierung der clientseitigen Zwischenspeicherung kann möglicherweise die Leistung Ihrer Anwendung beeinträchtigen.
-
Sie können auch bei Bedarf den Attributzwischenspeicher leeren, indem Sie eine mit den NFS-Vorgängen kompatible Computersprache verwenden. Zu diesem Zweck können Sie
ACCESS
-Vorgangsanforderung unmittelbar vor einer Leseanforderung senden.Beispielsweise können Sie mit der Programmiersprache Python den folgenden Aufruf konstruieren.
# Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file import os os.access(path, os.W_OK)
Die Erstellung von Sicherungen mit Oracle Recovery Manager ist langsam
Die Erstellung von Sicherungen mit Oracle Recovery Manager kann langsam sein, wenn Oracle Recovery Manager für 120 Sekunden pausiert, bevor er einen Sicherungsauftrag startet.
Maßnahme
Wenn dieses Problem auftritt, deaktivieren Sie Oracle Direct NFS, wie unter Enabling and Disabling Direct NFS Client Control of NFS
Anmerkung
Amazon EFS unterstützt kein Oracle Direct NFS.