Freigeben über

Anforderungen an das Host-Netzwerk für Azure Local

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

In diesem Thema werden Überlegungen zu Host-Netzwerken und Anforderungen für Azure Local behandelt. Informationen zu Rechenzentrumsarchitekturen und den physischen Verbindungen zwischen Computern finden Sie unter physische Netzwerkanforderungen.

Informationen zum Vereinfachen des Hostnetzwerks mithilfe von Network ATC finden Sie unter Vereinfachen der Hostnetzwerke mit Network ATC.

Typen des Netzwerkdatenverkehrs

Azure Localer Netzwerkverkehr kann nach seinem Verwendungszweck klassifiziert werden:

  • Verwaltungsdatenverkehr: Datenverkehr zu oder von außerhalb des lokalen Systems. Zum Beispiel Datenverkehr von Speicherreplikaten oder Datenverkehr, der vom Administrator für die Verwaltung des Systems wie Remote Desktop, Windows Admin Center, Active Directory usw. verwendet wird.
  • Rechenverkehr: Datenverkehr, der von einer virtuellen Maschine (VM) stammt oder an diese bestimmt ist.
  • Speicherdatenverkehr: Datenverkehr mit Server Message Block (SMB), z. B. Storage Spaces Direct oder SMB-basierte Live-Migration. Dieser Verkehr ist Schicht-2-Verkehr und kann nicht geroutet werden.

Wichtig

Für Speicherreplikate wird Nicht-RDMA-basierter SMB-Datenverkehr genutzt. Dies und die Richtung des Datenverkehrs (Nord-Süd) führt dazu, dass er dem oben erwähnten Verwaltungsdatenverkehr sehr ähnlich ist, ähnlich wie bei einer herkömmlichen Dateifreigabe.

Auswählen eines Netzwerkadapters

Netzwerkadapter werden von den Netzwerkdatenverkehrstypen (siehe oben) qualifiziert, für deren Verwendung sie unterstützt werden. Während Sie den Windows Server-Katalog überprüfen, gibt die Windows Server 2022-Zertifizierung jetzt eine oder mehrere der folgenden Rollen an. Bevor Sie einen Computer für Azure Local erwerben, müssen Sie mindestens einen Adapter besitzen, der für die Verwaltung, Berechnung und Speicherung qualifiziert ist, da alle drei Datenverkehrstypen in Azure Local erforderlich sind. Anschließend können Sie Netzwerk-ATC verwenden, um Ihre Adapter für die entsprechenden Datenverkehrstypen zu konfigurieren.

Weitere Informationen zu dieser rollenbasierten NIC-Qualifizierung finden Sie in diesem Windows Server-Blogbeitrag.

Wichtig

Die Verwendung eines Adapters außerhalb des qualifizierten Datenverkehrstyps wird nicht unterstützt.

Grad Verwaltungsrolle Computerolle Speicherrolle
Rollenbasierte Unterscheidung Verwaltung Computestandard Lagerung Standard
Maximaler Preis Nicht zutreffend Compute Premium Speicher Premium

Hinweis

Die höchste Qualifikation für jeden Adapter in unserem Ökosystem enthält die Qualifikationen Management, Compute Premium und Storage Premium .

Screenshot zeigt die Zertifizierungen

Treiberanforderungen

Posteingangstreiber werden für die Verwendung mit Azure Local nicht unterstützt. Führen Sie das folgende Cmdlet aus, um zu ermitteln, ob der Adapter einen Posteingangstreiber verwendet. Ein Adapter verwendet einen Posteingangstreiber, wenn die Eigenschaft DriverProvider auf Microsoft festgelegt ist.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Übersicht über die wichtigsten Funktionen des Netzwerkadapters

Zu den wichtigen Netzwerkadapter-Funktionen, die von Azure Local verwendet werden, gehören:

  • Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ oder d.VMMQ)
  • Remotezugriff auf den direkten Speicher (RDMA)
  • Gast-RDMA
  • Eingebettetes Teaming wechseln (SET)

Dynamische VMMQ

Alle Netzwerkadapter mit der Qualifikation Compute (Premium) unterstützen Dynamic VMMQ. Dynamic VMMQ erfordert die Verwendung von Switch Embedded Teaming.

Anwendbare Datenverkehrstypen: Berechnen

Zertifizierungen erforderlich: Compute (Premium)

Dynamic VMMQ ist eine intelligente empfangsseitige Technologie. Sie baut auf den Vorläufern Virtual Machine Queue (VMQ), Virtual Receive Side Scaling (vRSS) und VMMQ auf und bietet im Vergleich zu diesen drei wichtige Verbesserungen:

  • Optimierte Hosteffizienz durch die Verwendung von weniger CPU-Kernen
  • Automatische Optimierung der Verarbeitung von Netzwerkdatenverkehr auf CPU-Kernen, sodass VMs den erwarteten Durchsatz erzielen und aufrechterhalten können
  • Erlaubt Workloads mit Auslastungsspitzen, um die erwartete Datenverkehrsmenge empfangen zu können.

Weitere Informationen zu dynamic VMMQ finden Sie im Blogbeitrag synthetische Beschleunigungen.

RDMA

RDMA bezeichnet eine Abladung des Netzwerkstapels auf den Netzwerkadapter. Dies ermöglicht es dem SMB-Speicherdatenverkehr, bei der Verarbeitung das Betriebssystem zu umgehen.

RDMA ermöglicht Netzwerke mit hohem Durchsatz und geringer Latenz bei möglichst geringer Auslastung der Host-CPU-Ressourcen. Diese Host-CPU-Ressourcen können dann verwendet werden, um zusätzliche VMs oder Container auszuführen.

Anwendbare Datenverkehrstypen: Hostspeicher

Zertifizierungen erforderlich: Speicher (Standard)

Alle Adapter mit der Qualifikation „Speicher (Standard)“ oder „Speicher (Premium)“ unterstützen hostseitigen RDMA. Weitere Informationen zur Verwendung von RDMA mit Gast-Workloads finden Sie im Abschnitt "Gast-RDMA" weiter unten in diesem Artikel.

Azure Local unterstützt RDMA entweder mit dem Internet Wide Area RDMA Protocol (iWARP) oder RDMA over Converged Ethernet (RoCE) Protokollimplementierungen.

Wichtig

RDMA-Adapter können nur mit anderen RDMA-Adaptern verwendet werden, die dasselbe RDMA-Protokoll (iWARP oder RoCE) implementieren.

RDMA wird nicht von allen Netzwerkadaptern der Anbieter unterstützt. In der folgenden Tabelle sind die Anbieter (in alphabetischer Reihenfolge) aufgeführt, die zertifizierte RDMA-Adapter anbieten. In dieser Liste sind jedoch nicht alle Hardwareanbieter aufgeführt, die RDMA unterstützen. Sehen Sie sich den Windows Server-Katalog an, um Adapter mit der Qualifizierung "Storage (Standard) oder Storage (Premium)" zu finden, die RDMA-Unterstützung erfordern.

Hinweis

InfiniBand (IB) wird von Azure Local nicht unterstützt.

Netzwerkkartenhersteller iWARP RoCE (Rendite des eingesetzten Kapitals)
Broadcom Nein Ja
Intel Ja Ja (bestimmte Modelle)
Marvell (Qlogic) Ja Ja
Nvidia Nein Ja

Für weitere Informationen über die Bereitstellung von RDMA für den Host empfehlen wir Ihnen die Verwendung von Network ATC. Informationen zur manuellen Bereitstellung finden Sie im SDN GitHub-Repository.

iWARP

iWARP verwendet TCP (Transmission Control Protocol) und kann optional mit PFC (Priority-based Flow Control) und ETS (Enhanced Transmission Service) erweitert werden.

Verwenden Sie iWARP in folgenden Situationen:

  • Sie haben keine Erfahrung in der Verwaltung von RDMA-Netzwerken.
  • Sie verwalten Ihre ToR-Switches nicht oder sind mit der Verwaltung nicht vertraut.
  • Die Lösung wird nach der Bereitstellung nicht von Ihnen verwaltet.
  • Sie verfügen bereits über Bereitstellungen, die iWARP verwenden.
  • Sie sind unsicher, für welche Option Sie sich entscheiden sollen.

RoCE (Rendite des eingesetzten Kapitals)

RoCE verwendet das User Datagram Protocol (UDP) und erfordert PFC und ETS, um Zuverlässigkeit zu gewährleisten.

Verwenden Sie RoCE in folgenden Situationen:

  • Sie verfügen bereits über Bereitstellungen mit RoCE in Ihrem Rechenzentrum.
  • Sie sind mit der Verwaltung der DCB-Netzwerkanforderungen vertraut.

Gast-RDMA

Das Gast-RDMA wird in Azure Local nicht unterstützt.

Eingebettetes Teaming wechseln (SET)

Switch Embedded Teaming (SET) ist eine softwarebasierte Teamingtechnologie, die ab Windows Server 2016 Bestandteil des Windows Server-Betriebssystems ist. SET ist die einzige Teaming-Technologie, die von Azure Local unterstützt wird. SET eignet sich gut für Rechen-, Speicher- und Verwaltungsdatenverkehr und wird von bis zu acht Adaptern im selben Team unterstützt.

Anwendbare Datenverkehrstypen: Berechnen, Speichern und Verwalten

Zertifizierungen erforderlich: Compute (Standard) oder Compute (Premium)

SET ist die einzige Teaming-Technologie, die von Azure Local unterstützt wird. SET kann gleichermaßen für Compute-, Storage- und Verwaltungsdatenverkehr verwendet werden.

Wichtig

Azure Local unterstützt NIC-Teamvorgänge mit der älteren LBFO-Technologie (Load Balancing, Failover; Lastenausgleich/Failover) nicht. Weitere Informationen zu LBFO in Azure Local finden Sie im Blogbeitrag Teaming in Azure Local.

SET ist wichtig für Azure Local, denn es ist die einzige Teaming-Technologie, die dies ermöglicht:

  • Teaming von RDMA-Adaptern (bei Bedarf)
  • Gast-RDMA
  • Dynamic VMMQ
  • Weitere wichtige lokale Azure-Features (siehe Teaming in Azure Local).

SET erfordert die Verwendung symmetrischer (identischer) Adapter. Netzwerkadapter sind symmetrisch, wenn Folgendes identisch ist:

  • Marke (Hersteller)
  • Modell (Version)
  • Geschwindigkeit (Durchsatz)
  • Konfiguration

In 22H2 erkennt Network ATC automatisch, ob die von Ihnen gewählten Adapter asymmetrisch sind und informiert Sie darüber. Die einfachste Möglichkeit, manuell zu identifizieren, ob Adapter symmetrisch sind, ist, ob die Geschwindigkeiten und Schnittstellenbeschreibungen exakt übereinstimmen. Eine Abweichung ist nur bei der in der Beschreibung aufgeführten Ziffer zulässig. Verwenden Sie das Cmdlet Get-NetAdapterAdvancedProperty , um sicherzustellen, dass die gemeldete Konfiguration die gleichen Eigenschaftswerte auflistet.

In der folgenden Tabelle finden Sie ein Beispiel für Schnittstellenbeschreibungen, die sich nur durch die Ziffer (#) unterscheiden:

Name Schnittstellenbeschreibung Verbindungsgeschwindigkeit
NIC1 Netzwerkadapter #1 25GBit/s
NIC2 Netzwerkadapter #2 25GBit/s
NIC3 Netzwerkadapter #3 25GBit/s
NIC4 Netzwerkadapter #4 25GBit/s

Hinweis

SET unterstützt nur switchunabhängige Konfigurationen mit dynamischen oder Hyper-V-Port-Lastenausgleichsalgorithmen. Für eine optimale Leistung wird Hyper-V-Port für die Verwendung auf allen NICs empfohlen, die mit mindestens 10 GBit/s arbeiten. Network ATC nimmt alle erforderlichen Konfigurationen für SET vor.

Überlegungen zum RDMA-Datenverkehr

Wenn Sie Data Center Bridging (DCB) implementieren, müssen Sie sicherstellen, dass die Konfiguration von PFC und ETS für jeden Netzwerkport, einschließlich Netzwerkswitches, ordnungsgemäß implementiert wurde. DCB ist für RoCE erforderlich und bei iWARP optional.

Ausführliche Informationen zum Bereitstellen von RDMA finden Sie im SDN GitHub-Repository.

RoCE-basierte Azure Local-Implementierungen erfordern die Konfiguration von drei PFC-Verkehrsklassen, einschließlich der Standard-Verkehrsklasse, in der gesamten Fabric und auf allen Hosts.

Klasse des Systemdatenverkehrs

Diese Verkehrsklasse stellt sicher, dass genügend Bandbreite für die Herzschläge des Systems reserviert ist:

  • Erforderlich: Ja
  • PFC-fähig: Nein
  • Empfohlene Datenverkehrspriorität: Priorität 7
  • Empfohlene Bandbreitenreservierung:
    • RDMA-Netzwerke bis 10 GbE = 2 %
    • RDMA-Netzwerke bis 25 GbE = 1 %

RDMA-Datenverkehrsklasse

Diese Datenverkehrsklasse stellt sicher, dass genügend Bandbreite für eine verlustfreie RDMA-Kommunikation mithilfe von SMB Direct reserviert ist:

  • Erforderlich: Ja
  • PFC-fähig: Ja
  • Empfohlene Datenverkehrspriorität: Priorität 3 oder 4
  • Empfohlene Bandbreitenreservierung: 50 %

Standard-Datenverkehrsklasse

Diese Datenverkehrsklasse umfasst alle anderen Daten, die nicht in den System- oder RDMA-Datenverkehrsklassen definiert sind, einschließlich VM-Datenverkehr und Management-Datenverkehr:

  • Erforderlich: Standardmäßig (keine Konfiguration auf dem Host erforderlich)
  • PFC-fähig (Flusssteuerung): Nein
  • Empfohlene Datenverkehrsklasse: Standard (Priorität 0)
  • Empfohlene Bandbreitenreservierung: : Standardmäßig (keine Host-Konfiguration erforderlich)

Modelle für den Speicherdatenverkehr

SMB bietet viele Vorteile als Speicherprotokoll für Azure Local, einschließlich SMB Multichannel. SMB Multichannel wird in diesem Artikel nicht behandelt, aber Sie sollten wissen, dass der Datenverkehr für alle Links, die von SMB Multichannel verwendet werden können, Multiplexing verwendet.

Hinweis

Wir empfehlen die Verwendung mehrerer Subnetze und VLANs, um den Speicherverkehr in Azure Local zu trennen.

Betrachten Sie das folgende Beispiel eines Systems mit vier Knoten. Jedes Gerät hat zwei Speicheranschlüsse (links und rechts). Da sich alle Adapter im gleichen Subnetz und VLAN befinden, verteilt SMB Multichannel Verbindungen über alle verfügbaren Links. Daher wird der linke Port auf dem ersten Rechner (192.168.1.1) eine Verbindung mit dem linken Port auf dem zweiten Rechner (192.168.1.2) herstellen. Der rechte Port auf dem ersten Rechner (192.168.1.12) wird mit dem rechten Port auf dem zweiten Rechner verbunden. Ähnliche Verbindungen werden für die dritte und vierte Maschine hergestellt.

Dies führt jedoch zu unnötigen Verbindungen und zu einer Überlastung des Interlink (Multi-Chassis Link Aggregation Group, MC-LAG), der die ToR-Switches verbindet (mit X gekennzeichnet). Sehen Sie sich die folgende Abbildung an:

Diagramm, das ein Vierknotensystem im selben Subnetz zeigt.

Die empfohlene Vorgehensweise besteht darin, separate Subnetze und VLANs für jede Gruppe von Adaptern zu verwenden. Im folgenden Diagramm verwenden die rechten Ports nun Subnetz 192.168.2. x/24 und VLAN2. Dadurch kann der Datenverkehr an den linken Ports auf TOR1 und der Datenverkehr an den rechten Ports auf TOR2 bleiben.

Diagramm, das ein Vierknotensystem in verschiedenen Subnetzen zeigt.

Bandbreitenzuordnung für Datenverkehr

Die folgende Tabelle zeigt Beispiele für die Bandbreitenzuweisung verschiedener Datenverkehrstypen unter Verwendung gängiger Adaptergeschwindigkeiten in Azure Local. Beachten Sie, dass dies ein Beispiel für eine zusammengeführte Lösung ist, bei der alle Datenverkehrstypen (Compute, Speicher und Verwaltung) über dieselben physischen Adapter ausgeführt werden und mithilfe von SET zusammengeführt werden.

Da dieser Anwendungsfall mit den meisten Einschränkungen verbunden ist, stellt er eine gute Baseline dar. Unter Berücksichtigung der Variationen in Bezug auf die Anzahl von Adaptern und Geschwindigkeiten sollte dies jedoch als Beispiel und nicht als erforderliche Unterstützung betrachtet werden.

Dieses Beispiel geht von folgenden Voraussetzungen aus:

  • Zwei Adapter pro Team

  • SBL- (Storage Bus Layer), CSV- (Cluster Shared Volume) und Hyper-V-Datenverkehr (Livemigration):

    • Verwendung derselben physischen Adapter
    • Verwenden Sie SMB.

  • SMB erhält über DCB eine Bandbreitenreservierung von 50 %

    • SBL/CSV ist der Datenverkehr mit der höchsten Priorität und erhält 70 % der SMB-Bandbreitenreservierung
    • Einschränkung der Livemigration (LM) mithilfe des Cmdlets Set-SMBBandwidthLimit, Zuweisung von 29 % der verbleibenden Bandbreite

      • Wenn die verfügbare Bandbreite für die Livemigration > = 5 Gbit/s beträgt und die Netzwerkadapter dies unterstützen, verwenden Sie RDMA. Verwenden Sie hierzu das folgende Cmdlet:

        Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

      • Wenn die verfügbare Bandbreite für die Livemigration < 5 Gbit/s beträgt, verringern Sie die Ausfallzeiten mithilfe von Komprimierung. Verwenden Sie hierzu das folgende Cmdlet:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

  • Wenn Sie RDMA für den Datenverkehr zur Livemigration verwenden, stellen Sie mithilfe einer SMB-Bandbreitenbegrenzung sicher, dass dieser Datenverkehr nicht die gesamte Bandbreite belegen kann, die der RDMA-Datenverkehrsklasse zugeordnet ist. Gehen Sie umsichtig vor, weil dieses Cmdlet eine Eingabe in Byte pro Sekunde (B/s) erwartet, während für die Netzwerkadapter Bit pro Sekunde (Bit/s) aufgeführt sind. Verwenden Sie das folgende Cmdlet, um eine Bandbreitenbegrenzung von 6 Gbit/s festzulegen. Beispiel:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

    Hinweis

    750 MB/s in diesem Beispiel entsprechen 6 Gbit/s.

Hier sehen Sie die Tabelle mit der Beispiel-Bandbreitenzuordnung:

NIC-Geschwindigkeit Kombinierte Bandbreite SMB-Bandbreitenreservierung** SBL/CSV-% SBL/CSV-Bandbreite Livemigration % Maximale Bandbreite für die Livemigration Takt % Taktbandbreite
10 GBit/s 20GBit/s 10 GBit/s 70 % 7 GBit/s * 200 MBit/s
25GBit/s 50 GBit/s 25GBit/s 70 % 17.5 GBit/s 29 % 7.25 GBit/s %1 250 MBit/s
40 GBit/s 80 GBit/s 40 GBit/s 70 % 28 GBit/s 29 % 11.6 GBit/s %1 400 MBit/s
50 GBit/s 100 GBit/s 50 GBit/s 70 % 35 GBit/s 29 % 14.5 GBit/s %1 500 MBit/s
100 GBit/s 200 GBit/s 100 GBit/s 70 % 70 GBit/s 29 % 29 GBit/s %1 1 GBit/s
200 GBit/s 400 GBit/s 200 GBit/s 70 % 140 GBit/s 29 % 58 GBit/s %1 2 GBit/s

* Verwenden Sie anstelle von RDMA die Komprimierung, da die Bandbreitenzuordnung für den Datenverkehr zur Livemigration < 5 Gbit/s beträgt.

** 50 % sind ein Beispiel für eine Bandbreitenreservierung.

Stretchingcluster

Stretched Cluster bieten eine Notfallwiederherstellung, die mehrere Rechenzentren umfasst. In seiner einfachsten Form sieht ein gestreckter Cluster von Azure Local wie folgt aus:

Diagramm, das einen gestreckten Cluster zeigt.

Anforderungen für Stretched Cluster

Wichtig

Die Stretched-Cluster-Funktionalität ist nur in Azure Local, Version 22H2, verfügbar.

Stretched Cluster weisen die folgenden Anforderungen und Merkmale auf:

  • RDMA ist auf einen einzelnen Standort beschränkt und wird nicht über verschiedene Standorte oder Subnetze hinweg unterstützt.

  • Rechner am selben Standort müssen sich im selben Rack und in derselben Layer-2-Grenze befinden.

  • Die Hostkommunikation zwischen Standorten muss eine Layer-3-Grenze überschreiten. Layer-2-Topologien mit Stretched Cluster werden nicht unterstützt.

  • Sie verfügen über genügend Bandbreite, um die Workloads am anderen Standort ausführen zu können. Im Falle eines Failovers muss der gesamte Datenverkehr vom alternativen Standort ausgeführt werden. Es wird empfohlen, Standorte mit 50 % der verfügbaren Netzwerkkapazität bereitzustellen. Dies ist keine jedoch keine verbindliche Anforderung, wenn während eines Failovers Leistungseinbußen hinnehmbar sind.

  • Für die Kommunikation zwischen Standorten verwendete Adapter:

    • Können physisch oder virtuell (Host-vNIC) sein. Bei virtuellen Adaptern müssen Sie pro physischer Netzwerkkarte eine vNIC in einem eigenen Subnetz und VLAN bereitstellen.

    • Muss sich in einem eigenen Subnetz und VLAN befinden, das eine Weiterleitung zwischen Standorten erlaubt.

    • RDMA muss mit dem Cmdlet Disable-NetAdapterRDMA deaktiviert werden. Es wird empfohlen, dass Sie mithilfe des Cmdlets Set-SRNetworkConstraint explizit festlegen, dass das Speicherreplikat bestimmte Schnittstellen verwenden muss.

    • Muss alle zusätzlichen Anforderungen für das Speicherreplikat erfüllen.

Nächste Schritte