0

Rebalancing von Verbindungen in einem Scale-Out File Server

In einem aktuellen Projekt bin ich dabei, einen Scale-Out File Server aufzubauen. Dieses Mal werden als Speicher keine JBODs mit Festplatten und SSDs genutzt; im Hintergrund steht stattdessen ein per Fibre Channel angeschlossenes SAN. Bisher wurden die LUNs im Hyper-V Failover Cluster direkt an alle zwölf Hyper-V Hosts angebunden, dies bedingt jeweils FC-Adapter in den Hosts. In dem aktuellen Projekt werden zwischen die Hypervisor und dem SAN zwei Server gebaut, die eine hochverfügbare Dateiserver-Rolle im Failover Cluster betreiben (ein Scale-Out File Server, kurz SOFS).

Um das Thema dieses Beitrags zu erklären, muss ich etwas weiter ausholen.

Wird ein Scale-Out File Server betrieben, existiert zwischen den Hyper-V Hosts oder dem Hyper-V Cluster und dem SOFS Cluster eine Verbindung über eine, oder besser, mehrere SMB3-Verbindungen. Häufig werden hier zwei 10 GbE Karten pro Server genutzt, teilweise kommen aber auch Karten mit 40 bzw. 56 Gb/s oder höher zum Einsatz. Alle Daten der VMs werden in einem oder mehreren Shares gespeichert, die von dem SOFS Cluster zur Verfügung gestellt werden. Die SOFS-Rolle steht im Netzwerk unter einem Namen und mehreren IP-Adressen zur Verfügung. Häufig heißt die Rolle einfach nur SOFS.domain.local, die IP-Adressen sind hierbei die der Cluster-Knoten.

Baut ein Hypervisor nun eine Verbindung zu seinem Storage auf, erfolgt eine Auflösung des Namens und eine Verbindung zu einer IP-Adresse. Welche IP-Adresse genutzt wird kann nicht bestimmt werden, da DNS Round Robin genutzt wird.

An dieser Stelle gibt es zwei Möglichkeiten:

1. Es kommen JBODs mit HDDs und ggf. SSDs zum Einsatz, die mit Hilfe der Storage Spaces zu einem Pool zusammengefasst werden. Aus diesem Pool werden dann vDisks erstellt, die wiederum im SOFS Cluster als Cluster Shared Volume-Datenträger genutzt werden. Auf diesen Datenträgern werden die Daten gespeichert.
2. Es kommt ein oder mehrere SAN-Systeme zum Einsatz. Dieser Blockstorage wird per iSCSI oder Fibre Channel an die SOFS Knoten angebunden, die LUNs werden als Cluster Shared Volume genutzt und die Daten werden auf diesen Datenträgern gespeichert.

In beiden Fällen gibt es für jeden Datenträger einen Besitzer. Dieser Besitzer kann wechseln. Standardmäßig pendelt Windows Server 2012 R2 die Datenträger jedoch aus, so dass (wenn möglich) auf jedem Server mindestens ein Datenträger zur Verfügung steht und dieser der Besitzer des Datenträgers ist. Werden im SOFS Cluster zwei Knoten betrieben, sollten auch mindestens zwei Datenträger genutzt werden, alternativ das Mehrfache der Anzahl der Knoten (vier, sechs, acht, usw.).

Die SMB-Clients, also unsere Hyper-V Hosts, verhalten sich bei den beiden oben angesprochenen Typen von CSVs/Freigaben anders. Schauen wir uns die beiden Möglichkeiten einmal an:

1. Da wir in dem ersten Beispiel Storage Spaces nutzen, erfolgt eine Verbindung auf die vDisks nur über den Besitzer der entsprechenden Disk. Dies bedeutet, dass alle anderen SOFS Knoten im Failover Cluster keinen direkten Zugriff auf die vDisk haben und bei entsprechendem Bedarf die Daten über den Besitzer schicken. Wenn Sie jetzt denken „Hoppla, das hört sich aber nach einem umgeleiteten Modus (Redirected Mode) an“: Ja, das ist so, kommt allerdings praktisch fast nie vor. Dies liegt daran, dass die SMB Clients (in Form unserer Hyper-V Hosts) ab Windows Server 2012 R2 immer zu dem Server eine Verbindung aufbauen, der Besitzer der vDisk ist. Bietet nun SOFS Knoten A einen Share an, der auf vDisk A gespeichert ist, werden alle Verbindungen zu dieser Freigabe über den SOFS Knoten A abgewickelt. Eine Verbindung zu Share B auf SOFS Knoten B läuft über Knoten B usw.
   Wird nun die vDisk A von SOFS Knoten A auf Knoten B verschoben, werden ebenfalls die Verbindungen der SMB Clients auf Knoten B geschwenkt. Dieses Verhalten stellt sich, dass kein großer SMB Traffic zwischen den SOFS Knoten herrscht. Je nach Anbindung würde dies die Kommunikation verlangsamen.
   
2. Im zweiten Fall, nämlich der Anbindung von LUNs an einen Scale-Out File Server, verhält sich alles etwas anders. Grundsätzlicher Unterschied von LUNs gegenüber vDisks: LUNs können von allen SOFS Knoten gleichzeitig genutzt werden, d.h. alle Server können gleichzeitig auf den Datenträger zugreifen. Das Cluster Shared Volume File System, kurz CSVFS, sorgt während dieser gleichzeitigen Nutzung dafür, dass es keine defekten Daten durch gleichzeitigen Zugriff gibt.
   Dieser technische Unterschied kann dazu führen, dass die SMB Clients auf einen Share zugreifen über Server A, während die LUN aber momentan von Server B verwaltet wird (Server B ist der momentane Besitzer). Die Daten laufen in diesem Fall von Hyper-V Host zu SOFS Knoten A und von dort direkt auf die LUN. Es erfolgt kein Redirect über den SOFS Knoten B als Besitzer der LUN.
   

Wir gehen nun weiter auf die zweite Variante ein, da dies in dem Kundenprojekt genau so der Fall war:

Auf dem SAN gab es zu Demo-Zwecken zwei LUNs, zwei SOFS Knoten, zwei Freigaben (jeweils eine auf einer LUN) und zwei Hyper-V Hosts. Nach dem Aufbau des SOFS Cluster wurden die ersten Hyper-V Benchmark-VMs verteilt, um ein bisschen Last zu erzeugen. Jeder Hyper-V Host hat 40 VMs bekommen, die immer im Wechsel auf die beiden Shares des SOFS verteilt wurden. Nach dem Start der VMs und dem Beginn der SQLIO-Worker zeigten beide SOFS Knoten eine Bandbreite zwischen 4 und 5 Gb/s auf den vier 10 GbE NICs. Alles lief gut, es erfolgte die gewünschte Verteilung der Bandbreite auf beide SOFS Knoten und die VMs haben auf dem SAN ordentlich IOPS erzeugt.

Nun wurde zu Testzwecken einer der beiden SOFS Knoten stromlos gemacht, um einen Ausfall zu simulieren. Kurz nach dem Ausfall gab es einen kleinen Freeze der IOPS auf den beiden Shares – gefühlt eine Sekunde, danach ging es direkt weiter. Auf dem zweiten SOFS Knoten lagen nun auf allen 10 GbE NICs knapp 9 Gb/s an. Auch hier lief Alles wie gewünscht. Der überlebende SOFS Knoten war Besitzer der Rolle und aller Datenträger.

Nun wurde der zweite Knoten wieder eingeschaltet, bootete, meldete sich wieder am Failover Cluster an und durch den Ausgleich der Datenträger war er kurze Zeit später auch wieder der Besitzer von einem der beiden CSV Datenträger. Was zu diesem Zeitpunkt auffällig war: Die Daten der VMs gingen komplett über den Knoten, der nicht stromlos gemacht wurde. Auch ein mehrfacher Wechsel des Besitzers änderte nichts an dem Verhalten, der zweite SOFS Knoten schien nicht genutzt zu werden.

Technisch liegt dies daran, dass ein Wechsel der Verbindung (in diesem Szenario mit LUNs) von Hyper-V zu SOFS Knoten nicht notwendig ist. Egal wer Besitzer der LUN bzw. des CSV-Datenträgers ist, alle Server können direkt zugreifen. Trotz der nicht vorhandenen Notwendigkeit wäre es natürlich trotzdem schön, wenn sich die Last der Verbindungen auf die SOFS Knoten aufteilen würde. Das kann über mehrere Wege manuell erreicht werden:

• Ein Reboot der Hyper-V Hosts
  Diese Variante ist eher unschön, da ein Reboot eines oder mehrerer Hyper-V Hosts recht lange dauert und auch gar nicht notwendig ist, wenn man die zweite Möglichkeit kennt. Bei einem Reboot und dem erneuten Beitritt zum Failover Cluster macht der Hypervisor erneut einen Aufruf des SOFS-DNS-Namens. In diesem Fall kann es sein (muss aber nicht), dass er durch das DNS Round Robin eine Adresse nutzt, die dem zweiten und bisher ungenutzten SOFS Knoten gehört. Ab diesem Moment konnten wir beobachten, dass die Verbindungen und Daten sich wieder über beide SOFS Knoten verteilen. Dies kann so sein, muss aber nicht zwingend.
• Die Ausbalancierung der Verbindungen per PowerShell
  Die zweite Möglichkeit, um einen Ausgleich der Verbindungen hinzubekommen, ist die Verwendung von PowerShell. Diese Variante funktioniert erfahrungsgemäß sehr gut und kann sogar im laufenden Betrieb durchgeführt werden. Somit sparen Sie sich einen Neustart der Hosts und das „Glücksspiel“, ob die Verbindungen danach wirklich wieder aufgeteilt werden.

Sie können sich die Verbindungen, die auf den Scale-Out File Server aufgebaut werden, mit dem Befehl

Get-SmbWitnessClient

auf den SOFS Knoten anschauen. Als Ausgabe erhalten Sie eine Auflistung der Server, die eine Verbindung aufgebaut haben. Zusätzlich sehen Sie, wohin diese Verbindung aufgebaut wurde.

Diese Verteilung können Sie bei Bedarf auch manuell umsetzen, indem Sie folgenden Befehl benutzen

Move-SmbWitnessClient -ClientName Hyperv11 -DestinationNode FSNode2

Das Resultat sieht wie folgt aus:

Diesen Vorgang müssen Sie natürlich nicht bei jedem Neustart der SOFS Knoten (z.B. bei dem Update der Systeme) manuell durchführen. Sie können ein Skript verwenden, welches Jose Barreto geschrieben und in seinem Blog veröffentlicht hat: File Server Tip: How to rebalance a Scale-Out File Server using a little PowerShell

Dieses kleine Skript sorgt für eine automatische Verteilung im SOFS Cluster. Wenn Sie das Skript speichern und z.B. einmal täglich ausführen lassen können Sie sicher sein, dass Ihr SOFS Cluster nach spätestens 24 Stunden wieder mit allen Systemen aktiv betrieben wird.