In diesem Artikel werden wir ein wenig über einen sehr einfachen Mechanismus sprechen, der heutzutage für jedes kleine Unternehmen notwendig ist. Dies ist natürlich ein „verteiltes Dateisystem“ (DFS) und „Replikationsdienst für verteilte Dateisysteme“ (DFSR). Der Replikationsmechanismus als integrierte Lösung in der Windows Server-Betriebssystemfamilie erschien bereits im Jahr 2000 in Windows Server 2000. Seitdem ist die Lösung in Bezug auf ihre Funktionalität und Fehlertoleranz sehr stark gewachsen. Heute werden mit nur wenigen Klicks eine Vielzahl von Parametern mit Standardwerten konfiguriert, die für 99 % der Unternehmen geeignet sind.
Dieser Artikel zeigt buchstäblich die wichtigsten Punkte für die Einrichtung der Grundelemente dieses Dienstes. Aber dieser Mechanismus ist damit nicht erschöpft, und wenn Sie diesen Dienst vorher nicht kannten, dann ist dieser Artikel für Sie.
Welche Replikationstypen gibt es?
Diese Replikationsgruppe wird fast automatisch erstellt, wenn dem verteilten Dateisystem ein zweites Ziel hinzugefügt wird.
Eine unabhängige Replikationsgruppe wird in Fällen benötigt, in denen Sie keine „freigegebenen“ Ordner, sondern einfach beliebige Ordner zwischen zwei oder mehr verschiedenen Servern replizieren müssen.
Wenn mit der Replikation von Endobjekten im Namensraum alles klar und einfach ist, dann gibt es noch ein Feature mit unabhängigen Replikationsgruppen, da diese Gruppe auf zwei Arten erstellt werden kann:
Eine universelle Replikationsgruppe wird für die gegenseitige bidirektionale Replikation der darin enthaltenen Dateien und Ordner benötigt. Eine solche Gruppe wird nur verwendet, wenn eine Replikationsgruppe für die letzten Objekte des Namensraums erstellt wird.
Eine Replikationsgruppe für die Datenerfassung wird benötigt, um alle Dateien und Ordner beispielsweise auf einen Sicherungsserver zu kopieren. Wenn gleichzeitig einige Dateien auf dem Backup-Server geändert oder gelöscht werden, wirkt sich dies in keiner Weise auf das ursprüngliche Objekt aus. Diese Funktionalität ist praktisch, um einen unidirektionalen Datenaustausch zu implementieren, beispielsweise zwischen einem geschützten Segment und einer DMZ (die Lösung ist sicherheitstechnisch nicht optimal!)
Ein wenig über die Nuancen
- Beim Erstellen einer Replikationsgruppe, egal welchen Typs, können Sie die Datenübertragungsrate nach Wochentag und Stunde festlegen. Dies ist sehr nützlich, um die Netzwerklast während der Geschäftszeiten zu reduzieren. Besonders in Fällen, in denen das Unternehmen viele Niederlassungen in verschiedenen Städten und / oder Ländern hat.
- Der Dienst ist äußerst stabil und stellt sich bei den allermeisten Fehlern selbst wieder her und funktioniert weiterhin ordnungsgemäß. Auch wenn der Server abstürzt.
- Ein replizierter Ordner kann keine Datenbanken (jeglicher Art) verwenden, da Reproduktionen nicht nach Sektoren, sondern nach Dateien übertragen werden. Beispielsweise ist die gemeinsame Nutzung von DBase-, MS Access- und MS Excel-Dateien nicht zulässig.
- Wenn Sie in verschiedenen Städten/Ländern über dieselbe Schreibreplik verfügen und häufig dieselbe Datei geändert wird, kann es zu einer Kollision kommen. Und es stellt sich heraus, dass zwei Personen gleichzeitig dieselbe Datei in zwei Zweigen geändert haben. Anschließend platziert der DFSR-Dienst die neueste Version der Datei auf beiden Replikaten, verschiebt die Konfliktdatei in den Ordner „[Laufwerk]:\[Replikationsordner]\DfsrPrivate\ConflictAndDelete“ und schreibt Informationen über die Datei in die Konfigurationsdatei „[ Laufwerk]:\[Replikationsordner]\DfsrPrivate \ConflictAndDeletedManifest.xml.“
- Der Ordner „ConflictAndDeleted“ hat ein Standardlimit von 4 GB. Sie können dieses Limit ändern.
- Der Zwischenspeicher hat eine Standardgrenze von 4 GB. Wenn Sie oder Benutzer eine größere Datei hochladen, kann diese Datei nicht repliziert werden, aber DFSR wird endlos versuchen, sie zu kopieren. Wenn Sie erwarten, dass Benutzer dies tun, ändern Sie das Speicherlimit sofort nach oben.