Die häufigsten Fehler und Missverständnisse bei der Konfiguration von DFSR

[Anmerkung Übersetzer. Der Artikel ist für Windows Server 2003 / 2003R2 / 2008 / 2008R2, aber die meisten der oben genannten Punkte gelten für spätere Versionen des Betriebssystems.]

Hallo allerseits! Warren ist wieder hier und dieser Blog-Beitrag ist eine Zusammenstellung der häufigsten DFSR-Probleme, auf die ich in den letzten Jahren gestoßen bin. Der Zweck dieses Beitrags besteht darin, häufige Fehler in der DFSR-Konfiguration aufzulisten, die diese Probleme verursachen, und zu verhindern, dass Sie ähnliche Fehler machen. Zu wissen, was nicht getan werden sollte, ist genauso wichtig wie zu wissen, was zu tun ist. Viele der beschriebenen Elemente beziehen sich auf andere Themen, sodass entsprechende Links für eine eingehende Untersuchung des Problems bereitgestellt werden.

Kontingentgröße zu klein für Staging-Ordner

Haben Sie viele Ereignisse in der Zeitschrift mit den Codes 4202 und 4204 gesehen? In diesem Fall ist die Größe für den Staging-Ordner falsch eingestellt. Eine unangenehme Folge der falsch eingestellten Größe des Staging-Ordners ist die Verringerung der Replikationsleistung, da der Dienst anstelle der Replikation von Dateien Zeit damit verbringt, den Staging-Ordner zu bereinigen.
DFSR-Server, die mit einer ausreichenden Größe des Staging-Ordners konfiguriert sind, sind aus mindestens zwei Gründen effizienter:

1. Es ist viel effizienter, die Datei nur einmal in einem Zwischenordner abzulegen und dann an alle Host-Replikationspartner zu senden, als die Datei zu erstellen, zu replizieren und dann für jeden Host-Partner eine Kopie zu löschen.
2. Wenn die Enterprise Edition des Betriebssystems auf mindestens einem Mitglied installiert ist, können die Server die dateiübergreifende RDC-Technologie verwenden [ca. Übersetzer: Ab Windows Server 2012 ist diese Technologie auch in der Standard Edition verfügbar. ]

Eine falsch konfigurierte Größe für den Staging-Ordner kann auch Replikationsschleifen verursachen. Dies geschieht, wenn die replizierte Datei bereits in den Zwischenordner auf dem empfangenden Server kopiert wurde, der Bereinigungsmechanismus für Zwischenordner diese Datei jedoch löscht, bevor sie in den Zielordner verschoben werden kann. Die gelöschte Datei wird erneut auf den Server repliziert und von diesem Server erneut aus dem Staging-Ordner gelöscht, wodurch der Server die Datei niemals empfangen kann. Dieser Vorgang wird wiederholt, bis der Server die Datei akzeptiert.

Ignorieren Sie keine Protokollereignisse für den Staging-Ordner.

In diesem Beitrag wird beschrieben, wie Sie mit der Methode die Mindestgröße eines Zwischenordners ermitteln.

Siehe hier den Abschnitt „Erhöhung der Zwischenquote“.

Informationen zum dateiübergreifenden RDC finden Sie im Artikel "Informationen zur Remote-Differentialkomprimierung", der hier veröffentlicht wird .

Falsches oder ungetestetes Vorsaatverfahren

Ein Voreinstellungsverfahren ist das Kopieren von Daten, die auf einen neuen Replikationsmitgliedsserver repliziert werden, bevor sie zum endgültigen Ordner dieses Servers hinzugefügt werden, um die für den Abschluss der primären Replikation erforderliche Zeit zu verkürzen. Die meisten Fehler des Voreinstellungsverfahrens, auf die ich gestoßen bin, wurden aus drei Gründen verursacht.

1. ACL-Nichtübereinstimmung an Quelle und Ziel.
2. Nach dem Kopieren auf ein neues Replikationsmitglied wurden Änderungen an den Dateien vorgenommen.
3. Es wurden keine Vortests durchgeführt, um zu überprüfen, ob das verwendete Vorsaatverfahren wie erwartet funktioniert hat.

Kurz gesagt, die Dateien müssen auf eine bestimmte Weise kopiert werden und können nicht geändert werden, nachdem sie in den Zwischenordner kopiert wurden, und der gesamte Prozess muss von Ihnen vorab getestet werden.

Klicken Sie hier , um den Blog von Mr. Pile zu lesen, wie Sie das Voreinstellungsverfahren für Ihre DFSR-Server ordnungsgemäß organisieren können.

Große Größe der Kopierwarteschlange im Laufe der Zeit

Neben der Tatsache, dass eine große Kopierwarteschlange, die lange Zeit besteht, bedeutet, dass Ihre Daten nicht synchronisiert werden, kann dies zu einer unerwünschten Konfliktlösung führen, wenn eine Datei mit altem Inhalt in einem Konfliktlösungsskript gewinnt. Das häufigste Szenario, in dem ich auf dieses Verhalten gestoßen bin, ist das massive Hinzufügen neuer Replikationsordner. Anstatt eine schrittweise Bereitstellung durchzuführen, fügten einige Administratoren sofort 20 neue Ordner für die Replikation aus 20 verschiedenen Zweigen hinzu, wodurch der Hostserver überlastet wurde. Die Bereitstellung erfolgt schrittweise, sodass die primäre Replikation in angemessener Zeit abgeschlossen ist.

DFSR wird als Backup-Lösung verwendet

Ob Sie es glauben oder nicht, einige Administratoren stellen DFSR ohne Offline-Sicherungen replizierter Daten bereit. DFSR wurde nicht als Backup-Lösung entwickelt. Eines der Ziele der DFSR-Entwicklung besteht darin, Teil einer Unternehmens-Backup-Strategie zu sein, da Sie mit DFSR Ihre geografisch verteilten Daten an einem zentralen Standort für die spätere Sicherung, Wiederherstellung und Archivierung sammeln können. Mehrere Replikationsmitglieder bieten Schutz vor Serverausfällen, schützen Sie jedoch nicht vor versehentlichem Löschen. Um vollständig geschützt zu sein, müssen Sie Ihre Daten sichern.

Einwegreplikation: Verwendung und falsche Reparaturmethoden

Um zu verhindern, dass unerwünschte Aktualisierungen auf Servern angezeigt werden, auf denen sich die Daten niemals ändern (oder wenn sie Änderungen an ihnen verhindern möchten), richten viele Kunden die Einwegreplikation ein, indem sie ausgehende Verbindungen für Replikationsmitglieder entfernen. Die Einwegreplikation wird in keiner Version von DFSR vor Windows Server 2008 R2 unterstützt. Windows 2008 R2 unterstützt die Einwegreplikation, mit der Sie schreibgeschützte Ordner für replizierte Ordner konfigurieren können.

Durch die Verwendung schreibgeschützter Replikationsmitglieder kann das Ziel der Einwegreplikation erreicht werden, wodurch unerwünschte Änderungen an den zu replizierenden Daten verhindert werden. Wenn Sie die Einwegreplikation mit DFSR verwenden möchten, verwenden Sie Windows 2008 R2. Wählen Sie für die Mitglieder, die nicht geändert werden sollen, den schreibgeschützten Modus aus.

Klicken Sie hier und hier , um mehr über die schreibgeschützte DFSR-Replikation zu erfahren.

Ein weiteres häufiges Problem tritt auf, wenn der Administrator feststellt, dass die Einwegreplikation nicht unterstützt wird, und versucht, die Situation zu korrigieren, dies jedoch falsch. Das einfache Aktivieren der bidirektionalen Replikation kann zu unerwünschten Ergebnissen führen.

Klicken Sie hier , um zu erfahren, wie Sie die Einwegreplikation beheben.

Knotenserver als Single Point of Failure und überlastete Knotenserver

Ich habe viele Bereitstellungen mit einem einzelnen Knotenserver gesehen. Wenn dieser Knotenserver ausfällt, ist die gesamte Bereitstellung gefährdet. Wenn Sie Windows Server 2003 oder 2008 verwenden, müssen mindestens zwei Hostserver vorhanden sein. Wenn einer von ihnen abstürzt, muss der andere die Last der Wiederherstellungszeit des ersten mit minimalen Auswirkungen auf die Endbenutzer bewältigen. Ab Windows Server 2008 R2 kann DFSR auf einem Windows-Failovercluster bereitgestellt werden. Dies bietet hohe Verfügbarkeit und halbiert gleichzeitig die Speicheranforderungen.

Früher oder später haben Administratoren eine Situation, in der sich zu viele Server in den Zweigen befinden, die für die Replikation mit einem einzelnen Knotenserver konfiguriert sind. Dies kann zu Verzögerungen bei der Replikation führen. Um zu verstehen, wie viele Server-Office-Server ein einzelner Knotenserver bedienen kann, können Sie die Nachverfolgung der Kopierwarteschlange verwenden. Es gibt keine Zauberformel, da jede Umgebung einzigartig ist und es viele Abhängigkeiten gibt.

Lesen Sie hier den Abschnitt „Topologiekonfiguration“, um mehr über die Bereitstellung von Hostservern zu erfahren.
Klicken Sie hier , um zu erfahren, wie Sie DFSR in einem Windows Server 2008-Failovercluster konfigurieren.

Zu viele Ordner, um in eine einzelne Jet-Datenbank zu replizieren

DFSR verwendet eine Jet-Datenbank auf dem Volume. Wenn Sie also alle replizierten Ordner auf demselben Volume platzieren, befinden sich alle in derselben Jet-Datenbank. Wenn in dieser Datenbank ein Problem auftritt, das repariert oder wiederhergestellt werden muss, wirkt sich die Datenbank auf alle replizierten Ordner auf dieser Festplatte aus. [Anmerkung Übersetzer. Offensichtlich handelt es sich hierbei nicht um eine Festplatte, sondern um ein Volume.] Es wäre korrekter, so viele Festplatten wie möglich zu verwenden und die replizierten Ordner zwischen ihnen zu verteilen, um so eine maximale Datenverfügbarkeit zu gewährleisten.

Bereitstellung basierend auf Budget iSCSI-Lösungen

Ich habe oft DFSR-Bereitstellungen mit der billigsten iSCSI-Hardware gesehen. Wenn Sie DFSR verwenden, tun Sie dies normalerweise, um wichtige Ziele wie Datenredundanz, Sicherungskonsolidierung, geplante Bereitstellung von Anwendungen und Betriebssystemaktualisierungen zu erreichen. Es ist keine gute Idee, sich von minderwertigen Geräten abhängig zu machen, die keinen normalen Anbietersupport haben. Wenn Daten für Ihr Unternehmen wichtig sind, sind die Geräte, auf denen das Betriebssystem und der Replikationsmechanismus arbeiten, für das Unternehmen wichtig.

Der DFSR-Dienst installiert keine aktuellen Patches

DFSR wird von Microsoft aktiv unterstützt und bei Bedarf aktualisiert. Aktualisieren Sie DFSR, wenn zum Zeitpunkt Ihres nächsten Update-Installationszyklus eine neue Version dafür vorhanden ist. Stellen Sie sicher, dass Ihre Server gemäß den unten aufgeführten Knowledge Base-Artikeln aktualisiert werden.

DFSR-Hotfixes für Windows 2003 R2
DFSR-Hotfixes für Windows 2008 und Windows 2008 R2

Bitte beachten Sie, dass die aufgeführten Updates neben DFSR.EXE / DFSRS.EXE auch für NTFS.SYS und andere Dateien gelten. Stellen Sie immer sicher, dass die neuesten Patches mindestens für DFSR und NTFS installiert sind, damit die Replikation ordnungsgemäß funktioniert. Andere Korrekturen aus der Liste betreffen hauptsächlich Probleme mit der Benutzeroberfläche, und Sie müssen sie zumindest auf den Systemen installieren, auf denen DFSR-Konfigurationsaufgaben ausgeführt werden.

Es wird empfohlen, Patches im Voraus auf dem DFSR-Server zu installieren, auch wenn alles einwandfrei funktioniert, da Sie später das Auftreten bereits bekannter Probleme vermeiden können.

Netzwerkadaptertreiber werden aktuell nicht unterstützt

DFSR kann nur dann normal funktionieren, wenn das von Ihnen bereitgestellte Netzwerk ebenfalls problemlos funktioniert. Die Verwendung von Treibern vor 5 Jahren ist nicht die intelligenteste Lösung. Ich hatte Erfahrung in der Kommunikation mit mehreren Kunden, für die DFSR-Replikationsprobleme durch Aktualisieren eines veralteten NIC-Treibers behoben wurden.

Fehlende DFSR-Überwachung

Trotz der Tatsache, dass DFSR zum Verschieben kritischer Daten verwendet wird, haben viele Administratoren keine Ahnung, was DFSR tut, bis sie auf ein Problem stoßen. Diejenigen, die einfallsreicher sind, erstellen ihre eigenen Skripte, um die Kopierwarteschlangen auf ihren Servern zu überwachen. Die meisten verlassen sich jedoch einfach darauf. Das Management Pack für DFSR wurde vor fast einem Jahr veröffentlicht (und andere Versionen erschienen früher). Installieren Sie es und verwenden Sie es - und dann können Sie Probleme erkennen und darauf reagieren, bevor sie sich in einen Albtraum verwandeln. Wenn Sie das Operations Management Management Pack für DFSR nicht verwenden können, schreiben Sie mindestens ein Skript, um die Kopierwarteschlange täglich zu überwachen und festzustellen, ob DFSR-Dateien repliziert werden.

Klicken Sie hier, um Informationen zum Operations Management Management Pack für DFSR zu erhalten.

Aktualisiert am 19. Januar 2011:

Änderungen am Festplattenspeicher vornehmen, ohne zuvor Daten zu archivieren

Wenn der DFSR-Server die Festplatte ersetzen oder eine neue hinzufügen muss, um den Speicherplatz zu erhöhen, ist es äußerst wichtig, eine aktuelle Datensicherung zu haben, falls etwas schief geht. Alles kann schief gehen. In den meisten Fällen treten Konfliktereignisse aufgrund unerwarteter Änderungen im übergeordneten Ordner oder durch versehentliches Löschen des übergeordneten Ordners auf, der auf alle Partner repliziert wird. Sie müssen Ihre Daten sichern, bevor Sie Änderungen vornehmen, und sie aufbewahren, bis das Projekt abgeschlossen ist.

Beenden des DFSR-Dienstes, um die Replikation vorübergehend zu stoppen

Manchmal müssen Sie die Replikation vorübergehend stoppen. Der richtige Weg, dies zu tun, besteht darin, die Replikation für die gewünschte Gruppe mithilfe eines Zeitplans zu deaktivieren. Der DFSR-Dienst muss ausgeführt werden, damit Aktualisierungen im USN-Protokoll gelesen werden können. Beenden Sie den DFSR-Dienst nicht für einen längeren Zeitraum (Tage, Wochen), da dies zu einem Protokollüberlauf führen kann (wenn in dieser Zeit viele Dateien geändert, hinzugefügt oder gelöscht wurden). DFSR wird nach Protokollüberläufen wiederhergestellt, aber in großen Bereitstellungen dauert es lange und die Replikation funktioniert nicht oder ist während der Protokollwiederherstellung sehr langsam. Außerdem werden Sie wahrscheinlich sehr große Kopierwarteschlangen beobachten, bis die Protokollwiederherstellung abgeschlossen ist.

Hoffe diese Liste hilft dir. Gute Replikation!

Warren "breites Netz" Williams

[Anmerkung Übersetzer. Wenn das Interesse der Leser besteht, werde ich später versuchen, die Artikel, die auf den im Text angegebenen Links veröffentlicht sind, sowie andere Artikel des ursprünglichen Autors zu übersetzen.]