Datenreplikation unabhängige Domänen
Hallo zusammen,
kann mir jemand ein Programm empfehlen, das sich so ähnlich verhält wie die DFS-Replikation von Windows, blos zwischen verschiedenen Domänen? Ich habe die beiden Domänen komplett eingerichtet und zu dem Zeitpunkt nicht gewusst, dass DFSR nur innerhalb der gleichen Domäne funktioniert.
Gegeben sind zwei unabhängige Domänen (und die sollen auch unabhängig voneinander sein) mit jeweils einem Fileserver, basierend auf Windows Server 2019 Datacenter. Die Standorte sind per Site2Site miteinander vebunden.
Ich wünsche mir nun ein Synchronisierungs-Tool, dass stabil als Service läuft und die Freigaben der Server vergleicht und bi-direktional synchronisiert. Ändert sich am Standort 1 etwas, soll das auf den Standort 2 synchronisiert werden und umgekehrt. Damit das schneller geht, wäre das auf Blockebene natürlich am schönsten.
Hat jemand schon Erfahrungen damit sammeln können?
https://www.andysblog.de/windows-mirrorfolder-ordner-in-echtzeit-und-auf ...
Die Software muss natürlich nicht kostenlos sein, aber sollte auch nicht exorbitant teuer sein. In der Umgebung wird eine Domäne als "Hauptdomäne" geführt, die im Normalfall in Betrieb ist und die zweite Domäne ist eine "Fallback-Domäne", die im Notfall genutzt wird oder wenn es ein geplantes Wartungsfenster in der Hauptdomäne gibt.
Kann mir jemand helfen?
Vielen Dank!
MfG
kann mir jemand ein Programm empfehlen, das sich so ähnlich verhält wie die DFS-Replikation von Windows, blos zwischen verschiedenen Domänen? Ich habe die beiden Domänen komplett eingerichtet und zu dem Zeitpunkt nicht gewusst, dass DFSR nur innerhalb der gleichen Domäne funktioniert.
Gegeben sind zwei unabhängige Domänen (und die sollen auch unabhängig voneinander sein) mit jeweils einem Fileserver, basierend auf Windows Server 2019 Datacenter. Die Standorte sind per Site2Site miteinander vebunden.
Ich wünsche mir nun ein Synchronisierungs-Tool, dass stabil als Service läuft und die Freigaben der Server vergleicht und bi-direktional synchronisiert. Ändert sich am Standort 1 etwas, soll das auf den Standort 2 synchronisiert werden und umgekehrt. Damit das schneller geht, wäre das auf Blockebene natürlich am schönsten.
Hat jemand schon Erfahrungen damit sammeln können?
https://www.andysblog.de/windows-mirrorfolder-ordner-in-echtzeit-und-auf ...
Die Software muss natürlich nicht kostenlos sein, aber sollte auch nicht exorbitant teuer sein. In der Umgebung wird eine Domäne als "Hauptdomäne" geführt, die im Normalfall in Betrieb ist und die zweite Domäne ist eine "Fallback-Domäne", die im Notfall genutzt wird oder wenn es ein geplantes Wartungsfenster in der Hauptdomäne gibt.
Kann mir jemand helfen?
Vielen Dank!
MfG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1429608883
Url: https://administrator.de/forum/datenreplikation-unabhaengige-domaenen-1429608883.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
ch wünsche mir nun ein Synchronisierungs-Tool, dass stabil als Service läuft und die Freigaben der Server vergleicht und bi-direktional synchronisiert. Ändert sich am Standort 1 etwas, soll das auf den Standort 2 synchronisiert werden und umgekehrt.
Was soll geschehen, wenn eine Datei zu selben Zeit an beiden Standorten bearbeitet wird bzw. wurde?In der Umgebung wird eine Domäne als "Hauptdomäne" geführt, die im Normalfall in Betrieb ist und die zweite Domäne ist eine "Fallback-Domäne", die im Notfall genutzt wird oder wenn es ein geplantes Wartungsfenster in der Hauptdomäne gibt.
Sorgt erst einmal für Overhead im laufenden Betrieb. Zudem muss alles immer doppelt konfiguriert werden. Ein Wartungsfenster an der "Hauptdomäne" ist heutzutage kein Grund mehr. Man kann alle notwendigen Dienste n+1 redundant auslegen. Weshalb tut man sich zwei Domänenstrukturen an?Gruß,
Dani
Moin,
Kannst Du mir mal bitte erklären, was der Unsinn soll? Ich verstehe das doch richtig, dass Ihr zwei Domains habt, die noch nicht einmal in derselben Gesamtstruktur sind - denn sonst ginge DFS-R ja - damit Ihr ein Fall Back habt für Wartungen an der eigentlichen Domain? Entschuldigung, aber das ist vollkommen unnötig. Sobald ich die Domain redundant auslege, kann ich Wartungsarbeiten machen, wie ich gerade Lust und Zeit habe, ohne dass das irgend jemand merkt. Da fällt nichts aus, wenn man es richtig macht. Und selbst wenn man nur einen DC hat, beschränkt sich die reguläre Ausfallzeit auf den monatlichen Neustart wegen der blöden Updateritis. Aber Ihr habt ja schon mindestens zwei. Nur nicht in derselben Domain. Ein grober Designfehler.
Liebe Grüße
Erik
Zitat von @support-it:
Die Software muss natürlich nicht kostenlos sein, aber sollte auch nicht exorbitant teuer sein. In der Umgebung wird eine Domäne als "Hauptdomäne" geführt, die im Normalfall in Betrieb ist und die zweite Domäne ist eine "Fallback-Domäne", die im Notfall genutzt wird oder wenn es ein geplantes Wartungsfenster in der Hauptdomäne gibt.
Kannst Du mir mal bitte erklären, was der Unsinn soll? Ich verstehe das doch richtig, dass Ihr zwei Domains habt, die noch nicht einmal in derselben Gesamtstruktur sind - denn sonst ginge DFS-R ja - damit Ihr ein Fall Back habt für Wartungen an der eigentlichen Domain? Entschuldigung, aber das ist vollkommen unnötig. Sobald ich die Domain redundant auslege, kann ich Wartungsarbeiten machen, wie ich gerade Lust und Zeit habe, ohne dass das irgend jemand merkt. Da fällt nichts aus, wenn man es richtig macht. Und selbst wenn man nur einen DC hat, beschränkt sich die reguläre Ausfallzeit auf den monatlichen Neustart wegen der blöden Updateritis. Aber Ihr habt ja schon mindestens zwei. Nur nicht in derselben Domain. Ein grober Designfehler.
Liebe Grüße
Erik
moin..
sagt er oben doch...
😹
frank
Zitat von @erikro:
Kannst Du mir mal bitte erklären, was der Unsinn soll? Ich verstehe das doch richtig, dass Ihr zwei Domains habt, die noch nicht einmal in derselben Gesamtstruktur sind -
Kannst Du mir mal bitte erklären, was der Unsinn soll? Ich verstehe das doch richtig, dass Ihr zwei Domains habt, die noch nicht einmal in derselben Gesamtstruktur sind -
sagt er oben doch...
Ich habe die beiden Domänen komplett eingerichtet und zu dem Zeitpunkt nicht gewusst, dass DFSR nur innerhalb der gleichen Domäne funktioniert.
😹
frank
Zitat von @Vision2015:
moin..
sagt er oben doch...
😹
moin..
Zitat von @erikro:
Kannst Du mir mal bitte erklären, was der Unsinn soll? Ich verstehe das doch richtig, dass Ihr zwei Domains habt, die noch nicht einmal in derselben Gesamtstruktur sind -
Kannst Du mir mal bitte erklären, was der Unsinn soll? Ich verstehe das doch richtig, dass Ihr zwei Domains habt, die noch nicht einmal in derselben Gesamtstruktur sind -
sagt er oben doch...
Ich habe die beiden Domänen komplett eingerichtet und zu dem Zeitpunkt nicht gewusst, dass DFSR nur innerhalb der gleichen Domäne funktioniert.
😹
Naja, das ist offensichtlich nicht das Einzige, was er nicht wusste. Deshalb mein Tipp:
https://openbook.rheinwerk-verlag.de/windows_server_2012r2/
Lesen und verstehen. Die ersten zwei Hauptkapitel darf der TO auslassen. Ansonsten ist das m. E. immer noch die beste Einstiegslektüre, wenn es um Windows-Server geht, auf Deutsch. Schade, dass das nicht weitergeführt wurde. Klar, ein wenig veraltet, aber das Prinzip ist einfach gut erklärt.
N'Abend.
War auch mein erster Gedanke....
Anyway, back2topic:
Das Problem sind gleichzeitige Änderungen auf beiden Seiten. Mir ist kein Tool bekannt, dass diese wirklich zuverlässig erkennen kann über Domain-Grenzen hinweg. Aber warum eigentlich bi-direktional?
Wenn normalerweise nur in Domain A gearbeitet wird, können auch nur dort Änderungen entstehen. Wenn du dann A offline nimmst, entstehen nur Änderungen an B. Somit würde jeweils ein One-Way-Sync ausreichen und der wäre schon mit robocopy zu erledigen.
Cheers,
jsysde
War auch mein erster Gedanke....
Anyway, back2topic:
Das Problem sind gleichzeitige Änderungen auf beiden Seiten. Mir ist kein Tool bekannt, dass diese wirklich zuverlässig erkennen kann über Domain-Grenzen hinweg. Aber warum eigentlich bi-direktional?
Wenn normalerweise nur in Domain A gearbeitet wird, können auch nur dort Änderungen entstehen. Wenn du dann A offline nimmst, entstehen nur Änderungen an B. Somit würde jeweils ein One-Way-Sync ausreichen und der wäre schon mit robocopy zu erledigen.
Cheers,
jsysde
Ich frage mich gerade, wie ein Fallback passieren soll, wenn die Hauptdomain offline wäre. Die Clients können nur "einer" Domain gehören. Will man im Fallbackfall anfangen alle Clients aus der Domain raus nehmen und in die zweite Domain rein stecken? Der Benutzer bekommt dann auch noch ein neues Profil. No Go.
Ich würde bei einer Hauptdomain bleiben und an beiden Standorten jeweils einen Domain Controller betreiben, die zusammen in dieser Hauptdomäne sind. Sie replizieren sich automatisch. Sollte einer ausfallen, greift der Standort automatisch auf den Domain Controller des zweiten Standortes zu.
In Zeiten der Virtualisierung habe ich an fast jedem Standort einen Domain Controller, in der Hauptniederlassung einfach mal zwei - ohne Grund. Braucht genau 1.5GB RAM pro VM. Und alle sind in einer einzigen Domain. Niemand merkt was, egal, welchen Domain Controller ich herunter fahre.
Ich würde bei einer Hauptdomain bleiben und an beiden Standorten jeweils einen Domain Controller betreiben, die zusammen in dieser Hauptdomäne sind. Sie replizieren sich automatisch. Sollte einer ausfallen, greift der Standort automatisch auf den Domain Controller des zweiten Standortes zu.
In Zeiten der Virtualisierung habe ich an fast jedem Standort einen Domain Controller, in der Hauptniederlassung einfach mal zwei - ohne Grund. Braucht genau 1.5GB RAM pro VM. Und alle sind in einer einzigen Domain. Niemand merkt was, egal, welchen Domain Controller ich herunter fahre.
Moin,
Nein. Beim DFS wird die Datei systemweit gelockt. Also kann das nicht passieren.
Und? Umso schlimmer ist der Designfehler. Unsere Notrufzentrale ist georedundant aufgebaut mit Servern in verschiedenen RZs in ganz Deutschland. In einer Domain. So und nur so kann ein unterbrechungsfreier Betrieb gewährleistet werden. Dabei ist es dann auch gar kein Problem, weitere Standorte oder RZs einzubinden. Was Ihr da macht ist Murks und noch viel schlimmer, Murks, der Leben gefährdet. Wer schaltet denn z. B. nachts um drei, wenn eine Hütte abbrennt, auf die andere Domain um, sorgt dafür, dass die TK über die anderen Leitungen läuft usw. usf. Sowas automatisiert man und macht nicht so einen Unsinn. Ganz ehrlich. Und wenn ich dann auch noch lese "Der Kunde" werde ich an der Stelle ausnahmsweise mal richtig grantig. Sowas muss man können und Ihr könnt es offensichtlich nicht. Ihr gebt ein Ereichbarkeitsversprechen und könnt es offensichtlich nicht einhalten, scheitert Ihr doch schon an so einem simplen Design, stellt hinterher fest, dass es nicht funktioniert und baut Workarounds, um Euer falsches Design zu verbergen.
Ja, seid ehrlich zum Kunden und sagt, dass Ihr Euch übernommen habt. Ich vermittele gerne einen DL, der auf sowas spezialisiert ist und es richtig macht.
Nicht ganz so liebe Grüße
Erik
Zitat von @support-it:
Hallo, zusammen,
danke für eure Antworten.
@Dani:
Dass zur selben Zeit an der gleichen Datei was verändert wird sollte eigentlich nicht passieren. Dafür gibt es aber auch keine wirklich Lösung oder? Auch mit DFSR würde eine der Dateien einfach weggeschmissen werden.
Hallo, zusammen,
danke für eure Antworten.
@Dani:
Dass zur selben Zeit an der gleichen Datei was verändert wird sollte eigentlich nicht passieren. Dafür gibt es aber auch keine wirklich Lösung oder? Auch mit DFSR würde eine der Dateien einfach weggeschmissen werden.
Nein. Beim DFS wird die Datei systemweit gelockt. Also kann das nicht passieren.
Bezüglich "Designfehler":
Der Grund ist im Prinzip ganz simpel. Der Kunde ist ein Notrufdienst, der seine IT (die dort durchaus bereits redundant aufgezogen ist) in einem Rechenzentrum neu aufzieht.
Der Grund ist im Prinzip ganz simpel. Der Kunde ist ein Notrufdienst, der seine IT (die dort durchaus bereits redundant aufgezogen ist) in einem Rechenzentrum neu aufzieht.
Und? Umso schlimmer ist der Designfehler. Unsere Notrufzentrale ist georedundant aufgebaut mit Servern in verschiedenen RZs in ganz Deutschland. In einer Domain. So und nur so kann ein unterbrechungsfreier Betrieb gewährleistet werden. Dabei ist es dann auch gar kein Problem, weitere Standorte oder RZs einzubinden. Was Ihr da macht ist Murks und noch viel schlimmer, Murks, der Leben gefährdet. Wer schaltet denn z. B. nachts um drei, wenn eine Hütte abbrennt, auf die andere Domain um, sorgt dafür, dass die TK über die anderen Leitungen läuft usw. usf. Sowas automatisiert man und macht nicht so einen Unsinn. Ganz ehrlich. Und wenn ich dann auch noch lese "Der Kunde" werde ich an der Stelle ausnahmsweise mal richtig grantig. Sowas muss man können und Ihr könnt es offensichtlich nicht. Ihr gebt ein Ereichbarkeitsversprechen und könnt es offensichtlich nicht einhalten, scheitert Ihr doch schon an so einem simplen Design, stellt hinterher fest, dass es nicht funktioniert und baut Workarounds, um Euer falsches Design zu verbergen.
Gibt es noch andere Vorschläge?
Ja, seid ehrlich zum Kunden und sagt, dass Ihr Euch übernommen habt. Ich vermittele gerne einen DL, der auf sowas spezialisiert ist und es richtig macht.
Nicht ganz so liebe Grüße
Erik