Eine EFS-Mount-Verbindung reparieren

Einführung

A kann gemeinsame Uploads lesen, B erreicht denselben EFS-Speicher nicht. Diagnostiziere die Verbindung, stelle Bs Mount wieder her und beschränke den Zugriff weiterhin auf die vorgesehenen Anwendungen.

Absolviere zuerst beide vorherigen EFS-Übungen. Diese frische Umgebung liefert das vorhandene Dateisystem, den Zugriffspunkt, den Originalupload und die Hosts. Nutze konfigurierte AWS CLI, SSH und AWS View; frühere Ressourcen oder ein persönliches AWS-Konto brauchst du nicht.

Bezug zu Zertifizierungen

Konzeptdarstellung; tatsächliche IDs stehen in der frischen Umgebung.

NFS-Netzwerkregel diagnostizieren und reparieren

In diesem Schritt findest du die fehlerhafte Ebene und reparierst die Speichergruppe.

Arbeite in /home/labex/project. resources.json enthält die IDs von Speicher und Anwendungen:

cd /home/labex/project
aws sts \
  get-caller-identity
FS_ID=$(jq -r .fault.filesystem_id resources.json)
MOUNT_TARGET_ID=$(jq -r .fault.mount_target_id resources.json)
AP_ID=$(jq -r .fault.access_point_id resources.json)
EFS_GROUP_ID=$(jq -r .fault.storage_group_id resources.json)
APP_GROUP_ID=$(jq -r .application_group_id resources.json)
APP_A_IP=$(jq -r '.clients["application-a"].ip' resources.json)
echo "$FS_ID"
echo "$MOUNT_TARGET_ID"
echo "$AP_ID"
echo "$EFS_GROUP_ID"
echo "$APP_GROUP_ID"
echo "$APP_A_IP"

Lies den vorhandenen Upload über beide Anwendungen:

curl -i http://127.0.0.1:8081/uploads/original-upload.txt
curl -i http://127.0.0.1:8082/uploads/original-upload.txt

A liefert 200 OK mit Original upload from application A, B 404 Not Found. Prüfe ihre Mounts:

ssh -F ssh_config application-a 'findmnt -t nfs4 /srv/shared'
ssh -F ssh_config application-b 'findmnt -t nfs4 /srv/shared'

A hat einen NFS-Mount. B hat keinen; findmnt liefert Status 1. Prüfe vor Pfaden oder Berechtigungen, ob B den Netzwerkendpunkt erreichen kann:

MOUNT_IP=$(aws efs \
  describe-mount-targets \
  --mount-target-id "$MOUNT_TARGET_ID" \
  --query 'MountTargets[0].IpAddress' --output text)
echo "$MOUNT_IP"
ssh -F ssh_config application-b "nc -zvw2 $MOUNT_IP 2049"

Die Verbindung scheitert. nc prüft TCP, ohne zu mounten. Eine falsche Zugriffspunktwurzel oder POSIX-Identität kann Dateien nach erfolgreicher Verbindung blockieren, erklärt aber diesen TCP-Fehler nicht.

Prüfe Verfügbarkeit des Mount Targets und seine zugeordnete Gruppe:

aws efs \
  describe-mount-targets \
  --mount-target-id "$MOUNT_TARGET_ID" \
  --query 'MountTargets[].{ID:MountTargetId,State:LifeCycleState,Subnet:SubnetId}'
aws efs \
  describe-mount-target-security-groups \
  --mount-target-id "$MOUNT_TARGET_ID"
aws ec2 \
  describe-security-groups \
  --group-ids "$EFS_GROUP_ID" \
  --query 'SecurityGroups[].IpPermissions'

Die Regel erlaubt TCP 2049 nur aus As privater Adresse als /32-CIDR. Sie schließt B aus. Ersetze sie durch eine Regel der Anwendungsgruppe:

aws ec2 \
  revoke-security-group-ingress \
  --group-id "$EFS_GROUP_ID" \
  --protocol tcp \
  --port 2049 \
  --cidr "$APP_A_IP/32"

Erlaube beide Mitglieder der Gruppe:

aws ec2 \
  authorize-security-group-ingress \
  --group-id "$EFS_GROUP_ID" \
  --ip-permissions "IpProtocol=tcp,FromPort=2049,ToPort=2049,UserIdGroupPairs=[{GroupId=$APP_GROUP_ID}]"
ssh -F ssh_config application-b "nc -zvw2 $MOUNT_IP 2049"

Die neue Verbindung gelingt. Du hast das Netzwerk repariert, ohne NFS für 0.0.0.0/0 zu öffnen oder das Dateisystem zu ersetzen.

Bs Zugriffspunkt-Mount wiederherstellen

In diesem Schritt verbindest du B mit dem vorhandenen gemeinsamen Upload-Verzeichnis, ohne As Daten zu ersetzen.

Prüfe den bereitgestellten Zugriffspunkt:

aws efs \
  describe-access-points \
  --access-point-id "$AP_ID" \
  --query 'AccessPoints[].{ID:AccessPointId,Root:RootDirectory.Path,User:PosixUser}'

Die Wurzel ist /uploads, die numerische Identität entspricht dem vorbereiteten Anwendungsbenutzer. Beide Anwendungen wählen denselben Punkt für gemeinsame Uploads. Erstelle kein anderes Dateisystem und kopiere As Dateien nicht auf Bs lokale Festplatte.

Mounte ihn auf B mit offiziellem Helfer und TLS:

ssh -F ssh_config application-b \
  "sudo mkdir -p /srv/shared && sudo mount -t efs -o tls,stunnel,lookupcache=positive,accesspoint=${AP_ID} ${FS_ID}:/ /srv/shared"
ssh -F ssh_config application-b 'findmnt -t nfs4 /srv/shared'

lookupcache=positive prüft zuvor fehlende Dateinamen erneut auf dem Server, wenn eine andere Anwendung sie erstellt. So bleibt die kurze Übung beobachtbar; Cacheänderungen in Produktion verlangen eine separate Leistungsbewertung. Siehe Linux-NFS-Cacheoptionen.

B zeigt NFS 4 unter /srv/shared. Die Anwendung ist bereits auf diesen Pfad eingestellt; die nächste Anfrage liest EFS direkt:

curl -i http://127.0.0.1:8082/uploads/original-upload.txt
ssh -F ssh_config application-a 'stat -c "%i %u:%g" /srv/shared/original-upload.txt'
ssh -F ssh_config application-b 'stat -c "%i %u:%g" /srv/shared/original-upload.txt'

B liefert den ursprünglichen Inhalt und beide Hosts zeigen dieselbe inode und Eigentümer. Der Zugriff auf die vorhandene Datei wurde wiederhergestellt, ohne eine Kopie zu erzeugen.

Neue Uploads und Zugriffsgrenze prüfen

In diesem Schritt belegst du Bs Schreibzugriff und den Ausschluss des unabhängigen Clients.

Lade über B hoch und lies über A:

curl -i -X PUT --data-binary 'Shared upload after connection repair' \
  http://127.0.0.1:8082/uploads/shared.txt
curl -i http://127.0.0.1:8081/uploads/shared.txt

B liefert 201 Created, A 200 OK mit demselben Inhalt. Lies shared.txt auf beiden AWS-View-Karten.

Der Referenzserver gehört einer anderen Gruppe an. Prüfe, dass er keine neue NFS-Verbindung öffnen kann:

ssh -F ssh_config reference-c "nc -zvw2 $MOUNT_IP 2049"

Die Verbindung soll mit einem Status ungleich null scheitern. Das ist die vorgesehene Grenze, kein weiterer Anwendungsfehler. Prüfe seinen unabhängigen Upload:

curl -i http://127.0.0.1:8083/uploads/reference.txt

Er liefert 200 OK und Unrelated reference upload remains unchanged. Reparierte Anwendungen und Referenz behalten unterschiedliche Netzwerkbereiche.

Beide Anwendungen lesen den neuen gemeinsamen Upload. IDs variieren zwischen Umgebungen.

Speicher freigeben

In diesem Schritt entfernst du nach dem Test temporären Speicher und behältst die vorbereiteten Hosts und das Netzwerk.

Stelle beide Anwendungen auf lokale Verzeichnisse zurück und hänge aus:

ssh -F ssh_config application-a \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-b \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-a 'sudo umount /srv/shared'
ssh -F ssh_config application-b 'sudo umount /srv/shared'

Die IDs stammen aus resources.json; entferne genau diese Ressourcen. Beginne mit Zugriffspunkt und Mount Target:

aws efs \
  delete-access-point \
  --access-point-id "$AP_ID"
aws efs \
  delete-mount-target \
  --mount-target-id "$MOUNT_TARGET_ID"
aws efs \
  describe-mount-targets \
  --file-system-id "$FS_ID"

Warte auf leere MountTargets, dann entferne Dateisystem und Speichergruppe:

aws efs \
  delete-file-system \
  --file-system-id "$FS_ID"
aws ec2 \
  delete-security-group \
  --group-id "$EFS_GROUP_ID"

Bestätige erfolgreiche leere Antworten:

aws efs \
  describe-file-systems \
  --query 'FileSystems[?Name==`fs03-shared-uploads`].FileSystemId'
aws ec2 \
  describe-security-groups \
  --filters Name=group-name,Values=fs03-efs-access \
  --query 'SecurityGroups[].GroupId'

Die Speicherlisten sollen leer sein. Behalte Server, ursprüngliche Gruppen, Subnetz und Referenzupload. Führe die Prüfung aus, solange autorisierte Abfragen möglich sind.

Zusammenfassung

Du hast Speicherverfügbarkeit, TCP-Erreichbarkeit, Mount-Auswahl und Dateirechte unterschieden. Du hast die Regel mit der Anwendungsgruppe repariert, Bs Originaldateizugriff wiederhergestellt und einen neuen Upload unter Ausschluss des Referenzclients geprüft. Schließlich hast du Speicher in Abhängigkeitsreihenfolge entfernt.

Weitere Informationen bietet die AWS-Dokumentation: Netzwerkregeln für Clients und Mount-Ziele; Mount-Zeitüberschreitungen und Zugriffsfehler diagnostizieren.