Teil 4 – Netzwerkdesign bei Storage Spaces Direct
Bisher veröffentlichten Teile der Blogpostserie
- Teil 1 – Was ist Storage Spaces Direct?
- Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct
- Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen
- Teil 4 – Netzwerkdesign bei Storage Spaces Direct
In diesem Teil der Blogpost Serie möchte ich euch die verschiedenen Möglichkeiten für das Netzwerkdesign bei einem Storage Spaces Direct Failover Cluster aufzeigen.
Mit dem Windows Server 2016 stehen uns zwei unterschiedliche Switch Typen zur Verfügung, die ich hier kurz vorstellen möchte.
Einmal der Hyper-v Switch mit dem LBFO Team. LBFO steht für Load Balancing and Failover. Das LBFO Team wurde mit Windows Server 2012 eingeführt.
Das LBFO Team unterstützt alle verfügbaren Teaming Modi. Hier können bis zu 32 Netzwerkkarten zu einem Team hinzugefügt werden. Es kann unabhängig von einem Hyper-V Switch angelegt werden.
Ein Hyper-V Switch der auf Basis des LBFO Teams angelegt wurde, unterstützt alle verfügbaren Switch Extensions. Eine virtuelle Netzwerkkarte (vNIC) die auf Basis des LBFO Teams angelegt wird, verfügt nicht über RDMA und RSS. Das LBFO Team kann über den Server Manager erzeugt werden. Mit folgendem PowerShell Beispiel kann ein LBFO Team angelegt werden.
New-NetLBFOTeam -Name „TEAM LAN“ -TeamNICName ‚TEAM LAN‘ -TeamMembers ‚LAN1′,’LAN2‘ -TeamingModeSwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false
Der zweite Teaming Mode ist der SET Switch. SET steht für Switch Embedded Teaming. Wie der Name schon sagt, ist hier die NIC-Teaming Logik im Hyper-V Switch integriert. D. h. es wird ein Hyper-V Switch erzeugt, dem dann Netzwerkkarten zugewiesen werden. Dieser Teaming Mode wurde mit Windows Server 2016 neu eingeführt. Ein SET Switch kann nur über die PowerShell oder dem SCVMM 2016 angelegt werden. Der SET Switch unterstützt nur Microsoft SDN (Software Defined Network) Extensions und Switch Independent Teaming. Ein Vorteil des SET Switches, vNICs unterstützen RDMA und RSS. Ganz ausführlich hat mein Kollege Jan Kappen in folgenden Blogpost dem SET Switch beschrieben. Mit folgendem PowerShell Beispiel kann ein SET Switch angelegt werden.
New-VMSwitch -Name ‚vSwitch‘ -NetAdaperName ‚LAN1′,’Lan2‘ -EnableEmbeddedTeaming $true -AllowManagementOS $false
Einige Grundsatzregeln vorweg:
Optimal ist es, wenn wir unsere Netzwerke ausfallsicher, entweder im Team oder wie beim SMB Netzwerk, mit mind. 2 SMB Netzwerken einplanen. Optimal wäre es zu dem, wenn wir die Netzwerke über zwei Netzwerkkarten verteilen könnten, so dass auch eine Netzwerkkarte ausfallen kann, ohne dass ein Netzwerk komplett wegbricht.
Die Netzwerkkarten für den SMB Traffic werden nicht geteamt. Wir benötigen immer separate NICs. Microsoft empfiehlt für den SMB Traffic mind. 2 x 10 Gbps. Das erhöht die Ausfallsicherheit und die Performance. Sollten NVMe als Cache Laufwerke vorgesehen werden, so empfiehlt es sich, nach unserer Erfahrung, für den SMB Traffic auf 25 Gbps pro NIC zu gehen. Ab Windows Server 2016 können SMB Direct Netze im selben Subnetz liegen. Wir empfehlen dennoch, dass die SMB Netze jeweils in einem separaten IP Segment betrieben werden. RDMA benötigt zusätzlich eine VLAN ID.
Auch bei den weiteren Netzwerken ist genügend Bandbreite einzuplanen z.B. fürs Backup.
S2D Converged Networking Stack:
Die erste Frage, die wir uns nun stellen sollten ist: Welche Netzwerke benötigen wir?
- Server (Domain) Lan (MGMT)
- Cluster Traffic (Livemigration, Heartbeat)
- SMB Traffic
für das converged Deployment benötigen wir keinen virtuellen Switch, der die Kommunikation mit den VMs ermöglicht.
Designvariante – mit 2x MGMT-LAN Ports und 2x SMB Direct Ports
Beschreibung:
- Ein Team fürs MGMT-LAN
- Der Ost-West SMB Traffic (zwischen den Clusterknoten) erfolgt über SMB1 + SMB2
- Der Nord-Süd SMB Traffic (zu den Hyper-V Hosts) erfolgt ebenfalls über SMB1 + SMB2
- Cluster Traffic erfolgt auch über die SMB Adpater
Vorteil:
Nachteil:
- Es wird nur eine Dual Port RDMA NIC benötigt.
- Einfache Konfiguration
- Sowohl der Ost-West, wie auch der Nord-Süd SMB Traffic gehen über den gleichen Adapter.
- Keine saubere Trennung des SMB Traffics und keine Ausfallsicherheit des RDMA Adapters.
Designvariante – mit 2x MGMT-LAN Ports und 4x SMB Direct Ports
Beschreibung:
- MGMT Traffic über das MGMT-Team
- Ost-West SMB Traffic über SMB1 + SMB2
- Cluster Traffic erfolgt über SMB1 + SBM2
- Nord-Süd SMB Traffic über SMB3 + SMB4
Vorteil:
Nachteil:
- Der Nord-Süd SMB Traffic und Ost-West SMB Traffic ist über separate SMB Netze sauber voneinander getrennt
- Es werden zwei Dualport RDMA NICs benötigt. Die SMB Netze können ausfallsicher über die beiden Netzwerkkarten verteilt werden.
- Die von uns bevorzugte Variante
- Mehr Hardware durch eine weitere Dualport RDMA NIC
- komplexeres Setup
S2D Hyper-Converged Networking Stack:
beim hyper-converged Deployment benötigen wir zu den bereits unter dem converged Deployment aufgeführten Netzwerken, zusätzlich noch einen Hyper-V Switch für die Kommunikation der VMs.
Designbeispiel – SMB Direct und LBFO Team
Beschreibung:
- 2 NIC Ports im LBFO Team für:
- Hyper-V Switch (für die VMs)
- vNIC für das MGMT-LAN
- SMB1 und SMB2 für:
- Livemigration
- Clusterkommunikation
- Ost-West SMB Traffic
Vorteil:
Nachteil:
- Das LBFO Team ist ein seit 2012 bekanntes und stabiles Design.
- Beim LBFO Team werden alle Teaming Modi unterstützt.
- Der Hyper-V Switch auf Basis vom LBFO Team unterstützt alle Extensions
- Ausfallsicherheit durch mehrere Netzwerk Adapter
- Die von uns bevorzugte Variante
- vNIC (MGMT-LAN) unterstützt kein RDMA und RSS
Designbeispiel – Switch Embedded Teaming (SET)
Beschreibung:
eine DualPort RDMA Netzwerkkarte verbunden über einen SET Switch
- Hyper-V Switch für VMs
- eine vNIC für das MGMT-LAN
- 2 vNICs für das SMB1 + SMB2 Direct LAN
- das SMB Direct LAN wird genutzt für
- Livemigration
- Clusterkommunikation
- Ost-West SMB Traffic
Vorteil:
Nachteil:
- vNICs unterstützen RDMA und RSS
- einfaches und günstiges Design
- SET Switch unterstützt nur Microsoft SDN Extensions und Switchindepended Teaming
- der gesamte Netzwerktraffic des hyper-converged S2D Clusters geht über eine Netzwerkkarte – keine Ausfallsicherheit.
- SMB und VM Traffic laufen über die selbe Switch Infrastruktur – keine Trennung des Storage Traffic vom übrigen LAN Traffic.
- SET Switch Technologie ist noch nicht so ausgereift wie das LBFO Team
Mein Fazit aus unseren Erfahrungen in den Storage Spaces Direct Projekten ist, ein gut geplantes Netzwerk kann die Performance steigern und trägt viel zur Stabilität der Umgebung bei.
Im Teil 5 geht es um „SMB 3 und SMB Direct“
gutes Gelingen und bis zum nächsten Mal
Petra
