Grundlegendes zu (fehlenden) verteilten Dateisperren in DFSR

In diesem Artikel wird die Abwesenheit eines verteilten Dateisperrmechanismus mit mehreren Hosten innerhalb Windows und insbesondere innerhalb von Ordnern erläutert, die von DFSR repliziert wurden.

Einige Hintergrundinformationen

  • Verteilte Dateisperre – dies bezieht sich auf das Konzept, mehrere Kopien einer Datei auf mehreren Computern zu haben und wenn eine Datei zum Schreiben geöffnet wird, werden alle anderen Kopien gesperrt. Dadurch wird verhindert, dass eine Datei gleichzeitig auf mehreren Servern von mehreren Benutzern geändert wird.
  • Verteilte Dateisystemreplikation – DFSR arbeitet in einem mehrmasterbasierten, zustandsbasierten Design. In der zustandsbasierten Replikation wendet jeder Server im Multimastersystem Aktualisierungen für das Replikat an, während sie ankommen, ohne Protokolldateien zu austauschen (stattdessen verwendet er Versionsvektoren, um "aktuelle Informationen" zu erhalten). Kein Server ist nach der anfänglichen Synchronisierung beliebig autoritativ, sodass es auf verschiedenen Netzwerktopologien hoch verfügbar und sehr flexibel ist.
  • Servernachrichtenblock – SMB ist das allgemeine Protokoll, das in Windows für den Zugriff auf Dateien über das Netzwerk verwendet wird. In vereinfachten Ausdrücken ist es ein Clientserverprotokoll, das eine Umleitung verwendet, um Remotedateisysteme als lokale Dateisysteme zu verwenden. Es ist nicht spezifisch für Windows und ist ziemlich häufig – ein bekanntes Nicht-Microsoft-Beispiel ist Samba, was Linux, Mac und andere Betriebssysteme ermöglicht, als SMB-Clients/-Server zu handeln und an Windows Netzwerken teilzunehmen.

Es ist wichtig, eine klare Linie zu machen, wo DFSR und SMB in Ihrer replizierten Datenumgebung leben. SMB ermöglicht Benutzern den Zugriff auf ihre Dateien, und es hat kein Bewusstsein für DFSR. Ebenso behält DFSR (mithilfe des RPC-Protokolls) Dateien in der Synchronisierung zwischen Servern und weist keine Kenntnis von SMB auf. Verwechseln Sie die verteilte Sperrung nicht wie in diesem Beitrag definiert und opportunistische Sperrung.

Hier ist also, wo dinge birnform gehen können, wie die Briten sagen.

Da Benutzer Daten auf mehreren Servern ändern können und da jeder Windows Server nur über eine Dateisperre selbst weiß, und da DFSR nichts über diese Sperren auf anderen Servern weiß, wird es möglich, dass Benutzer die Änderungen der anderen überschreiben können. DFSR verwendet einen Konfliktalgorithmus "Last Writer Wins", sodass jemand verlieren muss und die Person, die zuletzt gespeichert werden soll, ihre Änderungen beibehalten kann. Die verlorene Dateikopie wird in den Ordner "ConflictAndDeleted" eingefügt.

Jetzt ist dies weit weniger häufig als Menschen, die glauben möchten. In der Regel werden true freigegebene Dateien in einer lokalen Umgebung geändert; in der Zweigstelle oder in derselben Zeile von Würfeln. Sie werden in der Regel von Personen im gleichen Team bearbeitet, sodass die Personen im Allgemeinen wissen, dass Kollegen Daten ändern. Und da sie in der Regel auf derselben Website sind, sind die Chancen viel höher, dass alle Benutzer, die an einem freigegebenen Dokument arbeiten, den gleichen Server verwenden. Windows SMB behandelt die Situation hier. Wenn ein Benutzer eine Datei für Änderungen gesperrt hat und sein Kollegen versucht, es zu bearbeiten, erhält der andere Benutzer einen Fehler wie:

Screenshot of the File In Use dialog box showing an error message that says This action can't be completed because the file is open in another program.

Und wenn die Anwendung, die die Datei öffnet, wirklich clever ist, wie Word 2007, kann es Ihnen geben:

Screenshot of the File In Use dialog box showing three actions you can take when a file is locked by another user.

DFSR verfügt über einen Mechanismus für gesperrte Dateien, aber nur im eigenen Kontext des Servers. DFSR repliziert keine Datei in oder aus, wenn die lokale Kopie über eine exklusive Sperre verfügt. Dies verhindert jedoch, dass jeder auf einem anderen Server die Datei ändert.

Zurück zu thema, ist das Problem der änderung von freigegebenen Daten geografisch vorhanden, und für einige Leute ist es ziemlich narrisch. Wir werden gelegentlich gefragt, warum DFSR diese Sperrung nicht behandelt und alles mit einer Wellen der Magischen Wand nimmt. Dies ist ein interessantes und schwieriges Szenario, das für ein Multimaster-Replikationssystem gelöst werden kann. Sehen wir uns dies einmal genauer an.

Lösungen von Drittanbietern

Es gibt einige Anbieterlösungen, die dieses Problem übernehmen, was sie in der Regel durch eine oder mehrere der folgenden Methoden *angehen:

  • Verwendung eines Brokermechanismus

Mit einem zentralen "Datenverkehrs-Cop" kann ein Server alle anderen Server kennen und welche Dateien von Benutzern gesperrt wurden. Leider bedeutet dies auch, dass es oft einen einzigen Fehlerpunkt im verteilten Sperrsystem gibt.

Diagram showing the use of a broker mechanism.

  • Anforderung für ein voll weitergeleitetes Netzwerk

Da ein zentraler Broker in der Lage sein muss, mit allen Servern zu sprechen, die an der Dateireplikation teilnehmen, entfernt dies die Möglichkeit, komplexe Netzwerktopologien zu behandeln. Ringtopologien und Multi-Hub-and-Spoke-Topologien sind in der Regel nicht möglich. In einem nicht vollständig weitergeleiteten Netzwerk können einige Server möglicherweise nicht direkt aneinander oder einen Broker wenden und nur mit einem Partner sprechen, der sich selbst mit einem anderen Server sprechen kann – und so weiter. Dies ist in einer Multi-Master-Umgebung gut, aber nicht mit einem Brokermechanismus.

Diagram showing the requirement for a fully routed network.

  • Sind auf ein Paar von Servern beschränkt

Einige Lösungen beschränken die Topologie auf ein Paar von Servern, um ihren verteilten Sperrmechanismus zu vereinfachen. Für größere Umgebungen ist dies möglicherweise nicht möglich.

  • Verwenden von Agents auf Clients und Servern
  • Verwenden Sie keine Multimasterreplikation
  • Verwenden Sie keine MS-Clustering
  • Verwenden von Spezialgeräten

* Beachten Sie, dass ich in der Regel sage! Bitte posten Sie keine Todesdrohungen, da Sie über eine Lösung verfügen, die keine oder mehrere dieser Methoden implementiert!

Tiefere Gedanken

Wie Sie weiter über dieses Problem nachdenken, beginnen einige grundlegende Probleme, die aufstehen. Wenn beispielsweise vier Server mit Daten vorhanden sind, die von Benutzern in vier Websites geändert werden können, und die WAN-Verbindung zu einem davon geht offline, was tun wir? Die Benutzer können weiterhin auf ihre einzelnen Server zugreifen – aber sollten wir sie zulassen? Wir möchten nicht, dass sie Änderungen an diesem Konflikt vornehmen, aber wir möchten, dass sie unbedingt arbeiten und unser Unternehmen Geld verdienen. Wenn wir Änderungen an diesem Punkt willkürlich blockieren, können keine Benutzer funktionieren, obwohl möglicherweise keine Konflikte auftreten! Es gibt keine Möglichkeit, die anderen Server zu informieren, dass die Datei verwendet wird, und Sie befinden sich wieder auf einem Quadrat.

Diagram showing the results of a partial network outage.

Dann gibt es SMB selbst und die Fehlerbehandlung von Berichtssperren. Wir können nicht wirklich ändern, wie SMB-Berichte über die Freigabe von Verletzungen berichten, da wir einen Ton von Anwendungen unterbrechen und Clients trotzdem keine neuen erweiterten Fehlermeldungen verstehen würden. Anwendungen wie Word 2007 machen einige unterdeckende Tricks, um herauszufinden, wer Dateien sperrt, aber die große Mehrheit der Anwendungen weiß nicht, wer eine Datei verwendet (oder sogar, dass SMB vorhanden ist. Wirklich.) Wenn ein Benutzer die Nachricht "Diese Datei wird verwendet" erhält, ist es also nicht besonders aktionsfähig – sollten sie alle den Helpdesk aufrufen? Hat der Helpdesk Zugriff auf alle Dateiserver, um zu sehen, welche Benutzer auf Dateien zugreifen? Chaotisch.

Da wir mehr Master für hohe Verfügbarkeit wünschen, ist ein Brokersystem weniger wünschenswert; Möglicherweise müssen wir auf allen Servern etwas ausführen, mit dem sie alle über nicht vollständig weitergeleitete Netzwerke kommunizieren können. Dies erfordert sehr komplexe Synchronisierungstechniken. Es wird einige Kosten auf dem Netzwerk hinzufügen (obwohl wahrscheinlich nicht viel) und es muss blitzschnell sein, um sicherzustellen, dass wir den Benutzer in ihrer Arbeit nicht halten; es muss die Dateireplikation selbst auslaufen - tatsächlich muss es tatsächlich an die Replikation gebunden werden. Außerdem müssen Serverausfälle, die Netzwerkverknüpfungen sind, und nicht serverbezogene Abstürzen, irgendwie berücksichtigt werden.

Diagram showing Locking and Replication across five servers.

Und dann kehren wir zu spezieller Clientsoftware für dieses Szenario zurück, die die Sperren besser verstehen und dem Benutzer einige nützliche Informationen geben kann ("Rufen Sie Susie in Buchhaltung auf und teilen Sie sie mit, dass diese Dokumentation veröffentlicht wird", "Leider ist die Dateisperrtopologie unterbrochen, und Ihr Administrator verhindert, dass Sie diese Datei öffnen, bis sie behoben ist", usw.) Dies ist schön mit den Millionen von Anwendungen zu spielen, die in Windows ausgeführt werden, ist definitiv interessant. Es gibt viele Betriebssystems, die nicht unterstützt oder die Software erhalten würden – Windows 2000 ist aus dem Mainstream-Support und XP bald nicht mehr verfügbar. Linux- und Mac-Clients würden diese Software erst dann haben, wenn sie es wichtig waren, sodass der Kunde hoffen muss, dass seine Anbieter etwas analog gemacht haben.

Weitere Informationen

Die einfachste Möglichkeit zum Steuern dieser Situation in DFSR besteht darin, DFS-Namespaces zu verwenden, um Benutzer zu vorhersehbaren Speicherorten mit einem konsistenten Namespace zu führen. Indem Sie Ihre DFSN-Websitetopologie und Serverlinks ordnungsgemäß konfigurieren, erzwingen Sie Benutzern, denselben lokalen Server zu teilen und nur auf Remotecomputer zuzugreifen, wenn ihr "Hauptserver" herunter ist. Für die meisten Umgebungen funktioniert dies ziemlich gut. Alternativ zu DFSR ist SharePoint eine Option aufgrund ihres Check-Out/Check-In-Systems. BranchCache (in Windows Server 2008 R2 und Windows 7) ist möglicherweise eine Option für Sie, da sie für das Lesen von Dateien in einem Verzweigungsszenario konzipiert ist, aber am Ende wird die autoritativen Daten immer noch nur auf einem Server live – mehr dazu hier. Und wieder haben diese Anbieter ihre Lösungen.