Optionen, um 1 Million fileen mit Remote-servern effizient zu synchronisieren?

Bei einer Firma arbeite ich für wir haben so etwas wie "Playlists", die kleine fileen ~ 100-300 Bytes sind. Es gibt ungefähr eine Million von ihnen. Etwa 100.000 von ihnen werden jede Stunde gewechselt. Diese Playlisten müssen jede Stunde auf 10 weitere entfernte server auf verschiedenen Kontinenten hochgeladen werden und es muss schnell in weniger als 2 Minuten passieren. Es ist sehr wichtig, dass fileen, die auf dem Master gelöscht werden, auch auf allen Repliken gelöscht werden. Wir verwenden derzeit Linux für unsere Infrastruktur.

Ich dachte daran, rsync mit der Option -W zu versuchen, ganze fileen zu kopieren, ohne den Inhalt zu vergleichen. Ich habe es noch nicht ausprobiert, aber vielleicht Leute, die mehr Erfahrung mit rsync haben, könnte mir sagen, ob es eine praktikable Option ist?

Welche anderen Optionen sind es wert?

Update: Ich habe die lsyncd-Option als Antwort gewählt, aber nur weil es das beliebteste war. Andere vorgeschlagene Alternativen gelten auch auf ihre eigene Weise.

  • DRBD als DR: Synchronisieren von dataspeichern von 2 ESXI-Hosts, vmdk-Konsistenz?
  • Wie man die time auf mehreren servern synchron hält
  • Live-filesynchronisierung über mehrere Linux-server mit Millionen von fileen und Verzeichnissen
  • Wie kann man Software raid resync unterbrechen?
  • Vorwärts-Synchronisierung auf HDFS? (ODER einen unvollständigen hdfs-Upload fortsetzen)
  • Was ist der Vorteil der Synchronisierung von UID / GID auf Linux-Rechnern?
  • OpenLdap synchronisiert das Home-Verzeichnis zwischen Client und server
  • 7 Solutions collect form web for “Optionen, um 1 Million fileen mit Remote-servern effizient zu synchronisieren?”

    Da sofortige Updates auch akzeptabel sind, könntest du lsyncd benutzen.
    Es sieht Verzeichnisse (Inotify) und wird rsync Änderungen an Sklaven.
    Beim Start wird es einen vollen rsync , also dauert es einige time, aber danach werden nur Änderungen übertragen.
    Rekursives Beobachten von Verzeichnissen ist möglich, wenn ein Slave-server heruntergefahren wird, wird die Synchronisation wiederholt, bis es zurückkommt.

    Wenn dies alles in einem einzigen Verzeichnis (oder einer staticen list von Verzeichnissen) ist, können Sie auch incron verwenden .
    Der Nachteil dort ist, dass es nicht rekursive Beobachtung von Ordnern erlaubt und Sie müssen die Synchronisierungsfunktionalität selbst implementieren.

    Verwenden Sie ein verteiltes filesystem wie GlusterFS . Mit Replikation und Parallelität konzipiert, kann GlusterFS bis zu 10 server viel reibungsloser skalieren als Ad-hoc-Lösungen mit Inotify und rsync .

    Für diesen speziellen Use-Case könnte man ein 10-server-GlusterFS-Volumen von 10 Repliken (dh 1 Replik / Brick pro server) aufbuild, so dass jede Replik ein exakter Spiegel jeder anderen Replik im Volume wäre. GlusterFS würde automatisch filesystem-Updates auf alle Repliken übertragen.

    Clients in jedem Standort würden sich mit ihrem lokalen server in Verbindung setzen, so dass der Lesezugriff auf fileen schnell wäre. Die zentrale Frage ist, ob die Schreiblatenz gut akzeptabel gehalten werden könnte. Der einzige path, um das zu beantworten, ist, es zu versuchen.

    Ich bezweifle, dass rsync für das in der normalen Weise arbeiten würde, weil das Scannen einer Million Akten und das Verstehen mit dem entfernten System 10mal zu lange dauern würde. Ich würde versuchen, ein System mit etwas wie inotify zu implementieren, das eine list der geänderten Akten beibehält und sie zu den entfernten Bedienern drückt (wenn diese Änderungen nicht irgendwie in irgendeiner anderen Weise protokolliert werden). Sie können diese list dann verwenden, um schnell die fileen zu identifizieren, die übertragen werden sollen – vielleicht sogar mit rsync (oder besser 10 parallele Instanzen davon).

    Bearbeiten: Mit ein wenig Arbeit können Sie sogar diese Inotify / Log Watch Ansatz verwenden, um die fileen zu kopieren, sobald die Änderung erfolgt.

    Weitere Alternativen:

    • Legen Sie einen Job in RabbitMQ oder Gearman ein, um asynchronous auszuschalten und die gleiche file auf allen entfernten servern zu löschen (oder hinzuzufügen), wenn Sie eine file auf dem primären server löschen oder hinzufügen.
    • memoryn Sie die fileen in einer database und verwenden Sie die Replikation, um die Remote-server synchron zu halten.
    • Wenn du ZFS hast, kannst du die ZFS-Replikation verwenden .
    • Einige SANs haben filereplikation. Ich habe keine Ahnung, ob dies über das Internet genutzt werden kann.

    Dies scheint ein idealer Storybook Use Case für MongoDB und vielleicht GridFS zu sein . Da die fileen relativ klein sind, sollte MongoDB allein reichen, obwohl es praktisch sein kann, die GridFS API zu verwenden.

    MongoDB ist eine nosql database und GridFS ist ein filespeicher, der oben auf ihm aufbaut. MongoDB hat eine Menge von eingebauten Optionen für Replikation und Sharding , so sollte es sehr gut in Ihrem Anwendungsfall skalieren.

    In Ihrem Fall werden Sie wahrscheinlich mit einem Replikat-Set beginnen, der aus dem Master besteht, der sich in Ihrem primären Rechenzentrum befindet (vielleicht ein zweiter, falls Sie Failover an der gleichen Stelle wollen) und Ihre zehn "Slaves", die auf der ganzen Welt verteilt sind. Dann laden Sie Tests, um zu überprüfen, ob die Schreibleistung ausreicht und überprüfen Sie die Replikationszeiten auf Ihre Knoten. Wenn du mehr performance benötigst, kannst du das Setup zu einem Sharded machen (meistens, um die Schreibladung auf mehr server zu verteilen). MongoDB wurde mit der Skalierung von riesigen Setups mit "billigen" Hardware entworfen, so dass Sie in eine Reihe von preiswerten servern casting können, um die performance zu verbessern.

    Ich würde ein S3 Backend verwenden und dann einfach das auf allen servern, die ich brauche – so dass jeder ist in sync sofort sowieso

    Eine Option, die noch nicht erwähnt wurde, besteht darin, alle fileen in einer komprimierten file zu archivieren. Dies sollte die Gesamtgröße erheblich reduzieren und entfernen Sie alle Overhead get aus dem Umgang mit Millionen von einzelnen fileen. Durch das Ersetzen der gesamten Satz von fileen in einem großen Update können Sie auch sicher sein, dass entfernte fileen auf den Repliken entfernt werden.

    Der Nachteil ist natürlich, dass man viele fileen unnötig überträgt. Das kann durch die reduzierte Größe durch Kompression ausgeglichen werden. Auch habe ich keine Ahnung, wie lange es dauern würde, um viele fileen zu komprimieren.

    Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de réseau.