Inhaltsverzeichnis
Ein Bereich, der vielen Netzwerkadministratoren Probleme verursacht, sind Sperren. Das Ausmaß des Problems ist bereits durch Recherchen über das Internet bewiesen.
Samba bietet alle Sperrsemantiken, die MS Windows-Clients erwarten und die MS Windows NT/200x-Server auch zur Verfügung stellen.
Der Ausdruck Sperren (entsprechend dem etwas treffenderen englischen Begriff Locking, Anm. d. Übers.) hat grundsätzlich eine weite Bedeutung und deckt eine Vielzahl von Funktionen ab, die alle unter diesem einen Begriff zusammengefasst sind.
Opportunistisches Sperren ist ein wünschenswertes Feature, wenn es die wahrnehmbare Geschwindigkeit von Anwendungen auf einem Netzwerkclient beschleunigen kann. Jedoch ist das opportunistische Sperrprotokoll nicht robust, und deshalb können Probleme entstehen, wenn es von einer einfachen Konfiguration oder in einem sehr langsamen oder fehlerhaften Netzwerk aufgerufen wird. In diesen Fällen können der Aufwand für die Verwaltung der opportunistischen Sperren, die vom Betriebssystem durchgeführt wird, und der Aufwand für das Wiederherstellen nach Fehlern den erzielten Performance-Zuwachs wieder zunichte machen.
Der MS Windows-Netzwerkadministrator muss sich darüber im Klaren sein, dass Datei- und Satzsperren-Semantiken (Verhalten) entweder in Samba kontrolliert werden können oder durch Registry-Einstellungen auf einem MS Windows-Client.
Manchmal ist es sogar notwendig, Einstellungen zu Sperrkontrollen sowohl auf dem Samba-Server als auch auf dem MS Windows-Client abzuschalten!
Es gibt zwei Arten von Sperren, die durch einen SMB-Server durchgeführt werden müssen. Die erste ist die Satzsperre, die einem Client das Sperren eines Bereichs von Bytes innerhalb einer geöffneten Datei erlaubt. Die zweite sind die Verbotszustände (deny modes), die spezifiziert werden, wenn eine Datei geöffnet ist.
Satzsperren-Semantiken unter UNIX sind etwas vollkommen anderes als Satzsperren unter Windows. Samba-Versionen vor 2.2 hatten versucht, den nativen UNIX-Systemaufruf fcntl() zu nutzen, um saubere Satzsperren zwischen den verschiedenen Samba-Clients zu implementieren. Dies kann allerdings aus mehreren Gründen nicht vollständig richtig sein. Der einfachste Grund ist die Tatsache, dass ein Windows-Client einen Byte-Bereich von bis zu 2^32 oder 2^64 (je nach Client-Betriebssystem) sperren darf. Die UNIX-Sperren unterstützen nur einen Byte-Bereich bis zu 2^31. So ist es nicht möglich, eine Sperranfrage oberhalb von 2^31 sauber zu ermöglichen. Es gibt noch wesentlich mehr Unterschiede, zu viele, um hier alle aufzuführen.
Samba 2.2 und jüngere Versionen implementieren Satzsperren völlig unabhängig vom darunterliegenden UNIX-System. Wenn eine Byte-Bereichssperre, die ein Client anfordert, in den Bereich von 0-2^31 fällt, gibt Samba diese Anfrage an das UNIX-System weiter. Alle anderen Sperren können von UNIX jedoch nicht gesehen werden.
Vereinfacht ausgedrückt, sollte ein SMB-Server vor jedem Lese- und Schreibzugriff auf eine Datei nach Sperren suchen. Leider kann dies durch die Art und Weise, wie fcntl() arbeitet, langsam sein und den rpc.lockd überbeanspruchen. Dies ist fast immer unnötig, da von den Clients erwartet wird, dass sie unabhängig Sperr-Aufrufe vor Lese- und Schreibzugriffen absetzen, wenn das Sperren für sie wichtig ist. In der Voreinstellung setzt Samba nur dann Sperr-Aufrufe, wenn es explizit von einem Client danach gefragt wird; aber wenn Sie die Option strict locking = yes setzen, wird es diese Aufrufe bei jedem Lese- und Schreibzugriff ausführen.
Sie können das Sperren von Byte-Bereichen auch komplett abschalten, indem Sie locking = no setzen. Das ist hilfreich für jene Freigaben, die die Sperren nicht unterstützen oder sie nicht brauchen (wie CD-ROMs). In diesem Fall bildet Samba die Antwort-Codes von Sperr-Aufrufen nach, um den Clients mitzuteilen, dass alles in Ordnung ist.
Die zweite Klasse der Sperren sind die so genannten deny modes. Diese werden von einer Applikation gesetzt, wenn diese eine Datei öffnet, um zu bestimmen, welche Zugriffsarten gleichzeitig mit dieser Öffnung zu erlauben sind. Ein Client könnte nach DENY_NONE, DENY_READ, DENY_WRITE oder DENY_ALL fragen. Es gibt auch spezielle Kompatibilitätsmodi namens DENY_FCB und DENY_DOS.
Das opportunistische Sperren, auch bezeichnet als „Oplocks“ (entspricht „Opportunistic locking“) wird vom Windows-Dateisystem über Registrierungseinträge aufgerufen (im Gegensatz zu einer API), um die Netzwerk-Performance zu erhöhen, wenn auf eine Datei auf einem Server zugegriffen wird. Die Performance wird durch lokales Puffern der Datei auf dem Client erhöht, was Folgendes erlaubt:
Der Client liest die lokale Kopie der Datei, dadurch wird die Netzwerk-Latenz eliminiert.
Der Client schreibt in die lokale Kopie der Datei, dadurch wird die Netzwerk-Latenz eliminiert.
Der Client puffert die Sperren der Anwendung lokal, und wieder wird die Netzwerk-Latenz eliminiert.
Die Performance-Steigerung von Oplocks kommt von der Möglichkeit des exklusiven Zugriffs auf die Datei sogar wenn sie über DENY_NONE geöffnet ist , da Windows den Status der Datei auf konkurrierende Zugriffe von anderen Prozessen überwacht.
Windows definiert vier Arten von Oplocks:
Der Redirektor sieht, dass die Datei mit DENY_NONE geöffnet wurde (was konkurrierende Zugriffe erlaubt), prüft, ob auch kein anderer Prozess auf die Datei zugreift, und prüft, dass Oplocks aktiviert sind. Dann gewährt er DENY_ALL/R+W/Exklusiv-Zugriff auf die Datei. Der Client führt seine Operationen nun auf die gepufferte Datei durch.
Wenn ein zweiter Prozess nun versucht, die Datei zu öffnen, wird das Öffnen verzögert, während der Redirektor den originalen Oplock „aufbricht“. Dieser Bruch des Oplocks signalisiert dem puffernden Client, die gepufferte Datei zurück auf den Server zu schreiben, die lokalen Sperren zu löschen und die Read-ahead-Daten zu verwerfen. Der Bruch ist dann komplett, die verzögerte Öffnung wird gewährt, und mehrere Prozesse können konkurrierenden Dateizugriff genießen, wie er von den Byte-Bereichs- oder den zwingenden Sperren diktiert wird. Wenn jedoch der originale öffnende Prozess die Datei in einem anderen Modus als DENY_NONE geöffnet hat, wird dem zweiten Prozess nur eingeschränkter oder gar kein Zugriff gewährt, trotz des Bruchs des Oplocks.
Arbeitet wie ein Level1 Oplock, außer dass nur Lesezugriffe gepuffert werden. Alle anderen Operationen werden auf der Server-Kopie der Datei durchgeführt.
Erlaubt keinen Schreib- oder Löschzugriff auf Dateien.
Manipuliert das Öffnen und Schließen von Dateien und erlaubt das Puffern von Dateiattributen.
Ein wichtiges Detail ist, dass Oplocks vom Dateisystem aufgerufen werden, nicht von einer Anwendungs-API. Daher kann eine Applikation eine opportunistisch gesperrte Datei schließen, aber das Dateisystem gibt den Oplock nicht auf. Wenn der Bruch des Oplocks durchgeführt wird, schließt das Dateisystem einfach die Datei in Vorbereitung auf das folgende Öffnen der Datei durch den zweiten Prozess.
Opportunistisches Sperren ist eigentlich ein unpassender Name für dieses Feature. Der wirkliche Nutzen dieses Features ist das Puffern von Daten („Cachen“) auf Client-Seite, und die Oplocks sind nur ein Mitteilungsmechanismus für das Zurückschreiben von Daten auf die Platte des Netzwerk-Servers. Die Einschränkung der Oplocks ist die Zuverlässigkeit des Mechanismus, einen Oplock-Bruch (Mitteilung) zwischen dem Server und dem puffernden Client auszuführen. Wenn dieser Austausch fehlerhaft abläuft (üblicherweise wegen eines Timeouts aus irgendwelchen Gründen), dann geht der Nutzen des client-seitigen Pufferns verloren.
Die tatsächliche Entscheidung, die ein Anwender oder Administrator erwägen sollte, ist, ob es vernünftig ist, unter mehreren Anwendern Daten zu teilen, die lokal auf den Clients gepuffert werden. In vielen Fällen ist die Antwort „Nein“. Zu entscheiden, wann Daten gepuffert werden und wann nicht, das ist hier die Frage, und daher sollte „opportunistisches Sperren“ als Schalter für client-seitiges Puffern behandelt werden. Schalten Sie es „on“, wenn client-seitiges Puffern erwünscht und zuverlässig ist. Schalten Sie es „off“, wenn client-seitiges Puffern redundant, unzuverlässig oder kontraproduktiv ist.
Opportunistisches Sperren wird von Samba standardmäßig für alle Freigaben auf „on“ gesetzt, also sollten Sie in jedem Fall vorsichtig vorgehen, um zu bestimmen, ob der potenzielle Nutzen die potenziellen Verzögerungen wert ist. Die folgenden Empfehlungen sollen Ihnen dabei helfen, eine Umgebung zu charakterisieren, in der opportunistische Sperren effektiv eingerichtet werden können.
Die Windows-Oplocks sind ein leichtgewichtiges performance-steigerndes Feature. Sie sind kein robustes und zuverlässiges Protokoll. Jede Implementierung von Oplocks sollte als Kompromiss zwischen Performance und Zuverlässigkeit geprüft werden. Die Zuverlässigkeit sinkt mit jeder oben genannten Regel, die nicht erzwungen wird. Stellen Sie sich einen Hochverfügbarkeits-Server auf einem Atoll im Südpazifik vor, der über ein WAN eine „mission-critical“ Multi-User-Firmen-Datenbank bereitstellt, und das auf einer Freigabe mit aktivierten Oplocks, während eines tropischen Sturms. Diese Konfiguration wird sehr wahrscheinlich Probleme mit Oplocks erfahren.
Oplocks können sehr wirksam die Client-Performance steigern, wenn sie als Konfigurationsschalter für client-seitiges Daten-Puffern behandelt werden. Wenn das Puffern der Daten wahrscheinlich unterbrochen werden könnte, sollte der Einsatz von Oplocks nochmals überdacht werden. Samba aktiviert standardmäßig die Verwendung von Oplocks auf allen Freigaben. Die client-seitige Verwendung von Daten auf dem Server, die Zuverlässigkeit des Servers im Netzwerk und die Oplock-Konfiguration jeder Freigabe sollten mit besonderer Aufmerksamkeit bedacht und konfiguriert werden. In Hochverfügbarkeitsumgebungen hat die Integrität der Daten oft hohe Priorität. Komplexe und teure Konfigurationen werden implementiert, um zu gewährleisten, dass sofort ein Ersatz verfügbar ist, wenn ein Client die Verbindung zum Dateiserver verliert, damit die durchgehende Verfügbarkeit der Daten gewährleistet ist.
Das Verhalten von Windows-Clients bei Ausfällen birgt ein höheres Risiko von Anwendungsunterbrechungen als das Verhalten anderer Plattformen, da es von einer aufgebauten TCP-Transport-Verbindung abhängt. Wenn die Verbindung unterbrochen wird wie bei einem Datei-Server-Ausfall und dessen Ersatz durch einen Failover-Server , muss eine neue Verbindung aufgebaut werden. Es ist selten, dass eine Windows-Client-Applikation so programmiert ist, dass sie sich korrekt von einer unterbrochenen Transport-Verbindung erholt. Daher werden die meisten Applikationen in irgendeiner Art unterbrochen im schlimmsten Fall abgebrochen, und erfordern einen Neustart.
Wenn eine Client-Session Schreib- und Lese-Vorgänge mit Oplocks lokal gepuffert hat, ist es wahrscheinlich, dass die Daten verloren gehen, wenn die Applikation neu startet oder sich nach der TCP-Unterbrechung wieder verbindet. Wenn die TCP-Verbindung ausfällt, ist der Status des Clients verloren. Wenn der Server die Verbindung wiederherstellt, wird keine Aufforderung zum Brechen des Oplocks an den Client gesandt. In diesem Fall ist die Arbeit aus der vorangegangenen Session verloren. Durch Echtzeit-Überwachung dieses Szenarios mit deaktivierten Oplocks und des Clients, der Daten auf den Datei-Server schreibt, wird die Ausfallsicherung die Daten auf der Platte so bewahren, wie sie zum Zeitpunkt des Verbindungsabbruchs existiert haben.
In „mission-critical“ Hochverfügbarkeitsumgebungen sollte große Vorsicht im Umgang mit Oplocks geübt werden. Idealerweise sollten umfassende Tests mit allen betroffenen Applikationen erfolgen, sowohl mit als auch ohne aktivierte Oplocks.
Opportunistische Sperren sind am effektivsten, wenn sie auf Freigaben beschränkt sind, auf die ausschließlich ein einzelner Anwender zugreift oder nur ein Anwender gleichzeitig. Da der eigentliche Wert der Oplocks das client-seitige Puffern von Daten ist, verursacht jede Operation, die den Puffer-Mechanismus unterbricht, eine Verzögerung.
Home-Verzeichnisse sind die offensichtlichsten Beispiele für das sichere Realisieren von Performanc-Steigerungen mit Oplocks.
Mit jedem weiteren Anwender, der auf eine Datei auf einer Freigabe mit aktiven Oplocks zugreift, erhöht sich das Potenzial für Verzögerungen und eine daraus resultierende Performance-Verschlechterung. Wenn mehrere Anwender auf eine Datei auf einer Freigabe mit aktiven Oplocks zugreifen, übersteigt der Verwaltungsaufwand für das Senden und Empfangen der Oplock-Breaks und die resultierende Latenz, während die anderen Clients auf den momentan puffernden Client warten (bis er seine Puffer geleert hat), den Performance-Gewinn des puffernden Clients.
Mit jedem weiteren Client, der auf eine Datei mit gesetzten Oplocks zugreift, wird der potenzielle Performance-Zuwachs negiert, und es ergibt sich eventuell sogar ein Flaschenhals.
Lokale UNIX- oder NFS-Clients greifen ohne einen zwingenden Datei-Sperren-Mechanismus auf Dateien zu. Daher sind diese Client-Plattformen nicht imstande, vom Server aus einen Oplock-Bruch am Client zu erfragen, der gerade eine Datei puffert. Ein lokaler UNIX- oder NFS-Dateizugriff kann daher in eine Datei schreiben, die von einem Windows-Client gepuffert wurde, was diese Datei sehr wahrscheinlich unbrauchbar macht.
Wenn Dateien sowohl an Windows-Clients als auch an lokale UNIX- oder NFS-Benutzer freigegeben werden, sollten Sie das opportunistische Sperren abschalten.
Der größtmögliche Performance-Gewinn für Oplocks wird dann erzielt, wenn das client-seitige Puffern der Lese- und Schreib-Vorgänge den größten Unterschied zum Senden dieser Vorgänge über das Netzwerk liefert. Dies passiert am wahrscheinlichsten dann, wenn das Netzwerk extrem langsam, verstopft oder weit verteilt (wie in einem WAN) ist. Die Netzwerk-Latenz hat jedoch auch einen großen Einfluss auf die Zuverlässigkeit des Oplock-Bruch-Mechanismus und erhöht daher die Wahrscheinlichkeit, Oplock-Probleme zu bekommen, die die potenziellen Performance-Gewinne mehr als zunichte machen. Wenn natürlich niemals ein Oplock-Bruch gesendet werden müsste, wäre dies das vorteilhafteste Szenario, um Oplocks einzusetzen.
Wenn das Netzwerk langsam, unzuverlässig oder ein WAN ist, sollten Sie keine Oplocks konfigurieren, falls irgendeine Möglichkeit besteht, dass mehrere Benutzer regelmäßig dieselbe Datei öffnen.
Mehrbenutzer-Datenbanken stellen klarerweise durch ihre grundlegende Natur ein Risiko dar auf sie wird üblicherweise massiv von vielen Anwendern in zufälligen Intervallen zugegriffen. Das Platzieren einer Mehrbenutzer-Datenbank auf einer Freigabe mit aktivierten Oplocks wird wahrscheinlich zu einem Flaschenhals auf dem Samba-Server führen, weil die Sperren verwaltet werden müssen. Egal, ob eine Datenbank eine Eigenentwicklung ist oder ein kommerzielles Produkt, stellen Sie sicher, dass die entsprechende Freigabe deaktivierte Oplocks hat.
Process Data Management-(PDM-)Applikationen wie IMAN, Enovia und Clearcase finden immer mehr Verwendung mit Windows-Client-Plattformen und daher auch mit SMB-Daten-Servern. PDM-Applikationen verwalten Mehrbenutzer-Umgebungen für die Sicherheit von und den Zugriff auf kritische Daten. Die typische PDM-Umgebung ist üblicherweise mit ausgeklügelt entworfenen Client-Anwendungen verbunden, die Daten bei Bedarf lokal laden. Zusätzlich überwacht die PDM-Applikation üblicherweise den Daten-Status jeden Clients. In diesem Fall wird das client-seitige Puffern am besten der lokalen Applikation und dem PDM-Server überlassen. Es ist angemessen, das Client-OS von jeglichen Puffer-Aufgaben zu befreien, und auch den Server von der Verwaltung der Oplocks, indem man Oplocks auf der Freigabe deaktiviert.
Samba enthält einen Parameter in smb.conf namens force user, der den Benutzer, der auf eine Freigabe zugreift, vom tatsächlich zugreifenden Benutzer auf den in diesem Parameter angegebenen ändert. Wenn Oplocks auf einer Freigabe aktiviert sind, verursacht die Änderung des Benutzers, dass ein Bruch des Oplocks an den Client gesendet wird, sogar wenn der Benutzer gar nicht explizit eine Datei geladen hat. In den Fällen, wo das Netzwerk langsam oder unzuverlässig ist, kann ein Oplock-Bruch verloren gehen, ohne dass der Benutzer auch nur auf eine Datei zugreift. Das kann sichtbare Performance-Einbrüche verursachen, wenn der Client wiederholt neu verbindet, um den verlorenen Oplock-Bruch „zu überwinden“.
Vermeiden Sie die folgende Kombination:
Samba bietet Oplock-Parameter, die es dem Administrator erlauben, verschiedene Eigenschaften des Oplock-Mechanismus an Timing- und Benutzungs-Level anzupassen. Diese Parameter bieten hohe Flexibilität, um Oplocks in Umgebungen zu implementieren, wo sie sehr wahrscheinlich Probleme verursachen würden. Die Parameter sind: oplock break wait time und oplock contention limit.
Falls diese Parameter benötigt werden, ist es für die meisten Anwender, Administratoren und Umgebungen die bessere Wahl, die Oplocks einfach abzuschalten. Der Samba-SWAT-Hilfetext für diese beiden Parameter sagt: „Do not change this parameter unless you have read and understood the Samba oplock code.“ Dies ist ein guter Rat.
In Hochverfügbarkeitsumgebungen ist die Integrität der Daten oft von hoher Priorität. Komplexe und teure Konfigurationen werden implementiert, um zu gewährleisten, dass sofort ein Ersatz verfügbar ist, wenn ein Client die Verbindung zum Dateiserver verliert, damit eine durchgehende Verfügbarkeit der Daten gewährleistet ist.
Das Verhalten von Windows-Clients bei Ausfällen birgt ein höheres Risiko von Anwendungsunterbrechungen als andere Plattformen, da es von einer aufgebauten TCP-Transport-Verbindung abhängt. Wenn die Verbindung unterbrochen wird wie bei einem Datei-Server-Ausfall und dessen Ersatz durch einen Failover-Server muss eine neue Verbindung aufgebaut werden. Es ist selten, dass eine Windows-Client-Applikation so programmiert ist, dass sie sich korrekt von einer unterbrochenen Transport-Verbindung erholt. Daher werden die meisten Applikationen in irgendeiner Art unterbrochen im schlimmsten Fall abgebrochen und erfordern einen Neustart.
Wenn eine Client-Session Schreib- und Lese-Vorgänge mit Oplocks lokal gepuffert hat, ist es wahrscheinlich, dass die Daten verloren gehen, wenn die Applikation neu startet oder sich nach der TCP-Unterbrechung wieder verbindet. Wenn die TCP-Verbindung ausfällt, ist der Status des Clients verloren. Wenn der Server die Verbindung wiederherstellt, wird keine Aufforderung zum Brechen des Oplocks an den Client gesandt. In diesem Fall ist die Arbeit aus der vorangegangenen Session verloren. Durch die Echtzeit-Überwachung dieses Szenarios mit deaktivierten Oplocks und des Clients, der Daten auf den Datei-Server schreibt, wird die Ausfallsicherung die Daten auf der Platte so bewahren, wie sie zum Zeitpunkt des Verbindungsabbruchs existiert haben.
In „mission-critical“ Hochverfügbarkeitsumgebungen sollte große Vorsicht im Umgang mit Oplocks geübt werden. Idealerweise sollten umfassende Tests mit allen betroffenen Applikationen erfolgen, sowohl mit als auch ohne aktivierte Oplocks.
Oplocks sind ein einzigartiges Datei-Sperr-Feature von Windows. Sie sind keine richtigen Dateisperren, werden aber in die meisten Diskussionen über Windows-Dateisperren miteinbezogen, also de facto als Sperr-Feature betrachtet. Oplocks sind tatsächlich ein Teil des Windows-Client-Datei-Caching-Mechanismus. Sie sind kein speziell robustes oder zuverlässiges Feature, wenn sie in der Vielzahl von angepassten Netzwerken implementiert werden, die es in Unternehmensumgebungen gibt.
Wie Windows implementiert Samba Oplocks als eine server-seitige Komponente des client-seitigen Cache-Mechanismus. Wegen des leichtgewichtigen Entwurfs des Windows-Features muss man für die effektive Konfiguration von Oplocks ihre Einschränkungen genau kennen und dieses Wissen beim Konfigurieren des Datenzugriffs für jeden einzelnen Zustand von Netzwerk- und Client-Verwendung auch anwenden.
Opportunistisches Sperren bedeutet grundsätzlich, dass es dem Client erlaubt wird, eine Datei herunterzuladen und sie lokal auf seiner Platte zu puffern, während er Veränderungen daran vornimmt; wenn ein zweiter Client auf die Datei zugreifen will, erhält der erste Client ein Signal zum Bruch des Oplocks und muss die Datei wieder zurück auf den Server synchronisieren. Dies kann in einigen Fällen deutliche Performance-Steigerungen verursachen; manche Programme bestehen nur für eine einzelne Veränderung auf der Synchronisation der gesamten Datei mit dem Server.
Level1 Oplocks (auch bekannt als einfache „Oplocks“) sind ein anderer Begriff für das opportunistische Sperren.
Level2 Oplocks bieten opportunistisches Sperren für eine Datei, die als read only behandelt wird. Dies wird typischerweise für Dateien verwendet, die read-only sind, oder für Dateien, bei denen beim Öffnen keine Absicht besteht, darauf zu schreiben.
Kernel-Oplocks sind grundsätzlich eine Methode, die es dem Linux-Kernel erlaubt, mit Sambas opportunistisch gesperrten Dateien zu koexistieren, obwohl dies eine bessere Integration von MS-Windows-Netzwerk-Dateisperren mit dem darunterliegenden Betriebssystem gebracht hat; SGI IRIX und Linux sind derzeit die einzigen oplock-fähigen Betriebssysteme.
Sie sollten Oplocks deaktivieren, wenn Sie auf dieselben Dateien sowohl von UNIX/Linux- als auch von SMB-Clients aus zugreifen, außer wenn Ihr System Kernel-Oplocks unterstützt. Unabhängig davon sollten Oplocks immer deaktiviert sein, wenn Sie eine Datenbank-Datei (z.B. Microsoft Access) für mehrere Clients freigeben, da jeder Oplock-Bruch, den der erste Client empfängt, die Synchronisation der gesamten Datei bewirkt (nicht nur des einzelnen Eintrags), was in einer merklichen Beeinträchtigung der Performance resultiert, und, noch wahrscheinlicher, in Problemen mit dem Zugriff auf die Datenbank. Bemerkenswerterweise reagieren Microsoft Outlooks persönliche Ordner (*.pst) ziemlich schlimm auf Oplocks. Im Zweifelsfall sollten Sie Oplocks deaktivieren und Ihr System von diesem Ausgangspunkt aus einstellen.
Wenn client-seitiges Cachen in Ihrem Netzwerk erwünscht und zuverlässig ist, werden Sie vom Aktivieren der Oplocks profitieren. Wenn Ihr Netzwerk langsam und/oder unzuverlässig ist oder Sie Ihre Dateien über mehr als einen Freigabe-Mechanismus (z.B. NFS) oder ein WAN bereitstellen oder viele Anwender regelmäßig auf dieselben Dateien zugreifen, werden Sie voraussichtlich wegen des entstehenden Overheads durch das Management der Oplocks nicht von einer Aktivierung profitieren. In diesem Fall werden Sie die Oplocks stattdessen lieber deaktivieren.
Ein weiterer zu bedenkender Faktor ist die resultierende Performance des Dateizugriffs. Wenn Oplocks keinen messbaren Geschwindigkeitszuwachs in Ihrem Netzwerk bringen, macht es wahrscheinlich keinen Sinn, sich mit ihnen herumzuschlagen.
Im folgenden Abschnitt untersuchen wir zwei verschiedene Aspekte der Samba-Sperren.
Sie können Oplocks wie folgt auf einer Pro-Freigabe-Basis deaktivieren:
| [acctdata] |
| oplocks = False |
| level2 oplocks = False |
Der Standard-Oplock-Typ ist Level1. Level2-Oplocks werden auf einer Pro-Freigabe-Basis in der Datei smb.conf aktiviert.
Andererseits können Sie Oplocks auf einer Pro-Datei-Basis innerhalb der Freigabe deaktivieren:
| veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/ |
Wenn Sie Probleme mit Oplocks haben, die in Sambas Protokoll-Einträgen ersichtlich sind, möchten Sie vielleicht lieber auf der sicheren Seite bleiben und Oplocks und Level2-Oplocks deaktivieren.
kernel oplocks ist ein Parameter in smb.conf, der Samba informiert (wenn der UNIX-Kernel die Fähigkeit hat, einem Windows-Client einen Oplock-Bruch zu senden), wenn ein UNIX-Prozess versucht, eine Datei zu öffnen, die gepuffert wird. Dieser Parameter zielt auf die gemeinsame Nutzung von Dateien zwischen UNIX und Windows mit aktivierten Oplocks auf dem Samba-Server; der UNIX-Server kann die Datei öffnen, die durch Oplocks vom Windows-Client gesperrt (= gepuffert) ist, und der smbd-Prozess sendet keinen Oplock-Bruch, der die Datei sehr wahrscheinlich zerstören würde. Wenn der UNIX-Kernel die Fähigkeit hat, einen Oplock-Bruch zu senden, dann befähigt der Parameter kernel oplocks Samba dazu, den Oplock-Bruch zu senden. Kernel-Oplocks werden auf einer Per-Server-Basis in der Datei smb.conf aktiviert.
| kernel oplocks = yes |
Die Voreinstellung ist no.
veto oplocks ist ein Parameter in smb.conf, der spezifische Dateien angibt, für die Oplocks deaktiviert werden. Wenn ein Windows-Client eine Datei öffnet, die mit veto oplocks konfiguriert worden ist, wird dem Client der Oplock nicht erlaubt, und alle Operationen werden auf der originalen Datei auf der Platte durchgeführt, anstatt auf der vom Client gepufferten Kopie der Datei. Durch explizites Angeben der Dateien, die mit UNIX-Prozessen geteilt werden, und durch das Deaktivieren der Oplocks für diese Dateien kann die server-weite Oplock-Konfiguration aktiviert werden, um es Windows-Clients zu erlauben, den Performance-Gewinn aus dem Datei-Caching zu nutzen, ohne das Risiko zerstörter Dateien einzugehen. Veto-Oplocks können auf einer Per-Freigabe-Basis aktiviert werden oder global für den gesamten Server. Dies erfolgt in der Datei smb.conf wie in ???.
Beispiel 14.1. Freigabe mit einigen Dateien mit Oplocks
| [global] |
| veto oplock files = /dateiname.htm/*.txt/ |
| [share_name] |
| veto oplock files = /*.exe/dateiname.ext/ |
oplock break wait time ist ein Parameter in smb.conf, der das Zeit-Intervall justiert, in dem Samba auf eine Anfrage zum Bruch eines Oplocks reagiert. Samba empfiehlt: „Do not change this parameter unless you have read and understood the Samba oplock code.“ oplock break wait time kann nur global in der Datei smb.conf konfiguriert werden, wie nachfolgend gezeigt wird:
| oplock break wait time = 0 (default) |
oplock break contention limit ist ein Parameter in smb.conf, der die Antwort des Samba-Servers auf die Anfrage nach einem Oplock einschränkt, wenn die Anzahl der sich darum „bewerbenden“ Clients das in diesem Parameter angegebene Limit erreicht. Samba empfiehlt: „Do not change this parameter unless you have read and understood the Samba oplock code.“ oplock break contention limit kann auf einer Per-Freigabe-Basis aktiviert werden oder global für den gesamten Server. Dies erfolgt in der Datei smb.conf wie in ???.
Beispiel 14.2. Konfiguration mit oplock break contention limit
| [global] |
| oplock break contention limit = 2 (default) |
| [share_name] |
| oplock break contention limit = 2 (default) |
Es gibt einen bekannten Umstand beim Ausführen von Applikationen (wie Norton Anti-Virus) auf einer Windows 2000/XP-Workstation, der jede Anwendung beeinflussen kann, die versucht, über ein Netzwerk auf freigegebene Datenbank-Dateien zuzugreifen. Dies ist eine Folge einer Voreinstellung im Windows 2000/XP-Betriebssystem, dies opportunistic locking heißt. Wenn eine Workstation versucht, auf freigegebene Dateien auf einem anderen Windows 2000/XP-Rechner zuzugreifen, versucht das Windows 2000/XP-Betriebssystem, die Performance zu erhöhen, indem es die Dateien sperrt und lokal puffert. Wenn das passiert, kann die Anwendung nicht mehr korrekt arbeiten, und das hat zur Folge, dass die Meldung „Access Denied“ während der Netzwerk-Operation angezeigt wird.
Alle Windows-Betriebssysteme in der NT-Familie, die als Datenbank-Server für Dateien arbeiten können (das soll heißen, dass dort Dateien abgelegt werden, auf die von anderen Windows-PCs aus zugegriffen wird), müssen wahrscheinlich deaktivierte Oplocks haben, um das Risiko der Beschädigung von Dateien zu minimieren. Das gilt für Windows 9x/Me, Windows NT, Windows 200x und Windows XP. [4]
Wenn Sie eine Workstation der Windows NT-Familie anstatt eines Servers verwenden, müssen Sie auch darauf die Oplocks deaktivieren. Wenn Sie zum Beispiel einen PC mit dem Betriebssystem Windows NT Workstation anstatt Windows NT Server verwenden und Sie darauf Daten abgelegt haben, auf die von anderen Windows-PCs zugegriffen wird, werden Sie die Oplocks auf diesem System deaktivieren müssen.
Der hauptsächliche Unterschied ist der Ort in der Windows-Registrierung, an dem die Werte zum Deaktivieren der Oplocks eingegeben werden. Anstatt des Eintrags LanManServer muss eventuell der Eintrag LanManWorkstation verwendet werden.
Sie können diesen Wert mit dem Windows-Registrierungseditor überprüfen (auch hinzufügen oder ändern, falls nötig). Wenn Sie diesen Registrierungswert ändern, müssen Sie den PC neu starten, um sicherzustellen, dass die neue Einstellung wirksam wird.
Der Ort des Registrierungseintrags für Oplocks hat sich mit Windows 2000 geändert (gegenüber dem früheren Ort in Microsoft Windows NT).
Windows 2000 akzeptiert nach wie vor den Registrierungseintrag EnableOplocks, der in früheren Windows-Versionen zum Deaktivieren von Oplocks verwendet wurde.
Sie können die Oplocks auch deaktivieren, indem Sie die folgenden Registrierungseinträge ändern:
HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\MRXSmb\Parameters\ OplocksDisabled REG_DWORD 0 oder 1 Voreinstellung: 0 (nicht deaktiviert)
Der Registrierungseintrag OplocksDisabled konfiguriert Windows-Clients in Hinblick darauf, ob sie Oplocks für enfernte (= nicht-lokale) Dateien anfordern oder nicht. Um die Oplocks zu deaktivieren, muss der Wert von OplocksDisabled auf 1 gesetzt sein.
HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 oder 1 Voreinstellung: 1 (Aktiviert) EnableOpLockForceClose REG_DWORD 0 oder 1 Voreinstellung: 0 (Deaktiviert)
Der Registrierungseintrag EnableOplocks konfiguriert Windows-basierende Server (einschließlich Workstations, die Dateien freigeben) so, dass sie Oplocks für lokale Dateien erlauben oder nicht.
Um das Schließen von offenen Oplocks beim Schließen oder Verlassen eines Programms zu erzwingen, muss EnableOpLockForceClose auf 1 gesetzt sein.
Die folgende Liste illustriert die Arbeitsweise von Level2-Oplocks:
Station 1 öffnet die Datei und fordert einen Oplock an.
Da keine andere Station die Datei geöffnet hat, gewährt der Server der Station 1 einen exklusiven Oplock.
Station 2 öffnet die Datei und fordert einen Oplock an.
Da die Station 1 noch nicht auf die Datei geschrieben hat, fordert der Server die Station 1 dazu auf, den Oplock auf einen Level2-Oplock zu brechen.
Station 1 leistet dem Folge und gibt ihre gepufferten Sperr-Informationen zurück an den Server.
Station 1 informiert den Server, dass sie den Oplock auf einen Level2-Oplock geändert hat (alternativ dazu hätte die Station 1 auch die Datei schließen können).
Der Server antwortet auf die offene Anfrage von Station 2 und gewährt dieser einen Level2-Oplock. Andere Stationen können ebenso die Datei öffnen und einen Level2-Oplock erhalten.
Die Station 2 (oder irgendeine Station, die die Datei geöffnet hat) sendet eine Schreib-Anfrage per SMB. Der Server antwortet mit seiner entsprechenden „write response“.
Der Server fordert alle Stationen, die die Datei geöffnet haben, dazu auf, ihre Oplocks aufzubrechen, was bedeutet, dass keine Station mehr irgendwelche Oplocks auf dieser Datei gesetzt hat. Da die Workstations an diesem Punkt keinerlei gepufferte Schreibvorgänge oder Sperren haben können, brauchen sie auch nicht auf diese „break-to-none“-Aufforderung zu antworten; sie müssen lediglich, alle lokal gepufferten read-ahead-Daten verwerfen.
\HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanWorkstation\Parameters UseOpportunisticLocking REG_DWORD 0 oder 1 Voreinstellung: 1 (Aktiviert)
Dies gibt an, ob der Redirektor Oplocks verwenden soll. Dieser Parameter sollte nur deaktiviert werden, um Probleme einzugrenzen.
\HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks REG_DWORD 0 oder 1 Voreinstellung: 1 (Aktiviert)
Dies gibt an, ob der Server den Clients erlaubt, Oplocks für Dateien zu verwenden.
MinLinkThroughput REG_DWORD 0 bis zu unendlich vielen Bytes/Sekunde Voreinstellung: 0
Dies gibt den minimalen Durchsatz an, der vom Server erlaubt wird, bevor er raw-locks und Oplocks für diese Verbindung deaktiviert.
MaxLinkDelay REG_DWORD 0 bis 100,000 Sekunden Voreinstellung: 60
Dies gibt das zeitliche Limit für die Verzögerungen in einer Verbindung an. Wenn die Verzögerungen diesen Wert übersteigen, deaktiviert der Server raw-locks und Oplocks für diese Verbindung.
OplockBreakWait REG_DWORD 10 bis 180 Sekunden Voreinstellung: 35
Dies gibt die Zeit an, die der Server einem Client gibt, um auf eine Anfrage bezüglich eines Oplock-Breaks zu antworten. Kleinere Werte können helfen, abgestürzte Clients schneller zu finden, verursachen aber auch leichter den Verlust gepufferter Daten.
Wenn Sie alle in diesem Kapitel erwähnten Einstellungen gesetzt haben, aber nach wie vor Datenverluste erleiden, gibt es hier noch ein paar weitere Dinge, die Sie sich ansehen sollten.
Wir haben zuverlässige Berichte von Entwicklern, dass fehlerhafte Netzwerk-Hardware, wie eine einzelne fehlerhafte Netzwerkkarte, Symptome wie Caching-Probleme und Datenverlust verursachen kann. Wenn Sie auch nach wiederholtem Neu-Indizieren immer noch Datenverluste erleiden, müssen Sie wahrscheinlich die betreffenden Dateien neu aufbauen. Das bedeutet das Anlegen einer neuen Datei mit derselben Definition wie die neu zu bildende Datei und das Transferieren der Daten aus der alten in die neue Datei. Es gibt einige bekannte Methoden, dies zu tun, die Sie in unserer Knowledge Base finden können.
In manchen Installationen zeigen sich Probleme mit dem Sperren, sobald ein Server installiert wird; in anderen bleiben diese Probleme für eine lange Zeit verborgen. Fast ohne Ausnahme verursachen diese Probleme Ärger und potenzielle Datenverluste.
Über die letzten paar Jahre gab es eine Anzahl von Beschwerden in der Samba-Mailing-Liste, in denen behauptet wurde, dass Samba Datenverluste verursacht habe. Drei Ursachen wurden bislang festgestellt:
Fehlerhafte Konfiguration der Oplocks (inkompatibel mit der verwendeten Applikation). Dies ist ein gängiges Problem, sogar dort, wo MS Windows NT4- oder MS Windows 200x-basierende Server im Einsatz sind. Es ist zwingend erforderlich, dass die Anweisungen des Software-Herstellers in Bezug auf die Konfiguration der Dateisperren befolgt werden. Falls Sie im Zweifel sind, deaktivieren Sie die Oplocks sowohl auf dem Server als auch auf dem Client. Das Deaktivieren jeglicher Form der Datei-Pufferung auf den MS Windows-Clients kann ebenso erforderlich sein.
Defekte Netzwerk-Karten, -Kabel oder -HUBs/Switches. Dies ist im Allgemeinen eher beim Einsatz billiger Netzwerk-Hardware verbreitet, obwohl es manchmal auch Probleme mit Inkompatibilitäten bei eher teurer Hardware gibt.
Es hat auch einzelne Meldungen gegeben, in denen berichtet wurde, dass Sambas Protokoll-Dateien über Daten-Dateien geschrieben wurden. Dies wurde nur von sehr wenigen Installationen berichtet (ungefähr fünf in den letzten drei Jahren), und alle Versuche, dieses Problem zu reproduzieren, schlugen fehl. Das Samba-Team war bislang nicht imstande, dieses Ereignis zu beobachten, und konnte daher auch noch keine spezielle Ursache eingrenzen. Bedenkt man die Millionen von Systemen, die Samba einsetzen, ist es trotzdem für die paar Administratoren, die von diesem Problem betroffen wurden, genauso wie für das Samba-Team, eine frustrierende und ärgerliche Herausforderung. Wenn Sie so etwas beobachten, erstellen Sie bitte unverzüglich einen Bug-Report auf Samba Bugzilla. Geben Sie bitte so viele Informationen wie möglich, da Sie vielleicht dazu beitragen, die Ursache dieses Problems zu isolieren und die Reproduktion des Problems zu ermöglichen (ein Schritt von grundlegender Bedeutung, um das Problem eingrenzen und beheben zu können).
„
Wir haben viele Fehler in den Samba-Logs, wie:
tdb(/usr/local/samba_2.2.7/var/locks/locking.tdb): rec_read bad magic
0x4d6f4b61 at offset=36116
Was bedeuten diese Meldungen?
“
Dieser Fehler deutet auf eine zerstörte tdb-Datei hin. Stoppen Sie alle Instanzen von smbd, löschen Sie die Datei locking.tdb, und starten Sie smbd neu.
Dies ist ein Bug in Windows XP. Sie finden mehr Infos dazu im Microsoft Knowledge-Base-Artikel 812937.
„Manchmal dauert es ca. 35 Sekunden, um Dateien über das Netzwerk zu löschen, nachdem XP SP1 eingespielt wurde.“
Dies ist ein Bug in Windows XP. Sie finden mehr Infos dazu im Microsoft Knowledge-Base-Artikel 811492.
Sie möchten vielleicht auf unserer Website von Zeit zu Zeit nach einer aktualisierten Version dieser Informationen schauen. Viele der von uns zur Verfügung gestellten Hinweisen werden aktualisiert, sobald sich neue Informationen ergeben. Auf diesen „papers“ finden Sie das Datum der letzten Bearbeitung immer am Beginn des jeweiligen Artikels.
Der Abschnitt der Microsoft MSDN Library zum opportunistischen Sperren:
Opportunistic Locks, Microsoft Developer Network (MSDN), Windows Development > Windows Base Services > Files and I/O > SDK Documentation > File Storage > File Systems > About File Systems > Opportunistic Locks, Microsoft Corporation. http://msdn.microsoft.com/library/en-us/fileio/storage_5yk3.asp
Microsoft Knowledge-Base-Artikel Q224992 „Maintaining Transactional Integrity with OPLOCKS“, Microsoft Corporation, April 1999, http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224992.
Microsoft Knowledge-Base-Artikel Q296264 „Configuring Opportunistic Locking in Windows 2000“, Microsoft Corporation, April 2001, http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264.
Microsoft Knowledge-Base-Artikel Q129202 „PC Ext: Explanation of Opportunistic Locking on Windows NT“, Microsoft Corporation, April 1995, http://support.microsoft.com/default.aspx?scid=kb;en-us;Q129202.