Freigeben über

Hostnetzwerkanforderungen für Azure Local

  • Artikel

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

In diesem Thema werden Überlegungen zu Hostnetzwerken und Anforderungen für Azure Local erläutert. Informationen zu Rechenzentrumsarchitekturen und den physischen Verbindungen zwischen Computern finden Sie unter physische Netzwerkanforderungen.

Informationen zur Vereinfachung von Hostnetzwerken mithilfe von Network ATC finden Sie unter Vereinfachte Hostnetzwerke mit Network ATC.

Typen des Netzwerkdatenverkehrs

Azure Local network traffic can be classified by its intended purpose:

  • Verwaltungsdatenverkehr: Datenverkehr an oder von außerhalb des lokalen Systems. Beispiel: Speicherreplikatdatenverkehr oder Datenverkehr, der vom Administrator für die Verwaltung des Systems verwendet wird, z. B. Remotedesktop, Windows Admin Center, Active Directory usw.
  • Computedatenverkehr: Datenverkehr von oder zu einem virtuellen Computer (VM)
  • Speicherdatenverkehr: Datenverkehr unter Verwendung von Server Message Block (SMB), z. B. Direkte Speicherplätze oder SMB-basierte Live-Migration. Dieser Datenverkehr ist Layer-2-Datenverkehr und ist nicht routingfähig.

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. Im Windows Server-Katalog gibt die Windows Server 2022-Zertifizierung nun 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 Network 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.

Ebene Verwaltungsrolle Computerolle Speicherrolle
Rollenbasierte Unterscheidung Verwaltung Compute Standard Storage Standard
Höchstpreis Nicht zutreffend Compute Premium Speicher Premium

Hinweis

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

Screenshot der Qualifikation

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 Netzwerkadapterfunktionen, 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
  • Switch Embedded Teaming (SET)

Dynamic VMMQ

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

Anwendbare Datenverkehrstypen: Compute

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
  • Aktiviert "bursty"-Workloads, um die erwartete Menge an Datenverkehr zu erhalten.

Weitere Informationen zu Dynamic VMMQ finden Sie im Blogbeitrag Synthetic Accelerations (Synthetische Beschleunigung).

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 Speicherqualifizierung (Standard) oder Storage (Premium) unterstützen hostseitige RDMA. Weitere Informationen zur Verwendung von RDMA mit Gastarbeitslasten 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 mit Azure Local nicht unterstützt.

Netzwerkkartenhersteller iWARP RoCE
Broadcom No Ja
Intel Ja Ja (bestimmte Modelle)
Marvell (Qlogic) Ja Ja
Nvidia No Ja

Weitere Informationen zum Bereitstellen von RDMA für den Host empfehlen wir dringend, Netzwerk-ATC zu verwenden. 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 beim Verwalten von RDMA-Netzwerken.
  • Sie verwalten ihre Top-of-Rack-Schalter (ToR) nicht oder sind unangenehm.
  • 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

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

Mit Gast-RDMA können Sie bei SMB-Workloads für VMs von den gleichen Vorteilen wie bei Verwendung von RDMA auf Hosts profitieren.

Anwendbare Datenverkehrstypen: Gastspeicher

Zertifizierungen erforderlich: Compute (Premium)

Hauptvorteile der Verwendung von Gast-RDMA:

  • CPU-Abladung an die Netzwerkkarte zur Verarbeitung des Netzwerkdatenverkehrs
  • Äußerst niedrige Latenz
  • Hoher Durchsatz

Weitere Informationen finden Sie im Word-Dokument, das im SDN-GitHub-Repository zum Download bereitsteht.

Switch Embedded Teaming (SET)

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

Anwendbare Datenverkehrstypen: Compute, Speicher und Verwaltung

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

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

Wichtig

Azure Local unterstützt das NIC-Teaming mit dem älteren Lastenausgleich/Failover (LBFO) nicht. Weitere Informationen zu LBFO in Azure Local finden Sie im Blogbeitrag Teaming in Azure Local.

SET ist wichtig für Azure Local, da es sich um die einzige Teamtechnologie handelt, die Folgendes 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)
  • configuration

In 22H2 erkennt Network ATC automatisch und informiert Sie, ob die ausgewählten Adapter asymmetrisch sind. 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 in der zurückgegebenen Konfiguration die gleichen Eigenschaftswerte aufgeführt sind.

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. Netzwerk-ATC macht alle erforderlichen Konfigurationen für SET.

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

Weitere Informationen zum Bereitstellen von RDMA finden Sie im Word-Dokument, das im SDN-GitHub-Repository zum Download bereitsteht.

RoCE-basierte azure Local-Implementierungen erfordern die Konfiguration von drei PFC-Datenverkehrsklassen, einschließlich der Standarddatenverkehrklasse, über das Fabric und alle Hosts hinweg.

Systemdatenverkehrklasse

Diese Datenverkehrsklasse stellt sicher, dass genügend Bandbreite für Systemtakte 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 trägt alle anderen Datenverkehrs, die nicht in den System- oder RDMA-Datenverkehrsklassen definiert sind, einschließlich VM-Datenverkehr und Verwaltungsdatenverkehr:

  • Erforderlich: Standardmäßig (keine Konfiguration erforderlich auf dem Host)
  • PFC-fähig (Flusssteuerung): Nein
  • Empfohlene Datenverkehrsklasse: Standardmäßig (Priorität 0)
  • Empfohlene Bandbreitenreservierung: Standardmäßig (keine Hostkonfiguration 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

Es wird empfohlen, mehrere Subnetze und VLANs zum Trennen des Speicherdatenverkehrs in Azure Local zu verwenden.

Betrachten Sie das folgende Beispiel eines vier Knotensystems. Jeder Computer verfügt über zwei Speicherports (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 Anschluss auf dem ersten Computer (192.168.1.1.1) eine Verbindung mit dem linken Anschluss auf dem zweiten Computer (192.168.1.2) herstellen. Der rechte Anschluss auf dem ersten Computer (192.168.1.12) wird mit dem rechten Anschluss auf dem zweiten Computer verbunden. Ähnliche Verbindungen werden für die dritten und vierten Computer 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 Beispielbandbreitenzuweisungen verschiedener Datenverkehrstypen mit allgemeinen Adaptergeschwindigkeiten in Azure Local. Beachten Sie, dass es sich hierbei um ein Beispiel für eine zusammengeführte Lösung handelt, bei der alle Datenverkehrstypen (Compute, Speicher und Verwaltung) über die gleichen physischen Adapter ausgeführt werden und ein Teaming mithilfe von SET erfolgt.

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
    • Verwendung von 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 100GBit/s 50 GBit/s 70 % 35 GBit/s 29 % 14,5 GBit/s %1 500 MBit/s
100GBit/s 200 GBit/s 100GBit/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: Stretched Cluster

Anforderungen für Stretched Cluster

Wichtig

Gestreckte Clusterfunktionen sind 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.

  • Computer am selben Standort müssen sich in derselben Rack- und 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