SMB3 - Überblick & Funktionsweise (Teil 1)

Das SMB Protokoll (häufig auch als CIFS Protokoll genannt) ist heute in vielen Kundenumgebungen die Grundlage für das klassische File-Sharing und deshalb den meisten auch bestens bekannt.

 

Mit Windows Server 2012 wurde das SMB Protokoll in der Version 3.0 eingeführt, später mit Windows Server 2012R2 (SMB 3.02) um zusätzliche Funktionen erweitert. Das SMB3 Protokoll bringt deutliche Verbesserungen in punkto Verfügbarkeit sowie einige Performanceoptimierungen im Zugriff auf Netzwerk-Speicherressourcen (Dateifreigaben). Vor allem Enterprise-Applikationen, wie etwa der SQL Server und/oder Virtualisierung mittels Hyper-V profitieren von diesem neuen Protokoll.

 

Seit clustered DataONTAP 8.2 unterstützen wir das SMB3.0 Protokoll. Mehr und mehr Partner bzw. Kunden springen auf den „SMB3-Zug“ und beginnen das Protokoll einzuführen. Aber, SMB3 ist nicht gleich SMB2.x oder NFS. Wie bei fast allem Neuen, gibt es ein paar Dinge zu beachten. Aus diesem Grund möchte ich im Rahmen einer Blog Serie das Thema SMB3 mit clustered DataONTAP etwas näher beleuchten.

 

In Teil 1 SMB3 Überblick & Funktionsweise meines Blogs möchte ich vor allem die neuen Funktionen und Begrifflichkeiten erklären.

In Teil 2 Installation & Setup einer SVM für SMB3 steht vor allem die richtige Installation einer Storage Virtual Machine (kurz SVM genannt) im Vordergrund. 

 

Teil 1 SMB3 Überblick & Funktionsweise & Performance:

 

Wie anfangs erwähnt, kommt SMB3 vor allem Applikationen wie SQL Server oder Hyper-V zu Gute. Wer sich mit SMB 2.x und älter beschäftigt hat, der wird sich jetzt sicherlich fragen:

„Hmm … virtuelle Server oder SQL Datenbanken auf CIFS Shares ablegen… und was passiert, wenn mal ein Server ausfällt oder es zu einer Unterbrechung im Netzwerk kommt?“

 

Genau dies waren in der Vergangenheit die Herausforderungen von SMB 2.x und älter. Unterbrechung im Netzwerk durch beispielsweise geplante oder ungeplante Storage Controller Takeover/Giveback Aktionen benötigten einen „manuellen Reconnect“ und das bedeutete letztlich Ausfall für die Applikation (z.B. SQL) oder die virtuellen Server. Dies war auch der Grund warum Hyper-V oder SQL Datenbanken über SMB2.1 nicht für produktive Umgebungen unterstützt wurden. 

 

Anders sieht es bei SMB3 aus. Mit den nachfolgenden SMB3 Features wird man diesen Herausforderungen gerecht, d.h. beginnend mit Windows Server 2012 ist es erlaubt, virtuelle Server in Hyper-V oder SQL Datenbanken auf sogenannte SMB3 Continuously-Available Shares abzulegen.

 

SMB3 Features

  • Continuously Available File Shares (Persitent Handles)
  • Witness protocol
  • Clustered client failover

Im Folgenden möchte ich einen kurzen technischen Überblick über die drei SMB3 Features geben:  

 

Continuously Available File Shares (Persitent Handles)

Wie der Name schon vermuten lässt, sorgt diese Art von CIFS Share, dass es im Falle eines Controller-Ausfalls zu keiner Unterbrechung für die Applikation bzw. die VM kommt.

 

Wie funktioniert’s ?

Öffnet ein SMB3 Client (z.B. Hyper-V Server) ein File (z.B. VHDX) auf einem SMB3 CA Share wird automatisch ein sogenanntes „Persitent-File-Handle“ erzeugt. Diese Persistent-File-Handel Informationen werden innerhalb eines Clustered DataONTAP HA Pair (zwei Controller) repliziert.

Kommt es zu einem geplanten oder ungeplanten Ausfall eines Storage Controllers, erfolgt ein automatischer „Reconnect“ des SMB3 Client auf den übernehmenden Controller und der Client kann mittels des Persistent-File-Handels die Datei sofort wieder öffnen. Damit kommt es aus Sicht der Applikation oder der virtuellen Server zu keiner Unterbrechung, lediglich die Verarbeitung der IO Operation verzögert sich.

 

Witness Protocol

Sicherlich wird man sich fragen, wie kommt eigentlich ein automatischer „Reconnect“ zu Stande und wie lange ist denn diese Verzögerung für die IO Verarbeitung?

Nun, SMB Clients verlassen sich i.d.R. auf den TCP Timeout um den Fehler zu erkennen. Für kritische Ressourcen wie beispielsweise eine SQL Datenbank oder eine VHDX Datei könnte das im worst-case Fall zu lange dauern. Deshalb hat Microsoft in das SMB3 Protokoll die sogenannte Witness Funktion eingebaut. Diese stellt sicher, dass vorgegebene „Reconnect- bzw. Failover-Zeiten“ eingehalten werden.  

 

Wie funktioniert’s ?

Verbindet sich ein Hyper-V Server mit einem SMB3 CA Share findet ein sogenannter „Negotiation“ Prozess statt. Während dieser Phase tauscht der Hyper-V Server Informationen mit dem Storage System aus. Unter anderem wird dem Hyper-V Server mitgeteilt, dass es sich um einen ScaleOut File Server handelt, d.h. es gibt weitere Controller, LIFs bzw. IP Adressen über die der Datenzugriff erfolgen kann.  Anschließend registriert sich der Hyper-V Server ebenfalls bei den anderen Controllern (LIFs), die er während der Negotation Phase übermittelt bekommen hat.

 

Kommt es zum Ausfall eines Storage Controllers, informiert der überlebende Storage Controller mit Hilfe des Witness Protokolls den Hyper-V Server über den Fehler. Dies hat den Vorteil, dass nicht abgewartet werden muss, bis der TCP Timeout abgelaufen ist. Nachdem der Hyper-V Server bereits mit den anderen Controller bzw. LIFs verbunden ist, wird letztlich nur das „Persitens-File-Handle“ übergeben, um die Datei (z.B. SQL Datenbank oder VHDX File) wieder zu öffnen. Wie bereits erwähnt, kommt es aus Sicht der Applikation oder der virtuellen Server zu keiner Unterbrechung.

 

Cluster Client Failover

Aus Gründen der Hochverfügbarkeit kommen in der Regel Hyper-V Cluster zum Einsatz. Kommt es zu einem Ausfall eines Hyper-V Servers werden die VMs, die sich auf diesem Server befinden per „Live Migration“ auf die überlebenden Hyper-V Server Knoten verteilt.

Ohne der SMB3 Funktion Cluster Client Failover würde  die VM auf dem anderen Hyper-V Server Knoten als eine neue sogenannte „Applikationsinstanz“ und damit mit einer neuen Applikations-ID erscheinen. Diese neue Applikationsinstanz kann nicht sofort auf das VHDX zugreifen, sondern muss warten, bis der TCP Timeout abgelaufen ist und das aktive File Handle freigegeben wurde. Dies führt letztlich zu längeren Failoverzeiten. 

 

Wie funktioniert´s?

Mit Hilfe der SMB3 Funktion Cluster Client Failover wird der VM eine eindeutige Applikations-ID mitgegeben. Kommt es zum Ausfall eines Hyper-V Server Knoten wird die VM auf einen anderen Server Knoten verschoben. Durch die eindeutige Applikation-ID kann sofort das VHDX File geöffnet werden ohne abwarten zu müssen bis der TCP Timeout abgelaufen bzw. das aktive File Handel geschlossen wurde. 

 

Nachdem wir nun die drei "relevanten" Funktionen erläutert haben, stellt sich vielleicht der ein oder andere die Frage: „… und wie aktiviert man o.g. SMB3 Funktionen?“

Kurz gesagt, gar nicht, diese Funktionen sind per Default an. Vorausgesetzt die SVM wurde korrekt eingerichtet.

In Teil 2 meines Blogs möchte ich anhand eines Beispiels zeigen, wie eine SVM für SMB3 korrekt eingerichtet wird bzw. welche Anforderungen / Rahmenbedingungen erfüllt werden müssen.