PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : File Replikation oder Sync über mehrere Server



asi_dkn
28.11.08, 11:05
Hallo zusammen,

Ich hab da so ein Problem. Es handelt sich um einen 3 Node Webcluster hinter einem Loadbalancer. Es ist jetzt so das wenn jemand ein File uploaded, das File nur gerade auf dem Server liegt wo die Session eben läuft. Ich möchte jetzt dieses Verzeichnis mit den Uploads irgendwie synchronisieren oder replizieren, und zwar so das auf allen drei Nodes genau dieselben Files liegen.

NFS möchte ich nicht umbedingt verwenden da dann doch alle Files auf einem Server liegen und, falls dieser ausfällt, eben nicht verfügbar sind.

bei rsync bin ich mir nicht ganz sicher wie ich das gescheit anstellen soll und unison (könnte evtl. helfen) kann, soweit ich weiss, nur zwei Verzeichnisse syncen.

Hätte da jemand eine Idee wie ich das anstellen soll?

Gruss und danke ;)

marce
28.11.08, 11:11
Möglichkeiten gibt's mehrere - du könntest:
(1) die Datei durch den Uploadprozess selbst auf die anderen Server verteilen
(2) ein geshartes Upload-VZ verwenden (NFS), von dort dann in den Downloadbereich verschieben per Cronjob / pro Server
(3) regelmäßige Syncs von jedem Server auf die jeweils anderen
(4) ...

hängt auch immer von den Anforderungen ab (wie schnell müssen die Server im Sync sein, ...)

asi_dkn
28.11.08, 11:23
Die Server müssen nicht sofort gesynct werden, das kann schon gut per Cron alle 5 Minuten oder so passieren, die sind nicht super-wichtig oder so. Ich habe auch daran gedacht mir etwas zu backen das jeden Node die anderen Nodes informieren lässt wenn ich etwas verändert hat im Uploadverzeichnis... sollte, glaube ich, nicht all zu komplex werden.

marce
28.11.08, 11:27
dann würde ich pro Server ein ded. Uploadverzeichnis anlegen und einen Cronjob, der alle 5 Minuten schaut, ob darin eine Datei angekommen, wenn ja, diese auf alle Systeme in den Downloadbereich kopiert und dann im Upload-VZ löscht.

Aufwand für's Script: 10 Minuten.

asi_dkn
28.11.08, 11:32
Hmmm, das ist zwar eine extrem einfache, aber dafür auch geniale Lösung :D Ich muss mal nachsehen ob man das irgendwie anpassen kann an dieser app, also das uploadverzeichnis != downloadverzeichnis ist... aber die idee ist echt gut ;)

marce
28.11.08, 11:36
wenn sich das Upload-VZ nicht konfigurieren lässt ist der Aufwand auch nicht viel höher - man synct dann halt auf alle anderen Server des Pools außer auf sich selbst. Dafür muss man nichts löschen :-)

asi_dkn
28.11.08, 11:54
Also von der App her lassen sich keine separaten Verzeichnisse angeben... Ich habe mir aber noch etwas überlegt. Der Downloadbereich ist für unsere Kunden und wir stellen da Software, Manuals etc. zur Verfügung... das heisst, es werden sicher auch Files gelöscht... Ich glaube ganz so trivial ist es dann doch nicht mehr. Ich glaube ich brauche etwas wie eine Datenbank welche weiss welches File sich auf welchem Node befindet, ob es aktualisiert wurde oder nicht etc...

Ich glaube aber mit einer kleinen DB und MD5 Prüfsummen sollte das machbar sein :)

baumgartner
28.11.08, 12:27
http://tinyurl.com/yoe8qa

Alles klar? :)

asi_dkn
03.12.08, 11:43
Also ich hab eine Lösung. Sicher verbesserungsfähig und vermutlich auch nicht gerade das Optimum an Performance, aber es funktioniert. ;)

Initial wird eine SQLite DB angelegt welche den absoluten Filenamen und das Änderungsdatum der Datei speichert. Aus einer einfachen Config Datei werden alle Clusternodes gelesen sowie das zu syncende Verzeichnis.

Beim Start wartet das Script zwischen 0 und 60 Sekunden (das Script läuft alle 5 Minuten auf allen drei Servern, so sollen "Kollisionen" verhindert werden"). Beim Start, legt das Script auf allen anderen Nodes eine Lock-Datei an welche es den anderen Scripts auf den anderen Server verbietet überhaupt nach Änderungen zu suchen.

Zu erst wird nach neuen Files gesucht (sind alle Files im Verzeichnis in der DB?). Wenn nein, wird das File auf die anderen Nodes kopiert und auch auf deren Datenbanken eingetragen. Danach wird das File auch in der lokalen DB eingetragen.

Dann wird nach gelöschten Files gesucht (sind alle Files aus der DB noch im Verzeichnis?). Wenn nein, wird die Datei auf den andern Nodes entfernt, auf den remote DBs ebenfalls, und auch aus der lokalen DB entfernt.

Zu letzt wärden am Änderungsdatum der Datei Änderungen festgestellt. Ich habe mal vorsorglich noch ein Feld für md5 Summen angelegt, welches ich aber bei 400MB grossen Files nicht umbedingt immer testen will ;)
Auf jeden Fall, wenn sich Dateien ändern werden sie auf die anderen Nodes kopiert, auf den remote DBs aktualisiert und zu letzt auch lokal.

Ganz zu letzt wird das Lock File wieder entfernt.

Also nach den ersten Tests funkioniert das ganze ganz gut :)

marce
03.12.08, 11:46
vor dem Syncen würde ich noch das Änderungsdatum überprüfen - gerade im Upload befindliche Dateien machen sich immer schlecht, wenn sie verteilt werden :-)

asi_dkn
03.12.08, 13:16
vor dem Syncen würde ich noch das Änderungsdatum überprüfen - gerade im Upload befindliche Dateien machen sich immer schlecht, wenn sie verteilt werden :-)
Ja das hat was für sich... :rolleyes: