Freigeben über

Anforderungen an das physische Netzwerk für Azure Stack HCI

  • Artikel

Gilt für: Azure Stack HCI, Versionen 23H2 und 22H2

In diesem Artikel werden Überlegungen und Anforderungen zum physischen Netzwerk (Fabric) für Azure Stack HCI behandelt, insbesondere im Hinblick auf Netzwerkswitches.

Hinweis

Die Anforderungen können sich für zukünftige Azure Stack HCI-Versionen ändern.

Netzwerkswitches für Azure Stack HCI

Microsoft testet die Standards und Protokolle mit Azure Stack HCI, die im Abschnitt Anforderungen an Netzwerkswitches weiter unten genannt werden. Obwohl Microsoft keine Netzwerkswitches zertifiziert, arbeiten wir mit Anbietern zusammen, um Geräte zu identifizieren, die Anforderungen von Azure Stack HCI unterstützen.

Wichtig

Möglicherweise funktionieren auch andere Netzwerkswitches, die hier nicht aufgeführte Technologien und Protokolle verwenden, Microsoft kann allerdings nicht gewährleisten, dass diese mit Azure Stack HCI funktionieren, und kann ggf. nicht bei der Behandlung von Problemen behilflich sein.

Wenden Sie sich beim Kauf von Netzwerkswitchen an Ihren Switchanbieter, und stellen Sie sicher, dass die Geräte die Azure Stack HCI-Anforderungen für Ihre angegebenen Rollentypen erfüllen. Die folgenden (in alphabetischer Reihenfolge aufgeführten) Anbieter haben bestätigt, dass ihre Switches die Azure Stack HCI-Anforderungen unterstützen:

Klicken Sie auf eine Lieferantenregisterkarte, um überprüfte Switches für jeden Azure Stack HCI-Datenverkehrstyp anzuzeigen. Diese Netzwerkklassifizierungen finden Sie hier.

Wichtig

Wir aktualisieren diese Listen, während wir über Änderungen von Netzwerkswitchanbietern informiert werden.

Wenden Sie sich an den Anbieter Ihres Switches, wenn Ihr Switch nicht aufgeführt ist, um sicherzustellen, dass das Modell und die Betriebssystemversion des Switches die Anforderungen im nächsten Abschnitt unterstützen.

Anforderungen an Netzwerkswitches

In diesem Abschnitt werden Branchenstandards aufgeführt, die für die spezifischen Rollen von Netzwerkswitchen erforderlich sind, die in Azure Stack HCI-Bereitstellungen verwendet werden. Diese Standards tragen dazu bei, eine zuverlässige Kommunikation zwischen Knoten in Azure Stack HCI-Clusterbereitstellungen zu gewährleisten.

Hinweis

Für Netzwerkadapter, die für Compute-, Speicher- und Verwaltungsdatenverkehr verwendet werden, ist Ethernet erforderlich. Weitere Informationen finden Sie unter Anforderungen für Hostnetzwerke.

Im Folgenden finden Sie die obligatorischen IEEE-Standards und -Spezifikationen:

23H2-Rollenanforderungen

Anforderung Verwaltung Storage Compute (Standard) Compute (SDN)
Virtuelle LANS ✓ ✓ ✓ ✓
Prioritätsflusssteuerung ✓
Erweiterte Übertragungsauswahl ✓
LLDP-Port-VLAN-ID ✓
LLDP VLAN-Name ✓ ✓ ✓
LLDP-Verknüpfungsaggregation ✓ ✓ ✓ ✓
LLDP ETS-Konfiguration ✓
LLDP ETS Empfehlung ✓
LLDP PFC-Konfiguration ✓
LLDP Maximum Frame Size ✓ ✓ ✓ ✓
Maximale Übertragungseinheit ✓
Border Gateway Protocol ✓
DHCP-Relay-Agent ✓

Hinweis

Für Gast-RDMA sind Sowohl Compute (Standard) als auch Speicher erforderlich.

Standard: IEEE 802.1Q

Ethernet-Switches müssen der IEEE 802.1Q-Spezifikation entsprechen, die zum Definieren von VLANs dient. VLANs sind für verschiedene Aspekte von Azure Stack HCI erforderlich und werden in allen Szenarien benötigt.

Standard: IEEE 802.1Qbb

Ethernet-Switches, die für Azure Stack HCI-Speicherdatenverkehr verwendet werden, müssen die IEEE 802.1Qbb-Spezifikation erfüllen, die die Prioritätsflusssteuerung (Priority Flow Control, PFC) definiert. PFC ist bei Verwendung von Data Center Bridging (DCB) erforderlich. Da DCB sowohl in RoCE- als auch in iWARP RDMA-Szenarien verwendet werden kann, ist 802.1Qbb in allen Szenarien erforderlich. Es werden mindestens drei CoS-Prioritäten (Class of Service, Dienstklasse) benötigt, ohne die Switchfunktionen oder Portgeschwindigkeiten zu herabzustufen. Mindestens eine dieser Datenverkehrsklassen muss eine verlustfreie Kommunikation bieten.

Standard: IEEE 802.1Qaz

Ethernet-Switches, die für Azure Stack HCI-Speicherdatenverkehr verwendet werden, müssen die IEEE 802.1Qaz-Spezifikation erfüllen, die enhanced Transmission Select (ETS) definiert. ETS ist bei Verwendung von DCB erforderlich. Da DCB sowohl in RoCE- als auch in iWARP RDMA-Szenarien verwendet werden kann, ist 802.1Qaz in allen Szenarien erforderlich.

Es werden mindestens drei CoS-Prioritäten benötigt, ohne die Switchfunktionen oder die Portgeschwindigkeit herabzustufen. Falls für Ihr Gerät das Definieren von QoS-Raten in Eingangsrichtung zulässig ist, empfehlen wir Ihnen außerdem Folgendes: Konfigurieren Sie keine Raten in Eingangsrichtung, oder konfigurieren Sie diese so, dass sie genau die gleichen Werte wie die Raten in Ausgangsrichtung (ETS) aufweisen.

Hinweis

Eine hyperkonvergente Infrastruktur ist stark von Ost-West-Layer-2-Kommunikation im gleichen Rack abhängig und erfordert daher ETS. Microsoft testet Azure Stack HCI nicht mit DSCP (Differentiated Services Code Point).

Standard: IEEE 802.1AB

Ethernet-Switches müssen der IEEE 802.1AB-Spezifikation entsprechen, die zum Definieren des Verbindungsschichterkennungsprotokolls (Link Layer Discovery Protocol, LLDP) dient. LLDP ist für Azure Stack HCI erforderlich und ermöglicht die Problembehandlung physischer Netzwerkkonfigurationen.

Die Konfiguration der LLDP-TLVs (Type-Length-Values) muss dynamisch aktiviert werden. Switches dürfen abgesehen von der Aktivierung eines bestimmten TLV keine zusätzliche Konfiguration erfordern. Wenn also beispielsweise der Untertyp 3 von 802.1 aktiviert wird, müssen automatisch alle VLANs angekündigt werden, die an Switchports verfügbar sind.

Anforderungen an benutzerdefinierte TLVs

Mit LLDP können Organisationen eigene benutzerdefinierte TLVs definieren und codieren. Diese werden als organisationsspezifische TLVs bezeichnet. Alle organisationsspezifischen TLVs beginnen mit dem LLDP-TLV-Typwert 127. Die folgende Tabelle zeigt, welche Organisationsspezifischen benutzerdefinierten TLV -Untertypen (TLV Type 127) erforderlich sind.

Organisation TLV-Untertyp
IEEE 802.1 Port-VLAN-ID (Untertyp = 1)
IEEE 802.1 VLAN-Name (Untertyp = 3)
Mindestens 10 VLANS
IEEE 802.1 Link-Aggregation (Untertyp = 7)
IEEE 802.1 ETS-Konfiguration (Untertyp = 9)
IEEE 802.1 ETS-Empfehlung (Untertyp = A)
IEEE 802.1 PFC-Konfiguration (Untertyp = B)
IEEE 802.3 Maximale Framegröße (Untertyp = 4)

Maximale Übertragungseinheit

Die Maximum Transmission Unit (MTU) ist der größte Rahmen oder das größte Paket, das über eine Datenverbindung übertragen werden kann. Für die SDN-Kapselung ist ein Bereich von 1514 bis 9174 erforderlich.

Border Gateway Protocol

Ethernet-Switches, die für Azure Stack HCI SDN-Computedatenverkehr verwendet werden, müssen das Border Gateway Protocol (BGP) unterstützen. BGP ist ein Standardroutingprotokoll, das zum Austauschen von Routing- und Reichweiteninformationen zwischen zwei oder mehr Netzwerken verwendet wird. Routen werden automatisch zur Routentabelle aller Subnetze mit aktivierter BGP-Weitergabe hinzugefügt. Dies ist erforderlich, um Mandanten-Workloads mit SDN und dynamischem Peering zu ermöglichen. RFC 4271: Border Gateway Protocol 4

DHCP-Relay-Agent

Ethernet-Switches, die für azure Stack HCI-Verwaltungsdatenverkehr verwendet werden, müssen DHCP-Relay-Agent unterstützen. Der DHCP-Relay-Agent ist ein beliebiger TCP/IP-Host, der zum Weiterleiten von Anforderungen und Antworten zwischen dem DHCP-Server und dem Client verwendet wird, wenn sich der Server in einem anderen Netzwerk befindet. Es ist für PXE-Startdienste erforderlich. RFC 3046: DHCPv4 oder RFC 6148: DHCPv4

Netzwerkdatenverkehr und -architektur

Dieser Abschnitt richtet sich in erster Linie an Netzwerkadministratoren.

Azure Stack HCI kann bei verschiedenen Rechenzentrumsarchitekturen funktionieren, einschließlich solchen mit 2 Ebenen (Spine-Leaf) und 3 Ebenen (Core-Aggregation-Access). Dieser Abschnitt behandelt eher Konzepte der Spine-Leaf-Topologie, die häufig für Workloads in einer hyperkonvergenten Infrastruktur wie Azure Stack HCI verwendet wird.

Netzwerkmodelle

Der Netzwerkdatenverkehr kann anhand seiner Richtung klassifiziert werden. In herkömmlichen SAN-Umgebungen (Storage Area Network) fließt der Datenverkehr vorwiegend in Nord-Süd-Richtung von einer Computeebene über eine Layer-3-Grenze (IP) zu einer Speicherebene. Bei der hyperkonvergenten Infrastruktur herrscht die Ost-West-Richtung vor, wobei ein erheblicher Teil des Datenverkehrs innerhalb von Layer-2-Grenzen (VLAN) erfolgt.

Wichtig

Es wird dringend empfohlen, dass sich alle Clusterknoten physisch im gleichen Rack befinden und mit denselben ToR-Switches (Top-of-Rack) verbunden sind.

Hinweis

Gestreckte Clusterfunktionen sind nur in Azure Stack HCI, Version 22H2, verfügbar.

Nord-Süd-Datenverkehr für Azure Stack HCI

Nord-Süd-Datenverkehr weist die folgenden Eigenschaften auf:

  • Datenverkehr fließt von einem ToR-Switch zum Spine oder vom Spine zu einem ToR-Switch.
  • Datenverkehr verlässt das physische Rack oder überschreitet eine Layer-3-Grenze (IP).
  • Umfasst die Verwaltung (PowerShell, Windows Admin Center), Compute (VM) und inter-sitegestreckten Clusterdatenverkehr.
  • Verwendet einen Ethernet-Switch für Konnektivität mit dem physischen Netzwerk.

Ost-West-Datenverkehr für Azure Stack HCI

Ost-West-Datenverkehr weist die folgenden Eigenschaften auf:

  • Der Datenverkehr verbleibt innerhalb der ToR-Switches und layer-2-Grenze (VLAN).
  • Umfasst Speicherdatenverkehr oder Livemigrationsverkehr zwischen Knoten im selben Cluster und (bei Verwendung eines gestreckten Clusters) innerhalb desselben Standorts.
  • Kann einen Ethernet-Switch (mit Switch) oder eine direkte Verbindung (ohne Switch) verwenden, wie in den nächsten beiden Abschnitten beschrieben.

Verwenden von Switches

Für den Nord-Süd-Datenverkehr ist die Verwendung von Switches erforderlich. Neben der Verwendung eines Ethernet-Switches, der die erforderlichen Protokolle für Azure Stack HCI unterstützt, ist der wichtigste Aspekt die richtige Dimensionierung des Netzwerkfabrics.

Sie müssen unbedingt die „nicht blockierende“ Fabric-Bandbreite kennen, die Ihre Ethernet-Switches unterstützen. Eine Überzeichnung des Netzwerks muss minimiert (oder besser ganz vermieden) werden.

Allgemeine Staufallen und Überzeichnung wie bei einer zur Pfadredundanz verwendeten Multi-Chassis Link Aggregation Group können durch eine geeignete Verwendung von Subnetzen und VLANs vermieden werden. Siehe auch Anforderungen für Hostnetzwerke.

Arbeiten Sie mit Ihrem Netzwerkanbieter oder Netzwerksupportteam zusammen, um sicherzustellen, dass Ihre Netzwerkswitches für die beabsichtigte Arbeitsauslastung ordnungsgemäß dimensioniert sind.

Ohne Switches

Azure Stack HCI unterstützt Verbindungen ohne Switches (direkte Verbindungen) für den Ost-West-Datenverkehr bei Clustern beliebiger Größe, sofern jeder Knoten im Cluster über redundante Verbindungen mit allen Knoten im Cluster verfügt. Dies wird als „Full-Mesh-Verbindung“ bezeichnet.

Diagramm: Full-Mesh-Verbindung ohne Switch

Schnittstellenpaar Subnet VLAN
vNIC des Verwaltungshosts Kundenspezifisch Kundenspezifisch
SMB01 192.168.71.x/24 711
SMB02 192.168.72.x/24 712
SMB03 192.168.73.x/24 713

Hinweis

Die Vorteile von switchlosen Bereitstellungen werden aufgrund der Anzahl von erforderlichen Netzwerkadaptern bei Clustern eingebüßt, die mehr als drei Knoten umfassen.

Vorteile von switchlosen Verbindungen

  • Für den Ost-West-Datenverkehr muss kein Switch erworben werden. Ein Switch ist für den Nord-Süd-Datenverkehr erforderlich. Dies kann zu niedrigeren Investitionskosten führen, hängt jedoch von der Anzahl der Knoten im Cluster ab.
  • Da es keinen Switch gibt, ist die Konfiguration auf den Host beschränkt, wodurch die Anzahl potenziell erforderlicher Konfigurationsschritte verringert werden kann. Dieser Wert verringert sich mit zunehmender Clustergröße.

Nachteile von switchlosen Verbindungen

  • IP- und Subnetzadressierungsschemas sind mit einem höheren Planungsaufwand verbunden.
  • Sie bieten nur lokalen Speicherzugriff. Verwaltungsdatenverkehr, VM-Datenverkehr und sonstiger Datenverkehr, der Nord-Süd-Zugriff benötigt, können diese Adapter nicht nutzen.
  • Je höher die Anzahl der Knoten im Cluster, desto eher können die Kosten für die Netzwerkadapter die Kosten bei Verwendung von Netzwerkswitches überschreiten.
  • Eine Skalierung von Clustern über drei Knoten hinaus ist nicht optimal. Je mehr Knoten, desto höher ist der Verkabelungs- und Konfigurationsaufwand, der die Komplexität der Verwendung eines Switches übersteigen kann.
  • Die Clustererweiterung ist komplex, was Hardware- und Softwarekonfigurationsänderungen erfordert.

Nächste Schritte