DFS Target Auswahl

[bgeltenpoth 10]

Hallo,

wir planen bei uns DFS einzusetzen um bestimmte Dateien an 2 Standorten synchron zuhalten. Dazu haben wir in einer Testumgebung DFS und DSF-R aufegesetzt.

Wir betreiben 2 AD Sites an 2 unterschiedlichen Standorten. Die beiden Sites sind durch eine leistungsfähige Standortkopplung verbunden. 

Die DFS Server sind VM's (jeweils 2 pro Site) die jeweils in einem Rechenzentrum am jeweiligen Standort gehostet sind. Die Domain Controller sind auch über die Standorte verteilt.

Wir haben also einen DFS Namespace eingerichtet und mehrere Shares die über Standort Kopplung synchronisiert sind. Alles das klappt soweit wunderbar. Clients an beiden Standorten können problemlos auf die DFS Shares zugreifen...

 

Jetzt haben wir getestet, was denn passiert, wenn ein Rechenzentrum stirbt... Das haben wir simuliert in dem wir die beiden VMs einer Site heruntergefahren haben.

Am "defekten" Standort konnten die Clients nicht mehr auf die DFS Share zugreifen, am andern Standort ging das problemlos.

Unsere Erwartung war aber, das auch die lokalen Clients nach kurzer Zeit vielleicht auf das entfernte Target "umschalten" würden, das wird in den Share Eigenschaften ja auch so angezeigt. Irgendwas funktionierte auch, aber für einen Betrieb war das nicht brauchbar. (Zu träge, bis garnicht funktionierend) Wir haben auch mit den Cache Zeiträumen gespielt aber nur mit extrem kleinen Werten Erfolg gehabt... 

 

Im Prinzip geht es ja um einen hochverfügbaren, replizierten Fileservice...

Im echten Leben sind die beiden VMs sogar Nodes eines Failover Clusters, jeder Node läuft auf einem dedizierten ESX Hosts...was gegen Hostausfall absichert. Gegen den RZ Ausfall hilft dass dann leider auch nicht wie wir feststellen mussten.

 

Hat das schonmal jemand so oder ähnlich realisiert oder gibt es da bei uns Denkfehler... Die MS Doku zu DFS ist ...ach was ...MS Doku halt...was soll ich noch mehr sagen...

 

Liebe Grüsse

[NilsK 2.939]

Moin,

 

Bitte beschreibe (oder kläre) die Anforderungen. Muss der Speicher wirklich repliziert sein oder kommt es auf Hochverfügbarkeit an? Wir hoch sind die Anforderungen wirklich, wenn ein Standort ausfällt? Bedenke, dass es wenig wahrscheinlich ist, dass das RZ an einem Standort ausfällt und der Rest noch funktioniert ...

 

Regelmäßig ist DFS-R für solche Szenarien nicht gut geeignet.

 

Gruß, Nils

 

[cj_berlin 1.323]

Moin,

im Endeffekt ist DFS-N nur "DNS für Fileserver-Zugriff". Am Ende der Signalkette steht eine physikalische Freigabe. Wenn also der Zugriff über DFS-N standortübergreifend zu lahm war, hat es nichts mit DFS-N zu tun, sondern mit der Standortverbindung. Und da bin ich bei @NilsK: Fileservice ist nichts, was sich gut im WAN bereitstellen lässt, da das SMB-Protokoll per se ja gar nicht für WAN geeignet ist.

[q617 1]

Warum keine moderne Cloud-Lösung?

[bgeltenpoth 10]

Hallo,

 

vielen Dank für die Antworten...

@NilsK Ich stimme dir natürlich zu, dass die Wahrscheinlichkeit, dass das RZ down ist aber die Standortkopplung noch funktioniert ziemlich gering sein wird. Wir hatten das auch schon intern diskutiert. (Leider war das neulich genau der Fall  )

 

@cj_berlin Die Standortkopplung ist schon akzeptabel leistungsfähig. Der Zugriff auf die "normale" Shares ist wirklich ok. Nur bei DFS ist es fast nicht brauchbar wenn die lokalen DFS Server nicht erreichbar sind

 

Das DFS ist AD Integrated und die Namespace Server sind unser 2 VMs an jedem Standort. Diese stellen dann auch die lokalen Shares zur Verfügung die über DFS-R repliziert werden. soweit alles gut... 
Wenn auf einer Site die DFS Nameserver wegfallen scheinen die lokalen Clients aber keinen Targetfailover auf die verbleibenden (entfernten) Nameserver  oder die Shares selber hinzubekommen... wie es hier beschrieben ist:

https://learn.microsoft.com/de-de/windows/win32/dfs/dfs-server-target-prioritization

(Wobei ich nicht verstanden habe, wie ich diese Priosierung Steuern kann)

 

[cj_berlin 1.323]

Moin,

 

der *Zugriff* auf die Shares wird ja nicht "durch DFS" geschleust. Wenn die wahrgenommene Performance bei DFS-Zugriff über Standorte hinweg konstant schlechter ist als bei direktem Share-Zugriff, dann sind die Clients noch mit etwas anderem beschäftigt. Wenn der lokale DC auch noch mit ausgefallen ist, dann müssen sie ja bei jeder Konfigurationsabfrage für DFS erst mal einen DC suchen, um die Konfiguration zu laden.

 

Jetzt mal ganz doof gefragt: Funktioniert die Site-Zuordnung bei Clients einwandfrei, sprich: sind alle Client-Subnetze im AD erfasst un den jeweiligen Sites zugeordnet? 

 

Target Prioritization spielt bei je einem Server in zwei Standorten normalerweise keine große Rolle, wenn Du Targets nicht global priorisierst (was in dem von Dir geschilderten Fall ja nicht gut wäre, außer vielleicht im Wartungsfenster eines Standorts). Die Default-Konfiguration hier entspricht quasi schon dem, was ihr erreichen wollt: Clients greifen sich den Target aus der eigenen Site, solange er antwortet. Und wenn er nicht antwortet, greift der Timeout, bevor etwas anderes versucht wird.

 

Fakt bleibt aber, dass DFS-N + DFS-R kein "hochverfügbares Fileshare-System" ist, bei dem die Clients den Ausfall sofort erkennen und sich sofort ein neues Ziel suchen und dieses auch sofort finden.

[NilsK 2.939]

Moin,

 

bei jeder Replikationslösung hast du das Problem, dass die Replikate unabhängig voneinander sind. Das passt in vielen Fällen nicht zur Nutzung, denn daraus resultiert "Last Writer Wins". Mein Lieblingsbeispiel: Ute öffnet "Vertrag.docx" auf Server A, Udo öffnet dasselbe Dokument auf Server B. Ute macht sich irre viel Arbeit und erweitert das Dokument auf 1500 Seiten. Zehn Minuten später speichert Udo seine Kopie, die nur 10 Seiten hat. Rat mal, welchen Umfang Vertrag.docx nach dem nächsten Replikationsvorgang hat.

 

Gruß, Nils

 

[bgeltenpoth 10]

vor 3 Minuten schrieb cj_berlin:

Fakt bleibt aber, dass DFS-N + DFS-R kein "hochverfügbares Fileshare-System" ist, bei dem die Clients den Ausfall sofort erkennen und sich sofort ein neues Ziel suchen und dieses auch sofort finden.

Ja, das befürchten wir auch ...., aber erstmal Danke für Deine bestätigung...

vor 2 Minuten schrieb NilsK:

Moin,

 

bei jeder Replikationslösung hast du das Problem, dass die Replikate unabhängig voneinander sind. Das passt in vielen Fällen nicht zur Nutzung, denn daraus resultiert "Last Writer Wins". Mein Lieblingsbeispiel: Ute öffnet "Vertrag.docx" auf Server A, Udo öffnet dasselbe Dokument auf Server B. Ute macht sich irre viel Arbeit und erweitert das Dokument auf 1500 Seiten. Zehn Minuten später speichert Udo seine Kopie, die nur 10 Seiten hat. Rat mal, welchen Umfang Vertrag.docx nach dem nächsten Replikationsvorgang hat.

 

Gruß, Nils

 

Grins... ich weiss, es sind nur 10 Seiten...das spielt bei uns allerdings keine Rolle...(den Anwendungsfall wollte ich jetzt aber nicht auch noch erklären)...

Aber danke für den Input..