Überprüfen sie das Referenzmuster für die Netzwerkreferenz für die Bereitstellung mit drei Knoten, dualem TOR für Azure Local
> Gilt für: Azure Local, Version 23H2 und höher
In diesem Artikel erfahren Sie mehr über den Drei-Knoten-Speicherwechsel ohne zwei TOR L3-Switches und zwei Netzwerkverknüpfungsmuster mit Vollgitternetzverknüpfung, die Sie zum Bereitstellen Ihrer lokalen Azure-Lösung verwenden können.
Hinweis
Die in diesem Artikel beschriebenen 3-Knoten-Netzwerkreferenzmuster wurden von Microsoft getestet und überprüft. Informationen zu wechsellosen Netzwerkmustern mit zwei Knoten finden Sie unter Azure Local network deployment patterns.
Szenarien
Szenarien für dieses Netzwerkmuster umfassen Labore, Fabriken, Zweigstellen und Rechenzentren.
Erwägen Sie die Implementierung dieses Musters, wenn Sie nach einer kosteneffizienten Lösung suchen, die über Fehlertoleranz für alle Netzwerkkomponenten verfügt. SDN L3-Dienste werden für dieses 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 QoS erfordern keine zusätzliche Konfiguration des Firewallgeräts, da sie auf virtueller Netzwerkadapterebene implementiert werden.
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.
Vier RDMA-NICs auf jedem Knoten in einer Vollgitter-Dual-Link-Konfiguration für Ost-West-Datenverkehr für den Speicher. Jeder Knoten im System verfügt über eine redundante Verbindung mit zwei Pfaden zum anderen Knoten im System.
| Netzwerke | Verwaltung und Berechnung | Storage |
|---|---|---|
| Verbindungsgeschwindigkeit | Mindestens 1 GBIT/s. Empfohlene 10 GBps | Mindestens 10 GBIT/s |
| Schnittstellentyp | RJ45, SFP+ oder SFP28 | SFP+ oder SFP28 |
| Ports und Aggregation | Zwei teamierte Ports | Vier eigenständige Ports |
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 sechs 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 von drei Knoten in einer switchlosen Konfiguration 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.
StorageAutoIPDer Parameter muss auf "false" festgelegt sein,Switchlessder 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 markierte:
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 enthält, 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.
Sechs 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 - Speichernetzwerk 4: 10.0.4.0/24 –
Node1 -> Node3 - Speichernetzwerk 5: 10.0.5.0/24 –
Node1 -> Node3 - Speichernetzwerk 6: 10.0.6.0/24 –
Node2 -> Node3
- Speichernetzwerk 1: 10.0.1.0/24 –
Weitere Informationen finden Sie unter Bereitstellen von Hostnetzwerken mit Network ATC.
Konfigurationsbeispiel für ARM-Vorlagen für Speicherabsichtnetzwerke
Sie können die ARM-Vorlage für 3-Knoten-Speicherschalter, dualen TOR und dualen Link verwenden.
"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.5.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork2",
"networkAdapterName": "SMB2",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.2.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.2.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.4.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork3",
"networkAdapterName": "SMB3",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.5.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.3.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.3.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork4",
"networkAdapterName": "SMB4",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.4.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.6.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.6.3",
"subnetMask": "255.255.255.0"
}
]
}
]
},