Anforderungen an das Hostnetzwerk für Azure Stack HCI

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

In diesem Thema werden Überlegungen und Anforderungen für Azure Stack HCI-Hostnetzwerke behandelt. Informationen zu Rechenzentrumsarchitekturen und den physischen Verbindungen zwischen Servern finden Sie unter Anforderungen an das physische Netzwerk.

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

Typen des Netzwerkdatenverkehrs

Azure Stack HCI-Netzwerkdatenverkehr kann nach seinem beabsichtigten Einsatzzweck klassifiziert werden:

• Verwaltungsdatenverkehr: Datenverkehr zum lokalen Cluster oder von außerhalb des lokalen Clusters. Dazu zählt beispielsweise Speicherreplikat-Datenverkehr oder Datenverkehr, der vom Administrator für die Verwaltung des Clusters verwendet wird, wie 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.

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 Server für Azure Stack HCI erwerben, müssen Sie mindestens einen Adapter besitzen, der für die Verwaltung, Berechnung und Speicherung qualifiziert ist, da alle drei Datenverkehrstypen in Azure Stack HCI 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-Qualifikation finden Sie unter diesem Link.

Treiberanforderungen

Posteingangstreiber werden für die Verwendung mit Azure Stack HCI 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 Funktionen der von Azure Stack HCI genutzten Netzwerkadapter gehören folgende:

• 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 Stack HCI unterstützt RDMA entweder mit dem Internet Wide Area RDMA Protocol (iWARP) oder RDMA over Converged Ethernet (RoCE)-Protokollimplementierungen.

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.

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 Teamingtechnologie, die von Azure Stack HCI 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 Teamingtechnologie, die von Azure Stack HCI unterstützt wird. SET kann gleichermaßen für Compute-, Storage- und Verwaltungsdatenverkehr verwendet werden.

SET ist für Azure Stack HCI von großer Bedeutung, da es die einzige Teamingtechnologie ist, die folgende Funktionen unterstützt:

• Teaming von RDMA-Adaptern (bei Bedarf)
• Gast-RDMA
• Dynamic VMMQ
• Weitere wichtige Azure Stack HCI-Features (siehe Teaming in Azure Stack HCI)

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:

Ü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 Stack HCI-Implementierungen erfordern die Konfiguration von drei PFC-Datenverkehrsklassen, einschließlich der Standard-Datenverkehrsklasse, im gesamten Fabric und auf allen Hosts.

Cluster-Datenverkehrsklasse

Diese Datenverkehrsklasse stellt sicher, dass genügend Bandbreite für den Clustertakt 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

Dieser Datenverkehrsklasse unterliegt der gesamte sonstige Datenverkehr (einschließlich VM- und Verwaltungsdatenverkehr), der nicht in der Cluster- oder RDMA-Datenverkehrsklasse definiert ist:

• 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 als Speicherprotokoll für Azure Stack HCI viele Vorteile, darunter z. B. 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.

Betrachten Sie das folgende Beispiel eines Clusters mit vier Knoten. Jeder Server 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 stellt der linke Port auf dem ersten Server (192.168.1.1) eine Verbindung mit dem linken Port auf dem zweiten Server (192.168.1.2) her. Der rechte Port auf dem ersten Server (192.168.1.12) stellt eine Verbindung mit dem rechten Port auf dem zweiten Server her. Entsprechende Verbindungen werden für den dritten und vierten Server 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:

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.

Bandbreitenzuordnung für Datenverkehr

Die folgende Tabelle enthält Beispiele für Bandbreitenzuordnungen verschiedener Datenverkehrstypen bei üblichen Adaptergeschwindigkeiten in Azure Stack HCI. 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:

* 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 Azure Stack HCI-Netzwerk mit Stretched Cluster wie folgt aus:

Anforderungen für Stretched Cluster

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.

• Server am gleichen Standort müssen sich im gleichen Rack und innerhalb der gleichen Layer-2-Grenzen 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

• Informieren Sie sich über die Anforderungen an Netzwerkswitches und physische Netzwerke. Siehe Anforderungen für physische Netzwerke.
• Erfahren Sie, wie Sie Hostnetzwerke mithilfe von Network ATC vereinfachen. Weitere Informationen finden Sie unter Vereinfachte Hostnetzwerke mit Network ATC.
• Auffrischung: Failover Clustering Networking Basics (Netzwerkgrundlagen zum Failoverclustering).
• Siehe Bereitstellen mithilfe von Azure-Portal.
• Siehe Bereitstellen mithilfe der Azure Resource Manager-Vorlage.