Komisches DFS-R Verhalten

[goat82 2]

Hallo Zusammen,

ich habe ein komisches DFS-R Verhalten und freue mich wenn mich ein Profi hier aufklärt.

 

Wir haben 2 Server A und B welche DFS-R Replikation eines Ordners O im Full Mesh machen.

Der Replikationsordner O ist auf Server A und B freigegeben.

DFS-N wird ebenfalls umgesetzt wobei das Referal von Server B auf Ordner O deaktiviert ist. Daher sollten die Mitarbeiter über den Namespace \\domain.local\0 immer nur auf die Freigabe von Server A kommen.

Ein direkter Zugriff über die Freigabe \\Server B\O ist natürlich ebenfalls möglich, da die Freigabe nicht deaktiviert ist. (Sollte aber nicht umgesetzt werden weil dies ja zu Problemen führt)

 

Ist es normal, dass ich auf Server B (DFS-N Referal deaktiviert) im Computermanagement auf C:\DFSRoots\O "User Sessions" Verbundene User sehe ?

Ist es normal das hier teilweise Open Files mit z.B.)  2 angzeigt werden ? Unter Open Files sehe ich aber nur die Ordner C:\DFSRoot\O und andere aber keine geöffneten Dateien

 

Auf Server B (Referal enabled) sehe ich viel mehr User auf das Verzeichnis C:\DFSRoots\O unter "Sessions" zusätzlich werden unter  "Open Files" aber auch  User mit geöffneten Datein mit vollständigen Pfad angezeigt.

Auf Server A steht zwar unter Sessions Open Files 2 aber unter Open Files steht nur der C:\DFSRoot\O Ordner und andere aber keine geöffnete Datei, geschweige denn ein Dateipfad.

Eventuell werden auf Server B auch nur die Namespace Ordnerzugriffe, trotz deaktiviertem DFS-N Referal von Server B angezeigt, was ggf normal ist.

 

Es würde mir sehr helfen zu verstehen, wie das trotz deaktiviertem DFS-N Referal sein kann da ich ein weiteres größeres Problem habe:

 

Ich habe eine defekte DFS-R Datenbak auf Server B welche alle paar Tage an die Wand fährt (Er sagt Laufwerk wurde getrennt und die Datenbank macht dann eine Autowiederherstellung).

DFS-R wurde nie richtig geplegt und die Datenmenge ist auch viel zu groß, daher muss ich das alles neu aufteilen damit es wieder sauber läuft.

Daher möchte ich die Replikation auf Server B stoppen und dort eine neue Partition anlegenen damit eine neue DFS-R Datenbank für die Entsprechenden ORdnerreplikationsgruppen angelegt wird. Danach will ich den Server B erneut unter dem neuen Pfad (Neue Partition) hinzufügen damit Server A den Inhalt mit Server B wieder repliziert.

 

Schlecht wäre natürlich wenn es exklusiven Zugriff auf eine DFS-R Freigabe auf Server B gäbe denn das führt ja zu Konflikten da die User ja immer mit dem Referal (Namespace) arbeiten sollen,

Eventuell ist das aber auch normal, da C:\DFSRoot auf beiden Server ja identisch ist.

Merkwürdig ist die Anzahl der geöffneten Dateien schon. Eventuell sind die Anzahl Open Files unter Session welche auf C:\DFSRoot\ zeigen auch nur die ORdneranzahl? Das würde Sinn machen. (Es gibt natürlich mehr wie der O Ordner!)

 

Weiß jemand auch ob es bei DFS-R Probleme mit Volumen Schatten Kopie VSC oder Backups gibt ?  Ich suche ein Zusammenhang warum die Datenbank immer an die Wand fährt werde aber nicht wirklich fündig.

 

Vielen Dank für die Hilfe

 

Lieben Gruß Felix

 

 

 

 

bearbeitet 29. August von goat82

[Dukel 454]

Was wollt Ihr mit DFS-R erreichen?

Wieso solch eine komplizierte Konfiguration?

 

Wäre der "Nachfolger" evtl. eine alternative: https://learn.microsoft.com/en-us/windows-server/storage/storage-replica/server-to-server-storage-replication

[goat82 2]

Hi Dukel,

Es soll ein erreicht werden, dass die Datenstände von Server A+B synchron sind und bei Ausfall 7Neustart durch Updates usw. von Server A das Referal auf Server B ohne Downtime umgestellt werden kann.

 

Hast du eine Antwort wegen der merkwürdigen Anzeige in den Shares zu dem DFSRoot Ordner ?

[Dukel 454]

vor 9 Minuten schrieb goat82:

Es soll ein erreicht werden, dass die Datenstände von Server A+B synchron sind und bei Ausfall 7Neustart durch Updates usw. von Server A das Referal auf Server B ohne Downtime umgestellt werden kann.

 

Daher die Idee Storage Replica einzusetzen. Hier fallen diverse Nachteile von DFS-R weg.

  

vor 9 Minuten schrieb goat82:

Hast du eine Antwort wegen der merkwürdigen Anzeige in den Shares zu dem DFSRoot Ordner ?

 

Nein, leider nicht.

[goat82 2]

Hi Dukel,

 

was passiert denn bei Storage Replica wenn Daten auf einem Volume gelöscht werden. Hierzu steht im Artikel nichts. Im Synchronen Modus, wird es sicherlich dauert wenn ich mal 3TB lösche, bis alles auf dem anderen Server repliziert ist. (Wir haben mehrere Millionen Daten). Kann Storage Replica einfach mit DFS-N kombiniert werden und ist es möglich wie bei DFS auf Freigaben beider Server auf beiden Volumen zuzugreifen, je nach aktiven Namespace Referal ? So wäre Storage Replica einfach nur eine andere Synchronisierung (ohne ewigen DFS-R Datenbamnkcheck bei einem Crash). Wichtig wäre natürlich dass man direkt mit dem aktuellen Datenstand weiterarbeiten kann Wenn Server A mal ausfällt oder gewartet werden muss.

bearbeitet 29. August von goat82

[Nobbyaushb 1.472]

Wenn ich das mal anmerken darf, ihr braucht ganz was anderes 

All das erwähnte ist keine Hochverfügbarkeit, da muss man ganz anders ansetzen - meine Meinung 

das würde aber den Rahmen sprengen denke ich

Wenn du willst kann ich ein paar Stichwörter liefern - falls gewünscht und ihr in eine andere Richtung offen seid

[daabm 1.356]

"Kaffeesatz", weil das ja kein Problem verursacht, sondern nur Neugier ist: Der DFS-Client enumeriert alle Referrals (egal ob aktiv oder nicht) und macht - aus unbekannten Gründen - einen Tree Connect auf die Shares. Könnte man im NW-Trace sehen. Die drei Sub-Befehle von dfsutil cache könnten auch noch ein wenig helfen.

[goat82 2]

Hi daabm, vielen Dank für die 3 Tipps, das hilft sicher gut weiter.

Ich sehe es so, dass die Referals funktionieren, aber aus unerklärlichen Gründen wird eine Session zum Server B auf die DFSRoots aufgemacht, auch wenn am Server B (deaktiviertes Referral) keine Daten geöffnet werden. Am besten wäre natürlich wenn DFS-R auf Server B wieder läuft da, dass ganze sehr Zeitaufwändig ist und es auch um sehr viel Daten geht die wir nicht wirklich weniger bekommen (23TB), daher wäre es mir am liebsten wenn es wieder läuft, denn es gibt genug andere Dinge zu erledigen

Kannst du mir den Befehl zum Tree connect geben ?

Anbei die Ergebisse der Befehle.

 

 

 

 

Befehle.txt

[cj_berlin 1.323]

Moin,

 

was ich mich die ganze Zeit frage: hast Du denn wirklich ein Problem? Die Verbindungen zu Namespace-Servern haben doch erst einmal mit Referrals auf Ordner-Ziele nichts zu tun. Wenn letztere auf B ausgeschaltet sind, Zugriffe aber trotzdem stattfinden, finden sie über den Servernamen statt und nicht über DFS-N. Falls doch, hat das jemand gecached und nicht aktualisiert, da wäre der Blick auf den jeweiligen Client vermutlich zielführend.

 

Was das Thema kaputtes DFS-R angeht, müsstest Du das Verhalten noch einmal im Detail erläutern, Mit "an die Wand fahren" kenne ich mich nicht aus.

[daabm 1.356]

Was @cj_berlin sagt, meinte ich auch. Das ist doch kein Fehler, das ist vermutlich (wieder Kaffeesatz, ich hab keinen Sourcecode-Zugriff) ein Teil des DFS-Clients, daß er Referrals eben so enumeriert wie er es halt tut.

 

Du kannst jederzeit Server B aus der DFSR-Gruppe werfen, den Share woanders neu aufsetzen, die Dateien pre-stagen (Google hilft - "robocopy /sec") und ihn dann wieder reinnehmen.

[goat82 2]

so einfach ist es nicht, er sagt die Daten werden auf beiden Freigaben geändert, dies habe ich aber geprüft und stimmt nicht. Auch wird nur noch von B auf A repliziert, der Rest landet dann im Conflictand Deleted DFSR_Private Ordner auf Server A. Manuell den Sync antriggern hilft nicht. Nach ca. 10 Tagen funktioniert es dann irgendwann. Vermutlich ist die Datenbank oder die Datenmenge einfach zu groß. Ich habe den Mist nicht erstellt aber es geht hier um 22Tb auf einem Volume, also 1DFSR Datenbank für 22TB was wahnsinn ist. Eine neue Replikationsgruppe auf einem neuen Volume klappt natürlich einwandfrei. Nur habe ich 8TB frei wo ich umlagern kann. 16TB würden so dennoch auf der großen Disk liegen. Und die Disk in Vmware verkleinern ist auch nicht mit Boardmitteln möglich und führt zu einer längeren downtime von Server B

bearbeitet 3. September von goat82

[NilsK 2.939]

Moin,

 

wenn ich den Thread so ansehe, stimme ich @Nobbyaushb zu: Ich würde das ganze Konzept noch mal grundlegend prüfen. Was du beschreibst, klingt wie eine typische DFS-R-Leidensgeschichte. Über die Jahre habe ich DFS-R als sehr hakelig kennengelernt. In allzu vielen Situationen und Umgebungen sorgt es für Probleme.

 

Typischerweise hilft es dann, wenn man sich in Ruhe die eigentlichen Anforderungen ansieht und auf der Basis nach Lösungsansätzen sucht. Oft stellt man dann fest, dass DFS-R gar nicht passt und ein anderer Ansatz besser funktioniert.

 

Gruß, Nils

 

[Dukel 454]

Virtualisiert aber mit DFS-R redundant? Wieso?

Ist die Virtualisierung / Storage nicht redundant?

[goat82 2]

Leider nein. Beide Server laufen auf getrennten, unverwalteten Stand alone ESX Server ohne Vsphere und ohne Vmotion oder ohne Speicherreplikation.

Ursprünglich war die Idee vor mind. 15 Jahren so, dass Auf Server A gearbeitet wird, die Freigaben via DFS-R auf Server B repliziert werden.

Fullbackup wird dann auf Server B gefahren, weil dort keine Zugriffe/Änderungen sind. Heute sind es knapp 23TB und die Synchronisierung will nicht mehr richtig, weil die DFSR Datenbank wahrscheinlich zu groß ist.

Mein Ansatz ist DFSR auf neue Volumes zu unterteilen, sodass nicht mehr als 4TB / Partition (& DFS Datenbank) Daten repliziert werden.

Ein neues Konzept wäre natürlich besser aber es gibt derzeit kein Platz um die 23TB auszulagern oder zu puffern.

 

Weiß jemand ob VSC mit DFSR zu vielen Problemen führt. VSC läuft leider auch 3x täglich auf dem großen DFSR Volume mit 23TB. ISt sicher nicht best practise aber die Strukturen sind so und ich muss erst eine Alternative haben bwvor ich die vielen verwöhnten User davon entwöhnen kann.

[zahni 554]

Ihr braucht dringend Beratung inkl. eines Konzepts zur Ausfallsicherheit und Redundanz.