Fileserver synchronisieren/replizieren
Servus zusammen, ich stehe vor folgender Situation: Samba Server in Büro1 | / \ / \ Slow link Slow link | | | | Samba-Server Samba-Server in in Büro2 Büro3 Im Moment ist es so, daß Büro2 und Büro3 über ihr DSL auf den Samba-Fileserver in Büro1 zugreifen. Aber das ist natürlich unbefriedigend von der Performance her. Gibt es eine Möglichkeit, die drei Server so zu synchronisieren bzw. zu replizieren, daß sie sich gegenüber den Nutzern in den Büros verhalten, als wären sie einer? Ziel wäre, daß die Nutzer über das LAN auf den Datenbestand zugreifen können, und Änderungen im Hintergrund auf die anderen Maschinen geschoben werden, wo die entsprechenden Daten einstweilen gelockt sind. Man könnte die Datenbestände per unison o.ä. synchronisieren. Allerdings kommt man in Schwierigkeiten, wenn sich auf beiden Seiten des Datenbestandes etwas geändert hat. Gibt es dafür Software, oder irgendwelche Tricks, mit denen man arbeiten könnte? Danke für ein paar Ratschläge! -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Servus zusammen,
ich stehe vor folgender Situation:
Samba Server in Büro1 | / \ / \ Slow link Slow link | | | | Samba-Server Samba-Server in in Büro2 Büro3
Im Moment ist es so, daß Büro2 und Büro3 über ihr DSL auf den Samba-Fileserver in Büro1 zugreifen. Aber das ist natürlich unbefriedigend von der Performance her.
Gibt es eine Möglichkeit, die drei Server so zu synchronisieren bzw. zu replizieren, daß sie sich gegenüber den Nutzern in den Büros verhalten, als wären sie einer? Ziel wäre, daß die Nutzer über das LAN auf den Datenbestand zugreifen können, und Änderungen im Hintergrund auf die anderen Maschinen geschoben werden, wo die entsprechenden Daten einstweilen gelockt sind.
Man könnte die Datenbestände per unison o.ä. synchronisieren. Allerdings kommt man in Schwierigkeiten, wenn sich auf beiden Seiten des Datenbestandes etwas geändert hat.
Gibt es dafür Software, oder irgendwelche Tricks, mit denen man arbeiten könnte?
Danke für ein paar Ratschläge!
Theoretisch JA, ich grübele auch an dem Problem, allerdings noch nichts konkret umgesetzt hier, weil: ich warte noch einen Tick. (jetzt tägliches Sync mit rsync ) Ich werde wohl DRBD dazu verwenden und seit kurzem ist DRBD Kernelbestandteil. gehen täte auch unison condoit laut Literatur (siehe auch Linux-Magazin) Ich bin mir nicht sicher, wie ich mit DRBD per aDSL klarkomme, zumal es im Moment an einer guten "Spielumgebung" noch fehlt. Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Fred Ockert, Freitag 22 Oktober 2010:
Theoretisch JA, ich grübele auch an dem Problem, allerdings noch nichts konkret umgesetzt hier, weil: ich warte noch einen Tick. (jetzt tägliches Sync mit rsync )
Und wie löst Du die Kollision, wenn sich auf beiden Seiten was geändert hat?
Ich werde wohl DRBD dazu verwenden und seit kurzem ist DRBD Kernelbestandteil. gehen täte auch unison condoit laut Literatur (siehe auch Linux-Magazin)
-v bitte, ich nutze unison zwar täglich, aber verstehe nicht genau, was Du sagen willst. Danke! -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Fred Ockert, Freitag 22 Oktober 2010:
Theoretisch JA, ich grübele auch an dem Problem, allerdings noch nichts konkret umgesetzt hier, weil: ich warte noch einen Tick. (jetzt tägliches Sync mit rsync )
Und wie löst Du die Kollision, wenn sich auf beiden Seiten was geändert hat?
Kollisionen werden "per Definition" gelöst, d.h. es ist die Überschreibreihenfolge definiert. DRBD soll Kollisionen weitgehend auflösen können.. bei absolut gleichzeitig musst du eh vorher den Sieger festlegen :)
Ich werde wohl DRBD dazu verwenden und seit kurzem ist DRBD Kernelbestandteil. gehen täte auch unison condoit laut Literatur (siehe auch Linux-Magazin)
-v bitte, ich nutze unison zwar täglich, aber verstehe nicht genau, was Du sagen willst.
dass unison eigentlich auch für solche Sync-Aufgaben da ist, eben mit den bekannten Randbedingungen. Wenn es bei dir schon läuft ist je theoretisch die Frage überflüssig, praktisch stört das Zeitverhalten und andere Einschränkungen (Kollisionsgewinner usw, ). Deswegen beschränke ich mich auf 2 Dtifferenzsync's am Tage , auch wenn der Chef bei fehlender Terminplanung immer alles "schon vor einer Stunde", d.h. eigentlich schon, bevor der Mitarbeiter angefangen hat zu Schreiben, haben will/wollte. (Es gibt ja auch vorauseilenden Gehorsam... warum nicht vorauseilendes Filesync ?) Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Fred Ockert, Freitag 22 Oktober 2010:
Kollisionen werden "per Definition" gelöst, d.h. es ist die Überschreibreihenfolge definiert.
Sowas ist blöd. Ich stelle mir eher vor, daß eine Datei erst dann geöffnet werden kann, wenn sie auf den anderen Servern gelockt ist. Dann wird sie bearbeitet und wieder geschlossen, und erst dann der Lock entfernt. Damit gibts keine Kollisionen. Aber vielleicht ist das ja nur ne Wunschvorstellung, und vielleicht ist es auch nicht vernünftig realisierbar übers WAN... -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag, 22. Oktober 2010 schrieb Andre Tann:
Fred Ockert, Freitag 22 Oktober 2010:
Kollisionen werden "per Definition" gelöst, d.h. es ist die Überschreibreihenfolge definiert.
Sowas ist blöd. Ich stelle mir eher vor, daß eine Datei erst dann geöffnet werden kann, wenn sie auf den anderen Servern gelockt ist. Dann wird sie bearbeitet und wieder geschlossen, und erst dann der Lock entfernt. Damit gibts keine Kollisionen.
Aber vielleicht ist das ja nur ne Wunschvorstellung, und vielleicht ist es auch nicht vernünftig realisierbar übers WAN...
Hi Andre, doch doch, Du denkst schon richtig. Du mußt allerdings auf DRBD (spiegelt die Platten auf Blockebene) ein Filesystem einsetzen, was Cross-Locking (heißt das so?) kann. Etwa OCFS2. Damit kann eine Datei erst 'am anderen Ende' geöffnet werden, wenn sie 'vorne' wieder geschlossen wurde. Bye Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Bernd Nachtigall schrieb:
Am Freitag, 22. Oktober 2010 schrieb Andre Tann:
Fred Ockert, Freitag 22 Oktober 2010:
Kollisionen werden "per Definition" gelöst, d.h. es ist die Überschreibreihenfolge definiert.
Sowas ist blöd. Ich stelle mir eher vor, daß eine Datei erst dann geöffnet werden kann, wenn sie auf den anderen Servern gelockt ist. Dann wird sie bearbeitet und wieder geschlossen, und erst dann der Lock entfernt. Damit gibts keine Kollisionen.
Aber vielleicht ist das ja nur ne Wunschvorstellung, und vielleicht ist es auch nicht vernünftig realisierbar übers WAN...
Hi Andre,
doch doch, Du denkst schon richtig. Du mußt allerdings auf DRBD (spiegelt die Platten auf Blockebene) ein Filesystem einsetzen, was Cross-Locking (heißt das so?) kann. Etwa OCFS2. Damit kann eine Datei erst 'am anderen Ende' geöffnet werden, wenn sie 'vorne' wieder geschlossen wurde.
Bye
Bernd
DRBD ist imho jedoch mit vorsicht zu genießen, ich habe damit in verbindung mit heartbeat keine sehr positiven erfahrungen gemacht... devices waren unvermittelt secondary/secondary oder inconsistent und letzten endes musste man sich wieder für einen master entscheiden. ist es bei DRBD nicht so, dass eine node immer der aktive master/primary sein muss? sprich, es können nicht beide nodes zugleich gemountet und RW sein? grüße Stefan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag, 22. Oktober 2010 schrieb C.M. Burns: (...)
ist es bei DRBD nicht so, dass eine node immer der aktive master/primary sein muss? sprich, es können nicht beide nodes zugleich gemountet und RW sein?
Das ist schon länger her. Inzwischen ist es möglich zwei Primary-Server zu haben. (BTW: DRBD 8.3.9 ist seit gestern final) Heartbeat ist sicher für Cluster notwendig, aber eine einfache Synchronisierung ist m. E. ohne möglich.
grüße Stefan Äh Monti? Stefan? Wer Pseudonyme nutzt muß konsequent sein ;-)
Bye Homer ...ähh, Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Bernd Nachtigall, Samstag 23 Oktober 2010:
Das ist schon länger her. Inzwischen ist es möglich zwei Primary-Server zu haben. (BTW: DRBD 8.3.9 ist seit gestern final) Heartbeat ist sicher für Cluster notwendig, aber eine einfache Synchronisierung ist m. E. ohne möglich.
Habe jetzt auch einiges zu drbd gelesen, insbesondere das hier: http://www.drbd.org/docs/install/ Dort wird empfohlen, einen dedizierten routerfreien Gigabitlink zwischen den Nodes zu verwenden. Nicht nur habe ich keinen Gigabitlink, sondern Bandbreiten zwischen 4 und 8 MBit. Die Links sind nicht dediziert, haben gelegentlich Downtimes, und sind außerdem via VPN realisiert. Ist drbd unter diesen Voraussetzungen sinnvoll nutzbar? -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 23. Oktober 2010 schrieb Andre Tann: (...)
Habe jetzt auch einiges zu drbd gelesen, insbesondere das hier:
http://www.drbd.org/docs/install/
Dort wird empfohlen, einen dedizierten routerfreien Gigabitlink zwischen den Nodes zu verwenden. Nicht nur habe ich keinen Gigabitlink, sondern Bandbreiten zwischen 4 und 8 MBit. Die Links sind nicht dediziert, haben gelegentlich Downtimes, und sind außerdem via VPN realisiert.
Ist drbd unter diesen Voraussetzungen sinnvoll nutzbar?
VPN wird sogar ausdrücklich empfohlen wenn die Daten über eine externe Verbindung gehen. Und Bandbreite ... na gut ... wenn Dein Server mit 1GBit/s ans LAN angeschlossen ist und nur mit 4MBit/s (via WAN) an den anderen Server, dann kannst Du Dir ausrechnen, dass der Abgleich länger als das lokale Schreiben braucht. Die Frage in meinen Augen ist: Wieviel wird auf der gespiegelten Partition geschrieben? Wieviele Blocks pro Sekunde, wie groß ist die Blockgrösse, ... Bye Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Bernd Nachtigall, Freitag 22 Oktober 2010:
doch doch, Du denkst schon richtig. Du mußt allerdings auf DRBD (spiegelt die Platten auf Blockebene) ein Filesystem einsetzen, was Cross-Locking (heißt das so?) kann. Etwa OCFS2. Damit kann eine Datei erst 'am anderen Ende' geöffnet werden, wenn sie 'vorne' wieder geschlossen wurde.
Also ich verstehe das richtig: Erstens, ich setze ein DRBD so auf, daß drei gleichberechtigte und aktive Nodes vorhanden sind. Node1 / \ / \ / \ Node2----Node3 Zweitens, auf dieses Device setze ich ein Cluster-FS drauf, etwa OCFS2. Dieses FS kann ich dann normal mounten, und auf diesem FS liegen dann die Nutzdaten. Darauf greift Samba zu, und merkt nichts von den Vorgängen darunter. Ist derlei eine stabile Konstrunktion? Was ist, wenn eine Node mal ausfällt, oder wenn eine Netzwerkstrecke wackelt? Und vor allem: wie ist denn die Performance? Mein Ziel ist ja, daß das Arbeiten an den Dateien schneller wird. Wenn eine Datei lokal vorhanden ist, aber trotzdem immer auf den Sync auf allen Nodes gewartet werden muß, dann gewinne ich zumindest keine Geschwindigkeit. Ich stelle mir vor, daß lokal bearbeitet und gespeichert wird. Dann bleibt die Datei gelockt, bis sie überall synchronisiert ist, aber davon merkt der Nutzer nichts mehr, es sei denn, er will die Datei gleich wieder aufmachen. Lesetipps? Gegugelt hab ich schon, aber vielleicht hat ja jemand was für mich, was man nicht so leicht findet. Danke! -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Fred Ockert, Freitag 22 Oktober 2010:
Kollisionen werden "per Definition" gelöst, d.h. es ist die Überschreibreihenfolge definiert.
Sowas ist blöd. Ich stelle mir eher vor, daß eine Datei erst dann geöffnet werden kann, wenn sie auf den anderen Servern gelockt ist. Dann wird sie bearbeitet und wieder geschlossen, und erst dann der Lock entfernt. Damit gibts keine Kollisionen.
na ja .. wenn du OpenOffice verwendest, wird beim Öffnen einen #lock-Datei angelegt, alle anderen können dann nur noch lesende Files öffnen. Sicher weiss ich einiges nicht, aber mir fällt auch nix wirklich ein, mit Serverlock. Vielleicht gibt es ja sowas ( ZFS?) - auch mit Overlayfilessystemen kenne ich mich nicht wirklich aus... Deswegen war ich ja vorsichtig auf DRBD aus, dort passiert das nicht als File sondern auf Blockebene, aber eh ich sowas losslassen, wollte ich mir sicher sein, dass ich nicht mehr Probleme schaffe, als ich löse :)
Aber vielleicht ist das ja nur ne Wunschvorstellung, und vielleicht ist es auch nicht vernünftig realisierbar übers WAN...
Na ja .. wenn ich daran denke, dass bei aDSL mehr als 150 kByte/sec eher unrealistisch ist, aber 10..15 MB immer wieder vorkommen (mit tollen eingebtteten Bildern = Logos usw.) dann wird das etwas "fummelig", solange der "Automat" alles sequentiell abarbeitet, Fred ps: vorschläghze werden auch hier garn entgegengenommen .... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Fred Ockert, Montag 25 Oktober 2010:
Na ja .. wenn ich daran denke, dass bei aDSL mehr als 150 kByte/sec eher unrealistisch ist, aber 10..15 MB immer wieder vorkommen (mit tollen eingebtteten Bildern = Logos usw.) dann wird das etwas "fummelig", solange der "Automat" alles sequentiell abarbeitet,
Naja, dann ist die Datei halt ne Weile gelockt, das macht nichts. Hauptsache, man kann wenn dann mit LAN-Geschwindigkeit damit arbeiten. Ich werde eine Kombi aus DRBD und OCFS2 aufsetzen, testen, und dann hier nochmal schreiben. Denn das hört sich gut an. Das AFS wie nebenan vorgeschlagen scheint mir für meine Zwecke nicht geeignet zu sein, das ist zu komplex. Viele Grüße! -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (4)
-
Andre Tann -
Bernd Nachtigall -
C.M. Burns -
Fred Ockert