ZFS Bidirectional Synchronisieren

[Ser1ous1]

Hallo,

da unser Standort erweitert wird (Österreich, und Polen kommt dazu), frage ich mich wie ich unseren derzeitigen ZFS Fileserver für den Standort in Polen Syncen kann?

Fileserver Server AT <-> Fileserver Osten (zvol's mit replika)

Die Leitung wird 100 Mbit haben und die Daten werden vor beginn auf den neuen Server gespielt, bevor er nach Polen kommt.

Es soll so schnell wie möglich gesyncht werden quasi on-time. Gibt es da noch eine andere Lösung als DRBD?

LG

 

[luckysh0t]

Abend,

dazu müsste man erstmal wissen welches OS zum Einsatz kommt.

Gute Anlaufstelle https://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-360.html
Da ich nicht weis wie hier so die Wissenskapazitäten in dem Bereich sind.

Allerdings sollte man sich ggf eher an ein Systemhaus wenden, wenn es um Firmeneinsatz geht.

 

[andy_m4]

Es soll so schnell wie möglich gesyncht werden quasi on-time.

Grundsätzlich gibt es da zwei praktikable Möglichkeiten die mir spontan einfallen.
Einmal auf Dateiebene mit rsync.
Das andere eben via ZFS mit Snapshot + send/receive, wassich dann mit Tools wie zrep auch noch relativ simpel einrichten lässt.

 

[exuser0815]

Um welchen Datenpool handelt es sich?
20.000 Files mit insgesamt 5GB?
50 Millionen Files mit insgesamt 5GB?
20 Files mit insgesamt 100GB?

Wie oft aendern sich Daten?
Aendern sich bestehende Files, oder kommen nur neue hinzu?

 

[snaxilian]

ZFS bietet so ein geo-redundantes Feature leider nicht.
DRBD (zumindest V8) geht bei größerer Last in die Knie wenn parallel die Latenz nicht sehr klein ist und/oder die Anbindung zwischen den Hosts nicht 10G ist. Entweder du machst zwei separate Fileserver und synchronisierst die dann mit rsync oder Windows DFS-R o.ä. oder baust on top einen größeren Cluster. GlusterFS ist POSIX konform und kann das was du suchst. Sprich: 2-n Server mit ZFS > GlusterFS Cluster > Fileserver die Daten den Usern präsentieren je Standort mindestens einer > User.
Kann aber sein, dass GlusterFS mindestens 3 Knoten braucht für ein entsprechendes Quorum. Bei zwei Knoten hast einfach sehr schnell ein Split Brain wenn dein WAN mal down ist... Sowas ist dann aber schon technisch nicht ohne... Müssen beide Standorte denn alle Daten performant haben? Sonst hätte ich gesagt je ein Fileserver pro Standort, User sensibilisieren und je Shares pro Land oder so...

 

[Ser1ous1]

Es geht so etwa in folgende Richtung: 5551044++ Files size: 11.9 TiB

 

[exuser0815]

Also es gibt Leute, die syncronisieren 77TB mit 20 Millionen Files mit Syncthing.
Kann man sich ja mal ansehen, und mit ~1TB testen?

Vor allem ist das viel intelligenter als rsync.

Syncthing handles renaming files and updating their metadata in an efficient manner. This means that renaming a large file will not cause a retransmission of that file. Additionally, appending data to existing large files should be handled efficiently as well.

Inotify wird auch unterstuetzt, wenn man wirklich extrem geringe Wartezeit zwischen resyncs haben will.
Mit Inotify erkennt der Linux Kernel, dass etwas im beobachteten Verzeichnis geaendert wurde, und Syncthing triggert daraufhin einen Resync.

 

[Ser1ous1]

Syncthing klingt gut! Das werde ich mir mal näher ansehen. Danke!