Seite 3: Weniger Ballast

Inhaltsverzeichnis

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.