Zugriffsprobleme auf Fileserver nach Failover-Knotenwechsel
Hallo zusammen,
bei uns im Unternehmen bin ich mitverantwortlich für die IT und wir sind dabei die alte Serverumgebung auf neue Hardware und aktuelle OS umzuziehen. Zu unserem konkreten Problem habe ich allerdings hier im Forum noch keine Lösung gefunden oder einen klugen Google Hinweis gefunden. Daher habe ich mir mal einen Account erstellt
Wir haben leider noch ein fehlerhaftes Verhalten unseres Failoverclusters festgestellt, da den Endnutzer an den Clients nach einer Übergabe an den anderen Knoten kein Zugriff mehr möglich ist.
Zunächst möchte ich grob das Setup vorstellen:
Wir haben einen Failovercluster mit den beiden Dell Servern konfiguriert. In diesem ist ein Fileserver eingerichtet, welcher auf den zentralen Storage zugreift. Der Zugriff durch die Endnutzer erfolgt durch über GPO eingebundene Netzlaufwerke, welche auf Freigaben im Server Manager und im DFS eingerichteten Namespaces basieren. Das DFS arbeitet domänenbasiert, ist somit nicht auf den beiden lokalen Servern gehostet und entsprechend auch nicht Teil des Failoverclusters. Standardmäßig läuft dieses gesamte Setup auf Server2 und wir können da keine Fehler beim Arbeiten feststellen - alles läuft wie gewünscht.
Bei einem Ausfall (/Herunterfahren) von Server2 übernimmt dann Server1. Ein manueller Wechsel des Knotens ist ebenso möglich. Das Failover-Management an sich scheint also zu funktionieren. Serverseitig wird der Fileserver dann auch am Server1 eingebunden und die Partitionen sind über den Windows Explorer erreichbar. Allerdings haben die Endnutzer auf den Clients dann partiell keinen Lese- & Schreibzugriff mehr. Unsere Beobachtung ist, dass man zwar mit dem Windows Explorer durch die Ordner navigieren kann und auch beispielsweise Textdateien erzeugen kann. Allerdings ist es nicht möglich .pdf/.xlsx/.png/... zu öffnen oder zu speichern. Eine Neuanmeldung der Endnutzer führt nicht zum Erfolg.
Im Vergleich zum vorherigen Setup mit den alten Servern haben wir quasi nur etwas am DFS geändert, welches vorher selbstständig mit als Clusterressource gehostet wurde und somit im Failover-Fall ebenso mit auf den neuen Server übergeben wurde. Daher liegt der erste Verdacht darin, dass das domänenbasierte DFS System Probleme hat, wenn der Fileserver den Knoten wechselt. Dagegen spricht aber, dass man als Endnutzer aber weiterhin durch die Ordner navigieren kann.
Kennt vielleicht jemand die Problematik und kann uns helfen oder zumindest Ansatzpunkte geben, was man prüfen sollte?
Vorab ein großes Dankeschön! Ich bin da ehrlicherweise mit meinen Kenntnissen überfragt und habe keinen konkreten Ansatzpunkt mehr.
Viele Grüße!
bei uns im Unternehmen bin ich mitverantwortlich für die IT und wir sind dabei die alte Serverumgebung auf neue Hardware und aktuelle OS umzuziehen. Zu unserem konkreten Problem habe ich allerdings hier im Forum noch keine Lösung gefunden oder einen klugen Google Hinweis gefunden. Daher habe ich mir mal einen Account erstellt
Wir haben leider noch ein fehlerhaftes Verhalten unseres Failoverclusters festgestellt, da den Endnutzer an den Clients nach einer Übergabe an den anderen Knoten kein Zugriff mehr möglich ist.
Zunächst möchte ich grob das Setup vorstellen:
- Fileserver: 1x Dell Storage System
- Server: 2x Dell Server mit Windows Server 2019
- Domänencontroller: zentral in der übergeordneten Unternehmseinheit gehostet inkl DFS-Einstellungen
- Zugriff der Endnutzer: Einbindung über ein Netzlaufwerk an den Clients, welches auf DFS-Namespace Freigaben zugreift
Wir haben einen Failovercluster mit den beiden Dell Servern konfiguriert. In diesem ist ein Fileserver eingerichtet, welcher auf den zentralen Storage zugreift. Der Zugriff durch die Endnutzer erfolgt durch über GPO eingebundene Netzlaufwerke, welche auf Freigaben im Server Manager und im DFS eingerichteten Namespaces basieren. Das DFS arbeitet domänenbasiert, ist somit nicht auf den beiden lokalen Servern gehostet und entsprechend auch nicht Teil des Failoverclusters. Standardmäßig läuft dieses gesamte Setup auf Server2 und wir können da keine Fehler beim Arbeiten feststellen - alles läuft wie gewünscht.
Bei einem Ausfall (/Herunterfahren) von Server2 übernimmt dann Server1. Ein manueller Wechsel des Knotens ist ebenso möglich. Das Failover-Management an sich scheint also zu funktionieren. Serverseitig wird der Fileserver dann auch am Server1 eingebunden und die Partitionen sind über den Windows Explorer erreichbar. Allerdings haben die Endnutzer auf den Clients dann partiell keinen Lese- & Schreibzugriff mehr. Unsere Beobachtung ist, dass man zwar mit dem Windows Explorer durch die Ordner navigieren kann und auch beispielsweise Textdateien erzeugen kann. Allerdings ist es nicht möglich .pdf/.xlsx/.png/... zu öffnen oder zu speichern. Eine Neuanmeldung der Endnutzer führt nicht zum Erfolg.
Im Vergleich zum vorherigen Setup mit den alten Servern haben wir quasi nur etwas am DFS geändert, welches vorher selbstständig mit als Clusterressource gehostet wurde und somit im Failover-Fall ebenso mit auf den neuen Server übergeben wurde. Daher liegt der erste Verdacht darin, dass das domänenbasierte DFS System Probleme hat, wenn der Fileserver den Knoten wechselt. Dagegen spricht aber, dass man als Endnutzer aber weiterhin durch die Ordner navigieren kann.
Kennt vielleicht jemand die Problematik und kann uns helfen oder zumindest Ansatzpunkte geben, was man prüfen sollte?
Vorab ein großes Dankeschön! Ich bin da ehrlicherweise mit meinen Kenntnissen überfragt und habe keinen konkreten Ansatzpunkt mehr.
Viele Grüße!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666269
Url: https://administrator.de/forum/zugriffsprobleme-auf-fileserver-nach-failover-knotenwechsel-666269.html
Ausgedruckt am: 17.05.2025 um 07:05 Uhr
2 Kommentare
Neuester Kommentar
Hi,
Wir haben bei und die DFS-Stämme mit min. 2 Stamm-Freigaben auf 2 Servern eingerichtet. Bei uns sind das i.A. Domaincontroller.
Die Ziele der DFS-Ordner liegen auf FS-Rollen im Failovercluster. Manche repliziert, mit mehreren Replikaten, und manche mit nur genau einem Ziel, ohne Replikation.
Das am Rande erwähnt.
Wenn nur bestimmte Typen, dann schau mal, ob da einseitig nur auf dem Server1 nicht etwa der "Ressourcen-Manager für Dateiserver" konfiguriert ist, nur bestimmte Dateitypen zuzulassen o.ä.
E.
welches vorher selbstständig mit als Clusterressource gehostet wurde
Warum "selbstverständlich"? Das muss so nicht sein, weil domänenbasiertes DFS ein eigenes Failover hat.Wir haben bei und die DFS-Stämme mit min. 2 Stamm-Freigaben auf 2 Servern eingerichtet. Bei uns sind das i.A. Domaincontroller.
Die Ziele der DFS-Ordner liegen auf FS-Rollen im Failovercluster. Manche repliziert, mit mehreren Replikaten, und manche mit nur genau einem Ziel, ohne Replikation.
Das am Rande erwähnt.
Allerdings ist es nicht möglich .pdf/.xlsx/.png/... zu öffnen oder zu speichern.
Nur bestimmte Dateitypen oder generell keine Dateien?Wenn nur bestimmte Typen, dann schau mal, ob da einseitig nur auf dem Server1 nicht etwa der "Ressourcen-Manager für Dateiserver" konfiguriert ist, nur bestimmte Dateitypen zuzulassen o.ä.
E.
"Selbstständig" Also damit meine ich, dass im früherem Setup im Failovercluster zusätzlich zu dem Fileserver und den 2 VMs ( + Hyper VM Rolle) noch ein eigener DFS-Namespaceserver als Rolle definiert war. Jetzt sind wir auf Anraten eines anderen Systemadministrators einer anderen Firma auf das jetzige Setup gewechselt: DFS-Stamm über die Domäne und damit auch auf dem Domänencontroller abgelegt. Wie der jetzt gegen einen Ausfall gesichert ist weiß ich ehrlicherweise nicht. Ich glaube aber nicht, dass das eine Auswirkung auf unser Failover hätte.
Ein weitere Beobachtung ist auch, dass bei Win7 Clients (jaja, Schande über mein Haupt. Aber stellenweise ist echt alte Software im Einsatz und da macht die Kompatibilität Probleme - wir sind aber dran!) der Windows Explorer beim Wechsel des Knotens immer auf die höchste Ebene des Netzlaufwerks springt (z.B. Nutzer ist auf X:/Projekt1/OrdnerA/... dann springt er immer auf P:/ zurück). Bei Win10 konnte ich das nicht beobachten.
Danke für die ersten Hinweise!
Also damit meine ich, dass im früherem Setup im Failovercluster zusätzlich zu dem Fileserver und den 2 VMs ( + Hyper VM Rolle) noch ein eigener DFS-Namespaceserver als Rolle definiert war. Jetzt sind wir auf Anraten eines anderen Systemadministrators einer anderen Firma auf das jetzige Setup gewechselt: DFS-Stamm über die Domäne und damit auch auf dem Domänencontroller abgelegt. Wie der jetzt gegen einen Ausfall gesichert ist weiß ich ehrlicherweise nicht. Ich glaube aber nicht, dass das eine Auswirkung auf unser Failover hätte.Zitat von @emeriks:
Wenn nur bestimmte Typen, dann schau mal, ob da einseitig nur auf dem Server1 nicht etwa der "Ressourcen-Manager für Dateiserver" konfiguriert ist, nur bestimmte Dateitypen zuzulassen o.ä.
Bei meinen Tests versuche ich es immer gerne mit .txt Dateien aus um Zugriffsrechte und Freigaben zu prüfen. Da schien eigentlich alles zu laufen. Bei .pdfs/.xlsx/.jpg... hatte ich aber immer Probleme, auch mit einer Neuanmeldung des Testaccounts. Daher danke für den Hinweis, an einen solchen Fehler habe ich nicht gedacht! Wir haben auch eine Kontingentverwaltung aktiv, daher ist der Gedanke nicht abwegig, dass wir da einen Fehler beim Einstellen gemacht haben!Allerdings ist es nicht möglich .pdf/.xlsx/.png/... zu öffnen oder zu speichern.
Nur bestimmte Dateitypen oder generell keine Dateien?Wenn nur bestimmte Typen, dann schau mal, ob da einseitig nur auf dem Server1 nicht etwa der "Ressourcen-Manager für Dateiserver" konfiguriert ist, nur bestimmte Dateitypen zuzulassen o.ä.
Ein weitere Beobachtung ist auch, dass bei Win7 Clients (jaja, Schande über mein Haupt. Aber stellenweise ist echt alte Software im Einsatz und da macht die Kompatibilität Probleme - wir sind aber dran!) der Windows Explorer beim Wechsel des Knotens immer auf die höchste Ebene des Netzlaufwerks springt (z.B. Nutzer ist auf X:/Projekt1/OrdnerA/... dann springt er immer auf P:/ zurück). Bei Win10 konnte ich das nicht beobachten.
Danke für die ersten Hinweise!
