In diesem Artikel werden Überlegungen und Anforderungen für physische Netzwerke (Fabric) für Azure Local behandelt, insbesondere für Netzwerkswitche.
Hinweis
Die Anforderungen für zukünftige lokale Azure-Versionen können sich ändern.
Netzwerkswitche für Azure Local
Microsoft testet Azure Local auf die Standards und Protokolle, die im Abschnitt "Netzwerkswitchanforderungen " unten angegeben sind. Obwohl Microsoft Keine Netzwerkswitche zertifiziert, arbeiten wir mit Anbietern zusammen, um Geräte zu identifizieren, die Azure Local-Anforderungen unterstützen.
Wichtig
Während andere Netzwerkswitche mit Technologien und Protokollen, die hier nicht aufgeführt sind, möglicherweise funktionieren, kann Microsoft nicht garantieren, dass sie mit Azure Local arbeiten und möglicherweise nicht bei der Problembehandlung helfen können, die auftreten.
Wenden Sie sich beim Kauf von Netzwerkswitchen an Ihren Switchanbieter, und stellen Sie sicher, dass die Geräte die lokalen Azure-Anforderungen für Ihre angegebenen Rollentypen erfüllen. Die folgenden Anbieter (in alphabetischer Reihenfolge) haben bestätigt, dass ihre Switches Azure Local-Anforderungen unterstützen:
Klicken Sie auf eine Lieferantenregisterkarte, um überprüfte Switches für jeden der lokalen Azure-Datenverkehrstypen 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.
Broadcom Advanced Enterprise SONiC OS 4.2.1 oder höher
✓
✓
✓
✓
Hinweis
Für Gast-RDMA sind Sowohl Compute (Standard) als auch Speicher erforderlich.
Anforderungen an Netzwerkswitches
In diesem Abschnitt werden Branchenstandards aufgeführt, die für die spezifischen Rollen von Netzwerkswitchen erforderlich sind, die in lokalen Azure-Bereitstellungen verwendet werden. Diese Standards tragen dazu bei, eine zuverlässige Kommunikation zwischen Knoten in lokalen Azure-Bereitstellungen sicherzustellen.
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:
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 mehrere Aspekte von Azure Local erforderlich und sind in allen Szenarien erforderlich.
Standard: IEEE 802.1Qbb
Ethernet-Switches, die für den lokalen Azure-Speicherdatenverkehr verwendet werden, müssen der IEEE 802.1Qbb-Spezifikation entsprechen, 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 den lokalen Azure-Speicherdatenverkehr verwendet werden, müssen der IEEE 802.1Qaz-Spezifikation entsprechen, 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 testt Azure Local nicht mit Differenziertem Dienstcodepunkt (DSCP).
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 Local erforderlich und ermöglicht die Problembehandlung bei physischen 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 Local 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 den lokalen Azure-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
22H2-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 mehrere Aspekte von Azure Local erforderlich und sind in allen Szenarien erforderlich.
Standard: IEEE 802.1Qbb
Ethernet-Switches, die für den lokalen Azure-Speicherdatenverkehr verwendet werden, müssen der IEEE 802.1Qbb-Spezifikation entsprechen, 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 den lokalen Azure-Speicherdatenverkehr verwendet werden, müssen der IEEE 802.1Qaz-Spezifikation entsprechen, 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 testt Azure Local nicht mit Differenziertem Dienstcodepunkt (DSCP).
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 Local erforderlich und ermöglicht die Problembehandlung bei physischen 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
Neue Anforderung in 22H2
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
Neue Anforderung in 22H2
Ethernet-Switches, die für azure Local 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
Neue Anforderung in 22H2
Ethernet-Switches, die für den lokalen Azure-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 Local kann in verschiedenen Rechenzentrumsarchitekturen funktionieren, darunter 2-stufige (Spine-Leaf) und 3-stufige (Core-Aggregation-Access). Dieser Abschnitt bezieht sich mehr auf Konzepte aus der Spine-Leaf-Topologie, die häufig mit Workloads in hyperkonvergenter Infrastruktur wie Azure Local 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 lokalen Azure-Computer an einem Standort physisch im selben Rack befinden und mit denselben Top-of-Rack(ToR)-Switches verbunden sind.
Hinweis
Gestreckte Clusterfunktionen sind nur in Azure Local, Version 22H2, verfügbar.
Nord-Süd-Datenverkehr für Azure Local
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 Local
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 System 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 Local unterstützt, ist der wichtigste Aspekt die richtige Größenanpassung der Netzwerk fabric.
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.
Arbeiten Sie mit Ihrem Netzwerkanbieter oder Netzwerksupportteam zusammen, um sicherzustellen, dass Ihre Netzwerkswitches für die beabsichtigte Arbeitsauslastung ordnungsgemäß dimensioniert sind.
Ohne Switches
Azure Local unterstützt switchlose (direkte) Verbindungen für Ost-West-Datenverkehr für alle Systemgrößen, solange jeder Knoten im System über eine redundante Verbindung zu jedem Knoten im System verfügt. Dies wird als „Full-Mesh-Verbindung“ bezeichnet.
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 verringern sich aufgrund der Anzahl der erforderlichen Netzwerkadapter mit Systemen, die größer als drei Knoten sind.
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 geringeren Investitionskosten (CAPEX) führen, hängt aber von der Anzahl der Knoten im System 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 nimmt ab, wenn die Systemgröße zunimmt.
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.
Da die Anzahl der Knoten im System wächst, könnten die Kosten der Netzwerkadapter die Kosten für die Verwendung von Netzwerkswitchen überschreiten.
Skaliert nicht weit über drei Knotensysteme hinaus. Je mehr Knoten, desto höher ist der Verkabelungs- und Konfigurationsaufwand, der die Komplexität der Verwendung eines Switches übersteigen kann.
Die Systemerweiterung ist komplex, was Hardware- und Softwarekonfigurationsänderungen erfordert.
