30
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?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 350473
Url: https://administrator.de/contentid/350473
Printed on: April 19, 2024 at 01:04 o'clock
30 Comments
Latest comment
Hallo,
ein bißchen dürftig, was Du an Informationen lieferst.
Fragen über Fragen...
Gruss Penny
ein bißchen dürftig, was Du an Informationen lieferst.
- Sind die beiden Server im Cluster?
- Wenn nein, warum nicht?
- Welches DFS wird verwendet (DFS-N, oder DFS-R)
- Sind die Server am gleichen Standort / Brandabschnitt?
- Sind die Server an verschiedenen Standorten?
Fragen über Fragen...
Gruss Penny
Hey Penny,
* Sind die beiden Server im Cluster?
in welchen Cluster genau?* Wenn nein, warum nicht?
weil ich nicht weiß welchen Cluster ich hier nehmen soll* Welches DFS wird verwendet (DFS-N, oder DFS-R)
beides, Namespace sowie Replikation 24h* Sind die Server am gleichen Standort / Brandabschnitt?
ja im gleichen Standort* Sind die Server an verschiedenen Standorten?
nein beide Server sind über FC nur auf 2 verschiedenen Sans aufgeteilt. Ebenso wie auf 2 verschiedenen ESXi Servern. Allerdings befindet sich alles am gleichen Standort, wie in der selben Domäne.
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.
OK, also hast Du zwei VMs auf auf zwei unterschiedlichen ESXi Servern.
Warum dann zwei Server?
Wir haben 6 ESXi ServerWarum dann zwei Server?
Sind die ESXi wenigstens geclustert?
ja die Sind geclustert, VMware spricht hier von HA.Wenn die vSphere Umgebung nicht geclustert ist, warum nicht?
Ist SieWarum startest Du DFS neu? Wenn die Replikation aktiviert ist, hat der zweite Server den aktuellen Datenbestand.
ja die Replikation funktioniert auch einwandfrei. Wenn allerdings ein Server herunterfährt wie oben beschrieben, hängt sich das Netzlaufwerk auf.Was machst Du, wenn ein Server ausfällt?
Wenn welcher Server ausfällt? DFS? ESXi?Das Konstrukt scheint mir nicht ganz ausgegoren zu sein.
Genau aus diesem Grund frage ich hier ja nach
Ich denke ich sollte hier noch meine Informationen an die Gemeinde ergänzen um das Bild klarer zu machen.
6 ESXi Server / 2 SAN das ganze ist via FC angebunden.
DFS Server A läuft auf ESX1 und SAN1, DFS Server B läuft auf ESX2 und SAN2.
Ziel soll es nun sein, wenn DFS Server A ausfällt, das die Daten übergangslos auf Server B übernommen werden können.
6 ESXi Server / 2 SAN das ganze ist via FC angebunden.
DFS Server A läuft auf ESX1 und SAN1, DFS Server B läuft auf ESX2 und SAN2.
Ziel soll es nun sein, wenn DFS Server A ausfällt, das die Daten übergangslos auf Server B übernommen werden können.
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
Hey Schak, intressanter Artikel.
du hast recht, ich meine natürlich 24/7. Welche Einstellung muss den vorgenommen werden, um ein 0-Time Failover erzeugen zu können?
du hast recht, ich meine natürlich 24/7. Welche Einstellung muss den vorgenommen werden, um ein 0-Time Failover erzeugen zu können?
Ich werden das Szenario noch einmal mit 2k12 r2 nachbauen.
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.
Servus Emeriks, ich prüfe das und gebe dir Rückmeldung.
Servus emeriks, wie kann ich prüfen ob beide Server Die Root bereitstellen?
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.
Ja sie befinden sich in der selben AD-Site. Ebenfalls die Clients.Servus emeriks, wie kann ich prüfen ob beide Server Die Root bereitstellen?
Na indem Du in der MMC den Stamm anzeigen lässt, ihn dann links im Baum auswählst und dann rechts im Detailbereich nachschaust?
Dort sehe ich den Namespace, und die Replikation.
Nicht bei den Ordnern sondern beim Stamm!
Auf er rechten Seite heißt die Registrierkarte dann "Namespaceserver"
Auf er rechten Seite heißt die Registrierkarte dann "Namespaceserver"
Zitat von @emeriks:
Nicht bei den Ordnern sondern beim Stamm!
Auf er rechten Seite heißt die Registrierkarte dann "Namespaceserver"
Nicht bei den Ordnern sondern beim Stamm!
Auf er rechten Seite heißt die Registrierkarte dann "Namespaceserver"
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:
Und diese 30 s sind nicht zufällig jene Zeit, welche der Server B für den Neustart benötigt?
Ich kann ihn auch ausschalten, ist das gleiche Ergebnis.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?
Ganz genau, er geht nach 30 Sekunden wiederServer B ist auch der Primär Server im DSF.
Das ist für DFS-N irrelevant.Und diese 30 s sind nicht zufällig jene Zeit, welche der Server B für den Neustart benötigt?
mir ist gerade aufgefallen, das das Netzlaufwerk welches auf den Freigabepfad weist, solange nicht erreichbar ist, bis der Server heruntergefahren ist.
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.
Ja an das dachte ich auch. Ich finde es nur seltsam, das es nicht mit dfs funktioniert.
DFS ist eher für Lastverteilung als für HA gedacht.
Und natürlich die Konsolidierung der Freigaben unter zentrale Namespaces.
Und natürlich die Konsolidierung der Freigaben unter zentrale Namespaces.
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.
Funktioniert der Failovercluster auch mit FC? Ich dachte das funktioniert nur mit ISCSI?
Was hat jetzt die Anbindung via Fibre Channel bzw. iSCSI damit zu tun?
Erkläre Dich.
Erkläre Dich.
Da ich nicht sicher bin, wie ich eine Quorum Platte via VMWare einbinden kann, ohne die Disk über iscsi hinzuzufügen.
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.
Soweit ich weiß, geht es auch unter VMware Workstation.
Muss ich mich mal wieder weiter damit beschäftigen.
Gruss Penny
Muss ich mich mal wieder weiter damit beschäftigen.
Gruss Penny
Danke Emeriks, das ist die Lösung meines Problems. Sehr gut!
Danke auch dir Penny, für deine gute Hilfestellung!
