Freigeben über

Physische Netzwerkanforderungen für Azure Local

Gilt für: Azure Local 2311.2 und höher

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 die Registerkarte eines Anbieters, um die validierten Switches für jeden der Azure Local-Verkehrstypen zu sehen. 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 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:

Rollenanforderungen für 23H2

Anforderung Verwaltung Speicher Berechnung (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 Maximale Rahmengröße ✓ ✓ ✓ ✓
Maximale Übertragungseinheit ✓
Border Gateway Protocol (Grenz-Gateway-Protokoll) ✓
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

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 (Grenz-Gateway-Protokoll)

Ethernet-Switches, die für Azure Local SDN-Compute-Verkehr 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

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 ist die Ost-West-Richtung stark ausgeprägt, wobei ein erheblicher Teil des Datenverkehrs innerhalb einer Layer-2-Begrenzung (VLAN) bleibt.

Wichtig

Wir erfordern, 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-Verkehr für Azure Local

Nord-Süd-Verkehr hat die folgenden Merkmale:

  • 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 Verwaltungs- (PowerShell, Windows Admin Center), Compute- (VM) und standortübergreifenden Stretched Cluster-Datenverkehr.
  • Verwendet einen Ethernet-Switch für Konnektivität mit dem physischen Netzwerk.

Ost-West-Datenverkehr für Azure Local

Ost-West-Verkehr weist die folgenden Eigenschaften auf:

  • Der Datenverkehr verbleibt innerhalb der ToR-Switches und der 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 Schaltern

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.

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 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.

Diagramm: Full-Mesh-Verbindung ohne Switch

Schnittstellenpaar Subnetz 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-Verkehr ist der Kauf eines Switches nicht erforderlich. Ein Schalter ist für den Nord-Süd-Verkehr 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.

Nächste Schritte