15
Netzwerkkonfiguration Azure Local 23H2
Guten Tag,
ich arbeite mich aktuell in Azure Local ein und habe eine Verständnisfrage. Ich werde an dieser Stelle nicht aus der Microsoft Doku schlau. Gegeben sind zwei potenzielle Nodes, es soll eine switchless Bereitstellung werden. Neben den Netzwerkkarten für den Storage Traffic (Direktverkabelung) gibt es noch pro Nodes zwei Netzwerkanschlüsse. Außerdem gibt es zwei TOR Switche. Die Bereitstellung erfolgt über das Azure Portal. Jetzt gibt es bei mir Unsicherheiten was die Netzwerkkonfiguration für den Compute & Management betrifft. Ich weiß nicht welche Variante die richtige ist:
Variante 1
Pro Node wird 1 Netzwerk Adapter für Compute & Managementtraffic konfuriert und ich wähle dann bei dem Deployment des Clusters beide Netzwerkadapter für Compute & Management Traffic aus und über das Portal erfolgt dann eine automatische Bereitstellung und Konfiguration der Netzwerkkarten. Das VLAN tagge ich auch nur auf einem Netzwerkadapter.
Variante 2
Ich erstelle pro Node ein SET-Switch aus den beiden Netzwerkadaptern und wähle diesen dann im Azure Portal aus und daraus folgt dann die Konfiguration des Intent.
Wenn ich die KI frage, dann wird mir Variante 2 vorgeschlagen, ich wollte aber mal auch die Aussage von euch hören. Laut KI bleibt der zweite Netzwerkadapter ungenutzt.
VG
Olsen
ich arbeite mich aktuell in Azure Local ein und habe eine Verständnisfrage. Ich werde an dieser Stelle nicht aus der Microsoft Doku schlau. Gegeben sind zwei potenzielle Nodes, es soll eine switchless Bereitstellung werden. Neben den Netzwerkkarten für den Storage Traffic (Direktverkabelung) gibt es noch pro Nodes zwei Netzwerkanschlüsse. Außerdem gibt es zwei TOR Switche. Die Bereitstellung erfolgt über das Azure Portal. Jetzt gibt es bei mir Unsicherheiten was die Netzwerkkonfiguration für den Compute & Management betrifft. Ich weiß nicht welche Variante die richtige ist:
Variante 1
Pro Node wird 1 Netzwerk Adapter für Compute & Managementtraffic konfuriert und ich wähle dann bei dem Deployment des Clusters beide Netzwerkadapter für Compute & Management Traffic aus und über das Portal erfolgt dann eine automatische Bereitstellung und Konfiguration der Netzwerkkarten. Das VLAN tagge ich auch nur auf einem Netzwerkadapter.
Variante 2
Ich erstelle pro Node ein SET-Switch aus den beiden Netzwerkadaptern und wähle diesen dann im Azure Portal aus und daraus folgt dann die Konfiguration des Intent.
Wenn ich die KI frage, dann wird mir Variante 2 vorgeschlagen, ich wollte aber mal auch die Aussage von euch hören. Laut KI bleibt der zweite Netzwerkadapter ungenutzt.
VG
Olsen
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: 670631
Url: https://administrator.de/forum/netzwerkkonfiguration-azure-local-23h2-670631.html
Ausgedruckt am: 24.02.2025 um 18:02 Uhr
15 Kommentare
Neuester Kommentar
Moin,
was ist "switchless"? In Azure gibt es quasi keine Switche.
Einfach der VM in dem entsprechenden Netzwerk Objekt eine IP geben.
Gruß
Spirit
was ist "switchless"? In Azure gibt es quasi keine Switche.
Einfach der VM in dem entsprechenden Netzwerk Objekt eine IP geben.
Gruß
Spirit
Hallo Spirit,
Azure Local ist die lokale Bereitstellung auf eigener Hardware in den eigenen vier Wänden. Das hieß bis vor kurzem auch noch Azure Stack HCI.
VG
Olsen
Azure Local ist die lokale Bereitstellung auf eigener Hardware in den eigenen vier Wänden. Das hieß bis vor kurzem auch noch Azure Stack HCI.
VG
Olsen
Du meinst eher Azure Stack HCI?
Jetzt heißt es Azure Local, aber ja genau.
die sind doch alle bescheuert.
2
Hallo,
die verfügbarkeitsrelevanten Komponenten werden physisch vollständig vernetzt, Variante 2.
Jeder Server wird mit seinen zwei NICs an beide Switch angebunden. Dazu werden die NICs in einem SET konfiguriert.
"Ungenutzt" bleibt der zweite Adapter dabei nicht.
Grüße
Richard
die verfügbarkeitsrelevanten Komponenten werden physisch vollständig vernetzt, Variante 2.
Jeder Server wird mit seinen zwei NICs an beide Switch angebunden. Dazu werden die NICs in einem SET konfiguriert.
"Ungenutzt" bleibt der zweite Adapter dabei nicht.
Grüße
Richard
Hallo Richard,
nochmal zum Verständnis, ich mache das händisch, bevor ich zum eigentlichen Cluster Deployment im Azure Portal übergehe und wähle dort den „SET Switch“ aus? Was passiert denn, wenn ich den zweiten Adapter unberührt lasse, und dann beide Adapter im Portal für Compute,Management auswähle? Was passiert da mit dem zweiten Adapter?
VG
nochmal zum Verständnis, ich mache das händisch, bevor ich zum eigentlichen Cluster Deployment im Azure Portal übergehe und wähle dort den „SET Switch“ aus? Was passiert denn, wenn ich den zweiten Adapter unberührt lasse, und dann beide Adapter im Portal für Compute,Management auswähle? Was passiert da mit dem zweiten Adapter?
VG
Zitat von @Olsen1:
nochmal zum Verständnis, ich mache das händisch, bevor ich zum eigentlichen Cluster Deployment im Azure Portal übergehe und wähle dort den „SET Switch“ aus?
nochmal zum Verständnis, ich mache das händisch, bevor ich zum eigentlichen Cluster Deployment im Azure Portal übergehe und wähle dort den „SET Switch“ aus?
Nicht händisch/vorab. Intent-Konfigurationsanweisungen beziehen sich auf die physischen NICs und sind eine Abstraktionsebene zur Erzeugung der benötigten SETs. Das SET ist Ergebnis, nicht Voraussetzung.
Also dann bin ich ja wieder bei Variante 1., vielleicht habe ich mich aber auch falsch ausgedrückt. Also, wir gehen jetzt davon aus, ich habe das OS installiert, zwei Netzwerkadapter für den Storage Traffic, die fasse ich nicht an. Dann habe ich meine zwei übrigen Netzwerkadapter für Compute & Management. Bisher noch alles lokal per PowerShell.
Variante 1: Ich konfiguriere eine IP Adresse, vergebe, falls vorhanden einen VLAN Tag und das war’s. Den Rest mache ich im Azure Portal. Ich wähle für den Compute & Management Traffic meine beiden Netzwerkadapter (den von mir konfigurierten und den bisher unbenutzten) und die restliche Konfiguration erfolgt dann automatisch. Im Anschluss habe ich als Ergebnis meinen SET aus beiden Adaptern.
Oder doch
Variante 2: Ich erzeuge, noch lokal per PowerShell, aus meinen beiden Adaptern einen SET Switch und wähle diesen dann im Azure Portal aus?
Irgendwie finde ich die Microsoft Doku dazu auch etwas undurchsichtig.
Vielen Dank für deine Unterstützung
VG
Olsen
Variante 1: Ich konfiguriere eine IP Adresse, vergebe, falls vorhanden einen VLAN Tag und das war’s. Den Rest mache ich im Azure Portal. Ich wähle für den Compute & Management Traffic meine beiden Netzwerkadapter (den von mir konfigurierten und den bisher unbenutzten) und die restliche Konfiguration erfolgt dann automatisch. Im Anschluss habe ich als Ergebnis meinen SET aus beiden Adaptern.
Oder doch
Variante 2: Ich erzeuge, noch lokal per PowerShell, aus meinen beiden Adaptern einen SET Switch und wähle diesen dann im Azure Portal aus?
Irgendwie finde ich die Microsoft Doku dazu auch etwas undurchsichtig.
Vielen Dank für deine Unterstützung
VG
Olsen
Ok, so gesehen ist es Variante 1. Das VLAN-Tag hat mich verwirrt. Ich habe den Ablauf im Portal nicht vor Augen, aber ich bezweifle, dass man ein VLAN-Tag dort für den (virtuellen) Management-Adapter definieren kann, oder ein vorgefundenes VLAN-Tag von einem physischen Adapter auf den Management-Adapter übertragen würde.
Mach das doch auf zwei untagged Interfaces und setze ein Management-VLAN, wenn Management-Adapter und SET verfügbar sind.
Mach das doch auf zwei untagged Interfaces und setze ein Management-VLAN, wenn Management-Adapter und SET verfügbar sind.
Im Portal geht es nicht. Aber das VLAN Tag muss man vorher definieren, das steht auch so verständlich in der Doku (https://learn.microsoft.com/en-us/azure/azure-local/plan/cloud-deploymen ...) ) Aber Danke, dann hat mir das schonmal geholfen.
VG
VG
Moin @Olsen1,
aus den Dokus von Microsoft kann man oft leider auch nicht wirklich schlau werden, vor allem wenn man diese auf deutsch liest, dann wird es meistens eher sehr gruselig. 😔
Bei diesen bitte darauf achten dass RDMA auch wirklich funktioniert, sonst kannst du deine S2D Performance auch gleich knicken.
By the way, welche NIC's genau verwendest du in diesem System?
Sprich, du möchtest die Nodes, was Compute & Management Traffic angeht, redundant über die beiden Switche laufen lassen, korrekt?
Wie schnell sind die NIC's den angebunden?
1G, 10G oder gar noch schneller?
Wenn 10G oder noch schneller, möchtest du diese Performance auch in den VM's haben?
Denn, wenn 10G oder gar noch schneller und du möchtest vor allem auch diesen Durchsatz auch in den VM's haben, dann kommst du an SR-IOV oder VMQ nicht wirklich vorbei. Dann kannst du SET aber auch gleich knicken, weil SET selbst beim Server 2025 mit SR-IOV oder VMQ, leider noch nicht sauber funktioniert. 😔
Also das "Laut KI bleibt der zweite Netzwerkadapter ungenutzt." ist ein vollkommener Blödsinn, da beim Erstellen eines SET-Switches, das dazugehörige SET-Team, per Default immer mit dem Loadbalancing Typ "Dynamic" erstellt wird, was am ehesten Link Aggregation entspricht. Sprich, wenn du 2 x 10G NIc's zu einem SET-Team zusammenfasst, dann haben die vNIC's der VM's die da dranhängen, eine Uplinkgeschwindigkeit von 20G, theoretisch zumindest. 🙃
Aber, bei NIC's mit einer Uplinkgeschwindigkeit von => 10G, empfiehlt Microsoft selbst, eher den Loadbalancing Typ "HyperVPort" zu verwenden, der zwar wie LACP eine Ausfallsicherheit jedoch keine richtige Link Aggregation bietet.
Gruss Alex
Ich werde an dieser Stelle nicht aus der Microsoft Doku schlau.
aus den Dokus von Microsoft kann man oft leider auch nicht wirklich schlau werden, vor allem wenn man diese auf deutsch liest, dann wird es meistens eher sehr gruselig. 😔
Neben den Netzwerkkarten für den Storage Traffic (Direktverkabelung)
Bei diesen bitte darauf achten dass RDMA auch wirklich funktioniert, sonst kannst du deine S2D Performance auch gleich knicken.
By the way, welche NIC's genau verwendest du in diesem System?
Außerdem gibt es zwei TOR Switche.
Sprich, du möchtest die Nodes, was Compute & Management Traffic angeht, redundant über die beiden Switche laufen lassen, korrekt?
Variante 1
Pro Node wird 1 Netzwerk Adapter für Compute & Managementtraffic konfuriert und ich wähle dann bei dem Deployment des Clusters beide Netzwerkadapter für Compute & Management Traffic aus und über das Portal erfolgt dann eine automatische Bereitstellung und Konfiguration der Netzwerkkarten. Das VLAN tagge ich auch nur auf einem Netzwerkadapter.
Variante 2
Ich erstelle pro Node ein SET-Switch aus den beiden Netzwerkadaptern und wähle diesen dann im Azure Portal aus und daraus folgt dann die Konfiguration des Intent.
Pro Node wird 1 Netzwerk Adapter für Compute & Managementtraffic konfuriert und ich wähle dann bei dem Deployment des Clusters beide Netzwerkadapter für Compute & Management Traffic aus und über das Portal erfolgt dann eine automatische Bereitstellung und Konfiguration der Netzwerkkarten. Das VLAN tagge ich auch nur auf einem Netzwerkadapter.
Variante 2
Ich erstelle pro Node ein SET-Switch aus den beiden Netzwerkadaptern und wähle diesen dann im Azure Portal aus und daraus folgt dann die Konfiguration des Intent.
Wie schnell sind die NIC's den angebunden?
1G, 10G oder gar noch schneller?
Wenn 10G oder noch schneller, möchtest du diese Performance auch in den VM's haben?
Denn, wenn 10G oder gar noch schneller und du möchtest vor allem auch diesen Durchsatz auch in den VM's haben, dann kommst du an SR-IOV oder VMQ nicht wirklich vorbei. Dann kannst du SET aber auch gleich knicken, weil SET selbst beim Server 2025 mit SR-IOV oder VMQ, leider noch nicht sauber funktioniert. 😔
Wenn ich die KI frage, dann wird mir Variante 2 vorgeschlagen, ich wollte aber mal auch die Aussage von euch hören. Laut KI bleibt der zweite Netzwerkadapter ungenutzt.
Also das "Laut KI bleibt der zweite Netzwerkadapter ungenutzt." ist ein vollkommener Blödsinn, da beim Erstellen eines SET-Switches, das dazugehörige SET-Team, per Default immer mit dem Loadbalancing Typ "Dynamic" erstellt wird, was am ehesten Link Aggregation entspricht. Sprich, wenn du 2 x 10G NIc's zu einem SET-Team zusammenfasst, dann haben die vNIC's der VM's die da dranhängen, eine Uplinkgeschwindigkeit von 20G, theoretisch zumindest. 🙃
Aber, bei NIC's mit einer Uplinkgeschwindigkeit von => 10G, empfiehlt Microsoft selbst, eher den Loadbalancing Typ "HyperVPort" zu verwenden, der zwar wie LACP eine Ausfallsicherheit jedoch keine richtige Link Aggregation bietet.
Gruss Alex
Moin @Olsen1,
so so ...
... hier haben diese Microsoftians das "Network ATC" also mit reingefummelt. 🙃
Ähm ja, das Network ATC konfiguriert die Netzwerkadapter und auch vSwitche schon so wie es Microsoft gerne hätte, nur hat das Ganze meiner bisherigen Erfahrung nach mit "Best Performance" meistens leider nicht wirklich etwas zu tun, sondern eher mit dem Gegenteil davon. 😔
Mach die Konfig per PowerShell, damit bist du auf jeden Fall viel flexibler und lernst dabei auch viel mehr. 😉
Gruss Alex
Im Portal geht es nicht. Aber das VLAN Tag muss man vorher definieren, das steht auch so verständlich in der Doku (https://learn.microsoft.com/en-us/azure/azure-local/plan/cloud-deploymen ...) ) Aber Danke, dann hat mir das schonmal geholfen.
so so ...
For Azure Local, all deployments rely on Network ATC for the host network configuration. The network intents are automatically configured when deploying Azure Local via the Azure portal.
... hier haben diese Microsoftians das "Network ATC" also mit reingefummelt. 🙃
Ähm ja, das Network ATC konfiguriert die Netzwerkadapter und auch vSwitche schon so wie es Microsoft gerne hätte, nur hat das Ganze meiner bisherigen Erfahrung nach mit "Best Performance" meistens leider nicht wirklich etwas zu tun, sondern eher mit dem Gegenteil davon. 😔
Mach die Konfig per PowerShell, damit bist du auf jeden Fall viel flexibler und lernst dabei auch viel mehr. 😉
Gruss Alex
1
Hallo Alex,
SInd Broadcom NICs - hab das genaue Modell jetzt nicht vor Augen. Aber deine zahlreichen Beiträge darüber habe ich im Hinterkopf
Genau. Sind 10G Karten.
Zumindest bei meiner Variante 1 - wenn Network ATC die Konfiguration selber übernimmt, sagt das die KI. Das fande ich aber auch komisch, deswegen nochmal Nachfrage hier. Der ATC baut aus den zwei Netzwerkadaptern dann auch ein SET Switch und damit habe ich ja meine Redundanz.
Mit 23H2 hat sich ja das Deployment von Azure Local auch verändert, das erfolgt jetzt nur noch über das Portal. Sprich, Microsoft möchte das selber übernehmen. So werde ich das auch erstmal machen und dann im Anschluss prüfen, ob und wie die Netzwerkonfiguration aussieht.
So wie ich es verstehe, kann ich die Konfiguration im Anschluss ja auch nochmal anpassen, verändern - per Powershell.
VG und schönen Sonntag,
olsen
By the way, welche NIC's genau verwendest du in diesem System?
SInd Broadcom NICs - hab das genaue Modell jetzt nicht vor Augen. Aber deine zahlreichen Beiträge darüber habe ich im Hinterkopf
Sprich, du möchtest die Nodes, was Compute & Management Traffic angeht, redundant über die beiden Switche > laufen lassen, korrekt?
Genau. Sind 10G Karten.
Also das "Laut KI bleibt der zweite Netzwerkadapter ungenutzt." ist ein vollkommener Blödsinn, da beim Erstellen > eines SET-Switches, das dazugehörige SET-Team, per Default immer mit dem Loadbalancing Typ "Dynamic" erstellt wird, was am ehesten Link Aggregation entspricht. Sprich, wenn du 2 x 10G NIc's zu einem SET-Team zusammenfasst, dann haben die vNIC's der VM's die da dranhängen, eine Uplinkgeschwindigkeit von 20G, theoretisch zumindest.
Zumindest bei meiner Variante 1 - wenn Network ATC die Konfiguration selber übernimmt, sagt das die KI. Das fande ich aber auch komisch, deswegen nochmal Nachfrage hier. Der ATC baut aus den zwei Netzwerkadaptern dann auch ein SET Switch und damit habe ich ja meine Redundanz.
Ähm ja, das Network ATC konfiguriert die Netzwerkadapter und auch vSwitche schon so wie es Microsoft gerne hätte, nur hat das Ganze meiner bisherigen Erfahrung nach mit "Best Performance" meistens leider nicht wirklich etwas zu tun, sondern eher mit dem Gegenteil davon. 😔
Mach die Konfig per PowerShell, damit bist du auf jeden Fall viel flexibler und lernst dabei auch viel mehr.
Mit 23H2 hat sich ja das Deployment von Azure Local auch verändert, das erfolgt jetzt nur noch über das Portal. Sprich, Microsoft möchte das selber übernehmen. So werde ich das auch erstmal machen und dann im Anschluss prüfen, ob und wie die Netzwerkonfiguration aussieht.
So wie ich es verstehe, kann ich die Konfiguration im Anschluss ja auch nochmal anpassen, verändern - per Powershell.
VG und schönen Sonntag,
olsen
Moin @Olsen1:
ich habe für unser Testlab mittlerweile auch Marvell(QLogic) und auch Nvidia(Mellanox) NIC's organisiert und bei diesen sieht es zum Teil auch nicht viel besser aus.
Man kann schon fast durch die Bank sagen, dass je neuer/schneller eine NIC ist umso komplizierter ist diese grundsätzlich zu konfigurieren und umso grauenhafter ist diese per Default eingestellt. 😔😭
Hast du an deren BIOS schon irgendetwas umgestellt?
Für eine redundante Anbindung eines vSwitches, gibt es seit Hyper-V 2016 eigentlich nur einen offiziellen Weg und das ist SET, denn LBFO wird, zumindest für diesen Zweck, seit Server 2016 nicht mehr supportet.
Daher ja, wenn du einen vSwitch mit zwei oder mehr physikalischen NIC's ansteuern möchtest, macht ATC aber auch WAC, automatisch ein SET-Team daraus.
Ja, diese Microsoftians möchten uns Admin/Anwender immer mehr und mehr bevormunden. 😔
Zumindest bei mir, beissen die damit jedoch immer mehr auf Granit.
Kannst du danach mal auf einem der Nodes, das folgende hier laufen lassen ...
... und die Ausgabe hier zurückposten.
Bin schon echt gespannt wie das ATC bei dir die Konfig erstellt. 🙃
Zumindest konnte man bisher per PowerShell ziemlich viel wieder richten.
Ob das auch bei einem "Azure Local" so ist, werden wir, respektive, wirst du, denke ich bald herausfinden. 😉
Beste Grüsse zurück und ebenfalls noch einen schönen Restsonntag.
Alex
SInd Broadcom NICs - hab das genaue Modell jetzt nicht vor Augen. Aber deine zahlreichen Beiträge darüber habe ich im Hinterkopf
ich habe für unser Testlab mittlerweile auch Marvell(QLogic) und auch Nvidia(Mellanox) NIC's organisiert und bei diesen sieht es zum Teil auch nicht viel besser aus.
Man kann schon fast durch die Bank sagen, dass je neuer/schneller eine NIC ist umso komplizierter ist diese grundsätzlich zu konfigurieren und umso grauenhafter ist diese per Default eingestellt. 😔😭
Genau. Sind 10G Karten.
Hast du an deren BIOS schon irgendetwas umgestellt?
Zumindest bei meiner Variante 1 - wenn Network ATC die Konfiguration selber übernimmt, sagt das die KI. Das fande ich aber auch komisch, deswegen nochmal Nachfrage hier. Der ATC baut aus den zwei Netzwerkadaptern dann auch ein SET Switch und damit habe ich ja meine Redundanz.
Für eine redundante Anbindung eines vSwitches, gibt es seit Hyper-V 2016 eigentlich nur einen offiziellen Weg und das ist SET, denn LBFO wird, zumindest für diesen Zweck, seit Server 2016 nicht mehr supportet.
Daher ja, wenn du einen vSwitch mit zwei oder mehr physikalischen NIC's ansteuern möchtest, macht ATC aber auch WAC, automatisch ein SET-Team daraus.
Mit 23H2 hat sich ja das Deployment von Azure Local auch verändert, das erfolgt jetzt nur noch über das Portal. Sprich, Microsoft möchte das selber übernehmen.
Ja, diese Microsoftians möchten uns Admin/Anwender immer mehr und mehr bevormunden. 😔
Zumindest bei mir, beissen die damit jedoch immer mehr auf Granit.
So werde ich das auch erstmal machen und dann im Anschluss prüfen, ob und wie die Netzwerkonfiguration aussieht.
Kannst du danach mal auf einem der Nodes, das folgende hier laufen lassen ...
Get-VMSwitch | Select *
Get-VMSwitchTeam | Select *... und die Ausgabe hier zurückposten.
Bin schon echt gespannt wie das ATC bei dir die Konfig erstellt. 🙃
So wie ich es verstehe, kann ich die Konfiguration im Anschluss ja auch nochmal anpassen, verändern - per Powershell.
Zumindest konnte man bisher per PowerShell ziemlich viel wieder richten.
Ob das auch bei einem "Azure Local" so ist, werden wir, respektive, wirst du, denke ich bald herausfinden. 😉
Beste Grüsse zurück und ebenfalls noch einen schönen Restsonntag.
Alex
