DFSR Replikations Problem

[Wolle68 0]

Hallo Zusammen,

 

ich habe zwei Fileserver die per DFS ihre Daten Synchronisieren. Nachdem ein Server ein Problem hatte funktioniert die Replikation (vermutlich) nicht mehr.

Wir haben 5 Replkationsgruppen von denen 4 ok sind, heißt, die beiden Partner sind Synchron.

Bei einer Gruppe, die mit den meisten Daten, wird das Backlog immer größer.

Ich sehe aber bei Abfrage mit Get-DfsrState dass Daten "bearbeitet" werden.

 

Datei.abc                                                                         Downloading    True  Servername

 

Im Statusbericht für DFS-Replikation steht "Dieses Mitglied wartet auf die erste Replikation für den replizierten Ordner XXX und nimmt aktuell nicht an der Replikation teil............."

 

Jetzt frage ich mich,

- replizieren die Server jetzt?

- Warum wird das Backlog bei der einen Repl-Gruppe immer größer

- muss ich einfach warten?

 

In mehr als einer Woche wurde die Backlog Anzahl eher größer anstatt kleiner.

Hat jemand eine idee was man prüfen kann

 

Danke vorab und Gruß

[daabm 1.186]

Replikationsgruppe wegschmeißen, per Robocopy neu pre-stagen und dann neu erstellen?

[Wolle68 0]

vor 11 Stunden schrieb daabm:

Replikationsgruppe wegschmeißen, per Robocopy neu pre-stagen und dann neu erstellen?

 

Denke darauf wird es hinauslaufen.

MS schreibt ja in einem Artikel dass beim Pre-Seeding mit Robocopy auf dem Zielserver kein Ordner sein darf.
Ich habe ja jetzt schon einen der ja auch schon zu ca 80% gefüllt ist. 

Kann man den nicht einfach nur "auffüllen"? Weiß jemand warum da kein Ordner sein darf?

bearbeitet 24. Februar 2022 von Wolle68

[daabm 1.186]

Kann man klar auffüllen 

[NilsK 2.786]

Moin,

 

ich stelle dazu mal meine Standardfrage: Wozu wird das DFS-R denn benötigt?

 

In der freien Wildbahn sehe ich immer wieder Konstrukte, bei denen Fehlerhäufigkeit und Nutzen nicht in sinnvollem Verhältnis stehen. Daher könnte dies ein Anlass sein, das für die gegebene Umgebung mal zu prüfen.

 

Gruß, Nils

 

[Wolle68 0]

vor 5 Stunden schrieb daabm:

Kann man klar auffüllen 

Ok, danke 

vor 2 Stunden schrieb NilsK:

Moin,

 

ich stelle dazu mal meine Standardfrage: Wozu wird das DFS-R denn benötigt?

 

In der freien Wildbahn sehe ich immer wieder Konstrukte, bei denen Fehlerhäufigkeit und Nutzen nicht in sinnvollem Verhältnis stehen. Daher könnte dies ein Anlass sein, das für die gegebene Umgebung mal zu prüfen.

 

Gruß, Nils

 

Naja, wir replizieren die Daten auf einen zweiten Fileserver um im Fall der Fälle eine Verfügbarkeit der Daten zu haben.

 

[NilsK 2.786]

Moin,

 

Das hab ich befürchtet. Genau bei dem Einsatzzweck höre ich zu oft von Problemen, um das für eine gute Lösung zu halten.

 

Nur um das größte Problem anzusprechen: der Last-Writer-Wins-Algorithmus ist euch bekannt?

 

Gruß, Nils

 

 

[Wolle68 0]

vor 2 Stunden schrieb NilsK:

Moin,

 

Das hab ich befürchtet. Genau bei dem Einsatzzweck höre ich zu oft von Problemen, um das für eine gute Lösung zu halten.

 

Nur um das größte Problem anzusprechen: der Last-Writer-Wins-Algorithmus ist euch bekannt?

 

Gruß, Nils

 

 

Wo genau siehst du da das Problem?

und welche Alternative würdest du anstreben? 

 

aber erst mal muss ich den Sync wieder hinbekommen….

[NilsK 2.786]

Moin,

 

Gibt es zwei Replikate und beide sind zugänglich, dann lassen sich beide gleichzeitig bearbeiten. Es gewinnt die Version, die als letzte gespeichert wird. Ungünstig, wenn die zwei Seiten, die der Praktikant speichert, die 100 Seiten der Geschäftsführerin überschreiben.

 

Welche Lösung besser geeignet ist, hängt davon ab, was denn das Problem ist, das gelōst werden soll. Schon wenn man darüber nachdenkt, merken viele, dass ihr Konstrukt die Anforderungen überhaupt nicht erfüllen würde.

 

Mag auch sein, dass DFS-R für euch passt, aber meine Erfahrung ist, dass es für die meisten, die sich das noch mal genauer ansehen, eben nicht passt. Und da habe ich mit den technischen Problemen noch nicht mal begonnen.

 

Gruß, Nils

 

bearbeitet 24. Februar 2022 von NilsK

[Wolle68 0]

Moin Nils,

danke erst mal für deine Ausführung.

 

Zum ersten Problem: Wir haben zwei Server, einer Aktiv einer Passiv. Damit kommt die Sache mit dem "Überschreiben" nicht in Betracht weil es nur einen Server gibt auf dem "geschrieben" wird.

Unser derzeitiges Problem ist hausgemacht. Leider war Server 2, also der Passive, ein Zeit lang Offline ohne dass wir es merkten.

Seit der wieder Inbetriebnahme haben wir das Problem mit der Replikation. Bis dahin hatten wir keine Schwierigkeiten.

 

Also ich bin zumindest stand jetzt der Meinung dass das bei uns so passt. 

Werde jetzt die Replikation neu einrichten. Vorher aber mit RoboCopy die Dateien rüberkopieren. Wir haben knapp 4TB Daten, das sollte an einem Wochenende passen.

[NilsK 2.786]

Moin,

 

wenn es für euch insgesamt passt, ist das ja gut. Naturgemäß kommen bei mir in der Dienstleister-Rolle auch eher die Probleme an als die Fälle, in denen es gut läuft. 

 

Wichtig ist eben bei allen Konstrukten, die Ausfälle absichern sollen, dass man sich genau ansieht, was sie wirklich leisten können und welcher Aufwand dafür erforderlich ist. Da kann eine Replikation einen Teil abdecken - aber eben nur einen Teil.

 

Gruß, Nils

 

[djmaker 95]

Vielleicht ist es sinnvoller erst einmal die Anforderungen zu definieren. "Einen Ausfall überbrücken" ist ziemlich weitläufig. Sinnvoller wäre es RPO und RTO zu definieren (in sinnvollen Zeitangaben, 5 min braucht normalerweise keiner).