Überprüfen Des Drei-Knoten-Speicherschalters, dualer TOR- und Single Link Deployment Network Reference Pattern für Azure Local

> Gilt für: Azure Local, Version 23H2 und höher

In diesem Artikel erfahren Sie mehr über den Drei-Knoten-Speicherschalter ohne zwei TOR L3-Switches und ein Netzwerkverweismuster mit voll gitterbasiertem Netzwerk, mit dem Sie Ihre lokale Azure-Lösung bereitstellen können.

Szenarien

Szenarien für dieses Netzwerkmuster umfassen Labore, Fabriken, Einzelhandelsgeschäfte, öffentliche Sektoren und Behörden.

Erwägen Sie die Implementierung dieses Musters, wenn Sie nach einer kosteneffizienten Lösung suchen, die über Fehlertoleranz für alle Netzwerkkomponenten verfügt. L3-Dienste (Software Defined Network, Software Defined Network, SDN) werden in diesem Muster vollständig unterstützt. Routingdienste wie das Border Gateway Protocol (BGP) können direkt auf den TOR-Switches konfiguriert werden, wenn sie L3-Dienste unterstützen. Netzwerksicherheitsfeatures wie Mikrosegmentierung oder Quality of Service (QoS) erfordern keine zusätzliche Konfiguration des Firewallgeräts, da sie auf der Ebene des virtuellen Netzwerkadapters implementiert sind.

Physische Verbindungskomponenten

Wie im obigen Diagramm dargestellt, weist dieses Muster die folgenden physischen Netzwerkkomponenten auf:

• Für die nord- und südgebundene Kommunikation erfordert die lokale Azure-Instanz zwei TOR-Switches in der MLAG-Konfiguration (Multi-Chassis Link Aggregation Group).
• Zwei Netzwerkkarten mit SET virtual switch zum Verarbeiten von Verwaltungs- und Computedatenverkehr, die mit den TOR-Switches verbunden sind. Jede NIC ist mit einem anderen ToR verbunden.
• Zwei RDMA-NICs auf jedem Knoten in einer Vollgitter-Einzelverbindungskonfiguration für Ost-West-Datenverkehr für den Speicher.

  Hinweis

  Für diese Konfiguration gibt es keine redundante Netzwerkverbindung zwischen den Knoten.

Logische Netzwerke

Wie im folgenden Diagramm dargestellt, weist dieses Muster die folgenden logischen Netzwerkkomponenten auf:

Node interconnect networks VLAN for SMB traffic (Storage and live migration)

Der auf Speicherabsicht basierende Datenverkehr besteht aus drei einzelnen Subnetzen, die RDMA-Datenverkehr unterstützen. Jede Schnittstelle ist einem separaten Knotenverbindungsnetzwerk zugeordnet. Dieser Datenverkehr soll nur zwischen den drei Knoten reisen. Speicherdatenverkehr auf diesen Subnetzen ist ohne Verbindung mit anderen Ressourcen isoliert.

Jedes Paar von Speicheradaptern zwischen den Knoten funktioniert in verschiedenen IP-Subnetzen. Um eine switchlose Konfiguration zu ermöglichen, unterstützt jeder verbundene Knoten das gleiche übereinstimmende Subnetz seines Nachbarn.

Bei der Bereitstellung einer Switchless-Konfiguration mit drei Knoten weist Network ATC die folgenden Anforderungen auf:

• Unterstützt nur ein einzelnes VLAN für alle IP-Subnetze, die für die Speicherkonnektivität verwendet werden.

• StorageAutoIP Der Parameter muss auf "false" festgelegt sein, Switchless der Parameter muss auf "true" festgelegt werden, und Sie sind dafür verantwortlich, die IPs in der ARM-Vorlage anzugeben, die zum Bereitstellen der lokalen Azure-Instanz aus Azure verwendet wird.

• Für Azure Local, Version 23H2-Cloudbereitstellungen:

  • Skalierungsfreie Speichersysteme werden nicht unterstützt.

  • Es ist nur möglich, dieses Szenario mit drei Knoten mithilfe von ARM-Vorlagen bereitzustellen.

  Weitere Informationen finden Sie unter Bereitstellen über die Azure Resource Manager-Bereitstellungsvorlage.

Verwaltungs-VLAN

Alle physischen Computehosts müssen auf das logische Verwaltungsnetzwerk zugreifen. Für IP-Adressplanungszwecke muss jeder Host mindestens eine IP-Adresse aus dem logischen Verwaltungsnetzwerk zugewiesen haben.

Ein DHCP-Server kann automatisch IP-Adressen für das Verwaltungsnetzwerk zuweisen, oder Sie können statische IP-Adressen manuell zuweisen. Wenn DHCP die bevorzugte IP-Zuweisungsmethode ist, werden DHCP-Reservierungen ohne Ablauf empfohlen.

Weitere Informationen finden Sie in den Überlegungen zum DHCP-Netzwerk für die Cloudbereitstellung.

Das Verwaltungsnetzwerk unterstützt zwei verschiedene VLAN-Konfigurationen für Datenverkehr – systemeigene und getaggt. Die folgenden Überlegungen gelten für jede Konfiguration:

• Natives VLAN für Verwaltungsnetzwerk erfordert nicht, dass Sie eine VLAN-ID angeben.

• Tagged VLAN for management network erfordert DIE VLAN-ID-Konfiguration auf den physischen Netzwerkadaptern oder dem virtuellen Verwaltungsnetzwerkadapter, bevor die Knoten in Azure Arc registriert werden.

• Physische Switchports müssen ordnungsgemäß konfiguriert werden, um die VLAN-ID auf den Verwaltungsadaptern zu akzeptieren.

• Wenn die Absicht Verwaltungs- und Computedatenverkehrtypen umfasst, müssen die physischen Switchports im Trunkmodus konfiguriert werden, um alle FÜR die Verwaltung und Berechnung von Workloads erforderlichen VLANs zu akzeptieren.

Das Verwaltungsnetzwerk unterstützt datenverkehr, der vom Administrator für die Verwaltung des Systems verwendet wird, einschließlich Remotedesktop, Windows Admin Center und Active Directory.

Weitere Informationen finden Sie unter Überlegungen zum Verwaltungs-VLAN-Netzwerk.

Berechnen von VLANs

In einigen Szenarien müssen Sie keine virtuellen SDN-Netzwerke mit VXLAN-Kapselung verwenden. Stattdessen können Sie herkömmliche VLANs verwenden, um ihre Mandantenarbeitslasten zu isolieren. Diese VLANs müssen auf dem TOR-Switchesport im Trunkmodus konfiguriert werden. Beim Verbinden neuer virtueller Computer mit diesen VLANs wird das entsprechende VLAN-Tag auf dem virtuellen Netzwerkadapter definiert.

HNV Provider Address (PA)-Netzwerk

Das Netzwerk des Hyper-V-Netzwerkvirtualisierungsanbieters (HNV PA) dient als zugrunde liegendes physisches Netzwerk für ost-west(intern) Mandantendatenverkehr, Nord-Süd-Mandantendatenverkehr (extern-intern) und zum Austauschen von BGP-Peeringinformationen mit dem physischen Netzwerk. Dieses Netzwerk ist nur erforderlich, wenn virtuelle Netzwerke mithilfe der VXLAN-Kapselung für eine zusätzliche Isolations- und Netzwerkmehrheitsebene bereitgestellt werden müssen.

Weitere Informationen finden Sie unter Plan a Software Defined Network infrastructure.

AtC-Netzwerkabsichten

Für Wechsellose Muster mit drei Knoten werden zwei Netzwerk-ATC-Absichten erstellt. Der erste Zweck besteht darin, Netzwerkdatenverkehr zu verwalten und zu berechnen, und der zweite Zweck ist der Speicherdatenverkehr.

Verwaltungs- und Computeabsicht

• Intent-Typ: Verwaltung und Compute
• In Zelt-Modus: Clustermodus
• Teaming: Ja. pNIC01- und pNIC02-Team
• Standardverwaltungs-VLAN: Konfiguriertes VLAN für Verwaltungsadapter wird nicht geändert.
• PA und Berechnen von VLANs und vNICs: Network ATC ist transparent für PA vNICs und VLAN oder compute VM vNICs und VLANs.

Speicherabsicht

• Intent-Typ: Speicher

• In Zelt-Modus: Clustermodus

• Teaming: Nein. RDMA-NICs verwenden SMB Multichannel, um Resilienz und Bandbreitenaggregation bereitzustellen.

• Standard-VLANs: einzelnes VLAN für alle Subnetze

• Automatische Speicher-IP: False. Für dieses Muster ist eine manuelle IP-Konfiguration oder ARM-Vorlagen-IP-Definition erforderlich.

• Drei Subnetze erforderlich (benutzerdefiniert):

  • Speichernetzwerk 1: 10.0.1.0/24 – Node1 -> Node2
  • Speichernetzwerk 2: 10.0.2.0/24 – Node1 -> Node2
  • Speichernetzwerk 3: 10.0.3.0/24 – Node2 -> Node3

Weitere Informationen finden Sie unter Bereitstellen von Hostnetzwerken mit Network ATC.

Beispiel für die Konfiguration der ARM-Vorlage "Speicherabsichtsnetzwerk"

Sie können die ARM-Vorlage für wechsellose 3-Knoten-Speicherschalter, duale TOR und single link verwenden.

Hier ist ein Codeausschnitt aus der Vorlage:

"storageNetworkList": {
        "value": [
            {
                "name": "StorageNetwork1",
                "networkAdapterName": "SMB1",
                "vlanId": "711",
                "storageAdapterIPInfo": [
                    {
                        "physicalNode": "Node1",
                        "ipv4Address": "10.0.1.1",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node2",
                        "ipv4Address": "10.0.1.2",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node3",
                        "ipv4Address": "10.0.2.1",
                        "subnetMask": "255.255.255.0"
                    }
                ]
            },
            {
                "name": "StorageNetwork2",
                "networkAdapterName": "SMB2",
                "vlanId": "711",
                "storageAdapterIPInfo": [
                    {
                        "physicalNode": "Node1",
                        "ipv4Address": "10.0.2.2",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node2",
                        "ipv4Address": "10.0.3.1",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node3",
                        "ipv4Address": "10.0.3.2",
                        "subnetMask": "255.255.255.0"
                    }
                ]
            }
        ]
      },