DFS Server - Freigabe hängt sich auf
Servus zusammen,
ich habe 2 2k16 DFS Server eingerichtet. Beide Server sind gleichzeitig Fileserver. Das ganze findet in einer Domäne statt.
Ich habe einen neuen Namespace angelegt, beide Server mit den entsprechenden Freigaben hinzugefügt und einmalig replizieren lassen. Soweit so gut.
An einem Testclient habe ich ein Netzlaufwerk auf den entsprechenden Namespace und Freigabe (\\domäne\namepace\freigabe) gemountet.
Wenn ich DFS Server A neustarte, bleibt die Verbindung erhalten, und ich kann normal weiterarbeiten.
Starte ich jedoch DFS Server B neu, hängt die Verbindung ca 30 Sekunden, erst dann kann ich wieder arbeiten. Server B ist auch der Primär Server im DSF.
Jemand eine Idee warum das so ist?
ich habe 2 2k16 DFS Server eingerichtet. Beide Server sind gleichzeitig Fileserver. Das ganze findet in einer Domäne statt.
Ich habe einen neuen Namespace angelegt, beide Server mit den entsprechenden Freigaben hinzugefügt und einmalig replizieren lassen. Soweit so gut.
An einem Testclient habe ich ein Netzlaufwerk auf den entsprechenden Namespace und Freigabe (\\domäne\namepace\freigabe) gemountet.
Wenn ich DFS Server A neustarte, bleibt die Verbindung erhalten, und ich kann normal weiterarbeiten.
Starte ich jedoch DFS Server B neu, hängt die Verbindung ca 30 Sekunden, erst dann kann ich wieder arbeiten. Server B ist auch der Primär Server im DSF.
Jemand eine Idee warum das so ist?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 350473
Url: https://administrator.de/contentid/350473
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
30 Kommentare
Neuester Kommentar
OK, also hast Du zwei VMs auf auf zwei unterschiedlichen ESXi Servern.
Warum dann zwei Server?
Sind die ESXi wenigstens geclustert?
Wenn die vSphere Umgebung nicht geclustert ist, warum nicht?
Warum startest Du DFS neu? Wenn die Replikation aktiviert ist, hat der zweite Server den aktuellen Datenbestand.
Was machst Du, wenn ein Server ausfällt?
Das Konstrukt scheint mir nicht ganz ausgegoren zu sein.
Warum dann zwei Server?
Sind die ESXi wenigstens geclustert?
Wenn die vSphere Umgebung nicht geclustert ist, warum nicht?
Warum startest Du DFS neu? Wenn die Replikation aktiviert ist, hat der zweite Server den aktuellen Datenbestand.
Was machst Du, wenn ein Server ausfällt?
Das Konstrukt scheint mir nicht ganz ausgegoren zu sein.
Hi
DFS-R ist 0-Time Failover, http://help.globalscape.com/help/wafs4/using_microsoft_dfs_for_failover ... dein von dir aufgezeigtes Problem spiegelt Szenario 1 wieder
Deine Config bzw. Installation gibt keine 0 Downtime her, wenn du Downtimes ausschließen bzw. minimieren möchtest musst du DFS im Cluster laufen lassen - Replikation ist deiner Config ist nur ein Abgleich und mit einer 24h Sync eher kontraproduktiv (oder meinst du das die 24/7 läuft?).
Der darunter liegende VMWare Cluster hat mit der von dir dargestellten Config gar nichts zu tun. Es kann auch an Server 2016 liegen, damit haben wir eher bis sehr schlechte Erfahrung im Bereich DFS gemacht und sind wieder zurück auf Server 2012R2 gegangen.
Gruß
@clSchak
DFS-R ist 0-Time Failover, http://help.globalscape.com/help/wafs4/using_microsoft_dfs_for_failover ... dein von dir aufgezeigtes Problem spiegelt Szenario 1 wieder
Scenario 1
A client is browsing through a replicated folder. The computer hosting the replica loses power or drops off the network for some reason. In order to fail over, the client computer must first detect that the hosting computer is no longer present. How long this takes depends on which protocol the client computer is using. Many protocols, such as TCP/IP, account for slow and loosely connected WAN links before the protocol itself times out. After that occurs, DFS immediately selects a new replica. If no protocols are available from the local cache, the DFS client consults with the DFS root to see whether the administrator has modified any PKT entries and initiates a fresh replica selection and session setup.
Deine Config bzw. Installation gibt keine 0 Downtime her, wenn du Downtimes ausschließen bzw. minimieren möchtest musst du DFS im Cluster laufen lassen - Replikation ist deiner Config ist nur ein Abgleich und mit einer 24h Sync eher kontraproduktiv (oder meinst du das die 24/7 läuft?).
Der darunter liegende VMWare Cluster hat mit der von dir dargestellten Config gar nichts zu tun. Es kann auch an Server 2016 liegen, damit haben wir eher bis sehr schlechte Erfahrung im Bereich DFS gemacht und sind wieder zurück auf Server 2012R2 gegangen.
Gruß
@clSchak
@clSchak
Danke für Deinen Link. ich habe deshalb nach der Konfiguration (auch ESXi) nachgefragt, damit ich mir ein gesamtes Bild machen kann.
Wie Du schon geschrieben hast, wurde das DFS nicht nach best practise eingerichtet. Man kann DFS-R und DFS-N gleichzeitig nutzen. Nur man muss es richtig konfigurieren.
Bzgl. Server 2016 kann ich jetzt nichts dazu schreiben. Dazu habe ich zu wenig Erfahrungswerte.
@mksadm
Schau bei Microsoft nach den best practises für die Installation und Konfiguration von DFS, wie ihr es benötigt.
Sollte es tatsächlich am Server 2016 leigen, dann wie von @clSchak empfohlen, auf den Server 2012 R2 downgraden.
Gruss Penny
Danke für Deinen Link. ich habe deshalb nach der Konfiguration (auch ESXi) nachgefragt, damit ich mir ein gesamtes Bild machen kann.
Wie Du schon geschrieben hast, wurde das DFS nicht nach best practise eingerichtet. Man kann DFS-R und DFS-N gleichzeitig nutzen. Nur man muss es richtig konfigurieren.
Bzgl. Server 2016 kann ich jetzt nichts dazu schreiben. Dazu habe ich zu wenig Erfahrungswerte.
@mksadm
Schau bei Microsoft nach den best practises für die Installation und Konfiguration von DFS, wie ihr es benötigt.
Sollte es tatsächlich am Server 2016 leigen, dann wie von @clSchak empfohlen, auf den Server 2012 R2 downgraden.
Gruss Penny
Hi,
ich mische mich mal ein:
Es wäre jetzt wichtig zu wissen, ob nicht bloß die DFS-Ordner von beiden Servern bereitgestellt werden sondern auch die DFS-Root. Wenn die DFS-Root nur von einem Server bereitgstellt wird und dieser eine Server nicht verfügbar ist, dann können die einzelnen DFS-Ordner von je 100 Servern bereitgestellt werden, es würde nichts nützen. Ohne die verfügbare Root als Einstiegspunkt sind die DFS-Ordner auch nicht verfügbar. Also prüfe auch, ob die Root dieses Namespace ebenfalls von mehreren Servern bereitgestellt wird.
Dann ist es noch interessant zu wissen, ob sich beide Server in der selben AD-Site befinden, und in welcher AD-Site sich die Clients befinden.
Ob die Server nun physisch sind oder VM's ist vollkommen irrelevant.
E.
ich mische mich mal ein:
- Es wird so getan, als seien DFS-N und DFS-R Alternativen. Das sind sie nicht! Es sind lediglich 2 Technologie aus dem DFS-Umfeld welche unabhängig voneinander genutzt werden können.
- Zwei Ziele einer DFS-Node, welche mittels DFS-R synchronisiert werden, dürfen und können nicht gleichzeitig über einen Failovercluster bereitgestellt werden, in welchem beide Server sind, welche diesen DFS-Ordner versorgen. Das geht a) technisch überhaupt nicht und wäre b) Nonsens. Ein DFS-Ordner, welcher mit mehreren Zielen (Servern) bereitgstellt wird ist quasi im "DFS-Cluster". Man kann einen DFS-Ordner mit nur einem Ziel bereitstellen und dann dieses eine Ziel mittels eines Failoverclusters redundant bereitstellen. Allerdings dann ohne DFS-Replikation. Da hätte man eine und dieselbe LUN, welche wahlweise von einem der Mitglieder des Failoverclusters bereitgestellt wird.
Es wäre jetzt wichtig zu wissen, ob nicht bloß die DFS-Ordner von beiden Servern bereitgestellt werden sondern auch die DFS-Root. Wenn die DFS-Root nur von einem Server bereitgstellt wird und dieser eine Server nicht verfügbar ist, dann können die einzelnen DFS-Ordner von je 100 Servern bereitgestellt werden, es würde nichts nützen. Ohne die verfügbare Root als Einstiegspunkt sind die DFS-Ordner auch nicht verfügbar. Also prüfe auch, ob die Root dieses Namespace ebenfalls von mehreren Servern bereitgestellt wird.
Dann ist es noch interessant zu wissen, ob sich beide Server in der selben AD-Site befinden, und in welcher AD-Site sich die Clients befinden.
Ob die Server nun physisch sind oder VM's ist vollkommen irrelevant.
E.
OK. Jetzt wissen wir, dass auch die Root über je eine Freigabe auf je einen der beiden Server bereitgestellt wird.
Und es sind beide Freigaben direkt erreichbar?
Wir verhält es sich, wenn Du Server B herunterfährst oder vom Netz trennst? Geht es dann auch nach 30 s weiter oder dann gar nicht mehr?
Aber wenn Du einen dieser Server als "primär" betrachtest, dann solltest Du den 2. Server in eine andere AD-Site verfrachten. Das geht ganz einfach, indem Du im AD ein neues Subnet mit der IP-Adresse des 2. Servers + 32-Bit-Maske anlegst und dieses Subnet einem neuen AD-Standort zuordnest. Dann werden die Clients diesen zweiten Server als "entferntes" Ziel betrachten und den ersten Server bevorzugt suchen.
Schau mal auch hier:
Und es sind beide Freigaben direkt erreichbar?
Starte ich jedoch DFS Server B neu, hängt die Verbindung ca 30 Sekunden, erst dann kann ich wieder arbeiten.
Und diese 30 s sind nicht zufällig jene Zeit, welche der Server B für den Neustart benötigt?Wir verhält es sich, wenn Du Server B herunterfährst oder vom Netz trennst? Geht es dann auch nach 30 s weiter oder dann gar nicht mehr?
Server B ist auch der Primär Server im DSF.
Das ist für DFS-N irrelevant.Aber wenn Du einen dieser Server als "primär" betrachtest, dann solltest Du den 2. Server in eine andere AD-Site verfrachten. Das geht ganz einfach, indem Du im AD ein neues Subnet mit der IP-Adresse des 2. Servers + 32-Bit-Maske anlegst und dieses Subnet einem neuen AD-Standort zuordnest. Dann werden die Clients diesen zweiten Server als "entferntes" Ziel betrachten und den ersten Server bevorzugt suchen.
Schau mal auch hier:
Aber mal am Rande: Wenn es so zeitkritisch bei Euch ist, die Anforderungen an die Verfügbarkeit derart hoch sind, dann würde ich eher auf Failovercluster setzen. Hierbei würde die FS-Rolle vor dem Herunterfahren des aktiven Hosts zuerst auf den anderen Host verschoben. Dadurch bleibt die Freigabe (fast) unterbrechungsfrei verfügbar.
Unter VMware ESX geht das.
Die zusätzliche VMDK muss an VM1 an einem extra virtuellenn SCSI-Controller hängen. In den Eigenschaften des Controllers (habe es jetzt nicht vor Augen) stellst Du das Sharing auf "virtuell", wenn es nur über einen ESX funktionieren soll, oder auf "physisch", wenn es über mehrere ESX funktionieren soll. Wenn es mehrere ESX sind, dann müssen alle den selben Datastore sehen, auf welchem die o.g. VMDK ist. In der 2. VM fügst Du jetzt eine neue Festplatte hinzu, wählst aus "vorhandene", wählst die o.g. selbe VMDK aus. Noch vor dem Speichern den SCSI-Controller wechseln (neuen hinzufügen). Selbe SCSI-ID wie bei VM1 (nicht notwendig aber besser für Fehlersuche, wenn mal mehrere VMDK). Auch die Einstellungen für das Sharing einstellen, analog zu VM1, also "virtuell" oder "physisch".
Jetzt kann man beide VM starten, obwohl sie beide einen Verweis auf die selbe VMDK haben. Ob der Datastore dabei im NFS, FC oder iSCSI liegt, ist vollkommen irrelevant.
E.
Die zusätzliche VMDK muss an VM1 an einem extra virtuellenn SCSI-Controller hängen. In den Eigenschaften des Controllers (habe es jetzt nicht vor Augen) stellst Du das Sharing auf "virtuell", wenn es nur über einen ESX funktionieren soll, oder auf "physisch", wenn es über mehrere ESX funktionieren soll. Wenn es mehrere ESX sind, dann müssen alle den selben Datastore sehen, auf welchem die o.g. VMDK ist. In der 2. VM fügst Du jetzt eine neue Festplatte hinzu, wählst aus "vorhandene", wählst die o.g. selbe VMDK aus. Noch vor dem Speichern den SCSI-Controller wechseln (neuen hinzufügen). Selbe SCSI-ID wie bei VM1 (nicht notwendig aber besser für Fehlersuche, wenn mal mehrere VMDK). Auch die Einstellungen für das Sharing einstellen, analog zu VM1, also "virtuell" oder "physisch".
Jetzt kann man beide VM starten, obwohl sie beide einen Verweis auf die selbe VMDK haben. Ob der Datastore dabei im NFS, FC oder iSCSI liegt, ist vollkommen irrelevant.
E.