Ein Roundrobin für eingehende Dateien

Eine Reihe neuer Dateien mit eindeutigen Dateinamen "erscheint" regelmäßig ¹ auf einem Server. (Wie Hunderte GB neuer Daten pro Tag sollte die Lösung auf Terabyte skalierbar sein. Jede Datei ist mehrere Megabyte groß, bis zu mehreren zehn Megabyte.)

Es gibt mehrere Computer, die diese Dateien verarbeiten. (Zehn, sollte die Lösung auf Hunderte skalierbar sein.) Es sollte möglich sein , neue Maschinen einfach hinzuzufügen und zu entfernen.

Es gibt Sicherungsdateispeicherserver, auf die jede eingehende Datei für die Archivierung kopiert werden muss . Die Daten dürfen nicht verloren gehen, alle eingehenden Dateien müssen auf dem Backup-Speicherserver bereitgestellt werden.

Jede eingehende Datei wird zur Verarbeitung an einen einzelnen Computer gesendet und sollte auf den Sicherungsspeicherserver kopiert werden.

Der Empfängerserver muss keine Dateien speichern, nachdem er sie auf dem Weg gesendet hat.

Bitte empfehlen Sie eine robuste Lösung, um die Dateien auf die oben beschriebene Weise zu verteilen. Die Lösung darf nicht auf Java basieren. Unix-Way-Lösungen sind vorzuziehen.

Server sind Ubuntu-basiert und befinden sich im selben Rechenzentrum. Alle anderen Dinge können an die Lösungsanforderungen angepasst werden.

¹ Beachten Sie, dass ich absichtlich Informationen über den Transport von Dateien zum Dateisystem weglasse. Der Grund dafür ist, dass die Dateien heutzutage von Dritten mit verschiedenen Legacy-Mitteln gesendet werden (seltsamerweise über scp und über ØMQ). Es scheint einfacher zu sein, die clusterübergreifende Schnittstelle auf Dateisystemebene zu kürzen, aber wenn die eine oder andere Lösung tatsächlich einen bestimmten Transport erfordert, können ältere Transporte auf diese aktualisiert werden.

Hier ist eine Lösung für das, was Sie suchen. An der Erstellung dieses Systems ist kein Java beteiligt, sondern nur leicht verfügbare Open Source-Bits. Das hier vorgestellte Modell kann mit anderen Technologien als den als Beispiel verwendeten arbeiten.

1. Dateien werden per HTTP an eine bestimmte Round-Robin-DNS-Adresse gesendet.
2. Das System, das die Dateien POSTT, legt dann einen Job über ein weiteres Paar Load-Balancer in einem AMQP-System (hier Rabbit MQ) ab, um den Verarbeitungsworkflow zu starten.
3. Die Load Balancer, die den HTTP-POST empfangen, befinden sich jeweils vor einer Gruppe von OpenStack Swift-Objektspeicherservern.
   • Die Load-Balancer haben jeweils zwei oder mehr OpenStack Swift-Objektspeicherserver hinter sich.
   • "Round Robin ist nicht HA" kann sein, wenn die Ziele HA selbst sind. YMMV.
   • Für zusätzliche Haltbarkeit können die IPs im RRDNS einzelne Hot-Standby-LB-Cluster sein.
4. Der Object Store-Server, der den POST tatsächlich erhält, liefert die Datei an ein Gluster-basiertes Dateisystem.
   • Das Gluster-System sollte sowohl verteilt (auch als Sharded bezeichnet) als auch repliziert sein. Dies ermöglicht es, auf dumme Dichten zu skalieren.
5. Das AMQP-System sendet den ersten Auftrag, die Sicherung, an einen verfügbaren Verarbeitungsknoten.
6. Der Verarbeitungsknoten kopiert die Datei vom Hauptspeicher in den Sicherungsspeicher und meldet Erfolg / Misserfolg nach Bedarf.
   • Die Fehlermodusverarbeitung ist hier nicht dargestellt. Versuchen Sie es im Wesentlichen so lange, bis es funktioniert. Und wenn es nie funktioniert, führen Sie einen Ausnahmevorgang durch.
7. Sobald die Sicherung abgeschlossen ist, sendet AMQP den Verarbeitungsjob an einen verfügbaren Verarbeitungsknoten.
8. Der Verarbeitungsknoten zieht die Datei entweder in sein lokales Dateisystem oder verarbeitet sie direkt aus Gluster.
9. Der Verarbeitungsknoten hinterlegt überall ein Verarbeitungsprodukt und meldet den Erfolg an AMQP.

Dieses Setup sollte in der Lage sein, Dateien mit extremer Geschwindigkeit aufzunehmen, wenn genügend Server vorhanden sind. Das Erreichen einer aggregierten Aufnahmegeschwindigkeit von 10 GbE sollte möglich sein, wenn Sie die Größe ausreichend erhöhen. Um so viele Daten so schnell zu verarbeiten , sind natürlich noch mehr Server in Ihrer Verarbeitungsmaschinenklasse erforderlich. Dieses Setup sollte auf tausend Knoten und wahrscheinlich darüber hinaus skaliert werden (obwohl das Ausmaß davon abhängt, was genau Sie mit all dem machen).

Die tiefgreifenden technischen Herausforderungen werden im Workflow-Management-Prozess liegen, der im AMQP-Prozess verborgen ist. Das ist alles Software und wahrscheinlich maßgeschneidert für die Anforderungen Ihres Systems. Aber es sollte gut mit Daten gefüttert sein!

Angesichts der Tatsache, dass Sie klargestellt haben, dass Dateien über scp ankommen, sehe ich keinen Grund für die Existenz des Front-End-Servers, da der Transportmechanismus auf Schicht 3 umgeleitet werden kann.

Ich habe einen LVS-Director (ein Paar) mit einem Verarbeitungsserverpool und einer Round-Robin-Umleitungsrichtlinie vorgesetzt. Das macht das Hinzufügen und Entfernen von Servern zum / vom Pool sehr einfach, erhöht die Zuverlässigkeit, da kein Front-End-Server umkippt, und bedeutet, dass wir uns nicht mit der Pull / Push-Frage zum Abrufen der Dateien befassen müssen das Front-End zu den Verarbeitungsservern, da es kein Front-End gibt.

Jeder Poolserver sollte dann beim Empfang einer Datei zwei Schritte ausführen: Kopieren Sie sie zuerst in den Archivspeicher, verarbeiten Sie die Datei und senden Sie sie auf dem Weg.