Grundlegendes zu (fehlenden) verteilten Dateisperren in DFSR

Dieser Artikel befasst sich mit dem Fehlen eines Mechanismus zum Sperren von verteilten Dateien auf mehreren Hosts in Windows und insbesondere in den von DFSR replizierten Ordnern.

Hintergrund

• Distributed File Locking (Sperren von verteilten Dateien) – dies bezieht sich auf das Konzept, mehrere Kopien einer Datei auf mehreren Computern zu haben. Wenn eine Datei zum Schreiben geöffnet wird, werden alle anderen Kopien gesperrt. Dadurch wird verhindert, dass eine Datei auf mehreren Servern gleichzeitig von mehreren Benutzern geändert wird.
• Distributed File System Replication: DFSR (Replikation im verteilten Dateisystem) arbeitet in einem Multimaster, zustandsbasierten Design. Bei der zustandsbasierten Replikation wendet jeder Server im Multimaster-System Aktualisierungen auf seine Replika an, sobald sie eintreffen, ohne Protokolldateien auszutauschen (stattdessen werden Versionsvektoren verwendet, um die „Aktualität“ zu erhalten). Kein einziger Server ist nach der ersten Synchronisierung willkürlich maßgebend, so dass das System hochverfügbar und in verschiedenen Netzwerktopologien sehr flexibel ist.
• Server Message Block: SMB (Server-Nachrichtenblock) ist das allgemeine Protokoll, das in Windows für den Zugriff auf Dateien über das Netzwerk verwendet wird. Vereinfacht ausgedrückt handelt es sich um ein Client-Server-Protokoll, das einen Redirector verwendet, um Remote-Dateisysteme als lokale Dateisysteme erscheinen zu lassen. Er ist nicht spezifisch für Windows und recht weit verbreitet – ein bekanntes Beispiel, das nicht von Microsoft stammt, ist Samba, mit dem Linux, Mac und andere Betriebssysteme als SMB-Clients/Server fungieren und an Windows-Netzwerken teilnehmen können.

Es ist wichtig, klar abzugrenzen, wo sich DFSR und SMB in Ihrer replizierten Datenumgebung befinden. Mit SMB können Benutzer auf ihre Dateien zugreifen, und es kennt kein DFSR. Ebenso hält DFSR (unter Verwendung des RPC-Protokolls) Dateien zwischen Servern synchron und hat keine Kenntnis von SMB. Verwechseln Sie nicht das Sperren verteilter Dateien, wie in diesem Beitrag definiert, mit Opportunistischem Sperren.

Hier kann also einiges schief gehen.

Da Benutzer Daten auf mehreren Servern ändern können und jeder Windows-Server nur eine Dateisperre auf sich selbst kennt undDFSR nichts über die Sperren auf anderen Servern weiß, ist es möglich, dass Benutzer die Änderungen der anderen überschreiben. DFSR verwendet einen Konfliktalgorithmus nach dem Prinzip „der letzte Schreiber gewinnt“, d.h. jemand muss verlieren und derjenige, der als letzter speichert, darf seine Änderungen behalten. Die Dateikopie des „Verlierers“ wird im Ordner ConflictAndDeleted gespeichert.

Das kommt jedoch weitaus weniger häufig vor, als man glauben möchte. Normalerweise werden gemeinsam genutzte Dateien in einer lokalen Umgebung geändert; in der Zweigstelle oder in der gleichen Arbeitsgruppe. Sie werden in der Regel von Mitarbeitern desselben Teams bearbeitet, so dass die Mitarbeiter in der Regel wissen, wenn ein Kollege die Daten ändert. Und da sie sich in der Regel am selben Standort befinden, ist die Wahrscheinlichkeit viel größer, dass alle Benutzer, die an einem gemeinsam genutzten Dokument arbeiten, denselben Server verwenden. Hier regelt Windows SMB die Situation. Wenn ein Benutzer eine Datei zur Änderung gesperrt hat und sein Kollege versucht, sie zu bearbeiten, erhält der andere Benutzer eine Fehlermeldung wie:

Und wenn die Anwendung, die die Datei öffnet, wirklich clever ist, wie z. B. Word 2007, könnte folgendes angezeigt werden:

DFSR verfügt zwar über einen Mechanismus für gesperrte Dateien, aber nur im Kontext des Servers selbst. DFSR repliziert eine Datei nicht ein oder aus, wenn ihre lokale Kopie eine exklusive Sperre hat. Das hindert jedoch niemanden daran, die Datei auf einem anderen Server zu ändern.

Zurück zum Thema: Das Problem, dass gemeinsam genutzte Daten geografisch verändert werden können, existiert tatsächlich und ist für einige Leute ziemlich unangenehm. Gelegentlich werden wir gefragt, warum DFSR dieses Sperren und Entfernen von allem nicht wie durch Zauberhand bewältigen kann. Es stellt sich heraus, dass dies ein interessantes und schwierig zu lösendes Szenario für ein Multimaster-Replikationssystem ist. Sehen wir uns dies einmal genauer an.

Drittanbieterlösungen

Es gibt einige Herstellerlösungen, die sich dieses Problems annehmen und die normalerweise eine oder mehrere der folgenden Methoden anwenden*:

• Verwendung eines Vermittlungsmechanismus

Ein zentraler „Datenverkehrspolizist“ ermöglicht es einem Server, alle anderen Server zu erkennen und zu wissen, welche Dateien durch Benutzer gesperrt sind. Leider bedeutet dies auch, dass es in einem System mit Sperrung verteilter Dateien oft einen einzigen Fehlerpunkt gibt.

• Voraussetzung für ein vollständig geroutetes Netzwerk

Da ein zentraler Vermittler in der Lage sein muss, mit allen Servern zu kommunizieren, die an der Dateireplikation teilnehmen, ist es nicht mehr möglich, komplexe Netzwerktopologien zu handhaben. Ringtopologien und Multi-Hub-and-Spoke-Topologien sind normalerweise nicht möglich. In einem nicht vollständig gerouteten Netzwerk können einige Server möglicherweise nicht direkt miteinander oder mit einem Vermittler Kontakt aufnehmen, sondern nur mit einem Partner, der seinerseits mit einem anderen Server sprechen kann; und so weiter. In einer Multimaster-Umgebung ist das in Ordnung, aber nicht mit einem Vermittlungsmechanismus.

• Beschränkt auf ein Serverpaar

Einige Lösungen beschränken die Topologie auf ein Serverpaar, um ihren Sperrmechanismus verteilter Dateien zu vereinfachen. Für größere Umgebungen ist dies möglicherweise nicht machbar.

• Verwenden Sie Agents auf Clients und Servern
• Verwenden Sie keine Multimaster-Replikation
• Verwenden Sie kein MS-Clustering
• Verwenden Sie spezielle Anwendungen

*Denken Sie daran, dass ich „normalerweise“ gesagt habe! Bitte posten Sie keine Morddrohungen, weil Sie eine Lösung haben, die eine oder mehrere dieser Methoden einsetzt oder nicht einsetzt!

Weiterführende Überlegungen

Wenn Sie weiter über dieses Thema nachdenken, tauchen einige grundlegende Fragen auf. Wenn wir zum Beispiel vier Server mit Daten haben, die von Benutzern an vier Standorten geändert werden können, und die WAN-Verbindung zu einem dieser Server fällt aus, was machen wir dann? Die Benutzer können weiterhin auf ihre einzelnen Server zugreifen. Aber ist das wirklich ratsam? Wir wollen nicht, dass sie Änderungen vornehmen, die im Widerspruch zueinander stehen, aber wir wollen auf jeden Fall, dass sie weiterarbeiten und unserem Unternehmen Geld einbringen. Wenn wir an diesem Punkt willkürlich Änderungen blockieren, kann kein Benutzer mehr arbeiten, obwohl es vielleicht gar keine Konflikte gibt! Es gibt keine Möglichkeit, den anderen Servern mitzuteilen, dass die Datei verwendet wird und Sie stehen wieder am Anfang des Problems.

Und dann ist da noch SMB selbst und die Fehlerbehandlung bei der Meldung von Sperrung. Wir können die Art und Weise, wie SMB Freigabeverletzungen meldet, nicht wirklich ändern, da wir damit eine Vielzahl von Anwendungen zerstören würden und die Clients die neuen erweiterten Fehlermeldungen ohnehin nicht verstehen würden. Anwendungen wie Word 2007 können mit einigen verborgenen Kniffen herausfinden, wer die Dateien sperrt, aber die meisten Anwendungen wissen nicht, wer eine Datei verwendet (oder dass SMB überhaupt existiert. Kein Witz.). Wenn also ein Benutzer die Meldung „Diese Datei wird gerade verwendet“ erhält, ist das nicht besonders aussagekräftig. Sollen dann alle den Helpdesk anrufen? Hat der Helpdesk Zugriff auf alle Dateiserver, um zu sehen, welche Benutzer auf Dateien zugreifen? Verfahrene Situation.

Da wir aus Gründen der Hochverfügbarkeit ein Multimaster-System wünschen, ist ein Vermittlungssystem weniger wünschenswert. Wir müssen vielleicht etwas haben, das auf allen Servern läuft und es ihnen ermöglicht, auch über nicht vollständig geroutete Netzwerke zu kommunizieren. Dies erfordert sehr komplexe Synchronisierungstechniken. Das bedeutet einen gewissen Mehraufwand im Netzwerk (wenn auch wahrscheinlich nicht viel) und es muss blitzschnell sein, um sicherzustellen, dass wir den Benutzer nicht bei seiner Arbeit aufhalten. Es muss die Dateireplikation selbst übertreffen. Vielleicht muss es sogar irgendwie mit der Replikation verbunden sein. Auch Serverausfälle, die auf das Netzwerk zurückzuführen sind und nicht auf Serverabstürze, müssen irgendwie berücksichtigt werden.

Und dann sind wir wieder bei einer speziellen Client-Software für dieses Szenario, die die Sperren besser versteht und dem Benutzer nützliche Informationen geben kann („Rufen Sie Susie in der Buchhaltung an und sagen Sie ihr, sie soll das Dokument freigeben“, „Tut mir leid, die Topologie der Dateisperren ist defekt und Ihr Administrator verhindert, dass Sie diese Datei öffnen, bis das Problem behoben ist“ usw.). Der reibungslose Ablauf mit den Millionen von Anwendungen, die unter Windows laufen, wird noch sehr spannend werden. Es gibt viele Betriebssysteme, die nicht unterstützt werden oder die Software nicht erhalten – Windows 2000 wird nicht mehr unterstützt und XP bald auch nicht mehr. Linux- und Mac-Kunden wird diese Software erst dann zur Verfügung stehen, wenn es für wichtig erachtet wird. Der Kunde muss also hoffen, dass die Anbieter etwas Vergleichbares herstellen.

Weitere Informationen

Im Moment ist die einfachste Möglichkeit, diese Situation in DFSR zu kontrollieren, die Verwendung von DFS Namespaces, um Benutzer zu vorhersehbaren Orten mit einem konsistenten Namespace zu führen. Indem Sie die Topologie Ihrer DFSN-Site und die Serververbindungen richtig konfigurieren, zwingen Sie die Benutzer dazu, sich alle denselben lokalen Server zu teilen, und erlauben ihnen nur dann den Zugriff auf Remote-Computer, wenn ihr „Hauptserver“ ausgefallen ist. In den meisten Umgebungen funktioniert dies recht gut. Als Alternative zu DFSR bietet sich SharePoint mit seinem Check-out/Check-in-System an. BranchCache (verfügbar in Windows Server 2008 R2 und Windows 7) könnte eine Option für Sie sein, da es das Lesen von Dateien in einem Zweigstellenszenario erleichtert. Aber letztendlich werden die maßgeblichen Daten immer noch auf nur einem Server liegen – mehr dazu hier. Und auch diese Anbieter haben ihre Lösungen.