Teil 5 – SMB 3 und SMB Direct | Hyper-V Server Blog

Teil 5 – SMB 3 und SMB Direct

Bisher veröffentlichten Teile der Blogpostserie

​​​SMB 3 und SMB Direct spielen​ bei Storage Spaces Direct eine wichtige Rolle. Daher möchte ich mich in diesem Blogpost näher mit diesen Protokollen beschäftigen. 

Man könnte sagen, das der Vorläufer des SMB (Server Messaging Block) Protokoll seine Wurzel bereits im Windows für Workgroups 3.11 hat. Dessen Netzwerk basiert wiederum auf Technologie von IBM entwickelt. Im Laufe der Jahre wurde das SMB Protokoll in den verschiedenen Betriebssystemversionen von Micrsoft weiterentwickelt. Bis mit Windows Server 2012 das SMB Protokoll mit der Version 3.0 zur Verfügung steht.

​Mit Einführung von Windows Server 2012 bekam das SMB Protokoll einige sehr interessante ​​Verbesserungen wie

  • SMB Multichannel
  • SMB Direct
  • ​SMB ​Verschlüsselung
  • SMB Transparent Failover
  • usw..

​Diese Verbessungerungen spielen ​auch bei Storage Spaces Direct eine große Rolle, daher möchte ​an dieser Stelle auf die einzelnen Punkte eingehen.

​SMB Multichannel

​SMB Multichannel ermöglicht ​die Zusammenfassung von Netzwerkbandbreite und Netzwerkfehlertoleranz, wenn zwischen dem SMB 3.x Client und dem SMB 3.x Server mehrere Netzwerkpfade verfügbar sind.

  • Geschwindigkeit
    • Bandbreiten-Aggregation durch Nutzung mehrer Kanäle
    • Standard für Netzwekkarten mit RSS Support sind 4 Kanäle
    • Verteilung der Prozessor-Belastung auf mehrere Cores (RSS Support)
  • Failover
    • Implementiert Ende-zu-Ende Ausfall Erkennung
    • Benutzung von NIC-Teaming möglich
  • Automatische Konfiguration
    • SMB erkennt automatisch das Vorhandensein mehrerer verfügbarer Netzwerkpfade  und ​fügt diese Verbindung bei Bedarf dynamisch dazu
    • Für NICs abschaltbar

​Beispiele für SMB Multichannel

Einzelne Netzwerkkarte mit RSS Support

​Eine typische Konfiguration besteht aus einem SMB Client und einen SMB Server, die z.B. jeweils mit einer 10 Gbit Netzwerkkarte ausgestattet sind. Ohne SMB Multichannel wird nur ein TCP/IP Kanal aufgebaut, diesen nutzt das SMB​ Protokoll. ​Dieser TCP/IP Kanal wird ​einem CPU-Kern zugewiesen. Dies ist standardmäßig der Core 0, der auch vom Betriebssystem genutzt wird. Hier kann es leicht zu einer Auslastung der CPU-Kerns kommen. Ein ​CPU-Kern ist in der Lage ca. 3 Gbit Netzwerk Traffic zu verarbeiten. ​Dadurch kann die Bandbreite der 10 Gbit Netzwerkkarte ohne SMB Multichannel und RSS nicht genutzt werden.
Verwenden wir SMB Mulitchannel ​in Verbindung mit einer RSS (Receive Side Scaling) fähigen Netzwerkkarte können ​mehrere TCP/IP Kanäle aufgebaut und vom SMB Protokoll genutzt werden. Jeder TCP/IP Kanal wird einem CPU​-Kern zugewiesen. Somit ist die Last auf ​mehrere CPU-Kerne ​verteilt, dadurch kann ein Engpass auf einem einzigen CPU-Kern vermieden werden. Die Bandbreite der Netzwerkkarte kann voll genutzt werden.

​Mehrere Netzwerkkarten

​wird in einer Umgebung mit mehreren Netzwerkkarten kein SMB Multichannel genutzt, so ​kann nur ein TCP/IP Kanal auf einer Netzwerkkarte aufgebaut werden, der dann vom SBM Protokoll genutzt ​wird.​ In diesem Fall ist es nicht möglich die Bandbreite der verfügbaren NIC zusammenzufassen. Bei Ausfall dieser Netzwerkkarte wird die Verbindung getrennt.
​Mit RSS (Receive Side Scaling) ​Support für die Netzwerkkarten in Verbindung mit SMB Multichannel ermöglicht es, über alle ​Netzwerkkarten der gleichen Geschwindigkeit, mehrere TCP/IP Kanäle, die verschiedenen CPU-Kernen zugewiesen werden, gemeinsam zu nutzen. Dies verteilt die Last auf mehrere CPU-Kerne und ermöglicht es die volle Bandbreite der verfügbaren Netzwerkkarten zu nutzen.
Bei Netzwerkkarten ohne RSS Support kann mit SMB Multichannel nur jeweils ein TCP/IP Kanal pro Netzwerkkarte aufgebaut werden.
Bei SMB Multichannel Nutzung kann eine Netzwerkkarte ausfallen, ​der Traffic ​geht über die verbliebene Netzwerkkarte. Es können auch dynamisch Netzwerkkarten der gleichen Geschwindigkeit zugeschaltet werden.
​Netzwerkkarten Team

​Beim Netzwerkkartenteams ohne SMB Multichannel sehen wir in der Abbildung untern nur einen TCP/IP Kanal. Warum ist das so? Nun für den SMB Client und dem SMB Server ist der Team-Adapter eine NIC und über diese kann er nur eine TCP/IP Verbindung aufbauen. Einziger Vorteil hierbei, fällt der eine Team-Adapter aus, so kann die Verbindung über den zweiten Team Adapter neu aufgebaut werden.
​Steht dem Netzwerkkartenteam SMB Mulitchannel und RSS zur Verfügung, ​können, wie hier im Beispiel aufgezeigt, bei den 10 Gbit Karten nur insgesamt 4 TCP/IP Kanäle aufgebaut werden. ​Auch hier ​sieht der SMB Client und SMB Server​ nur eine NIC. Da wir bei SMB Multichannel auch ohne Team einen transparenten Failover haben, macht das Netzwerkkartenteam für reine SMB Anwendungen keinen Sinn. Denn ohne das Netzwerkkartenteam könnten wir bei den 2 10 Gbit NICs imsgesamt 8 TCP/IP Kanäle aufbauen. Ein weiterer Nachteil des Netzwerkkartenteams ist, dass die RDMA Funktionalität der Netzwerkkarten für den Team-Adapter nicht mehr zur Verfügung steht.

Unsere Empfehlung:
​Bei SMB Multichannel Anwendungen wie Storage Spaces Direct kein Netzadapterteam für den SMB Traffic.
​Mehrere RDMA Netzwerkkarten

​Ohne SMB Multichannel, kann nur eine TCP/IP Verbindung aufgebaut werden.
Mit SMB Multichannel plus der RDMA Fähigkeit der Netzwekkarte können sehr hohe Bandbreiten übertragen werden, ohne das die CPU der Server dadurch belastet wäre. Pro Netzwerkkarte werden zwei RDMA Verbindungen erstellt.

​SMB Direct (SMB über RDMA)

Vorteile von SMB Direct:
  • schnelle Netzewrkkommunikation aus dem HPC (High-Performance Computing)
  • SMB Direct nutzt RDMA um Daten zwischen Hosts zu übertragen
    • hoher Durchsatz
    • geringe Latenz
    • geringe Prozessorbelastung
  • alle Möglichkeiten von SMB Multichannel
  • Implementierungen
    • Infiniband - bis 100 Gbit auf Infiniband Switchen
    • RoCE - 100 Gbit mit Ethernet Switche die DCB unterstützen
    • iWarp - 100 Gbit mit Ethernet Switche
  • Für Storage Spaces Direct wird von Microsoft RoCE und iWarp supportet.

​SMB Verschlüsselung

  • Ende-zu-Ende Verschlüsselung der SMB Daten
    • Schützt die Daten auf der Leitung
    • Nutzt vorhandene SMB Session Schlüssel um Schlüssel abzuleiten
  • Nutzt den AES-CCM Algorithums
  • keine Deploymentkosten
    • keine spezielle Hardware notwendig
    • keine iPSec Infrastruktur notwendig
  • Konfigurierbar pro Share oder für den ganzen Server

​SMB Transparentes Failover

  • Der Failover ist transparent für die Anwendungen
    • zero downtime
    • kurzzeitiger I/O-Delay während des Failovers
  • ​Unterstützt geplante und ungeplante Faiovers
    • Hardware/Software Wartung
    • Hardware/Software Ausfälle
    • Load Balancing / Client Redirection
  • Resilierend für Datei- und Verzeichnisoperationen
  • Funktioniert mit beiden Typen des Dateiservers im Cluster
    • Scale-Out File Server
    • "Classic" File Server
  • Anforderungen:
    • ab Windows Server 2012 Failover Cluster
    • SMB Client mit SMB 3.0
    • Dateifreigaben sind mit "Continuously Availability" Eigenschaften konfiguriert
​So, das soll es für heute gewesen sein, in meinem nächsten Blog Teil 6 zu dieser Serie wird es um die 
RDMA Einstellungen für Storage Spaces Direct gehen.

Viel Spass bis dahin
​Petra
Petra Lipp
 

Petra Lipp ist ausgebildete Datenverarbeitungskauffrau mit 20 jähriger Berufserfahrung. Seit Februar 2015 verstärkt sie das Team der Rachfahl IT-Solutions GmbH & Co KG. Petra Lipp ist MCSE Private Cloud, MCSA Windows Server 2012 und 2008, MCITP Virtualization Administrator on Windows Server 2008 R2, MCITP Enterprise Administrator on Windows Server 2008, VEEAM Certified Engineer (VMCE)

>