Ich habe derzeit ein System-Setup, bei dem ein Client mir Dateien per FTP schickt, was inotify (über Linux-Kernel-Benachrichtigungen) auslöst, um eine Analyse auszulösen, die diese Dateien bearbeitet. Das Problem, auf das ich stoße, ist, dass der Parser derzeit die E/A-Kapazität einer EC2-Instanz erreicht und ich möchte zusätzliche Knoten hinzufügen, um die Dateilast aufzuteilen. Der Client kann leider nur per FTP hochladen. Daher frage ich mich, wie ich eine andere Instanz, die das EBS-Volume, auf dem die Dateien abgelegt werden, nicht teilt, an dieser Datei arbeiten lassen kann.
Gibt es derzeit eine AWS-Lösung, die meinen Client, der FTP verwendet, unberührt lässt (außer vielleicht einer IP-Änderung, was in Ordnung ist) und mir den Zugriff mehrerer EC2-Instanzen auf das Dateisystem ermöglicht?
Antwort1
Natürlich...
Sie können mehrere Volumes beider Typen verbinden und verteilen, um die für Ihre Amazon EC2-Anwendungen verfügbare E/A-Leistung zu erhöhen.
Das ist eine Sache, die ich verwendet habe, RAID-10 von EBS-Volumes, aber ... aber ich nehme an, Sie haben daran gedacht.
Ich dachte darüber nach, Ihren FTP-Server mit etwas wieHAProxyund/oder das redirmit Ubuntu mitgelieferte Dienstprogramm (das FTP-Pakete umschreiben kann, um einige der inhärenten Absurditäten dieses Protokolls zu beheben), aber die umständliche Mehrfachverbindungsnatur von FTP könnte dies zu einem komplizierten Unterfangen machen, und es ist vielleicht nicht wirklich das, was Sie wollen.
Also, was ist mit s3fs?
Bevor ich das vorschlug, habe ich gegoogelt und Dinge gefunden wiedieser Beitrag, was darauf hindeutete, dass es möglicherweise nicht funktionierte. Dann wurde mir jedoch klar, dass dem OP in diesem Fall offenbar erhebliches Verständnis dafür fehlte, wie S3 und Dateisysteme tatsächlich funktionieren, und er erwartete, dass inotify erkennt, dass sich Dinge in S3 aus externen Gründen (ohne das lokale Dateisystem zu durchlaufen) per Fernzugriff geändert haben, was natürlich keinen Sinn ergibt.
Aber ich habe etwas Code geschrieben, um es zu testen, und s3fs scheint tatsächlich korrekt mit inotify zu interagieren. Sie könnten einen Bucket anstelle eines EBS-Volumes von Ihrem FTP-Server mounten, sodass die Dateien, wenn Ihr Client sie über FTP hochlädt, direkt in den Bucket fallen – und inotify fängt dieses Ereignis ab, wie es bei einem herkömmlichen Dateisystem der Fall wäre. An diesem Punkt könnten Sie SQS oder eine beliebige Anzahl anderer Mechanismen verwenden, um die Arbeitsmaschinen zu benachrichtigen, dass Jobs zu erledigen sind. Sie könnten dann die Dateien unabhängig voneinander abrufen und verarbeiten, wobei die E/A nur durch die verfügbare Bandbreite zwischen jeder dieser Maschinen und der S3-Infrastruktur begrenzt wäre.
Es gibt eine Reihe von Dingen, für die s3fs völlig ungeeignet ist, wie z. B. ein Server, der immer wieder den gleichen statischen Inhalt ausliefert -- s3fs ist dafür keine gute Lösung, da wahrscheinlich eine große Anzahl redundanter Anfragen auftreten würde und/oder s3fs Dinge lokal zwischenspeichern muss (was es kann, aber es hat keinen Sinn -- wenn Sie das brauchen, dann würden Sie die Dateien einfach lokal speichern) und die Latenz, die entsteht, wenn man sie einzeln auf Anfrage abruft, während man versucht, eine responsive Website auszuliefern, könnte problematisch sein... aber wenn jede DateinichtDurch den wiederholten Zugriff habe ich positive Erfahrungen damit gemacht.
Ich habe vor kurzem ein kleines Projekt für einen Kunden durchgeführt, bei dem öffentlich herunterladbare Assets in S3 gespeichert werden sollten, aber es gab möglicherweise eine ähnliche Einschränkung wie bei Ihnen - sieWirklichwollte die Dateien per FTP hochladen können. Die Kombination von proftpd mit einem Bucket, der über s3fs an eine EC2-Instanz angehängt wurde, bot ihnen ein einfaches „Gateway“ zu S3, das mit ihren vorhandenen Systemen kompatibel war. Ich weiß also, dass es funktioniert, und nachdem ich gerade dasselbe Setup mit inotify getestet habe, kann ich Ihnen sagen, dass die beiden die erwartete Interaktion zu haben scheinen.
Wenn Sie S3 auf diese Weise innerhalb von EC2 verwenden, entspricht der Speicherpreis im Wesentlichen dem von EBS und Sie zahlen nicht für die Bandbreite, wenn sich der Bucket in derselben Region wie Ihr Endpunkt befindet – Sie zahlen nur für PUT(5 USD pro Million Anfragen) und GET(4 USD pro Million Anfragen) (meine Interpretation der Preistabellen; ich habe Millionen von Objekten in S3 gespeichert und hatte noch nie eine Überraschung bei der Abrechnung, aber verlassen Sie sich nicht auf mein Wort). Es wird möglicherweise keine exakte 1:1-Korrelation zwischen Dateien und Anfragen geben, da s3fs im Hintergrund einige Affentheater machen muss, um den Dateimodus und den Besitz in S3 als Teil seiner Pseudodateisystem-Emulation zu speichern, und Objekte iterieren muss, um Verzeichnislisten zu generieren, also können die Anfragen unterschiedlich ausfallen … aber es scheint eine praktikable Lösung zu sein.
Solange Sie mit dem richtigen Verständnis für die Impedanzanpassung zwischen der Funktion von S3 und der eines herkömmlichen Dateisystems an die Sache herangehen, sehe ich keinen Grund, warum Sie hierdurch nicht praktisch unbegrenzt skalieren können, wie es erforderlich ist.
Was mir an s3fs natürlich am besten gefällt, ist, dass einem nie der Speicherplatz ausgeht. :)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
Antwort2
Wenn Ihr Client über DNS statt über IP auf Ihren FTP zugreifen kann, scheint die einfachste Lösung darin zu bestehen, einen ELB vor mehrere FTP-Instanzen zu setzen, sodass Sie horizontal skalieren können.
Wenn Sie nach Abschluss der Verarbeitung alle per FTP heruntergeladenen Dateien an einem Ort speichern müssen, können Sie S3 oder eine beliebige Anzahl von Lösungen verwenden, um die verarbeiteten Dateien dauerhaft an einem einzigen Ort zu speichern.
Antwort3
Können Sie nicht über ein Skript verfügen, um diese Dateien per SCP an den anderen Knoten zu senden, wenn inotify feststellt, dass neue Dateien per FTP an Ihren Hauptknoten gesendet werden?