3 Synologys an unterschiedlichen Standorten syncron halten

[insano]

Moin moin,

ich plane einige Daten ( ca. 1400GB) an drei Unternehmensstandorten zur Verfügung zu stellen.

Was ist der einfachste Weg mehrere Stationen auf einem gemeinsamen Stand zu halten?

Ich habe immer gelesen, dass man per Rsync einiges machen kann, jedoch finde ich immer nur Beschreibungen, wie zwei Stationen sich austauschen und nicht drei oder vier.

Ich würde gerne Torrent Sync nicht nutzen, da ich es vermeiden möchte, dass es eventuell mit aktuellen Synology DSM Versionen nicht kompatibel ist.
Ich weiß noch, ob die Cloudstation der richtige Weg ist, da es Veeam Backup Daten geben wird, die ca. 350 GB groß sind.

Ich wäre sehr für eure Hilfe dankbar.

 

[dil88]

Die erste Frage ist, ob Du einen Master definieren kannst und die Daten der anderen Standorte nachgezogen werden können - oder ob Daten an allen Standorten eingespielt und bearbeitet werden, wir also keine Slaves haben?

 

[insano]

Es wird keinen Master geben, da auch Personen am Standort B und C etwas ändern können sollen.

Gibt es eine solche Option, die den Sync in Beide Richtungen ermöglicht?

 

[stefan_lx]

Bittorrent sync hat den Nachteil, dass Berechtgungen verloren gehen und die Dateien dem Benutzer btsync gehören. Ausserdem dauert es recht lange, bis Dateiänderungen "bemerkt" werden.
Für die CS in Verbindung mit dem CS Client muss es zwangsweise einen Master geben, der die CS hält. Die anderen bekommen nur den CS Client. Beim Synchronisieren der gemeinsamen Ordner kannst du auch Besitz und Berechtigungen mitnehmen. Allerdings müssen dann die Benutzer auf allen synos identisch sein. D.h. wenn es lokale Accounts sind, müssen die uids der jeweiligen Benutzer identisch sein....
Grosse Dateien würde ich nicht in die CS stecken, dein veam-Backup würde schon mal gleich 700GB auf dem Master verbrauchen.... dein Gesamtverbrauch wäre auch mal gleich auf dem Master bei 2800GB...

Für "kleine" Dateien, wie Officedateien, könnte das aber ganz gut funktionieren...

Stefan

 

[Micha81]

Moin moin,

Ich habe immer gelesen, dass man per Rsync einiges machen kann, jedoch finde ich immer nur Beschreibungen, wie zwei Stationen sich austauschen und nicht drei oder vier.

Selbstverständlich lässt sich das per rsync realisieren. Nur nicht im Sinne einer Echtzeit-Replikation. Du würdest auf den Maschinen unterschiedliche Skripte zur Verfügung stellen. Ich würde nur aufpassen dass ich die Ausführung der Skripte zeitlich nicht überschneidet.

 

[dil88]

Ich hätte auch rsync vorgeschlagen, aber auch dabei gibt es normalerweise ein Master-Slave Verhältnis, wenn ich mich nicht irre.

 

[stefan_lx]

genau da ist der Knackpunkt: der rsync transportiert die Daten nur in eine Richtung, also vom "Master" zum "Slave"...
ohne eine "Datenbank" (die rsync nicht hat), in der erkennbar ist, welcher Teilnehmer welchen Datenstand hat, dürfte das Vorhaben von Insano

da auch Personen am Standort B und C etwas ändern können sollen.

knifflig werden...

Hm, man könnte rsync das Überschreiben von neueren Dateien verbieten (--update), aber dann muss man der Reihe nach und zeitgesteuert ein rsync-Skript auf den drei synos laufen lassen, das immer die aktuellsten Dateien auf die anderen beiden synos rsynct... das führt evtl. zum Problem, wenn eine Datei auf zwei synos geändert wurde ... andererseits, wird die letzte Version gewinnen ... und am Schluss müssten alle den gleichen Stand haben...

Stefan

 

[insano]

Es ist doch schwieriger als gedacht. Eventuell muss ich das doch etwas anders umsetzen, wenn es keine bidirektionalen Möglichkeiten gibt. Eventuell muss ich dafür sorgen, dass Standort A der Master wird und die Stationen bei B und C nur als lokalen Cache genutzt werden. Somit würden die Daten aus den Standorten B und C immer auf dem Laufwerk im Standort A abgelegt und anschließet an die anderen Standorte verteilt.

Das Veeam Backup wird als extra Datensicherungsjob eingerichtet, der eine komplette LUN mit einem anderen Standort abgleicht um bei einem Feuer geschützt zu sein.

Ich hätte wirklich gehofft, dass diese Variante einfacher umgesetzt werden könnte :-(

Gruß
Lars

 

[dil88]

Wenn Du das Veeam Backup separat sicherst, könnte die CloudStation doch wieder der richtige Ansatz sein. Du solltest dafür dann nur ordentlich Plattenplatz vorsehen, dann ist das dank der Versionierung durchaus interessant. Wenn allerdings an zwei Orten die gleiche Datei bearbeitet wird, kommt es auch hier zu Konflikten. Aber wie soll das auch vermieden werden bei verteilten Daten?

 

[insano]

Ich werde mir das mit der Cloud Station noch mal überlegen, wenn ich dabei die Active Directory Besitzrechte behalten kann.
Ich habe die CS nur zwischen Clients getestet, jedoch nicht unter einzelnen Stationen.

Die CS hat im privaten Umfeld leider sehr häufig Konflikte verursacht, auch wenn nur ein User auf die Daten zugegriffen hat.

Laut Aussage der Mitarbeiter passiert ein gemeinsamer Zugriff nur ca. 1 mal im Jahr, da an komplett unterschiedlichen Dateien gearbeitet wird. Dies war auch meine erste Befürchtung.

 

[dil88]

In dem Fall wäre es aber vielleicht doch möglich, für die jeweiligen Arbeitsbereiche Master-Slave-Beziehungen zu definieren und in der entsprechenden Richtung rsync-Jobs aufzusetzen.

 

[iLion]

Warte bis zur Final vom DSM 5.1. Im dortigen CloudStation Paket soll man die Anzahl der Versionen auf 0 setzen können. Dann sind auch die 350 GB Sicherungen kein Problem mehr.

 

[benoga]

Könnte man es eventuell auch mit VPN lösen? An einem Standort den Server und die anderen 2 Standorte mit VPN dazu verbinden. Dann würden aber alle Daten übers VPN laufen, zum ersten Standort. Die Kosten/Unterhalt der Serverkomponenten an 2 Standorten würden wegfallen, dafür eventuell die Bandbreiten vom Provider erhöhen.

Vielleicht ist dass ja noch eine Idee anstatt ein rsync gewurstel

 

[insano]

Leider wird dies nicht so lange warten können

Die Veeam Sicherungen werden als LUN Sicherung laufen, somit wird es mit den Versionen keine Schwierigkeiten geben.

 

[insano]

Könnte man es eventuell auch mit VPN lösen? An einem Standort den Server und die anderen 2 Standorte mit VPN dazu verbinden. Dann würden aber alle Daten übers VPN laufen, zum ersten Standort. Die Kosten/Unterhalt der Serverkomponenten an 2 Standorten würden wegfallen, dafür eventuell die Bandbreiten vom Provider erhöhen.

Vielleicht ist dass ja noch eine Idee anstatt ein rsync gewurstel

Dort ist es momentan so gelöst, dass alle Standorte auf den Server A zugreifen. Ziel der Änderung ist, dass es für die Mitarbeiter an den Außenstandorten ermöglicht werden soll, Dateien schneller zu öffnen.

 

[Micha81]

In dem Fall wäre es aber vielleicht doch möglich, für die jeweiligen Arbeitsbereiche Master-Slave-Beziehungen zu definieren und in der entsprechenden Richtung rsync-Jobs aufzusetzen.

Das ist definitiv möglich. Es muss nur darauf geachtet werden dass die Skripte auf den unterschiedlichen Servern zeitlich versetzt ablaufen. Der Master ist immer die Maschine auf dem ein rsync Skript ausgeführt wird. Allerdings kann es passieren dass die Server nicht 100% synchron sind. Das hängt davon ab wie viele Änderungen pro Zeiteinheit gemacht werden. Beispiel. Auf Server1 wird Datei1 von Benutzer1 geändert. Kurze Zeit später wird Datei1 von Benutzer2 auf Server2 ebenfalls geändert. Nach Abarbeitung aller Skripte wird das dann dazu führen dass die Änderungen von Benutzer1 auf Server1 verloren gehen. Das ist ein Grenzbereich der sich mit dieser asynchronen Methode nicht vermeiden lässt. Wie sich das in der Praxis darstellt hängt von den rsync Zeitintervallen sowie der Häufigkeit der Änderungen ab. Da für 3 Server insgesamt 6 Skripte benötigt werden, dürften ein paar Stunden vergehen bis ein kompletter Durchlauf abgearbeitet ist.

Ich würde das einfach mal mit einem Testverzeichnis durchspielen.

 

[stefan_lx]

das mit der Laufzeit ist ein Problem, weil der rsync alle(!) Dateien vergleichen muss, bevor irgendwas über die Leitung wandert....

Aber das größere Problem sind gelöschte oder nicht vorhandene Dateien...

Wenn auf Server1 neue Dateien dazukommen ist das kein Problem, die werden rübersynchronisiert.
Wenn ich aber Dateien lösche, also Dateien auf Server1 nicht mehr vorhanden sind, dann müssen die auf Server2 auch gelöscht werden. Aber woher weiß man, ob diese Dateien auf Server2 nicht gerade frisch angelegt wurden und dann auf Server1 rüber müssen, der sie aber jetzt erfolgreich löschen wird, weil er sie ja nicht kennt??
Wenn man den rsync so konfiguriert, dass am Ziel nichts gelöscht wird, führt das wiederum dazu, dass die Dateien gar nicht mehr gelöscht werden und z.B. verschobene Verzeichnisbäume doppelt vorhanden sind...

Stefan

 

[dil88]

Es geht eben nur, wenn es für den Arbeits-/Verzeichnisbereich einen klaren Master gibt. Es darf eben nicht etwas auf dem Master gelöscht und auf dem Slave gerade angelegt werden. Wenn sich die Bereiche so sauber trennen lassen, dann sollte auch eine Synchronisierung in größeren Abständen möglich sein.

 

[Micha81]

Das Problem ist, dass man nicht in jedem Fall vorhersagen kann was passieren wird. Im obigen Beispiel hängt es allein davon ab, wann die Datei gelöscht wurde und welches Script auf welchem Server gerade läuft. Es kann also sein dass die Datei einfach von einem anderen Server wiederhergestellt wird oder aber auf den anderen Servern auch gelöscht wird. Das hängt alles vom Zeitplan und der Reihenfolge der Skriptausführung ab. Dieses Verfahren ist definitiv keine 100 Prozent Lösung wird aber in den allermeisten Fällen zufriedenstellend funktionieren. Zumindest solange keine 100 Prozent Lösung benötigt wird. Dann hilft sowieso nur Echtzeit Replikation.

 

[dil88]

Ja, das ist natürlich alles völlig richtig. Aber wenn man von einer typischen Laufzeit von 15-30min. ausgeht und die Skript im worst case einmal am Tag laufen lassen würde, kriegt man dieses Dilemma eigentlich ganz gut unter Kontrolle. Zudem kann man die Ausführung der einzelnen Skripte über lock-Dateien oder ähnliches exklusiv gestalten.