Den Abschluss des ersten Teils unseres Workshops bildete eine Übersicht, wie Sie dank Spiegelung und Parität schnell Reparaturen im S2D-Cluster durchführen. Dies erlaubt zum Beispiel den zügigen und unkomplizierten Tausch einer Festplatte. Zum Einstieg in den zweiten Teil der Artikelserie checken wir nun, ob der Datenträger erfolgreich in der Storage-Spaces-Direct-Umgebung angekommen ist.

Tauschen Sie einen defekten Datenträger aus, ist dies im S2D-Cluster ein geplanter und automatisierter Schritt. Haben Sie die Standardeinstellungen nicht geändert, werden neue Datenträger automatisch dem S2D-Cluster-Pool hinzugefügt. Sie prüfen die aktuellen Einstellungen per PowerShell mit dem folgenden Befehl:

Steht der Wert "System.Storage.PhysicalDisk.AutoPool.Enabled" auf "True", erfolgt eine automatische Aufnahme neuer Datenträger in den Pool. Da ein S2D-Cluster nur einen Storage-Pool unterstützt, gibt es an dieser Stelle in den wenigsten Fällen den Bedarf einer Anpassung. Benötigen Sie doch einmal eigene Werte, hilft der Befehl

Nachdem der neue Datenträger eingesteckt und Teil des Pools ist, startet nach einer gewissen Zeit eine automatische Verteilung der Daten. Da die neue Platte einen Füllstand von 0 Prozent hat und ihre Kollegen in diesem Knoten einen hohen Füllstand haben, erfolgt eine automatische Ausbalancierung. Hierbei verteilen sich die Daten wieder über alle Disks, sodass jede einen ungefähr identischen Füllstand besitzt. Die Ausbalancierung können Sie auch manuell anstoßen:

Planen Sie auf jeden Fall eine Reservekapazität ein. Sollte es zu einem Ausfall kommen, haben Sie so sehr schnell wieder einen intakten Spiegel und müssen sich nicht um Datenverlust sorgen. Sollte Ihnen in kurzer Zeit mehr als ein Datenträger kaputt gehen, wäre es sehr ärgerlich, wenn Sie die Daten aus dem Backup wiederherstellen müssen, weil Sie keine Reserve eingeplant haben.

Knoten eines Failover-Cluster müssen per Netzwerk miteinander kommunizieren können. Bei einem S2D-Cluster steigt die benötigte Bandbreite allerdings enorm an gegenüber einem normalen Cluster. Dies liegt daran, dass sämtliche Storage-Kommunikation per Ethernet erfolgt. Sie müssen daher während der Planung großes Augenmerk auf die genutzten Netzwerkkomponenten und -technologien legen, damit am Ende nicht das Netzwerk zum ersten Flaschenhals wird.

Im S2D-Cluster gibt es mehrere Arten von Netzwerkverkehr, den Sie berücksichtigen müssen. Bei der Storage-Kommunikation kommt es darauf an, welche und wie viele Datenträger Sie verwenden. Die Empfehlung von Microsoft für kleinere, hybride Cluster liegt bei 10 GBit/s oder mehr. An sich lohnt sich heutzutage meist schon 25 GBit/s, da die Karten mittlerweile gleich viel oder sogar weniger kosten und abwärtskompatibel sind. Selbst wenn Sie NICs mit SFP28-Ports und 25 GBit/s kaufen, können Sie mit SFP+-Modulen und Switches auf Basis von 10 GBit/s arbeiten.

Damit die Systeme beim Ausfall eines Ports kein Kommunikationsproblem haben, empfiehlt sich eine Redundanz über zwei Ports, oder noch besser über zwei Karten, die dann jeweils über einen eigenen Switch laufen. Damit ist selbst dann noch Kommunikation möglich, wenn ein Port, eine Karte oder ein Switch in die Knie geht.

Je schneller Ihr Storage ist, desto mehr Bandbreite benötigen Sie. Full-NVMe-Cluster kommen mit 10 oder 25 GBit/s nicht mehr aus, hier sollten es pro Port 50 oder 100 GBit/s sein. Durch die hohe Performance der einzelnen Datenträger (ein hochwertiger NVMe-Datenträger kann mittlerweile bis zu 7 GByte pro Sekunde schreibend verarbeiten) muss das Netzwerk im Hintergrund diesen Anforderungen gewachsen sein. Auch hier ist Redundanz erforderlich, um nicht durch den Ausfall einer Verbindung einen Crash des Clusters zu provozieren.

Bei Bandbreiten von 25 GBit/s oder höher ist es sinnvoll, RDMA-fähige Netzwerkadapter einzuplanen. RDMA ist die Abkürzung für "Remote Direct Memory Access" und beschreibt eine Technologie, bei der Server A Server B die Daten quasi in dessen RAM legen kann, anstatt dass Server B sie bei Server A anfordert und geschickt bekommt. Es gibt hierbei die drei Standards Infiniband, iWARP und RoCE (RDMA over Converged Ethernet). Die Infiniband-Technik ist sehr häufig im Linux-Umfeld zu finden und wird von Microsoft nicht für Windows-Failover-Cluster unterstützt, iWARP und RoCE hingegen sind beide vollständig supportet.

iWARP-fähige Netzwerkkarten haben keine speziellen Anforderungen an die Konfiguration der Windows-Server und an die verwendeten Switches. Dies ist der Grund, warum Microsoft eine Empfehlung für diese Technologie gegenüber RoCE ausspricht. Jeder Cluster-Knoten erhält eine oder mehrere identische NICs mit iWARP-Technologie. Sie müssen an dieser Stelle prüfen, ob die Technik in der Karte aktiv ist – mehr ist gar nicht notwendig. Vor einigen Jahren gab es nur einen NIC-Hersteller (Chelsio), der diese Technologie angeboten hat, mittlerweile sind mehrere Anbieter am Markt vertreten, die iWARP-fähige Netzwerkkarten verkaufen. Sie können mittlerweile auch NICs erwerben, die beide Technologien beherrschen und die gewünschte Einstellung im BIOS der Karte vornehmen. Sie bekommen aktuell Netzwerkkarten mit bis zu 100 GBit/s pro Port und iWARP-Unterstützung.

Gegenüber iWARP sind RoCE-Netzwerkkarten nicht Plug-and-Play-fähig und Sie müssen in Windows und in den verwendeten Switches eine aktive Konfiguration in Sachen "Quality of Service" (QoS) setzen. Dies bewertet den Netzwerk-Traffic, der über die Karten läuft und teilt ihn in unterschiedliche QoS-Klassen ein. Storage-Daten erhalten hierbei die höchste Priorität, sie werden also vorrangig behandelt und transportiert. RoCE-NICs sind mittlerweile mit Bandbreiten von 200 GBit/s pro Port verfügbar, 400 GBit/s wären technisch auch schon möglich, allerdings sind aktuell noch die PCIe-Slots auf den Mainboards der Engpass. Sind Server und Switches korrekt konfiguriert, arbeiten die Systeme mit RoCE sehr zuverlässig und fehlerfrei.

Ein genereller Vorteil von RDMA-Netzwerkkarten ist das Offloading, sodass die CPU nicht übermäßig belastet wird. Die TCP/IP-Kommunikation erfordert es, die Datenpakete auf dem Quellhost zu verpacken und zu verschicken und auf dem Zielsystem auszupacken und zu überprüfen. Diese Aufgaben benötigen um so mehr CPU-Ressourcen, je höher die Bandbreite ist. Je nach CPU-Typ kann ein einzelner Kern 5 bis 8 GBit/s abwickeln. Somit verlangen 100 GBit/s zwischen zwölf und 20 CPU-Kerne, die unter Volllast laufen, zudem fällt die Belastung auf Quell- und auf Zielhost gleichzeitig an. Da sich die Server für gewöhnlich um den Betrieb von virtuellen Servern kümmern, sollten Sie eine übermäßig starke Beanspruchung der CPUs vermeiden. RDMA sorgt zwar nicht dafür, dass überhaupt keine Belastung stattfindet, reduziert diese aber deutlich. Sie sollten für Ihren S2D-Cluster auf jeden Fall RDMA-fähige Netzwerkkarten einplanen – die Server-CPUs werden es Ihnen danken.

Neben dem Storage-Traffic müssen Sie noch dafür sorgen, dass die virtuellen Server per Livemigration zwischen den Knoten verschoben werden können. Bei diesem Vorgang bewegen sich die RAM-Daten der VMs vom Quellhost auf den Zielhost und danach nistet sich die VM auf dem Ziel ein. Je mehr Bandbreite Sie also dafür zur Verfügung stellen, desto schneller läuft der Prozess und desto weniger Delta-Daten fallen während der Migration an. In fast allen S2D-Clustern lassen sich die Storage-Karten ebenfalls für die Livemigration der VMs verwenden, sodass Sie keine dedizierten Ports einplanen und beschaffen müssen. In den Einstellungen der Livemigration besteht die Möglichkeit, die Art von Kommunikationsprotokoll zu bestimmen. Wenn Sie hier die dritte Option "SMB" auswählen, profitieren Sie von einer RDMA-Optimierung im Hintergrund, sofern verfügbar.

Sollten Sie eine sehr hohe Anforderung an das Livemigration-Netzwerk haben, besteht natürlich auch die Möglichkeit, ein oder mehrere dedizierte Karten beziehungsweise Netzwerke bereitzustellen. Dies gewährleistet, dass eine Livemigration niemals die Storage-Kommunikation im Cluster beeinträchtigt. Alternativ zu eigenen Karten können Sie die unterschiedlichen Arten von Traffic auch limitieren und in ihrer maximalen Bandbreite beschränken. Voraussetzung hierfür ist das Feature "SMB Bandwidth Limit", das Sie jederzeit über den Server-Manager, das Windows Admin Center oder die PowerShell installieren können. Anschließend stehen Ihnen zusätzliche PowerShell-Cmdlets zur Verfügung, um beispielsweise die Bandbreite zu begrenzen.

Ein weiterer wichtiger Aspekt im Fail-over-Cluster ist das Managementnetzwerk. Dieses war bis einschließlich Windows Server 2022 Pflicht für die Kommunikation zwischen den Cluster-Knoten und dem Active Directory. Dies ist mit Windows Server 2025 natürlich weiterhin möglich und unterstützt, alternativ besteht aber auch die Option, einen Workgroup-Cluster aufzubauen. Hierbei sind die Server nicht mehr Mitglied des Active Directory, sondern verbleiben in einer Workgroup. Da die Systeme aber administriert werden müssen, erfolgt dies in der Regel über ein eigenes, dediziertes Netzwerk. Für die Administration selbst sind keine hohen Bandbreiten notwendig, hier wäre theoretisch 1 GBit/s möglich. Auch für dieses Netzwerk sollten Sie Redundanz einplanen.

Im S2D-Cluster läuft das Backup der VMs über den Hypervisor beziehungsweise den Failover-Cluster. Bei der Kommunikation zwischen Backupserver und Cluster haben Sie mehrere Möglichkeiten. Die Anbindung kann über das soeben angesprochene Managementnetzwerk geschehen, wobei Sie aber eine ausreichend hohe Bandbreite einplanen sollten. Die Sicherung oder Rücksicherung von mehreren TByte über eine 1 GBit/s-Schnittstelle ist nicht mehr zeitgemäß, hier sollten 10 GBit/s oder mehr im Einsatz sein. Neben dem Managementnetz ist auch eine Sicherung der VMs über die Storage-Netzwerke des Clusters möglich. Bei dieser Variante bekommt der Backupserver ein oder mehrere Verbindungen in diese Netze und kann so ebenfalls von den hohen Bandbreiten profitieren.

Mit steigender Anzahl an VMs und Cluster-Knoten ergibt es irgendwann Sinn, dem Backup ein dediziertes Netz zu spendieren. Damit ist gewährleistet, dass der Backup-Traffic keine anderen Datenströme "wegdrückt" oder anderweitig negativ beeinflusst. Dies kann ebenfalls eine einzelne Karte sein, oder mehrere Verbindungen über mehrere NICs und Switches hinweg.

Der Failover-Cluster selbst braucht kein eigenes Netzwerk, auch nicht für den Heartbeat, über den ein Cluster den Zustand der Partner beobachtet und abfragt, ob diese noch online sind und zur Verfügung stehen. Bei einem Microsoft-Fail-over-Cluster (egal ob Hyper-V oder S2D) kommen alle verfügbaren Netzwerke standardmäßig für einen Heartbeat zum Einsatz. Sie können dies für einzelne Netzwerke manuell abschalten, was in einem S2D-Cluster aber nicht sinnvoll ist.

Zu guter Letzt benötigen wir noch Netzwerkkarten für die Anbindung der virtuellen Server. Dies kann im einfachsten Fall eine einzelne NIC sein (Achtung, keine Redundanz), verbreiteter ist es jedoch, zwei Ports als "Switch Embedded Teaming" (SET) zu konfigurieren. Hierbei ordnen Sie zwei (oder mehr) Ports einem virtuellen Switch zu und die VMs sprechen über diese Karten mit der Außenwelt. Viele Umgebungen benötigen mehr als einen vSwitch, daher müssen Sie während der Planungsphase Ihren Bedarf ermitteln und die Hardware entsprechend planen und beschaffen.

Wir haben in unserem S2D-Cluster somit Bedarf an minimal drei logischen Netzwerken: Ein Management- und zwei Storage-Netzwerke. Diese drei plus mindestens einen vSwitch lassen sich auf unter- schiedliche Art und Weise realisieren. Sie können pro Netzwerk einen oder zwei Hardwareports verwenden und somit alles über Hardware redundant aufbauen. Dies ist jedoch die kostspieligste Variante, da Sie neben den NICs noch Kabel und Switchports einkalkulieren müssen. Hier bietet es sich gegebenenfalls an, wenige NICs mit hoher Bandbreite zu verwenden und diese logisch aufzuteilen. Dieses Vorgehen ist als "Converged Networking" bekannt und ergänzt wenige physische Ports um virtuelle. Das Abtrennen der virtuellen Ports untereinander passiert dann meist per VLAN-Technik. Dies hat den Vorteil, dass Sie nur wenige Hardwarekarten beschaffen müssen und der Aufwand dadurch recht gering ist.

Theoretisch ließe sich ein S2D-Cluster mit nur zwei Ports realisieren (ohne Redundanz würde sogar ein einzelner Port ausreichen). Hierbei richten Sie die beiden Interfaces als SET-Verbund ein. Auf dieser Basis lassen sich beliebig viele weitere vNICs erzeugen, zum Beispiel für die Storage-Kommunikation, die Livemigration der VMs, die Verbindung zum Domaincontroller (sofern vorhanden) und die Backupanbindung. Auch Ihre virtuellen Server tauschen sich über diese Karten aus. Das Anlegen des SET-Switch und der zusätzlichen Karten ist per PowerShell möglich. Voraussetzung dafür ist lediglich die bereits installierte Rolle Hyper-V. Das Listing liefert die notwendigen Befehle.

Die Nutzung von sehr wenigen Hardwareports für alle Traffic-Arten wurde eine Zeit lang stark favorisiert, insbesondere von großen Anbietern wie Microsoft. Dies hatte mehrere Gründe, unter anderem die überschaubaren Kosten für Hardware sowie die geringere Anzahl von Netzwerkkabeln im Rack. Denn benötigt jeder Server nur noch zwei statt vier Kabel, macht dies bei 40 Servern im Rack schon einiges an Platz aus und bei einigen tausend Racks liegt die Ersparnis auf der Hand.

Obwohl es aktuell Netzwerkkarten mit zwei 100 GBit/s-Ports zu sehr erschwinglichen Preisen gibt, sollten Sie auch im kleineren Umfeld weder sprichwörtlich noch buchstäblich alles auf eine Karte setzen. Denn egal, wie gut und umfangreich Sie die QoS-Regeln, Limitierungen und Reservierungen konfigurieren, an der ein oder anderen Stelle kann es doch einmal klemmen oder Sie beobachten ungewünschte Nebeneffekte. Wir empfehlen daher, die Hardware so zu planen, dass der Storage-Traffic separat über eigene Karten läuft.

Dies hat mehrere Vorteile: Der erste ist, dass Sie so mehr Bandbreite für Storage erhalten. Während die Storage-Adapter aktuell nahezu immer mit zwei 100-GBit/s-Ports geplant werden, kann die Anbindung der virtuellen Server durchaus weniger Bandbreite aufweisen. Selten haben die virtuellen Server so viel Bandbreitenbedarf, dass 100 oder 200 GBit/s zur Verfügung stehen müssen. Dies spart Geld, da weniger Bandbreite automatisch kleinere und damit günstigere NICs bedeuten. Benötigen Sie trotzdem Redundanz über zwei identische NICs, können Sie den ersten Port beider Karten mit 100 GBit/s betreiben und den zweiten mit den passenden Modulen und Kabeln auf 25 oder 10 GBit/s reduzieren. Damit geht kein Dienst vollständig offline, sollte ein Adapter ungeplant ausfallen.

Ein weiterer Vorteil ist natives RDMA. Erzeugen Sie aus den Storage-Adaptern einen SET-Verbund, um danach virtuelle NICs daraus zu machen, geht ein Teil der Hardwarefunktionen verloren. RoCE als Beispiel lässt sich zwar virtuell wieder aktivieren, es ist aber technisch gesehen nicht das Gleiche, als wenn Sie die Netzwerkkarte direkt und ohne zusätzlichen vSwitch nutzen.

Lassen Sie den Storage-Traffic über eigene Adapter laufen, können Sie mit eigenen Switches arbeiten. Dies erlaubt Ihnen unter Umständen, Switch-Modelle mit geringerer Port-Anzahl zu beschaffen, die günstiger sind. Ein weiterer Vorteil ist, dass diese Geräte meist nur einmalig während der Implementierung konfiguriert werden müssen und danach keine großen Änderungen mehr erfahren. Dies führt zu einem sehr stabilen und zuverlässigen Betrieb. Sind die Storage-Adapter hingegen an das allgemeine Backbone angeschlossen und werden Opfer einer Fehlkonfiguration, reißt dies möglicherweise den gesamten Storage-Traffic mit sich. Bei Cluster-Installationen mit einer geringen Anzahl an Knoten ist auch eine direkte Verkabelung der Systeme untereinander denkbar, dies ist allerdings auch nur dann sinnvoll, wenn die Storage-Adapter ausschließlich dem SMB3-Datenverkehr dienen.

Für die Verwaltung der Server sowie die Kommunikation der VMs stehen andere Karten zur Verfügung, hier empfehlen wir zwei Dual-Port-Adapter mit 25 GBit/s pro Port. Auf Basis dieser vier Ports entsteht ein SET-vSwitch, der jeweils einen der beiden Ports pro Karte aufnimmt. Damit stehen in Summe 50 GBit/s für den VM-Datenverkehr zur Verfügung, wenn die Switches im Backend dies anbieten, ansonsten sind es bis zu 20 GBit/s.

Die anderen beiden Ports dienen der Administration der Server. Hierfür kommen Teaming per LBFO-Technik oder SET infrage. Dabei lernen wir hier LBFO (Load Balancing and Failover) kennen, das Microsoft allerdings mittlerweile als "deprecated" kennzeichnet und nicht weiterentwickelt. Die Technik ist zwar weiterhin in Windows Server 2025 enthalten, wir raten aber von einer Nutzung ab. Damit die beiden Ports trotzdem redundant sind, richten Sie einen zweiten SET-vSwitch ein, auf dessen Basis Sie anschließend einen vEthernet-Adapter erzeugen. Diesen virtuellen Adapter versehen Sie mit einer TCP/IP-Konfiguration und erzeugen so einen Managementadapter. Sollte in diesem Szenario ein Adapter ausfallen, übernimmt der verbleibende nahtlos und kann sowohl für das Management-OS selbst als auch für die VMs die Anbindung ans Netzwerk garantieren.

In kleineren Umgebungen und bei einer begrenzten Anzahl an Knoten lassen sich die Storage-Netzwerke ohne Switches betreiben. Bei dieser Variante verbinden Sie die Knoten über eine oder mehrere Kontakte direkt. Nutzen Sie im S2D-Cluster nur zwei Knoten, ist dieser Aufbau sehr einfach umzusetzen – Knoten A konnektiert mit Knoten B. Wie schon erwähnt, ist technisch mindestens eine Verbindung notwendig, allerdings sollten Sie grundsätzlich Redundanz einplanen. Den Zusammenschluss erledigen Sie über Kabel inklusive Transceiver (Direct Attach Cable; DAC) oder alternativ über Transceiver und Multimode- beziehungsweise Singlemode-Kabel. Port A auf den beiden Systemen legen Sie in ein logisches Netzwerk, Port B in ein anderes. Es ist dabei egal, ob Sie pro Netzwerk ein C-Netz mit einer /24-Subnetzmaske verwenden oder das kleinstmögliche Netzwerk mit einer /30-Subnetzmaske. Wichtig ist, dass die Systeme sich untereinander sehen und erreichen können.

Die unterschiedlichen Subnetze sind deshalb wichtig, weil unser Failover-Cluster jedes logische Netzwerk auf den Karten in den Cluster-Knoten einem eigenen Cluster-Netzwerk zuordnet. Die Verbindung eines Clusters innerhalb dieses Netzes muss zu jedem anderen Knoten in diesem Netzwerk möglich sein. Würden Sie bei einer direkten Verkabelung von jeweils einer Dual-Port-Karte dem Server A die IP-Adressen 192.168.0.1/24 und 192.168.0. 2/24 geben und Server B die IP-Adressen 192.168.0.3/24 und 192.168. 0.4/24, führt dies bei der Validierung des Clusters zu einem Fehler. Port 1 in Knoten A ist hart mit Port 1 in Knoten B verdrahtet, daher ist nur eine Verbindung von 192.168.0.1 auf 192.168.0.3 möglich, nicht auf 192.168.0.4. Um diese fehlerhafte Konfiguration zu unterbinden, geben Sie den Systemen auf Port 2 jeweils ein anderes Subnetz, beispielsweise 192. 168.1.0/24. Damit weiß der Failover-Cluster, dass nur diese beiden Ports im gleichen Subnetz sind und testet auch nur diese Verbindung.

Ein Switchless-Cluster ist auch mit drei oder vier Knoten möglich und vollständig unterstützt, allerdings steigt dann die Komplexität und der Bedarf an Netzwerkadaptern stark an. Bei drei Knoten muss jeder Server die anderen beiden Systeme sehen, optimalerweise über zwei Wege. Damit sind für jeden Knoten vier Ports notwendig, meist über zwei Dual-Port-Adapter. Server A kommuniziert über den jeweils ersten Port A beider Karten mit Server B und über die beiden anderen Ports B mit Server C. Dieses Szenario erreicht die beste Redundanz bei der minimal benötigten Anzahl an Karten und Kabeln. Wichtig in diesem Aufbau ist, pro Verbindung ein eigenes IP-Subnetz zu verwenden. Ein häufiger Fehler ist, dass die Konnektion von Knoten A zu B im gleichen Subnetz liegt wie Knoten B zu C. Ist dies der Fall, geht der Cluster davon aus, dass Knoten A den Knoten C in diesem Subnetz erreichen kann und muss. Da aber die Verbindung nur von Knoten B auf Knoten C gesteckt ist, schlägt dies fehl und die Cluster-Validierung meldet Fehler. Sie brauchen in diesem Aufbau insgesamt sechs logische Netzwerke – für jede Verbindung eine. Das sieht auf den ersten Blick vielleicht etwas seltsam aus, lässt sich aber einfach erklären, wenn Sie sich vor Augen führen, dass ein Failover-Cluster sich ausschließlich um logische Netzwerke kümmert und diese beachtet.

Ein Aufbau mit insgesamt vier Knoten gestaltet sich noch etwas aufwendiger, hier sind pro Knoten sechs Ports erforderlich. Das ergibt bei Dual-Port-Adaptern drei NICs, die ausschließlich für die Storage-Kommunikation zum Einsatz kommen. Die Anbindung der VMs und der Cluster-Knoten an das bestehende Netzwerk ist hier noch nicht berücksichtigt, diese Karten kommen noch oben drauf. Dies ist auch einer der Gründe, warum Microsoft ein Switchless-Setup nur bis maximal vier Knoten unterstützt. Bei der Serverkommunikation zu den jeweils drei anderen Knoten kommen wir dann auf insgesamt zwölf Verbindungen in insgesamt zwölf logischen Netzwerken. In der Praxis ist der IT-Verantwortliche dann oft an einem Punkt, an dem es attraktiver ist, zwei Switches einzuführen und die Verbindungen wieder auf zwei pro Knoten zu reduzieren.

Bei einem Switchless-Cluster müssen Sie noch einen letzten Aspekt bedenken: Da die Server in einem gewissen Abstand Updates bekommen und damit neustarten müssen, geht währenddessen die Verbindung der Karten der anderen Cluster-Mitglieder für eine kurze Zeit verloren. Sobald sich das neu startende System in der Pre-Boot-Phase befindet, gehen bei den angeschlossenen Systemen die Netzwerkkarten in den "Nicht verbunden"- beziehungsweise "Disconnected"-Status. Dies ist zwangsweise so, führt aber teilweise zu Warnungen im Failover-Cluster oder zu Alarmierungen im Monitoring. Dieses Verhalten lässt sich nur durch den Einsatz von einem Switch umgehen und ist nicht weiter schlimm, wenn Sie sich bewusst sind, was sich hinter den Meldungen verbirgt.

Da ein S2D-Cluster ausschließlich via Netzwerk kommuniziert, müssen diese Verbindungen sehr stabil und zuverlässig laufen. Dies beginnt beim Storage-Traffic und den damit verbundenen hohen Bandbreiten und endet mit der zuverlässigen und performanten Kommunikation der virtuellen Server. Viele Probleme in S2D-Setups resultieren aus schlechter Hardware, fehlenden Hardwarefunktionen sowie ungeeigneten Treibern – es ist daher sehr wichtig, dass das Gesamtpaket zusammenpasst.

Es gibt am Markt eine Handvoll Anbieter, von denen Sie Netzwerkkarten beziehen können. Wir geben an dieser Stelle einen Einblick, welche sich in Projekten bewährt haben, ohne jedoch einen Anspruch auf eine vollständige Marktbetrachtung zu erheben. Bei den Netzwerkadaptern sticht NVIDIA (hier durch den Zukauf von Mellanox) hervor. Die Karten sind äußerst stabil und zuverlässig, die angebotenen Funktionen wie VMQ, RSS und RSC arbeiten (im Vergleich zum Wettbewerb) sehr gut und es gibt nur äußerst selten Probleme mit den angebotenen Treibern. Mellanox war einer der ersten Hersteller, der bezahlbare Netzwerkkarten mit 100, 200 oder 400 GBit/s auf den Markt gebracht hat. Die Karten funktionieren auch unter ihrem neuen Namen sehr gut. Recht aktuell ist die ConnectX-7 Karte, aber auch ConnectX-6 ist noch geeignet für unser S2D-Setup. Je nach Ausprägung haben die Adapter 25 oder 100 GBit/s mit jeweils zwei Ports.

Sie erhalten diese NICs auch von den großen Serveranbietern, allerdings sollten Sie darauf achten, dass Sie die originalen Karten erwerben und keine gebrandete Variante davon. Denn nur so können Sie jederzeit den Treiber von der NVIDIA-Webseite herunterladen und einspielen. Karten mit angepasster Firmware erhalten erst dann ein Treiberupdate, wenn der entsprechende Hersteller dieses veröffentlicht. Die NVIDIA-Karten werden bei der Installation der Treiber direkt auf den genutzten Firmware-Stand geprüft und bei Bedarf wird über den Installer auch direkt eine neue Firmware auf die Adapter geflasht.

Es finden sich immer wieder produktive Installationen, in den die Karten nachträglich ausgetauscht werden müssen, etwa aufgrund von Latenzproblemen im Storage oder einer sehr schwankenden Performance unter Last. Auch an dieser Stelle legen wir Ihnen erneut nahe, sich einen Profi in diesem Bereich zu suchen, wenn Sie unsicher sind oder nicht über eine weitreichende Erfahrung in diesem Bereich verfügen. Bei der Wahl der Switches ist es meist so, dass schon Geräte vorhanden sind und diese natürlich auch für die Anbindung der neuen Server zum Einsatz kommen sollen. Bei den virtuellen Servern und dem Management-OS der S2D-Cluster-Knoten kommt es primär darauf an, dass die Systeme sauber angeschlossen werden können und dass die einzelnen Komponenten gegebenenfalls zertifiziert sind. Gewisse Hersteller bieten nur dann Support für angeschlossene Kabel und Module, wenn diese auf der Liste des unterstützen Zubehörs aufgeführt sind. Hier müssen dann teilweise statt einer DAC-Verkabelung SFP+- oder SFP28-Transceiver zum Einsatz kommen, um Support zu erhalten.

Möchten Sie die Storage-Adapter mit RoCE betreiben und diese Verbindungen führen über Switches, müssen diese Geräte besondere Anforderungen erfüllen. Damit RoCE fehlerfrei und zuverlässig arbeitet, richtet es sich am "Data Center Bridging" (DCB) aus. Hierbei handelt es sich um mehrere IEEE-Standards:

- Priority-based Flow Control (PFC), IEEE 802.1Qbb: Diese Technik ermöglicht eine Zuordnung von Netzwerkdiensten und -protokollen in verschiedene Klassen, die sich unabhängig voneinander steuern lassen. Dadurch ist "Lossless Ethernet" möglich, also die Kommunikation über ein Netzwerk ohne den Bedarf von einer erneuten Übermittlung von Daten.

- Enhanced Transmission Selection (ETS), IEEE 802.1Qaz: Dieser Standard kann Bandbreiten für definierte Dienste und Protokolle steuern.

- Data Center Bridging Capabilities Exchange Protocol (DCBX), IEEE 802.1az: Hierbei werden DCB-Parameter und -Optionen im Netzwerk unter den angeschlossenen Geräten ausgetauscht und angewandt. Im Microsoft S2D-Umfeld ist dies nicht unterstützt und daher abgeschaltet.

Das ETS-Protokoll ist nicht zwingend, da es sich hierbei nur um eine Garantie oder Limitierung von Bandbreiten für definierte Protokolle handelt. Viel wichtiger ist PFC: Wenn Sie mit RoCE arbeiten möchten und die angeschlossenen Systeme per Switch miteinander kommunizieren sollen, muss der Switch in der Lage sein, diesen Datenverkehr mittels PFC zu priorisieren und zu steuern. Berücksichtigen Sie dies nicht, kann es im S2D-Cluster zu Problemen und Fehlern kommen.

RoCE mit eine Lossless-Technik hat zur Folge, dass Sie einen Teil der TCP/IP-Kontrollprotokolle verlieren, dadurch aber enorm an Bandbreite gewinnen und von der deutlich geringeren Latenz profitieren. Dieses Lossless-Netzwerk benötigt eine Art Wächter, der die Kommunikationen und Bandbreiten der angeschlossenen Systeme überwacht und so steuert, dass keine Daten verfallen und erneut angefragt werden müssen.

Für diese Aufgabe benötigt der Switch die passenden Protokolle und Funktionen. Nicht jedes Modell und jeder Hersteller bietet Geräte mit diesen Features an. Nehmen Sie diese Anforderungen ernst und planen Sie ein Projekt entsprechend, ansonsten laufen Sie sehr schnell in Unannehmlichkeiten. Ein wichtiger Tipp: Sie werden erst Probleme feststellen, wenn die Systeme unter Last sind und eine gewisse Menge an Bandbreite anliegt. Je niedriger die genutzte Bandbreite, desto geringer sind die Auswirkungen auf das Netzwerk. Während einer Installations- und Testphase kann es sein, dass alles wie gewünscht läuft und erst wenn die Knoten dann mit produktiven VMs ausgestattet werden, beginnt der Ärger.

Haben Sie keine PFC-fähigen Switches im Einsatz, besteht natürlich jederzeit die Möglichkeit, dass Sie Geräte beschaffen und diese exklusiv für den S2D-Failover-Cluster verwenden. Dies führt zwar zu höheren Kosten, sorgt aber auch dafür, dass diese Devices nach der initialen Einrichtung kaum einer Wartung bedürfen. Dies sorgt in vielen Fällen für einen stabilen und zuverlässigen Betrieb. Da die Anzahl der S2D-Knoten meist relativ gering ist, reichen hier auch Geräte mit einer relativ geringen Anzahl an Ports. Es gibt zum Beispiel Modelle, die 16 100-GBit/s-Ports auf einer HE und einer halben Breite zur Verfügung stellen. So erreichen sie mit zwei Exemplaren 32 Ports auf einer Höheneinheit.

Ein weiterer Tipp aus der Praxis: Wenn Sie neue Geräte anschaffen, vergewissern Sie sich im Vorfeld, dass ein Techniker bereitsteht, um die Switches vollständig, korrekt und zeitnah zu konfigurieren. Es gibt immer wieder Projekte, in denen sowohl Server als auch Switches eingekauft werden – und niemand kann diese Netzwerkausstattung einrichten. Besonders gilt dies, wenn die Switches unter Cumulus Linux als OS laufen. Da auf den Geräten Linux werkelt, brauchen Sie jemanden, der die Konfiguration versteht und durchführen kann.

Für eine Storage-Spaces-Direct-Umgebung sind Design und Planung der Hardware sehr umfangreich. Allerdings entscheiden sich hier die Leistung und die Zuverlässigkeit im Betrieb. Nehmen Sie sich also die Zeit und holen Sie bei Bedarf externe Unterstützung. Lohn der Anstrengungen ist eines der schnellsten Software-defined-Storage-Produkte.