14
Windows Server 2022 - SET Switch
Hallo,
ich habe eine Frage zum SET Switch im Windows Server 2022.
Der Server dient als Hyper V Host und hat mehrere (identische) Netzwerkschnittstellen.
4 davon sollen zu je 2 Teams zusammen gefasst werden.
Dazu habe ich je einen SET-Switch erstellt.
Der erste SET-Switch dienst zur Anbindung der VMs und wird im Hyper-V-Manager verwendet.
Der zweite SET-Switch wurde nur erstellt, damit die Netzwerkkarten zusammengefasst werden (Team).
(wird auf dem Host für andere Zwecke verwendet).
Nun kann man ja den SET-Switch mit der Option "-AllowManagementOS $true" erstellen, wodurch dieser dann direkt eine virtuelle NIC zur Verfügung stellt, mit welcher man auf dem Hyper-V Host arbeiten kann.
Erstelle ich den SET-Switch ohne diese Option, kann ich ihn ja so im Host erst einmal nicht verwenden.
Mit dem Befehl kann ich dann aber dem SET-Switch wieder eine virtuelle NIC verpassen.
Was ist nun der Unterschied zwischen der 1. und 2. Option?
Und wäre in dem Fall der SET-Switch die richtige Auswahl anstatt dem herkömmlichen LBFO Teaming?
Vielen Dank, Ostera
ich habe eine Frage zum SET Switch im Windows Server 2022.
Der Server dient als Hyper V Host und hat mehrere (identische) Netzwerkschnittstellen.
4 davon sollen zu je 2 Teams zusammen gefasst werden.
Dazu habe ich je einen SET-Switch erstellt.
Der erste SET-Switch dienst zur Anbindung der VMs und wird im Hyper-V-Manager verwendet.
Der zweite SET-Switch wurde nur erstellt, damit die Netzwerkkarten zusammengefasst werden (Team).
(wird auf dem Host für andere Zwecke verwendet).
Nun kann man ja den SET-Switch mit der Option "-AllowManagementOS $true" erstellen, wodurch dieser dann direkt eine virtuelle NIC zur Verfügung stellt, mit welcher man auf dem Hyper-V Host arbeiten kann.
Erstelle ich den SET-Switch ohne diese Option, kann ich ihn ja so im Host erst einmal nicht verwenden.
Mit dem Befehl
Add-VMNetworkAdapter -SwitchName SETswitch -Name XXXTestWas ist nun der Unterschied zwischen der 1. und 2. Option?
Und wäre in dem Fall der SET-Switch die richtige Auswahl anstatt dem herkömmlichen LBFO Teaming?
Vielen Dank, Ostera
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 72218851054
Url: https://administrator.de/contentid/72218851054
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
ich vermute, dass du die Funktion der vSwitches falsch interpretierst.
Diese dienen der Anbindung der VMs an einen Adapter. Fassen allerdings selbst keine physischen NICs zusammen (anders als VMware).
Das was du suchst ist "NIC Teaming" und fast die Adapter je nach Konfig z.B. per LACP zusammen.
An so einen Teaming Adapter kannst du dann einen vSwitch binden.
Gruß
Spirit
ich vermute, dass du die Funktion der vSwitches falsch interpretierst.
Diese dienen der Anbindung der VMs an einen Adapter. Fassen allerdings selbst keine physischen NICs zusammen (anders als VMware).
Das was du suchst ist "NIC Teaming" und fast die Adapter je nach Konfig z.B. per LACP zusammen.
An so einen Teaming Adapter kannst du dann einen vSwitch binden.
Gruß
Spirit
Aber genau das macht doch der SET Switch auch?
Er fast bis zu 8 (identische) Netzwerkadapter (zu einem Team) zusammen und bildet damit einen vSwitch.
Den kann ich im Hyper-V Manager für die Anbindung der VMs nutzen aber auch direkt im Host, indem ich entweder über "AllowManagementOS" oder mit "Add-VMNetworkAdapter" dem SET-Switch einen virtuellen Adapter hinzufüge.
Ich frage nur, da die Microsoft Empfehlung der SET-Switch ist. Und da ich auf dem Host die Hyper-V Rolle installiert habe, steht mir diese Option zur Verfügung.
Er fast bis zu 8 (identische) Netzwerkadapter (zu einem Team) zusammen und bildet damit einen vSwitch.
Den kann ich im Hyper-V Manager für die Anbindung der VMs nutzen aber auch direkt im Host, indem ich entweder über "AllowManagementOS" oder mit "Add-VMNetworkAdapter" dem SET-Switch einen virtuellen Adapter hinzufüge.
Ich frage nur, da die Microsoft Empfehlung der SET-Switch ist. Und da ich auf dem Host die Hyper-V Rolle installiert habe, steht mir diese Option zur Verfügung.
Anscheint ist das ganze komplizierter als ich vermutet hätte. Die VMs müssen erstmal enabled werden eine Teaming Anbindung zu nutzen. Danach kannst du das NIC-Teaming einrichten.
Schau mal hier:
https://www.serverwatch.com/guides/configuring-nic-teaming-for-virtual-m ...
Da ist der Part beschrieben, den ich im Kopf hatte und zusätzlich was in den VMs angepasst werden.
Heißt wohl, das ein vSwitch nicht einfach an einen Teaming Adapter gehängt werden kann.
Schau mal hier:
https://www.serverwatch.com/guides/configuring-nic-teaming-for-virtual-m ...
Da ist der Part beschrieben, den ich im Kopf hatte und zusätzlich was in den VMs angepasst werden.
Heißt wohl, das ein vSwitch nicht einfach an einen Teaming Adapter gehängt werden kann.
Wenn du dir diesen Link anschaust:
https://www.windowspro.de/wolfgang-sommergut/nic-teaming-konfigurieren-w ...
Da wird erklärt, das die Funktion auch nur eine der Optionen ist. Bei meinen vorherigen Post wird ein Team ala VMware gemacht und dann muss die VM dafür angepasst werden (HyperV NIC-Team Mode)
Ich schlage dir daher dennoch vor einen Teaming Adapter auf dem Host anzulegen und dort LACP zu verwenden. An den Aadapter hängst du dann den vSwitch.
Was kommt denn überhaupt als Gegenseite zu Einsatz?
Ich kann das hier gerade leider nicht selbst testen.
https://www.windowspro.de/wolfgang-sommergut/nic-teaming-konfigurieren-w ...
Da wird erklärt, das die Funktion auch nur eine der Optionen ist. Bei meinen vorherigen Post wird ein Team ala VMware gemacht und dann muss die VM dafür angepasst werden (HyperV NIC-Team Mode)
Ich schlage dir daher dennoch vor einen Teaming Adapter auf dem Host anzulegen und dort LACP zu verwenden. An den Aadapter hängst du dann den vSwitch.
Was kommt denn überhaupt als Gegenseite zu Einsatz?
Ich kann das hier gerade leider nicht selbst testen.
Den vSwitch benötige ich für das eine Team eigentlich garnicht, da dieser nicht von den VMs genutzt wird.
Der entsteht mit dem erstellen des SET-Switch.
Auf einem anderen Server (ohne Hyper-V Rolle) verwende ich auch das „alte“ LBFO Teaming (wahlweise mit oder ohne LACP).
Auf diesen Servern würde ich aber halt alles über SET-Switche realisieren, da von MS empfohlen.
Der entsteht mit dem erstellen des SET-Switch.
Auf einem anderen Server (ohne Hyper-V Rolle) verwende ich auch das „alte“ LBFO Teaming (wahlweise mit oder ohne LACP).
Auf diesen Servern würde ich aber halt alles über SET-Switche realisieren, da von MS empfohlen.
Ich habe keinen Plan was du mit diesen "SET-Switches" willst. Das das jetzt die empfohlene Variante sein soll, wobei mal außen vor steht das es keine Funktion sondern nur ein Commando ist, habe ich nirgends finden können.
Die Frage ist ja die ganze Zeit was du erreichen willst. Was für einen Vorteil versprichst du dir.
Die ganze Funktion ist von MS nicht wirklich supportet. (Es sei denn das hat sich jetzt geändert)
Ich würde ganz simpel ein NIC Teaming einrichten und daran den vSwitch hängen. Das ist die sauberste Variante um dahinter vernünftig physische Switche zu betreiben. Das ganze natürlich per LACP Protokoll.
Die Frage ist ja die ganze Zeit was du erreichen willst. Was für einen Vorteil versprichst du dir.
Die ganze Funktion ist von MS nicht wirklich supportet. (Es sei denn das hat sich jetzt geändert)
Ich würde ganz simpel ein NIC Teaming einrichten und daran den vSwitch hängen. Das ist die sauberste Variante um dahinter vernünftig physische Switche zu betreiben. Das ganze natürlich per LACP Protokoll.
Ich glaub wir reden gerade an einander vorbei, bzw. bin ich hier auch nicht auf dem Stand.
Anscheint laufen viele hier auf Probleme.
Schau dir mal folgende Links an:
https://community.spiceworks.com/topic/2360465-windows-server-2022-nic-t ...
hier wird auf folgenden Artikel verwiesen und auch genau beschrieben wie man den Problemen aus dem Weg geht:
https://www.altaro.com/hyper-v/hyper-v-network-teaming-understanding-lin ...
Für dich dürfte hilfreich sein, das hier alles per PS konfiguriert wird.
Anscheint laufen viele hier auf Probleme.
Schau dir mal folgende Links an:
https://community.spiceworks.com/topic/2360465-windows-server-2022-nic-t ...
hier wird auf folgenden Artikel verwiesen und auch genau beschrieben wie man den Problemen aus dem Weg geht:
https://www.altaro.com/hyper-v/hyper-v-network-teaming-understanding-lin ...
Für dich dürfte hilfreich sein, das hier alles per PS konfiguriert wird.
Die Beiträge kenne ich auch. Dass trifft aber nicht auf meine Frage zu.
Ich benötige diesen Set-Switch am Ende garnicht für die VMs. Möchte ihn nur nutzen um Interfaces zu teamen (so wie alternativ auch mit LBFO(+ LACP) ).
Ich benötige diesen Set-Switch am Ende garnicht für die VMs. Möchte ihn nur nutzen um Interfaces zu teamen (so wie alternativ auch mit LBFO(+ LACP) ).
zeig mal einen Link wo drin steht, dass es nach deiner Vorgehensweise funktionieren soll.
Moin @Ostera,
Es gibt keinen, ist beides dasselbe. 😉
Wenn du einen Server >= 2016 benutzt, dann ist SET die richtige Wahl, da LBFO seit Server 2016 abgekündigt ist.
SET ist jedoch mit Vorsicht zu geniessen und funktioniert nicht immer sauber, zumindest nicht mit den Default Einstellung. 😔
Ich habe schon vor ca. 2 Jahren zu diesem Thema den folgenden Beitrag geschrieben.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Beste Grüsse aus BaWü
Alex
Was ist nun der Unterschied zwischen der 1. und 2. Option?
Es gibt keinen, ist beides dasselbe. 😉
Und wäre in dem Fall der SET-Switch die richtige Auswahl anstatt dem herkömmlichen LBFO Teaming?
Wenn du einen Server >= 2016 benutzt, dann ist SET die richtige Wahl, da LBFO seit Server 2016 abgekündigt ist.
SET ist jedoch mit Vorsicht zu geniessen und funktioniert nicht immer sauber, zumindest nicht mit den Default Einstellung. 😔
Ich habe schon vor ca. 2 Jahren zu diesem Thema den folgenden Beitrag geschrieben.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Beste Grüsse aus BaWü
Alex
1Zitat von @MysticFoxDE:
Moin @Ostera,
Es gibt keinen, ist beides dasselbe. 😉
Wenn du einen Server >= 2016 benutzt, dann ist SET die richtige Wahl, da LBFO seit Server 2016 abgekündigt ist.
SET ist jedoch mit Vorsicht zu geniessen und funktioniert nicht immer sauber, zumindest nicht mit den Default Einstellung. 😔
Ich habe schon vor ca. 2 Jahren zu diesem Thema den folgenden Beitrag geschrieben.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Beste Grüsse aus BaWü
Alex
Moin @Ostera,
Was ist nun der Unterschied zwischen der 1. und 2. Option?
Es gibt keinen, ist beides dasselbe. 😉
Und wäre in dem Fall der SET-Switch die richtige Auswahl anstatt dem herkömmlichen LBFO Teaming?
Wenn du einen Server >= 2016 benutzt, dann ist SET die richtige Wahl, da LBFO seit Server 2016 abgekündigt ist.
SET ist jedoch mit Vorsicht zu geniessen und funktioniert nicht immer sauber, zumindest nicht mit den Default Einstellung. 😔
Ich habe schon vor ca. 2 Jahren zu diesem Thema den folgenden Beitrag geschrieben.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Beste Grüsse aus BaWü
Alex
Okay, danke dir. Jetzt bin ich auch schlauer.
Hallo Alex, danke für die Klarstellung/Bestätigung.
Da ich den Set-Switch nicht für VMs oder RDMA nutzen möchte, dachte ich, dass die Einstellung für „LoadBalancingAlgorithm“=dynamic ausreichend sein wird. Gibt es noch mehr zu beachten?
Da ich den Set-Switch nicht für VMs oder RDMA nutzen möchte, dachte ich, dass die Einstellung für „LoadBalancingAlgorithm“=dynamic ausreichend sein wird. Gibt es noch mehr zu beachten?
Moin @Ostera,
sehr gerne.
Dann benötigst du auch kein vSwitch oder SET, vor allem wenn du auch LACP nutzen möchtest, den das geht mit SET überhaupt nicht.
In dem Fall kannst du auch ein klassisches LBFO Teaming einrichten.
https://learn.microsoft.com/en-us/powershell/module/netlbfo/new-netlbfot ...
Und, ja ich habe davor geschrieben, dass LBFO von Microsoft durch SET quasi ersetzt wurde. Das gilt aber nur für das Teaming in Verbindung mit einem vSwitch. Ohne vSwitch, kann man LBFO, wie du am oberen Link erkennen kannst, auch bei einem Server 2022 noch weiterhin ganz offiziell verwenden. 🙃
Und inoffiziell funktioniert LBFO bei neueren Servern mit einem vSwitch auch noch ganz gut.
https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/bypass- ...
😉🤪
Mal unabhängig von dem was ich oben geschrieben habe ist der „LoadBalancingAlgorithm“=dynamic, laut Microsoft nur für Uplinkgeschwindigkeiten von < 10G geeignet. Bei 10G und darüber, sollte man eher "LoadBalancingAlgorithm"=HyperVPort verwenden.
Aber Vorsicht, dieser Algorithmus kann eine Session immer nur an eine NIC Binden und nicht über mehrere verteilen!
Gruss Alex
Hallo Alex, danke für die Klarstellung/Bestätigung.
sehr gerne.
Da ich den Set-Switch nicht für VMs oder RDMA nutzen möchte ...
Dann benötigst du auch kein vSwitch oder SET, vor allem wenn du auch LACP nutzen möchtest, den das geht mit SET überhaupt nicht.
In dem Fall kannst du auch ein klassisches LBFO Teaming einrichten.
https://learn.microsoft.com/en-us/powershell/module/netlbfo/new-netlbfot ...
Und, ja ich habe davor geschrieben, dass LBFO von Microsoft durch SET quasi ersetzt wurde. Das gilt aber nur für das Teaming in Verbindung mit einem vSwitch. Ohne vSwitch, kann man LBFO, wie du am oberen Link erkennen kannst, auch bei einem Server 2022 noch weiterhin ganz offiziell verwenden. 🙃
Und inoffiziell funktioniert LBFO bei neueren Servern mit einem vSwitch auch noch ganz gut.
https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/bypass- ...
😉🤪
dachte ich, dass die Einstellung für „LoadBalancingAlgorithm“=dynamic ausreichend sein wird. Gibt es noch mehr zu beachten?
Mal unabhängig von dem was ich oben geschrieben habe ist der „LoadBalancingAlgorithm“=dynamic, laut Microsoft nur für Uplinkgeschwindigkeiten von < 10G geeignet. Bei 10G und darüber, sollte man eher "LoadBalancingAlgorithm"=HyperVPort verwenden.
Aber Vorsicht, dieser Algorithmus kann eine Session immer nur an eine NIC Binden und nicht über mehrere verteilen!
Gruss Alex
Es gibt, soweit ich weiß, außer RoundRobin keine Option die Links pro Session nicht einseitig aus zulasten.
Selbst LACP bindet eine Session nur auf einen Link.
Selbst LACP bindet eine Session nur auf einen Link.
