AWS: Verwenden eines regulären Dateisystems auf einem EBS-Multi-Attach-Volume in einem Szenario mit einem Writer und vielen Readern

AWS: Verwenden eines regulären Dateisystems auf einem EBS-Multi-Attach-Volume in einem Szenario mit einem Writer und vielen Readern

Ich möchte Daten zwischen mehreren AWS-Instanzen mit hoher Leistung und geringer Latenz austauschen. Es ist in Ordnung, allen Instanzen (außer einer Instanz, die Schreibzugriffe verarbeiten würde) nur Lesezugriff zu gewähren. Zwei Punkte zu diesem Anwendungsfall:

  1. An das Volume angeschlossene Knoten können jederzeit kommen und gehen (gestartet, gestoppt, beendet werden usw.).
  2. Zu den freigegebenen Daten gehören Tausende möglicherweise kleine Dateien, die aufgelistet und deren Metadaten überprüft werden müssen.

Also habe ich zunächst EFS ausprobiert, aber es ist ziemlich langsam für Vorgänge, bei denen Hunderte oder Tausende kleiner Dateien aufgezählt oder geändert werden müssen.

Also ziehe ich jetzt EBS Multi-Attach in Betracht. Um jedoch Datenbeschädigungen zu vermeiden, empfiehlt AWS die Verwendung ausschließlich von Cluster-Dateisystemen wie GFS2 oder OCFS. Beide scheinen komplex und schwierig zu konfigurieren zu sein und sind zudem anfällig für den Anwendungsfall eines Clusters, bei dem Knoten jederzeit hinzukommen und gehen können. Beispielsweise erfordert GFS2, dass die Cluster-Software auf allen Knoten neu gestartet wird, wenn die Anzahl der Knoten von mehr als 2 auf genau 2 ansteigt. Oder das Hinzufügen eines neuen Knotens erfordert die Anmeldung bei einem aktuellen Knoten, das Ausführen einiger Befehle und möglicherweise die Neuverteilung einer aktualisierten Konfigurationsdatei an alle anderen Knoten. Das scheint einfach sehr unflexibel und mit viel zusätzlichem Aufwand verbunden zu sein.

Wenn ich jedoch sicher wäre, dass nur eine Instanz auf die Festplatte schreiben würde (oder jede Instanz möglicherweise nur in ihren eigenen Unterordner oder sogar ihre eigene Festplattenpartition schreiben könnte), könnte ich dann ein reguläres Dateisystem wie XFS für dieses Volume verwenden und damit durchkommen? Oder würde es zu subtilen Datenbeschädigungen kommen, selbst wenn der Zugriff technisch schreibgeschützt ist oder der Schreibzugriff auf instanzspezifische Unterordner oder Partitionen beschränkt ist?

Oder gibt es eine völlig andere Lösung, die ich übersehe?

Antwort1

Ich habe dies (XFS) getestet und es funktioniert nicht. Sie benötigen ein Cluster-Dateisystem. Am besten verwenden Sie ein Cluster-Dateisystem. Sehen Sie sich auch andere Optionen wie Veritas Infoscale an.

Antwort2

Das Teilen von statischen Volume-Inhalten scheint mit Multi-Attach und regulärem XFS problemlos zu funktionieren. Hot-Adds zum Volume sind nur für die Instanz sichtbar, die die Daten geschrieben hat. Nachdem das geklärt war, habe ich Hot-Updates oder -Deletes nicht getestet, da ich davon ausging, dass sie ebenfalls nur vom Autor gesehen werden, aber möglicherweise den Zugriff auf diese Daten für andere Instanzen unterbrechen könnten. Neu gestartete, neu gestartete und/oder wieder verbundene Instanzen sehen den neuesten Volume-Status. Der Anwendungsfall, bei dem eine Instanz selten neue Daten schreibt und dadurch z. B. erzwungene Neustarts auslöst, damit die anderen diese Daten schließlich sehen, scheint also ein Anwendungsfall zu sein, den diese Technologie unterstützen könnte.

verwandte Informationen