Daten sync'en effektiv?

F

fred123

Well-Known Member
Hallo,
Mir ist nicht klar was besser/schneller/sicherer....... ist.
Eure Meinung, Erfahrung könnte mir weiter helfen.
.
Ausgangslage: 2 Server.
Arbeits-Server: 6 Kerne/32GB Speicher,
Backup-Server: 2 Kerne/8GB Speicher,
jeweils 2 Netzkarten 1000baseT full-duplex,
Die Server nutzen zum Backup Direktlink ohne Switch.
.
Identische Plattensätze, ca 8TB/Raidz1. rsync, NFS, ZFS send/rec in beiden Richtungen möglich.
Dateisysteme "kreuzweise" mount_nfs auf beiden Machinen
.
Der Datensatz (momentan 5 TB, ist schon gespiegelt) ) besteht zu 2/3 aus Dateinen > 500MB, der Rest ist Kleinzeug, Backup der Clienten, owncloud, usw. .
.
Die Last ist moderat, Beide Kisten "ideln" 70-80% des Tages vor sich hin. Interne Nutzung, bis zu 10 Clienten, keine ausgeprägten Lastspitzen.
.
Frage: Wer sollte MASTER beim "sync'en" sein, den Prozess anstossen, bzw. auf welchen Maschine sollte rsyc, ZFS send/recv.... ausgeführt werden?
.
Ich habe mehrfach "hin und her" getestet, bin aber zu keinem überzeugendem Ergebniss gekommen!
.
Gruss
Fred
.
Ps. Ja es gibt die "Wochensicherung" im Schrank und eine "dezentrale" Sicherungs-Kopie:-))
 
KobRheTilla schrieb:
Was war denn an deinem Ergebnis nicht überzeugend?

Rob
Zum Vergrößern anklicken....
Läuft in beiden Richtungen. Bei rsync z.B wenn die kleine Maschine Master macht, mit 50-60% Last, auf der grossen mit 10-20%. Tempo ist fast gleich, aber..... was ist die bessere Lösung? Das gleich bei ZFS send/recv....... Zeiten sind nur sehr aufwendig zu vergleichen. Hängen zu sehr von den übetragenen Dateien, der Hardware, ab........ usw.
.
Ist es effektiver NFS und dann ZFS send local zu machen, oder zfs <ferne Maschine>?
.
Da solche Prozesse meist ohne grosse Beobachtung laufen sollten, ich aber nicht erst aus EIGENEN Fehlern klug werden will:-) wären vielleicht Erfahrungen, Pech,Pleiten und Pannen ANDERER ganz brauchbar:-)) Ich schaufele zum ersten Mal mit so grossen Datensätzen rum.... Bis vor kurzer Zeit lagen die auf verschiedenen Machinen mit einzelnen externen Backups rum :-))
.
Das ist der Grund dieser Anfrage. Gehen gehts, aber was ist die optimale, bzw. bessere Lösung?
.
Gruss
Fred
.
Ps. Vielleicht siehst du das ja als akademische Frage, läuft ja, aber ich möchte da ein wenig über meinen Tellerrand hinaus sehen.
 
Ich würde auf der produktiven Maschine die Angriffsfläche so klein wie möglich halten. Soll heißen: kein NFS, rsync vom Backup-System aus via SSH.

Rob
 
Mag an mir liegen. Vielleicht bin ich zu altmodisch oder überbewerte "schlicht und einfach" als Qualitätsmerkmal, aber: Beidseitig NFS, noch irgendwas von ZFS plus noch rsync? Das klingt für mich nach "beidarmig von hinten durch die Brust ins Auge" unnötig kompliziert, resourcen verschwendend und aufwendig.

Meine Sicht dazu:
NFS vermeiden, wo immer möglich (ausser für seinen eigentlichen Existenzgrund, nämlich diversen Clients file system level Zugriff auf zentrale Verzeichnisse zu geben) . Für die Datenübertragung bzw. "rohes Backup" rsync. Und fertich. Vielleicht noch ne komfortablere Edelvariante wie rsync-backup, aber mehr auch nicht.
 
Es müssen beide Seiten Zugriff auf die Daten haben, oder? Ansonsten könntest man auch über HAST nachdenken.
 
Ich habe das eher als relativ hochfrequente Backup Situation verstanden mit vermutlich gewünschtem sehr schnellen restore im Falle des Falles.

Insoweit es wirklich um echtes Sync geht, sind die Angaben dürr bis unbrauchbar.

Möglichst real-time? <= 1s delay ist akzeptabel? "Nu je so alle 5 min. oder so ist OK"? Oder was?

Was ist die Quelle, woher kommen neue oder geänderte Dateien? Usw ...
 
Yamagi schrieb:
Es müssen beide Seiten Zugriff auf die Daten haben, oder? Ansonsten könntest man auch über HAST nachdenken.
Zum Vergrößern anklicken....
Sicher, aber nicht über die "Backup Verbindung". Die läuft auf einer eigenen Karte, in anderem. 2. getrenntem Netz und Direktlink. Die Clients haben nur über das Arbeitsnetz Zugriff auf den Arbeitsserver. Im Problemfall springt der Backupserver ein. (Sollte er wenigstens, tut er auch bei Tests:-))
.
Hast scheint der Richtige Tip zu sein.
.
@ rmoe: Du hängst das zu hoch. Das ist eine kleine Kiste mit sehr moderater Belastung, Nur der Hütehund ist manchmal weg und dann soll das wohl weiter laufen bis der per Fernwartung ...... :-))
.
Danke Yamagi, <hast> scheint das zu sein was ich gesucht habe:-))
.
Gruss
Fred
 
rmoe schrieb:
Mag an mir liegen. Vielleicht bin ich zu altmodisch oder überbewerte "schlicht und einfach" als Qualitätsmerkmal, aber: Beidseitig NFS, noch irgendwas von ZFS plus noch rsync? Das klingt für mich nach "beidarmig von hinten durch die Brust ins Auge" unnötig kompliziert, resourcen verschwendend und aufwendig.

Meine Sicht dazu:
NFS vermeiden, wo immer möglich (ausser für seinen eigentlichen Existenzgrund, nämlich diversen Clients file system level Zugriff auf zentrale Verzeichnisse zu geben) . Für die Datenübertragung bzw. "rohes Backup" rsync. Und fertich. Vielleicht noch ne komfortablere Edelvariante wie rsync-backup, aber mehr auch nicht.
Zum Vergrößern anklicken....

Das waren die MÖGLICHKEITEN, nicht der Wirkbetrieb:-) Darum ja meine Frage, WAS ist Besser ....... Gehen geht alles, aber ich SUCHTE eine einfache egffektive sichere Lösung. Habe mich wohl etwas ungenau, oder wie du sagst zu knapp ausgedrückt.
.
Dabei wollte ich Euch nur nicht mit einem Roman langweilen:-))
.
Wie mann/Fraus macht macht mans verkehrt :-)
.
Danke für die Hilfe
.
Fred
.
Ps. Hilft man der Dame in den Mantel ist Mann ein verspiester Schowi, lässt Mann es, ein Prolet! Frauen und Foren, werde ICH nie vetsehen :-))
 
HAST ist schon eine gute Lösung. Allerdings solltest du vorher:
  • Einmal auf dem kompletten HAST-Setup die Performance testen. Gerade Schreiboperationen werden durch die Netzwerklatenz doch schon recht deutlich verlangsamt. Wobei es seit Einführung des "memsync"-Mode in FreeBSD 9.2 zum Preis einer geringfügig verschlechterten Konsistenzgarantie deutlich besser geworden ist.
  • Den kompletten Failover mehrmals trocken durchspielen. HAST hat inzwischen zwar einiges an Logik um Splitbrains und teilweises Selbstüberschreiben zu verhindern, dennoch ist es gut, wenn man es nicht um 3 Uhr Nachts zum ersten Mal machen muss. :)
 
Yamagi schrieb:
HAST ist schon eine gute Lösung. Allerdings solltest du vorher:
  • Einmal auf dem kompletten HAST-Setup die Performance testen. Gerade Schreiboperationen werden durch die Netzwerklatenz doch schon recht deutlich verlangsamt. Wobei es seit Einführung des "memsync"-Mode in FreeBSD 9.2 zum Preis einer geringfügig verschlechterten Konsistenzgarantie deutlich besser geworden ist.
  • Den kompletten Failover mehrmals trocken durchspielen. HAST hat inzwischen zwar einiges an Logik um Splitbrains und teilweises Selbstüberschreiben zu verhindern, dennoch ist es gut, wenn man es nicht um 3 Uhr Nachts zum ersten Mal machen muss. :)
Zum Vergrößern anklicken....
Ich habe die Seite erst nur mal überflogen. Rsync u.a. läuft ja prinzipiell. Hast scheint aber das zu sein ,was ich gesucht habe. Werde das mal mit RUHE, am TAGE, ausgeruht :-)) testen und wenn ich zu Ergebnissen gekommen bin, auch was hier posten.
.
Danke noch mal
Fred
.
Ps. Prefomancetest sind immer schwierig. Da kommen bei mir immer nach Dateigrößen, Hardwarelast... und Wetterlage:-) selbst bei einem festen Datensetup die unterschiedlichsten Ergebnisse raus. Drauf Promovieren will ich im Grunde nicht :-)) Ne einfache, elegante, sichere Lösung ist das Ziel:-))
 
So, dann stelle mer uns emol dumm unn frage hald "was issn des füre Dampfmaschin?":

Kiste 1 = "der server". Nur file server? Oder auch Applikationsserver (dhcpd, ftp, FiBu, ...)?
Kiste 2 = "fallback" oder "failover" server, soll also Aufgaben von Kiste 1 übernehmen, wenn die nicht funktioniert, gewartet wird, etc. ?

Beide, Kiste 1 und Kiste 2 hängen via Gb Ethernet annem switch (für die Clients) und beide hängen via 2. Gb Ethernet direkt aneinander?

*Wenn* ich das so richtig kapiert habe, dann hast du 2 Themen.

- Daten gesynct halten.
- Failover (Kiste 2 springt für Kiste 1 ein).

Yamagi hat schon Recht. *Wenn* das so ungefähr deine Situation ist, dann sieht Hast+Carp nach einer professionellen, schicken Lösung aus.

Ich erlaube mir trotzdem in paar Gedanken dazu zu äussern, bzw. dir nahezulegen.

Deine Daten *sind bereits gesichert* (weil gespiegelt).
Bei solchen Kisten wird gerne einiges in einen Topf geschmissen. Aber 1 von drei Themen hast du wie gesagt schon erledigt, nämlich die Sicherheit der Daten (ich gehe natürlich davon aus, dass du auch eine Backup Lösung hast).

Bleiben also noch die anderen beiden. Und für die gibt es unterschiedliche Ansätze und wie immer gibt es nicht "die Lösung" (für alles).

Hast/Carp sind meinem Empfinden nach im wesentlichen aus 2 Antrieben entstanden: a) Linux hat sowas, also brauchen wir das auch und erst recht, b) Sowas braucht man einfach (in bestimmten Situationen, z.B Rechenzentren).
*Wenn* deine Daten sich potentiell 100 oder 1000 mal/Sekunde verändern können und *wenn* deine Anwender jede einzelne Sekunde 24/7/365 Zugriff auf diese Daten brauchen oder aber schreckliche Dinge passieren ... dann OK.

Ausserdem gehört dazu noch mehr, z.B. redundante switche, sonst hast du den Knackpunkt nämlich nur verschoben. Und redundante dhcp und inside dns server. Und ...

Vermutlich wirst du einfach Hast+Carp machen. Ist auch schick, keine Frage. ich rate dennoch dazu, zumindest *auch* eine saubere Analyse zu machen. Was genau brauche ich? Was sind die Zeitfaktoren? Was die Risiken? Wo könnte es klemmen (z.B. Ausfall des zentralen switches). Wie schnell, wie dringend wird was gebraucht? Usw.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben