DFS: Dateien in replizierten Verzeichnissen verschwinden

[Joachim Boettcher]

Eine Verzeichnisstruktur wird auf 2 Servern mittels DFS Replikation
vorgehalten. Ein Benutzer greift mit Excel auf eine Datei zu. Die Datei
bleibt geöffnet, hin und wieder werden Änderungen vorgenommen - die
Änderungen werden mittels "Speichern" sofort zurückgeschrieben. Eine zweite
Person möchte die gleiche Datei öffnen. Es kommt nun vor, daß diese Datei
nicht in der DFS-Freigabe angezeigt wird. Wird im physikalischen Verzeichnis
auf dem "einen" Server gesucht, ist die besagte Datei nicht vorhanden. Auf
dem "anderen" Server kann sie jedoch gefunden werden. Ein Doppelklick auf
diese Datei löst das Problem schlagartig. Die Datei ist sofort auf dem
"einen" Server auch wieder verfügbar.
Wie kann die Replikation derartiger Dateien beschleunigt werden ? (Langes
Warten würde bestimmt auch helfen, ist aber nicht akzeptabel. ( Ich spreche
hier über Zeitbereiche von 15 bis 30 min. und länger.) )

[Walter Steinsdorfer [MVP]]

Hallo Joachim,

Post by Joachim Boettcher
Wie kann die Replikation derartiger Dateien beschleunigt werden ?
(Langes Warten würde bestimmt auch helfen, ist aber nicht akzeptabel.
( Ich spreche hier über Zeitbereiche von 15 bis 30 min. und länger.) )

gar nicht, dafür ist DFS nicht gebaut worden. Primär geht es eigentlich
darum, Freigaben unter einem Namensraum zusammenzufassen ( was zum Beispiel
Vorteile bei einer Fileservermigration bietet ). Sofortige Replikation
sollte man ( wenn man es denn wirklich braucht ) auch mit
Enterprise-Produkten lösen, EMC oder Netapp machen da ein paar ganz nette
Sachen.

[unknown]

Enterprise-Produkten lösen, EMC oder Netapp machen da ein paar ganz nette Sachen.

... oder aber die R2 Version von 2003 abwarten, denn dann wird
DFS inkrementell repliziert.
Nur das was geändert wurde und nicht die ganze z.B. 50 MB Datei ;-)

[Denis Jedig]

Post by Walter Steinsdorfer [MVP]
gar nicht, dafür ist DFS nicht gebaut worden.

Dfs ist gar nicht für die Replikation gebaut worden - dafür gibt es
separate Replikationsdienste (z.B. ntfrs oder "Dfs Replication" aus R2),
die sich eher zufällig über die selbe Konsole verwalten lassen.

[Denis Jedig]

Post by Joachim Boettcher
Änderungen werden mittels "Speichern" sofort zurückgeschrieben. Eine zweite
Person möchte die gleiche Datei öffnen. Es kommt nun vor, daß diese Datei
nicht in der DFS-Freigabe angezeigt wird. Wird im physikalischen Verzeichnis
auf dem "einen" Server gesucht, ist die besagte Datei nicht vorhanden.

Passiert dir das auch, wenn die Datei vorher nachweislich auf beiden
Servern zu finden war?

[Joachim Boettcher]

Vielen Dank für die Antworten. Sie sind etwas ernüchternd.

Ja. Die Datei ist auf beiden Servern in dem entsprechenden Verzeichnis
vorhanden. Der beschriebene Effekt tritt z.B. auch auf, wenn beide Personen
die Datei geöffnet haben, eine Person möchte speichern und das System gibt
die Meldung zurück, dass die Datei nicht gespeichert werden kann weil Sie
nicht mehr vorhanden ist.

Ziel der gesamten Aktion sind Sicherheitserwägungen. Es soll ein
Serverausfall abgesichert werden. Das ist sicherlich nicht der Hauptzweck von
DFS aber eine gewisse "Spiegelfunktion" habe ich schon ausnutzen wollen.

Kann denn die Replikationsgeschwindigkeit überhaupt - in bestimmten Grenzen
- vorausbestimmt werden , bzw. beeinflusst werden. Würde das Schließen der
Datei nach der Änderung Abhilfe schaffen ?
--
JBOE

Post by Denis Jedig

Post by Joachim Boettcher
Änderungen werden mittels "Speichern" sofort zurückgeschrieben. Eine zweite
Person möchte die gleiche Datei öffnen. Es kommt nun vor, daß diese Datei
nicht in der DFS-Freigabe angezeigt wird. Wird im physikalischen Verzeichnis
auf dem "einen" Server gesucht, ist die besagte Datei nicht vorhanden.

Passiert dir das auch, wenn die Datei vorher nachweislich auf beiden
Servern zu finden war?
--
Denis Jedig
syneticon networks GbR http://syneticon.net/service/

[Denis Jedig]

Post by Joachim Boettcher
Ja. Die Datei ist auf beiden Servern in dem entsprechenden Verzeichnis
vorhanden. Der beschriebene Effekt tritt z.B. auch auf, wenn beide Personen
die Datei geöffnet haben, eine Person möchte speichern und das System gibt
die Meldung zurück, dass die Datei nicht gespeichert werden kann weil Sie
nicht mehr vorhanden ist.

Das klingt, als wäre bei dir irgendetwas kaputt. Die Funktionsweise von
ntfrs ist recht einfach:

- Nach Änderung der Datei und der Aufgabe der zugehörigen Schreibsperre
wird die Datei vom Replikationsservice in ein Staging-Verzeichnis kopiert
- anschließend wird die Datei zum Replikationspartner in sein
Staging-Verzeichnis übertragen
- nach Abschluss der Übertragung wird die Datei (wenn auf der Gegenseite
keine Dateisperre dies verhindert) im Zielverzeichnis durch die aus dem
Staging-Verzeichnis ersetzt

Eine Datei, die geöffnet ist, wird in aller Regel vom Prozess, in dem sie
geöffnet ist, mit einem Shared Lock versehen und kann ab da auch nicht
gelöscht werden, bevor der Prozess die Sperre aufgibt. Deshalb erscheint
das beschriebene Verhalten mehr als eigentümlich. Welche Anwendungen nutzt
du denn?

Post by Joachim Boettcher
Ziel der gesamten Aktion sind Sicherheitserwägungen. Es soll ein
Serverausfall abgesichert werden. Das ist sicherlich nicht der Hauptzweck von
DFS aber eine gewisse "Spiegelfunktion" habe ich schon ausnutzen wollen.

Das kann man machen, solange du sicher stellen kannst, dass alle Anwender
nur auf einem einzigen deiner Replika Daten schreiben. Dies lässt sich
meist mit entsprechender Site-Konfiguration bewerkstelligen.

Post by Joachim Boettcher
Kann denn die Replikationsgeschwindigkeit überhaupt - in bestimmten Grenzen
- vorausbestimmt werden , bzw. beeinflusst werden.

Man kann über die Eigenschaften des Sitelinks oder über die Eigenschaften
der Replika eine Zeitspanne festlegen, in der die Replikation stattfinden
darf (oder eben auch nicht) - man kann nicht die Bandbreite oder die
Reaktionsgeschwindigkeit des Service auf die Dateiänderungen beeinflussen.

Post by Joachim Boettcher
Würde das Schließen der Datei nach der Änderung Abhilfe schaffen ?

Das kommt auf die Art der Sperre an, mit der die Datei geöffnet wird - und
damit auf die Applikation.

Lektüre:

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/techref/7636AEDE-A944-4765-8973-40DC1E1F2D56.mspx

http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/windows/2000/server/reskit/en-us/distrib/dsdh_frs_vkhu.asp
http://support.microsoft.com/default.aspx?scid=kb;en-us;272279
http://support.microsoft.com/default.aspx?scid=kb;en-us;221112

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/24fc82bb-0e78-4a5f-8d55-fa43618cac9d.mspx

[Daniel Melanchthon [MSFT]]

Post by Joachim Boettcher
Vielen Dank für die Antworten. Sie sind etwas ernüchternd.

Hallo Joachim,

grundsätzlich ist DFS und FRS nicht für das gemacht und geeignet, was Du
vorhast. Ich würde an Deiner Stelle entweder auf DFS-Replikation verzichten
(DFS selbst knnst Du weiternutzen) und zum Spiegeln der Daten auf einen
Zweitserver regelmäßig robocopy nutzen oder auf Windows Server 2003 R2
demnächst umsteigen. DFS-N und DFS-R sind dann dafür auch vorgesehen und
unterstützen Primary und Secondary Server mit Failover und Failback.

[Denis Jedig]

[...] DFS-R

Ich habe mir sagen lassen, dass Steve Ballmer sehr ungehalten werden kann,
wenn er den Namen DFS-R hört ;-)

sind dann dafür auch vorgesehen und
unterstützen Primary und Secondary Server mit Failover und Failback.

Failback? Wo?

[Daniel Melanchthon [MSFT]]

Post by Denis Jedig
Failback? Wo?

Wo? Oder wohin?

[Denis Jedig]

Post by Daniel Melanchthon [MSFT]

Post by Denis Jedig
Failback? Wo?

Wo? Oder wohin?

Wo? Und wie? Dfs-Replikaauswahl findet ja am Client statt und dieser hält
an einem Target fest, wenn er erst einmal ein erreichbares gefunden hat.

[Daniel Melanchthon [MSFT]]

Post by Denis Jedig

Post by Daniel Melanchthon [MSFT]

Post by Denis Jedig
Failback? Wo?

Wo? Oder wohin?

Wo? Und wie? Dfs-Replikaauswahl findet ja am Client statt und dieser hält
an einem Target fest, wenn er erst einmal ein erreichbares gefunden hat.

ich zitiere mal:

Windows Server 2003 R2 delivers the vision and underlying technologies
needed for the seamless integration of branch office servers into a larger
enterprise ecosystem. R2 allows customers to maintain the performance,
availability, and productivity benefits of a local branch server while
avoiding connectivity limitations and management overhead.
To achieve this vision, R2 provides a branch office framework for the
deployment and management of key server roles that is conceptually:

• Optional.
Remote clients can fail over from the local branch office server to another
server—by closest site selection—if local services become unavailable. They
automatically fail back to a preferred server when services are restored.

• Disposable.
The branch office server performs as a service cache that does not hold a
unique state and does not require system backup. If the server fails, there
is no impact on branch office functionality.

• Replaceable.
If the branch server fails, it can be replaced, reprovisioned, or
redeployed—server roles are well-adapted for branch offices and varying
roles can be deployed as one. The recovery of data is automated.

Aus:
Windows Server 2003 R2: Support for Branch Offices
http://www.microsoft.com/windowsserver2003/techinfo/overview/branchoffice.mspx

Wir halten dazu übrigens am 15.12. einen Webcast. Es ist Teil 3 einer Reihe
zum Thema Windows Server 2003 R2:

TechNet Webcast: Windows Server 2003 R2 (Teil 3)
Niederlassungen effizienter anbinden (Level 200)
15.12.2005 15:30 Uhr
http://msevents-eu.microsoft.com/cui/eventdetail.aspx?eventid=118765653&culture=de-de

[Denis Jedig]

Post by Daniel Melanchthon [MSFT]

[failback - wo?]

server—by closest site selection—if local services become unavailable. They
automatically fail back to a preferred server when services are restored.

Irgendwo ein Paper, wie genau das umgesetzt wurde? Gibt es eine
Aktualisierung für die Dfs-Clients? Wenn ja - für welche? Und für welche
nicht? (Dfs-Clients gibt es schließlich sogar für Windows 95)

[Daniel Melanchthon [MSFT]]

Post by Denis Jedig
Irgendwo ein Paper, wie genau das umgesetzt wurde? Gibt es eine
Aktualisierung für die Dfs-Clients? Wenn ja - für welche? Und für welche
nicht? (Dfs-Clients gibt es schließlich sogar für Windows 95)

Was es zur Zeit an technischen Infos gibt, findest Du hier:
http://www.microsoft.com/windowsserver2003/R2/branchoffice/default.mspx
und hier: http://technet2.microsoft.com/windowsserver/en/r2.mspx

Den Windows Server 2003 R2 Release Candidate 0 hast Du auf dem IT Forum
imho bekommen - den RC1 gibt es hier:
http://www.microsoft.com/windowsserver2003/R2/trial/default.mspx

[Denis Jedig]

Post by Daniel Melanchthon [MSFT]

Post by Denis Jedig
Irgendwo ein Paper, wie genau das umgesetzt wurde? Gibt es eine
Aktualisierung für die Dfs-Clients? Wenn ja - für welche? Und für welche
nicht? (Dfs-Clients gibt es schließlich sogar für Windows 95)

http://www.microsoft.com/windowsserver2003/R2/branchoffice/default.mspx
und hier: http://technet2.microsoft.com/windowsserver/en/r2.mspx

Das ist leider noch ziemlich dünn - hoffen wir, dass es bis zum Release
Dokumentation in der Qualität der technischen Referenz gibt.

[Joachim Boettcher]

Noch eine weitere Frage zu diesem Thema.
U.a. beklagt der Benutzer auch, daß er bis zu 15 min. warten muss, um eine
bereits bearbeitete und wieder geschlossene Datei erneut öffnen zu können,
weil sie im Verzeichnis nicht eher zur Verfügung steht. Diese Datei wurde
von sonst keiner anderen Person verwendet. Deutet dieses Zeitverhalten auf
einen Fehler hin oder ist es für DFS "normal" ?
Es besteht die Möglichkeit, die Benutzer auf einen vorausbestimmbaren
Server auf phys. DFS-Verzeichnisse zugreifen zu lassen, indem ich ein
übergeordnetes Verzeichnis des DFS-Pfades freigebe und diese Freigabe für die
Dateizugriffe verwende. Wahrscheinlich hätte der Benutzer aber dann mit den
oben beschriebenen Problemen dennoch zu kämpfen !?
--
JBOE

Post by Joachim Boettcher
Eine Verzeichnisstruktur wird auf 2 Servern mittels DFS Replikation
vorgehalten. Ein Benutzer greift mit Excel auf eine Datei zu. Die Datei
bleibt geöffnet, hin und wieder werden Änderungen vorgenommen - die
Änderungen werden mittels "Speichern" sofort zurückgeschrieben. Eine zweite
Person möchte die gleiche Datei öffnen. Es kommt nun vor, daß diese Datei
nicht in der DFS-Freigabe angezeigt wird. Wird im physikalischen Verzeichnis
auf dem "einen" Server gesucht, ist die besagte Datei nicht vorhanden. Auf
dem "anderen" Server kann sie jedoch gefunden werden. Ein Doppelklick auf
diese Datei löst das Problem schlagartig. Die Datei ist sofort auf dem
"einen" Server auch wieder verfügbar.
Wie kann die Replikation derartiger Dateien beschleunigt werden ? (Langes
Warten würde bestimmt auch helfen, ist aber nicht akzeptabel. ( Ich spreche
hier über Zeitbereiche von 15 bis 30 min. und länger.) )
--
JBOE

[Joachim Boettcher]

Vielen Dank für Eure Infos. Ich glaube, ich habe eine Menge zu lesen.
--
JBOE

Post by Joachim Boettcher
Eine Verzeichnisstruktur wird auf 2 Servern mittels DFS Replikation
vorgehalten. Ein Benutzer greift mit Excel auf eine Datei zu. Die Datei
bleibt geöffnet, hin und wieder werden Änderungen vorgenommen - die
Änderungen werden mittels "Speichern" sofort zurückgeschrieben. Eine zweite
Person möchte die gleiche Datei öffnen. Es kommt nun vor, daß diese Datei
nicht in der DFS-Freigabe angezeigt wird. Wird im physikalischen Verzeichnis
auf dem "einen" Server gesucht, ist die besagte Datei nicht vorhanden. Auf
dem "anderen" Server kann sie jedoch gefunden werden. Ein Doppelklick auf
diese Datei löst das Problem schlagartig. Die Datei ist sofort auf dem
"einen" Server auch wieder verfügbar.
Wie kann die Replikation derartiger Dateien beschleunigt werden ? (Langes
Warten würde bestimmt auch helfen, ist aber nicht akzeptabel. ( Ich spreche
hier über Zeitbereiche von 15 bis 30 min. und länger.) )
--
JBOE