zurück zum Artikel

Bislang zeigte Microsofts SMB-Protokoll bislang Schwächen im Bereich Skalierung und Ausfallsicherheit – sehr zur Freude der großen SAN-Anbieter. Diese Freude soll die zu Windows 8 gehörende und stark erweiterte SMB-Version 2.2 trüben.

Auf der Storage Developer Conference im September 2011 hatte Microsoft die Version 2.2 seines Server-Message-Block-Protokolls (SMB) vorgestellt, die Bestandteil von Windows 8 ist. Das inzwischen vom Hersteller von SMB 2.2 in SMB 3.0 umbenannte Protokoll tritt an, Flaschenhälse von NAS-Servern zu beseitigen sowie Verfügbarkeitsanforderungen zu erfüllen, die bislang SAN-Architekturen vorbehalten sind – durchaus Potenzial, die Speicherindustrie kräftig aufzumischen.

Microsoft hatte SMB2 als grundsätzlich neu strukturiertes Protokoll zuerst mit Windows Vista freigegeben. Ein Grund für diese Neuentwicklung: SMB1 [1] war sowohl im Protokoll selbst als auch in den jeweiligen Implementierungen zahlreichen Beschränkungen unterworfen. Oft sind in den 1980er-Jahren aktuelle Vorgaben, als 10-MBit/s-Ethernet als schnell galt, heute nicht mehr richtig. Auch muss man heute im Protokoll nicht mehr einzelne Bytes einsparen. Darüber hinaus erfuhr SMB1 seit einigen Jahren keine signifikante Weiterentwicklung mehr, was auch der Kompatibilität mit Dutzenden Implementierungen des Protokolls geschuldet war.

Viele semantische Aspekte von SMB 2.0 [2] ähneln stark denen von SMB1, weil sich auch SMB1 selbst im Lauf der Jahre von DOS hin zu Windows und zur NTFS-Semantik entwickelt hat. Einige archaische Aspekte „entsorgten“ die Protokollarchitekten mit SMB 2.0, Details hierzu liefert der iX-Artikel Blöckchenspiele [3].

In Windows 7 sowie im Windows Server 2008 R2 präsentierte Microsoft die erste große Protokollaktualisierung: SMB 2.1 [4]. Bei dessen Entwicklung standen besseres Verhalten auf Weitverkehrsstrecken mit hoher Latenz und relativ niedriger Bandbreite im Fokus. SMB 2.1 führte hierzu einige neue Protokollelemente ein, unter anderem Leases, BranchCache und Large MTU.

Leases als Oplock-Nachfahre

Leases als Oplock-Nachfahre

Leases verbessern das schon in SMB1 vorhandene Modell der sogenannten opportunistischen Locks, kurz Oplocks. Die haben nichts mit Dateisperren im engeren Sinn zu tun, sondern sind eine Erlaubnis, Inhalte zwischenzuspeichern. Öffnet ein Client eine Datei, fragt er typischerweise nach einem Oplock. Ist er der einzige, der die Datei geöffnet hat, bekommt er ein exklusives Oplock. Damit sichert der Server dem Client zu, dass niemand anders die Datei gleichzeitig offen hat. Das erlaubt dem Client, Dateiinhalte lokal zu cachen, Schreibzugriffe erst verzögert abzusetzen und Anfragen nach Byte Range Locks ebenfalls lokal zu behandeln. Ein Oplock kann die Leistung eines Programms um ein Mehrfaches verbessern.

Will nun ein zweiter Client die Datei öffnen, informiert der Server den Client mit dem Oplock darüber. Der erste Client schreibt daraufhin seine lokal zwischengespeicherten Daten zurück und hört von diesem Zeitpunkt an mit dem Caching auf. Das heißt, er schickt jede Schreib/Lese-Anfrage einer Anwendung synchron zum Server. Erst nachdem der erste Client die Aufgabe des Oplock bestätigt hat, kann der zweite die Datei erfolgreich öffnen.

Der große Haken bei Oplocks ist, dass sie in der Praxis viel zu oft gebrochen werden und man sie nicht wiedererlangen kann, ohne die Datei komplett neu zu öffnen. Das Brechen erfolgt, sobald ein Client die Datei ein zweites Mal öffnen möchte, unabhängig davon, welcher Client das ist. Wenn also eine Applikation wie Excel eine Datei öffnet und diese in einem separaten Thread ein zweites Mal öffnet (das passiert bei Excel regelmäßig), bricht ein Client sein eigenes Oplock. Das Protokoll erlaubt es nicht, Oplocks von einem Client über mehrere Datei-Handles hinweg gemeinsam zu behandeln.

In SMB 2.1 hat Microsoft mit den „Leases“ diesen Designfehler behoben. Ein Lease entspricht in seiner Wirkung einem Oplock: Es ist die Erlaubnis, eine Datei auf dem Client zu cachen. Auch ein Lease bricht beim erneuten Öffnen einer Datei. Die Neuerung besteht darin, dass Microsoft die Bindung des Lease an den beim Öffnen vergebenen Datei-Handle aufgehoben hat. Ein Client gibt beim Öffnen einer Datei einen 16 Byte langen Key an, der das Lease repräsentiert. Will jetzt eine Applikation eine Datei ein zweites Mal öffnen, kann der Client beim zweiten Aufruf denselben Key angeben. Damit zeigt er an, dass er vom ersten Handle weiß und die Lease-Information zwischen beiden Handles teilen will. In diesem Fall bleibt das Lease gültig.

Dieses Teilen lässt sich auch dazu benutzen, ein gebrochenes Lease wiederzuerlangen. Der Client öffnet eine Datei mit einem gebrochenen Lease Key ein weiteres Mal mit einer Lease-Anforderung. Das erste, ohne Lease bestehende Handle erbt über den geteilten Key das neue Lease. Der Effekt ist, dass dies das Brechen des Leases „heilt“ und der Client erneut Datei-Inhalte cachen kann.

Mit dem BranchCache-Protokoll reduziert Windows 7 erheblich die benötigte Bandbreite von einer Zentrale, in der Fileserver stehen, in eine Zweigstelle mit vielen Clients. Dateien, die Clients in der Zweigstelle schon heruntergeladen haben, stehen dort auch anderen Clients zur Verfügung. Entweder stellt der BranchCache-Server ausführbare Dateien oder sich selten ändernde Dokumente zur Verfügung oder die Clients in der Zweigstelle helfen sich gegenseitig mit den Inhalten aus.

Damit kein Client einem anderen modifizierte Inhalte unterschieben kann, ist das BranchCache-Protokoll kryptografisch abgesichert. Im Rahmen von SMB 2.1 bittet der Client den Server, den Hashwert eines Abschnitts zu berechnen. Damit kann der Client überprüfen, dass er von seinem BranchCache-Partner den korrekten Dateiinhalt bekommen hat.

Weniger Ballast

Weniger Ballast durch Large MTU

SMB1 hat sich den Ruf als langsames und „geschwätziges“ Protokoll erworben. Es hat eine lange Geschichte und trägt viel Ballast mit sich herum, sein schlechter Ruf ist aber viel mehr schlechten Client-Implementierungen geschuldet als dem Protokoll selbst. Bis zur Version 3.0 hat der smbclient von Samba SMB1 zum Lesen und Schreiben von Dateien nicht voll ausgenutzt. Er las eine Datei sequenziell in 64 KByte großen Blöcken. Das beschränkte die effektiv genutzte TCP Window Size auf diese Größe, was sich insbesondere über Weitverkehrsstrecken mit hohen Latenzen fatal auf die Transferleistung auswirkt.

Mit der Version 3.2 bohrten die Entwickler smbclient dahingehend auf, die Anfragen nach den 64-KByte-Blöcken parallel zu senden. SMB1 erlaubt dies durch eine Kennzeichnung jeder Anfrage mit einer eindeutigen Kennung. Anhand dieser Kennung kann ein Client die Antworten des Servers den ausstehenden Anfragen zuordnen. Damit kann smbclient auch ein 10-GBit-Netz mit einer SMB1-Sitzung komplett auslasten, passende Hardware vorausgesetzt.

Zwar existiert die Unterstützung für parallele Anfragen in SMB1, sie ist aber recht rudimentär implementiert. Mit solchen parallelen Anfragen kann ein Client einen Server stark auslasten. Mit SMB2 hat Microsoft ein Verfahren eingeführt, das die Belastung des Servers durch die Clients steuert. Ein SMB2-Server kann dynamisch die Erlaubnis vergeben, parallele Anfragen zu schicken. Unter Last kann er diese Erlaubnis (Credit) schrittweise wieder zurücknehmen.

Obwohl die maximale Größe für Schreib-/Leseanfragen im SMB2-Protokoll theoretisch bei 4 GByte liegt, ist die praktische Nutzung auf 64 KByte beschränkt. Solange der Client genügend Credits hat, schickt er parallel mehrere 64-KByte-Anfragen an den Server. Durch die Aufteilung in die Blöcke entsteht jedoch sowohl erhöhter Aufwand bei der Verarbeitung als auch eine Verschwendung von Bandbreite, da man bei jeder 64-KByte-Anfrage einen Protokoll-Header übertragen muss.

SMB 2.1 erweitert das Credits-System: Ein Client kann bei entsprechender Serverunterstützung mehr als einen Credit für eine Schreib/Lese-Anfrage verwenden. Will er beispielsweise 256 KByte übertragen, kann er dies in einer Anfrage tun und dafür vier für jeweils eine 64-KByte-Anfrage gültige Credits verwenden. Dieses Vorgehen reduziert die Verarbeitungslast für die kleinen Anfragen signifikant und nutzt die beschränkte Bandbreite auf WAN-Strecken besser aus.

SMB 2.2: Auf dem Weg ins RZ

Für SMB 2.1 lag der Fokus der Entwickler auf Weitverkehrsnetzen. Für die weitere SMB2-Entwicklung haben sie die Kristallkugel bemüht und entdeckt, dass die Nutzung klassischer Dateiserver nachlässt. Anwendungen wie Google Mail, Office 365 und andere Serverdienste nutzen zwischen Client und Server keine Laufwerke mehr, sondern jede dieser Anwendungen bringt eigene, auf HTTP aufsetzende Protokolle mit. Beim Einsatz von Thin-Clients und virtuellen Desktops wird CIFS höchstens noch innerhalb des Rechenzentrums genutzt, der Client spricht mit dem Rechenzentrum über ein spezialisiertes Protokoll. So ist es folgerichtig, dass die nächste Version des SMB2-Protokolls Verbesserungen für den Einsatz innerhalb eines Rechenzentrums enthält. Dort zählen andere Eigenschaften als beim ausschließlichen Einsatz für Desktop-Anwendungen.

Im Rechenzentrum muss sich ein Dateiserver gegen SAN-Strukturen (Storage Area Network) durchsetzen. Als Vorteile des SAN gegenüber NAS-Lösungen gelten oft die höhere Zuverlässigkeit und deutlich bessere Performance. Die mangelnde Zuverlässigkeit im Vergleich zu SANs ist der Hauptgrund dafür, dass zentrale Anwendungen wie Exchange oder der SQL Server ihre Datenbanken nicht auf über SMB verbundenen Laufwerken ablegen können. Auch Hyper-V-Images setzen lokale oder über ein SAN angebundene Laufwerke voraus. Erklärtes Ziel von Microsoft ist es, mit SMB 2.2 (3.0) diese Anwendungen voll zu unterstützen. Dazu erweiterten die Redmonder SMB2 mit einigen Eigenschaften wie Multi-Channel, Persistent Handles oder SMB über RDMA (Remote Direct Memory Access), die der Artikel näher beleuchtet.

Bislang ist es so, dass ein Client für jede Verbindung zu einem SMB-Server genau eine TCP-Verbindung aufbaut. Dieser Umstand beschränkt die verfügbare Bandbreite durch die verwendete Hardware auf 1 oder 10 GBit pro Sekunde. Techniken wie Ethernet Bonding können diesen Engpass beheben, bereiten jedoch in der Praxis häufig Schwierigkeiten.

Viele Wege kombinieren

Viele Wege kombinieren

SMB 2.2 respektive 3.0 [5] verwendet per Multi-Channel-Erweiterung mehr als eine TCP-Verbindung für das Laufwerks-Mapping. Dabei kann der Client den Server nach der Liste seiner Netz-Devices fragen. Diese umfasst nicht nur die IP-Adressen der Interfaces, sondern auch die Bandbreite und weitere Fähigkeiten wie RDMA. Der Client gleicht die Liste des Servers mit seinen eigenen Ports ab und erstellt daraus eine Liste potenzieller Kanäle zum Server, die sich im Wesentlichen durch Client- und Server-IP-Adresse unterscheiden. Existieren mehrere solcher Kanäle zum Server, versucht ein SMB-2.2-Client, mehr als einen zu öffnen und zu nutzen.

Das gleichzeitige Verwenden mehrerer Kanäle addiert die nutzbare Bandbreite. Auch die Zuverlässigkeit einer SMB-Verbindung erhöht sich drastisch: Bricht eine Netzverbindung weg, muss der Client nicht erst aufwendig eine weitere Verbindung aufbauen. Er kann einfach einen der anderen Kanäle weiter nutzen. Einzig die Bandbreite reduziert sich um den Anteil des ausgefallenen Kanals.

Im Unterschied zu NFSv2 oder NFSv3 sind SMB1 und SMB 2.x zustandsbehaftete Protokolle. Dies drückt sich dadurch aus, dass Clients Dateien über das Netz öffnen und Handles die offenen Dateien repräsentieren. An den Handles hängen weitere Zustandsinformationen wie Sperren für bestimmte Dateibereiche.

Bricht eine SMB-Verbindung weg, muss ein Client sie neu aufbauen. Da offene Dateien nach dem Verbindungsabbruch geschlossen sind, kann dies dazu führen, dass der Server während der Unterbrechung Sperren an andere Clients vergibt. Das heißt, das Client-Betriebssystem kann seinen Anwendungen nicht garantieren, dass sie offene Dateien nach einem Verbindungsabbruch im gleichen Zustand wieder öffnen können.

Mit SMB 2.0 hat Microsoft die sogenannten Durable File Handles implementiert. Ein Client fordert beim Öffnen einer Datei ein Durable Handle an. Der Server gewährt dieses, sofern er gleichzeitig ein sogenanntes „Batch Oplock“ gewährt, wenn also kein anderer Client die Datei geöffnet hat. Hat der Server das Durable Handle gewährt, überlebt dieses Handle einen Verbindungsabbruch und mit ihm alle Dateisperren. Hat der Client die Verbindung erfolgreich neu aufgebaut, kann er vom Server ein Wiederöffnen desselben Handle anfordern. Dies gelingt, solange kein anderer Client inzwischen die Datei geöffnet hat, das Batch Oplock also in Abwesenheit des ersten Clients gebrochen hat.

Durable File Handles sind ein Schritt hin zum transparenten Wiederaufbau von Verbindungen. Das Ziel ist, kurzfristige Netzstörungen zu überwinden. Mit Durable Handles garantiert der Server dem Client aber nicht, dass ein Wiederöffnen auch klappt.

Wiederherstellung garantiert

Wiederherstellung garantiert

Einen weiteren Schritt in Richtung eines garantierten Wiederaufbaus von Verbindungen hat Microsoft in SMB 2.1 mit der Einführung von Resilient File Handles getan. Die sind aber nur von begrenztem Nutzen, weil Anwendungen sie explizit anfordern müssen, nur sehr wenige dürften dies tun.

Mit den persistenten File Handles in SMB 2.2 nimmt sich Microsoft der Anforderungen an, die Serveranwendungen wie Exchange oder SQL Server an die Verfügbarkeit von Dateien haben. SAN-Architekturen lassen sich redundant auslegen, sodass sie den Ausfall einer beliebigen Komponente gegenüber der Anwendung transparent ausgleichen können. Diese Anforderungen erfüllen die persistenten Handles ebenfalls.

Sie verlangen sowohl client- als auch serverseitig viel Logik, denn sie müssen berücksichtigen, dass irgendwo auf dem Weg vom Client zum Server die Anfragen oder auf dem Rückweg die entsprechenden Antworten verloren gehen. Dabei kann es vorkommen, dass ein Server während der Bearbeitung der Anfrage den Dienst quittiert. In einem solchen Fall muss serverseitig genau definiert sein, welcher Status zwingend auf einen Failover-Server zu übertragen ist und welchen Zustand der Client wieder herstellen kann und muss. Während ein Client mit persistenten Handles gerade nicht verbunden ist, muss der Server alle anderen modifizierenden Anfragen zurückhalten, bis sich der Client wieder verbindet oder ein zuvor ausgehandelter Timeout abgelaufen ist.

Neben der Zuverlässigkeit ist die mehr Performance ein Vorteil, den ein SAN gegenüber einer NAS-Lösung vorweisen kann. Diese lässt sich einerseits durch ein separates Netz mit niedrigerer Latenz und mehreren Kanälen erreichen, andererseits sind häufig die Fibrechannel-Hostbus-Adapter (FC-HBA) mit deutlich mehr Intelligenz ausgestattet, als Netzwerkkarten. Daher ist die durch Datentransfers erzeugte CPU-Last mit FC deutlich niedriger als bei einer auf TCP basierenden iSCSI-Infrastruktur.

Windows 8 kontert mit einer Technik namens SMBDirect oder SMB over RDMA [6]. Besteht zum Beispiel zwischen Client und Server eine RDMA-fähige InfiniBand-Verbindung, kann der Transfer der Massendaten über diese RDMA-Verbindung mit drastisch niedrigerer CPU-Belastung erfolgen. Die gesamte SMB-Logik bleibt über eine normale Verbindung erhalten, nur die eigentlichen Datentransfers lagert SMBDirect auf RDMA aus. Die Grafik verdeutlicht die Unterschiede im Vergleich zum TCP-Ansatz.

Mit der Einführung von SMB 2.2 (3.0) plant Microsoft, Dateiserver als Cluster anzubieten. Dabei erlauben die persistenten Handles ein transparentes Failover in einem Aktiv-Passiv-Cluster. Allerdings wollen die Redmonder noch einen Schritt weiter gehen und werden ein Volume auch im Aktiv-Aktiv-Cluster exportieren können. Die grundsätzliche Architektur des Clusterings wird sich von dem Weg unterscheiden, den Samba mit ctdb in den letzten Jahren gegangen ist. Samba-Server verteilen im Cluster die SMB-Logik wie Oplocks und Share Modes komplett auf die beteiligten Rechner, sodass der nach außen wie ein einzelner SMB-Server mit mehreren Interfaces erscheint [7].

Für das Clustering kann Microsoft Modifikationen am Client vornehmen. Durch die Logik, persistente Handles wiederzuverbinden, kann Microsoft serverseitig pro Datei einen Metadatenserver definieren, der die erwähnte SMB-Logik übernimmt. Fällt dieser Server aus, übernehmen die Clients mit den persistenten Handles einen großen Teil der Wiederherstellung der verloren gegangenen Information. Samba und ctdb werden in Zukunft für SMB-2.2/3.0-fähige Clients diese Logik ebenfalls nutzen können und trotzdem die bis heute installierten Clients mit hochverfügbaren Cluster-Diensten versorgen können.

Fazit

Mit SMB 2.2 (3.0) hat Microsoft zu einem großen Sprung in Richtung Rechenzentrum angesetzt. Die eigenen Serverapplikationen werden SMB-2.2/3.0-Dateiserver als Datenablage akzeptieren, und Support bekommen Anwender dafür dann ebenfalls. Die großen NAS-Hersteller wie EMC und NetApp haben Unterstützung für SMB 2.2 (3.0) zugesagt, und das Samba-Team ist ebenfalls intensiv dabei, die entsprechenden Neuerungen einzuarbeiten. (rek [8])

URL dieses Artikels:
https://www.heise.de/-1703492

Links in diesem Artikel:
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365233.aspx
[2] http://technet.microsoft.com/en-us/library/ff625695.aspx
[3] http://www.heise.de/artikel-archiv/ix/2009/1/53_kiosk
[4] http://technet.microsoft.com/en-us/library/ff625695.aspx
[5] http://www.snia.org/sites/default/files2/SDC2011/presentations/tuesday/DavidKruseMatthewGeorge_SMB2-2_Bigger_Faster_Scalier_Parts_I_and_II_combined-v1-0.pdf
[6] http://www.snia.org/sites/default/files2/SDC2011/presentations/tuesday/TomTalpey_GregKramer_SMB%202-2_Over_RDMA.pdf
[7] http://www.heise.de/artikel-archiv/ix/2010/10/119_kiosk
[8] mailto:rek@ct.de

Copyright © 2012 Heise Medien