Anforderungen an das Hostnetzwerk für Azure Stack HCI

  • Artikel

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.

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

Wichtig

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

Ebene Verwaltungsrolle Computerolle Speicherrolle
Rollenbasierte Unterscheidung Verwaltung Compute Standard Speicherstandard
Maximale Belohnung 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: Qualifikationen für

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 Qualifikation Compute (Premium) unterstützen dynamisches VMMQ. Dynamic VMMQ erfordert die Verwendung von Switch Embedded Teaming.

Anwendbare Datenverkehrstypen: Compute

Erforderliche Zertifizierungen: 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
  • Zulassen von Workloads mit Auslastungsspitzen, um die erwartete Datenverkehrsmenge empfangen zu können

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

Erforderliche Zertifizierungen: Speicher (Standard)

Alle Adapter mit Storage-Qualifikation (Standard) oder Storage (Premium) unterstützen hostseitiges RDMA. Weitere Informationen zur Verwendung von RDMA mit Gastworkloads finden Sie weiter unten in diesem Artikel im Abschnitt "Gast-RDMA".

Azure Stack HCI unterstützt RDMA entweder mit iWARP-Protokollimplementierungen (Internet Wide Area RDMA Protocol) oder RDMA über Converged Ethernet (RoCE).

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. Im Windows Server-Katalog finden Sie Adapter mit der Qualifikation Storage (Standard) oder Storage (Premium), die RDMA-Unterstützung erfordern.

Hinweis

InfiniBand (IB) wird mit Azure Stack HCI nicht unterstützt.

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

Für weitere Informationen zum Bereitstellen von RDMA für den Host wird dringend empfohlen, Network 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 mit der Verwaltung von RDMA-Netzwerken.
  • Die Verwaltung Ihrer ToR-Switches (Top-of-Rack) ist ihnen nicht egal.
  • 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

Erforderliche Zertifizierungen: 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

Erforderliche Zertifizierungen: 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.

Wichtig

Azure Stack HCI unterstützt keine NIC-Teamerstellung mit dem älteren Lastenausgleich/Failover (LBFO). Weitere Informationen zu LBFO in Azure Stack HCI finden Sie im Blogbeitrag Teaming in Azure Stack HCI.

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)
  • Konfiguration

In 22H2 erkennt Network ATC automatisch und informiert Sie darüber, ob die von Ihnen ausgewählten Adapter asymmetrisch sind. Die einfachste Möglichkeit, manuell zu ermitteln, ob Adapter symmetrisch sind, ist, wenn 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. 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.

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

Hinweis

Es wird empfohlen, mehrere Subnetze und VLANs zu verwenden, um den Speicherdatenverkehr in Azure Stack HCI abzutrennen.

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:

Diagramm: Cluster mit vier Knoten im gleichen Subnetz

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: Cluster mit vier Knoten in verschiedenen Subnetzen

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:

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

Diagramm: Stretched Cluster

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 Replikation zwischen Standorten (Nord-Süd-Datenverkehr) können die gleichen physischen NICs verwendet werden wie für den lokalen Speicher (Ost-West-Datenverkehr). Wenn Sie dieselben physischen Adapter verwenden, müssen diese Adapter mit SET zusammenarbeiten Für die Adapter müssen auch zusätzliche virtuelle NICs bereitgestellt werden, um routingfähigen Datenverkehr zwischen Standorten zu ermöglichen.

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

Beispiel für Stretched Cluster

Im folgenden Beispiel wird eine Stretched Cluster-Konfiguration veranschaulicht. Verwenden Sie das Cmdlet Set-VMNetworkAdapterTeammapping, um sicherzustellen, dass eine bestimmte virtuelle NIC einem bestimmten physischen Adapter zugeordnet ist.

Diagramm: Beispiel für Stretched Cluster-Speicher

Im Folgenden werden die Details für die Beispielkonfiguration eines Stretched Clusters gezeigt.

Hinweis

Ihre genaue Konfiguration (einschließlich NIC-Namen, IP-Adressen und VLANs) kann sich von der gezeigten Konfiguration unterscheiden. Dies ist lediglich eine Referenzkonfiguration, die an Ihre Umgebung angepasst werden kann.

SiteA – lokale Replikation, RDMA aktiviert, Routing zwischen Standorten nicht möglich

Knotenname vNIC-Name Physische NIC (zugeordnet) VLAN IP-Adresse und Subnetz Datenverkehrsbereich
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Nur lokaler Standort
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Nur lokaler Standort
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Nur lokaler Standort
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Nur lokaler Standort

SiteB – lokale Replikation, RDMA aktiviert, Routing zwischen Standorten nicht möglich

Knotenname vNIC-Name Physische NIC (zugeordnet) VLAN IP-Adresse und Subnetz Datenverkehrsbereich
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Nur lokaler Standort
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Nur lokaler Standort
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Nur lokaler Standort
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Nur lokaler Standort

SiteA – Stretched-Replikation, RDMA deaktiviert, Routing zwischen Standorten möglich

Knotenname vNIC-Name Physische NIC (zugeordnet) IP-Adresse und Subnetz Datenverkehrsbereich
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Routing zwischen Standorten möglich
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Routing zwischen Standorten möglich
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Routing zwischen Standorten möglich
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Routing zwischen Standorten möglich

SiteB – Stretched-Replikation, RDMA deaktiviert, Routing zwischen Standorten möglich

Knotenname vNIC-Name Physische NIC (zugeordnet) IP-Adresse und Subnetz Datenverkehrsbereich
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Routing zwischen Standorten möglich
NodeB2 Stretch1 pNIC01 175.0.0.2/8 Routing zwischen Standorten möglich
NodeB1 Stretch2 pNIC02 176.0.0.1/8 Routing zwischen Standorten möglich
NodeB2 Stretch2 pNIC02 176.0.0.2/8 Routing zwischen Standorten möglich

Nächste Schritte