W2K8 - Domainbasierendes DFS mit Replikationen, Warnungen in der Ereignisanzeige

[MartinAD 10]

Hallo,

 

ich bin neu hier und muss gleich mit einer (für mich) verzwickten Frage auftreten.

 

Ich habe ein Domainbasierendes DFS mit 2 W2K8 Storage Servern konfiguriert. Meine Freigaben im Namespace werden auf jeweils 2 Namespace Servern gehostet und auch auf diesen beiden Servern repliziert. Der 2. Server ist bei jedem Namespace-Ziel als "letztes aller Ziele" konfiguriert um so einen Hot-Standby zu erreichen.

 

Die Replikation der Daten verläuft soweit Problemlos. Als ich allerdings heute in den Server Manager schaue war ich etwas über diese "Warnung" verdutzt:

 

Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen für die Datei. Der Dienst konnte das Staging für eine Datei für die Replikation aufgrund einer Freigabeverletzung nicht durchführen. 

Weitere Informationen: 
Dateipfad: D:\groups\labor_abwasser_analytik\analyse\analyse.mdb 
Stamm des replizierten Ordners: D:\groups\labor_abwasser_analytik 
Datei-ID: {90E9888D-011E-4132-A5DC-DF106D7F30A0}-v169162 
Name des replizierten Ordners: awa 
ID des replizierten Ordners: C734BB2D-18F8-47DC-8745-53C3D42A3C85 
Replikationsgruppenname: xyz.com\data\awa 
Replikationsgruppen-ID: 1CC91A79-FD1D-457C-9942-7A53D630E7E1 
Mitglieds-ID: 0425275E-1AF5-43AB-A47A-3E460D1189B2

 

Die Datei ist eine MDB Datei, ich weis nicht inwieweit die Dateien Probleme mit DFS Replikationen machen - allerdings hab ich bei meiner Dokumentations Lektüre keine Hinweise über Probleme bei der Replizierung solcher Dateien finden können.

 

Das kuriose ist allerdings: Schaue ich mir diese Datei lokal auf beiden Servern an, ist sowohl die änderungszeit (14:33 Uhr) als auch die Dateigröße (aufs Byte genau) identisch. Wie kann das sein? Habt ihr evtl. Hinweise für mich?

 

Danke für Eure Hilfe!

Gruß

Martin

[Necron 71]

Hi und willkommen an Board,

 

wenn du die EventID und die Quelle des Ereignis hast, dann kannst du unter http://www.eventid.net danach suchen.;)

[olc 18]

Hi Martin und wilkommen an Board, :)

 

Access sperrt MDB-Dateien für den Zugriff (sog. file locking), daher kann DFSR diese Daten nicht replizieren. Generelle Empfehlung ist, auf DFSR replizierten Ordnern keine Datenbanken abzulegen (egal ob MDB oder PST etc.).

 

Siehe dazu auch: Ask the Directory Services Team : Top 10 Common Causes of Slow Replication with DFSR

 

Viele Grüße

olc

[MartinAD 10]

Das sind 2 sehr hilfreiche Tips gewesen, danke schonmal.

 

Interessant ist der Blog im 2. Post, besonders die Stelle:

 

Some applications will allow you to specify an alternate location for temporary and working files, or will simply follow the working path as specified in their shortcuts. But sometimes, this type of behavior may be unavoidable, and you will be forced to live with it or stop storing that type of data in a DFSR-replicated location. This is why our recommendation is that DFSR be used to store primarily static data, and not highly dynamic files like Roaming Profiles, Redirected Folders, Home Directories, and the like. This also helps with conflict resolution scenarios where the same or multiple users update files on two servers in between replication, and one set of changes is lost.

 

Dumm nur für mich, das ich das bis jetzt nicht wusste und eigentlich viele meiner Daten genau solcher Art sind (Home-Directories, Datenbanken usw.). Zwar nicht das Gro der Daten, trotzdem - die ein oder Andere Access Datei wird er schon anmeckern.

 

Gut, ich könnte jetzt MDB Dateien oder generell Dateien die bekannterweise lange im File-Lock sind von der Replikation ausnehmen. Da ich aber ein Hot-Standby Szenario mit dem DFS abdecken wollte, bringt mir das dann nicht viel.

 

Bricht mir mein Hauptserver weg, schaltet sich zwar der 2. Server still ein - aber auf dem existiert (mangels Replikation) natürlich nur eine veraltete Version der (natürlich überlebenswichtigen) MDB Datenbank.

 

Habt ihr vielleicht eine Idee wie man so ein Szenario praxistauglich vermeiden kann? Mir würde jetzt nur der Weg über meinen Backend-Administrator einfallen und hoffen das er mir eine akzeptabel-alte MDB Datei zrückholen kann.

[olc 18]

Hey Martin,

 

ganz ehrlich - DFSR ist halt kein vollständiger "Cluster-Ersatz". Also der "Hot Stand-by" Gedanke bzw. dieses Design an sich ist nicht optimal.

 

Wenn es um Ausfallsicherheit geht, dann solltet Ihr über einen Cluster nachdenken. Wenn das vom Budget her nicht ausreicht, dann bleibt nur die DFSR Variante, bei der Ihr dann jedoch mit genau diesen Einschränkungen leben müßt. :(

 

AUsgewachsene Lösungen wie Datenreplikation auf Blockbasis lasse ich jetzt einmal raus - denn die kosten ebenfalls eine Stange Geld, so daß dann sicher auch ein Cluster drin wäre.

 

Viele Grüße

olc

[MartinAD 10]

Haja dann ist des halt so - ich hab zwar bei etlichen Quellen gelesen das man auf diese weise einen Hot-Standby realisieren kann, allerdings war mit zu der Zeit noch nichts über diese Einschränkungen bekannt.

 

Mit Clustersystemen kenne ich mich in der Praxis nicht aus - hier müsste man sicher einen Experten ranholen der ganz tief in der Materie drin ist befürchte ich.

 

Ok, ich danke euch für Eure Hinweise und die Hilfe. Alles in Allem denke ich das ICH mit den Einshränkungen leben kann - eine 70% Hot-Standby Lösung ist besser als keine.

 

Zumal die Server ohnehin über ein SAN abgesichert sind und das DFS somit nur dem Software-Crash vorgreifen muss und hier auch nur die Zeit überbrücken muss bis der Haupt-Server wieder da ist. Das mit den geöffneten Files ist unschön und kann auch Probleme verursachen - aber hier fehlt mir (und ich glaube auch meinen Kollegen) einfach das Know How und auch die Zeit um wirklich eine Enterprise-fähige Clusterlösung mal eben zwischen Tür und Angel zu entwerfen. Danke nochmal für die Konstruktiven Beiträge :)

[olc 18]

Hi Martin,

 

tut mir Leid, daß wir keine anderen Hinweise geben können als die oben genannten. :)

 

Aber es ist ehrlich gesagt angenehm zu lesen, daß Ihr Eure Ressourcen entsprechend ehrlich einschätzt - das ist gut. Schlimm wird es immer nur, wenn die Konsequenz aus solch einer technischen Einschränkung lautet: "Irgendwie muß es doch gehen, wir frickeln das irgendwie hin."

 

Die Konsequenz von Dir ist sicherlich schmerzhaft aber meines Erachtens wirklich "gut so". :)

 

Viele Grüße

olc

[MartinAD 10]

Was heißt "tut euch leid" - ist doch absolut ok, solange ich die technischen einschränkungen kenne, kann ich die auch kommunizieren und mich drauf einstellen.

 

Ich hab das Thema eben mit meinem Chef durchgesprochen, er ist jetzt auch "gebrieft" und ist derselben Meinung wie ich.

 

Schade finde ich nur das ich nichts von diesen Einschränkungen in der offiziellen DFS Doku UND im offiziellen W2K8 Handbuch von MS Press lesen durfte - dann hätte ich mich auch früher auf sowas einstellen können.

 

Aber danke nochmal für eure Tips, die waren Gold wert!