Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: Azure Local 2411.1 und höher
In diesem Artikel wird beschrieben, wie Sie ein Netzwerkreferenzmuster mit vier Knoten mit zwei TOR L3-Switches und zwei Full-Mesh-Verbindungen verwenden können, um Ihre Azure Local-Lösung bereitzustellen.
Anmerkung
Microsoft hat die in diesem Artikel beschriebenen Switchless Networking-Referenzmuster mit vier Knoten getestet und validiert.
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.
Anmerkung
Denken Sie daran, dass Skalierungsvorgänge für lokale Azure-Bereitstellungen mit switchlosem Speicher nicht unterstützt werden. Um einen zusätzlichen Knoten hinzuzufügen, stellen Sie den Cluster erneut bereit, da Sie die physische Speicherkonnektivität und die Speichernetzwerke neu konfigurieren müssen.
SDN L3-Dienste sind 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 QoS erfordern keine zusätzliche Konfiguration des Firewallgeräts, da sie auf virtueller Netzwerkadapterebene implementiert werden.
Physische Verbindungskomponenten
Wie im folgenden Diagramm mit vier Knoten dargestellt, weist dieses Muster die folgenden physischen Netzwerkkomponenten auf:
Für die Nord-/Süd-Kommunikation benötigt die Azure Local-Instanz zwei TOR-Switches in der MLAG-Konfiguration (Multi-Chassis Link Aggregation Group).
Zwei Netzwerkkarten, die mit den TOR-Switches verbunden sind und einen virtuellen SET-Switch verwenden, um den Datenverkehr zu verwalten und zu berechnen. Jeder Netzwerkschnittstellenport ist mit einem anderen Inhaltstyp verbunden.
Sechs RDMA-NICs auf jedem Knoten in einer vollständigen Mesh-Dual-Link-Konfiguration für den Ost-West-Datenverkehr des Speichers. Jeder Knoten im System verfügt über eine redundante Verbindung mit zwei Pfaden zum anderen Knoten im System.
| Netzwerke | Verwaltung und Berechnung | Lagerung |
|---|---|---|
| Verbindungsgeschwindigkeit | Mindestens 1 GBps. 10 GBps empfohlen | Mindestens 10 GBps |
| Schnittstellentyp | RJ45, SFP+ oder SFP28 | SFP+ oder SFP28 |
| Ports und Aggregation | Zwei gekoppelte Ports | Vier eigenständige Ports |
Logische Netzwerke
VLAN der Node-Interconnect-Netzwerke für SMB-Datenverkehr (Speicher und Livemigration)
Der auf Intent-basierter Architektur beruhende Storage-Datenverkehr besteht aus zwölf einzelnen Subnetzen, die den RDMA-Datenverkehr unterstützen. Jede Schnittstelle ist einem separaten Knotenverbindungsnetzwerk zugeordnet. Dieser Netzwerkverkehr soll nur zwischen den vier Knoten fließen. Der Speicherdatenverkehr auf diesen Subnetzen wird isoliert und hat keine Verbindung zu anderen Ressourcen.
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 vier Knoten in einer switchlosen Konfiguration hat Network ATC die folgenden Anforderungen:
Unterstützt nur ein einzelnes VLAN für alle IP-Subnetze, die für die Speicherkonnektivität verwendet werden.
Der
StorageAutoIP-Parameter muss auf Falsch festgelegt werden, derSwitchless-Parameter muss auf Wahr festgelegt werden, und Sie müssen die IPs auf der Azure Resource Manager (ARM)-Vorlage angeben, die für die Bereitstellung der Azure Local-Instanz von Azure verwendet wird.Für Azure Local:
Aufskalierende Speichersysteme ohne Switch werden nicht unterstützt.
Es ist nur möglich, dieses Szenario mit vier Knoten mithilfe von ARM-Vorlagen bereitzustellen.
Weitere Informationen finden Sie unter Bereitstellung mittels Azure Resource Manager Vorlage.
Verwaltungs-VLAN
Alle physischen Computehosts müssen auf das logische Verwaltungsnetzwerk zugreifen. Bei der Planung von IP-Adressen muss jedem Host mindestens eine IP-Adresse aus dem logischen Verwaltungsnetzwerk zugewiesen werden.
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 Ablaufdatum empfohlen.
Weitere Informationen finden Sie unter DHCP Netzwerküberlegungen für die Bereitstellung in der Cloud.
Das Management-Netzwerk unterstützt zwei verschiedene VLAN-Konfigurationen für den Datenverkehr – Nativ und Tagged:
Natives VLAN für Verwaltungsnetzwerk erfordert nicht, dass Sie eine VLAN-ID angeben.
Das VLAN mit Tags für das Verwaltungsnetzwerk erfordert eine VLAN-ID-Konfiguration auf den physischen Netzwerkadaptern oder dem virtuellen Netzwerkadapter für die Verwaltung, 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 Management-VLAN-Networking.
VLANs berechnen
In einigen Szenarien müssen Sie keine virtuellen SDN-Netzwerke mit VXLAN-Kapselung verwenden. Stattdessen können Sie herkömmliche VLANs verwenden, um ihre Mandantenworkloads zu isolieren. Diese VLANs müssen auf dem Port der TOR-Switches im Trunkmodus konfiguriert werden. Beim Verbinden neuer virtueller Computer mit diesen VLANs wird das entsprechende VLAN-Tag auf dem virtuellen Netzwerkadapter definiert.
HNV PA-Netzwerk
Das HNV PA-Netzwerk (Hyper-V Network Virtualization Provider Address) dient als zugrunde liegendes physisches Netzwerk für den Ost-West-Mandantendatenverkehr (intern–intern), den Nord-Süd-Mandantendatenverkehr (extern–intern) und für den Austausch von BGP-Peeringinformationen mit dem physischen Netzwerk. Dieses Netzwerk ist nur dann erforderlich, wenn virtuelle Netzwerke mit VXLAN-Kapselung bereitgestellt werden müssen, um eine zusätzliche Schicht der Isolierung und Netzwerk-Multitenancy zu schaffen.
Weitere Informationen finden Sie unter Planen einer Software-definierten Networking-Infrastruktur.
Network ATC-Absichten
Für vierknotige Speichermuster ohne Switch werden zwei Network ATC-Absichten erstellt. Der erste Zweck besteht darin, Netzwerkdatenverkehr zu verwalten und zu berechnen, und der zweite Zweck ist der Speicherdatenverkehr.
Verwaltungs- und Berechnungsabsicht
- Absichtstyp: Verwaltung und Compute
- Absichtsmodus: Clustermodus
- Teamarbeit: Ja. pNIC01- und pNIC02-Team.
- Standardverwaltungs-VLAN: Konfiguriertes VLAN für Verwaltungsadapter wird nicht geändert.
- PA- und Compute-VLANs und vNICs: Network ATC ist transparent für PA-vNICs und -VLANs oder Compute-VM-vNICs und -VLANs.
Speicherabsicht
Intent-Typ: Speicher
Absichtsmodus: Clustermodus
Teambildung: Nein. RDMA-NICs verwenden SMB Multichannel, um Resilienz und Bandbreitenaggregation bereitzustellen.
Standard-VLANs: einzelnes VLAN für alle Subnetze.
Storage Auto-IP: FALSE. Für dieses Muster ist entweder eine manuelle IP-Konfiguration oder die IP-Definition in einer ARM-Vorlage erforderlich.
Zwölf 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 –
Node1 -> Node3 - Speichernetzwerk 4: 10.0.4.0/24 –
Node1 -> Node3 - Speichernetzwerk 5: 10.0.5.0/24 –
Node1 -> Node4 - Speichernetzwerk 6: 10.0.6.0/24 –
Node1 -> Node4 - Speichernetzwerk 7: 10.0.7.0/24 –
Node2 -> Node3 - Speichernetzwerk 8: 10.0.8.0/24 –
Node2 -> Node3 - Speichernetzwerk 9: 10.0.9.0/24 –
Node2 -> Node4 - Speichernetzwerk 10: 10.0.10.0/24 –
Node2 -> Node4 - Speichernetzwerk 11: 10.0.11.0/24 –
Node3 -> Node4 - Speichernetzwerk 12: 10.0.12.0/24 –
Node3 -> Node4
- 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 vierknotigen Speicher ohne Switch, mit dualem TOR und Dual Link verwenden.
"storageNetworkList": {
"value": [
{
"name": "StorageNetwork1",
"networkAdapterName": "SMB1",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.1.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.1.3",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.3.3",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node4",
"ipv4Address": "10.0.5.3",
"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.2.3",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.4.3",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node4",
"ipv4Address": "10.0.6.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork3",
"networkAdapterName": "SMB3",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.3.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.7.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.7.3",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node4",
"ipv4Address": "10.0.9.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.8.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.8.3",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node4",
"ipv4Address": "10.0.10.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork5",
"networkAdapterName": "SMB5",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.5.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.9.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.11.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node4",
"ipv4Address": "10.0.11.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork6",
"networkAdapterName": "SMB6",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.6.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.10.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.12.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node4",
"ipv4Address": "10.0.12.3",
"subnetMask": "255.255.255.0"
}
]
}
]
},