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 2311.2 und höher
In diesem Artikel erfahren Sie mehr über die speicherlose Drei-Knoten-Konfiguration mit zwei TOR L3-Switches und einem Netzwerkreferenzmuster mit zwei Vollmesh-Verbindungen, das Sie zur Bereitstellung Ihrer lokalen Azure-Lösung verwenden können.
Hinweis
Die in diesem Artikel beschriebenen 3-Knoten-schalterlosen 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.
Hinweis
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.
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 zur Abwicklung von Verwaltungs- und Rechenverkehr, 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 | Speicher |
---|---|---|
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:
VLAN der Node-Interconnect-Netzwerke für SMB-Datenverkehr (Speicher und Livemigration)
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 fließen. 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.
Legen Sie den
StorageAutoIP
-Parameter auf "false" und denSwitchless
-Parameter auf "true" fest. Geben Sie die IPs für die ARM-Vorlage an, die zum Bereitstellen der lokalen Azure-Instanz aus Azure verwendet wird.Für Lokale Azure-Cloudbereitstellungen:
Switchlose Scale-Out-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 Bereitstellung mit der Azure Resource Manager Bereitstellungsvorlage.
Verwaltungs-VLAN
Alle physischen Computehosts müssen auf das logische Verwaltungsnetzwerk zugreifen. Für die IP-Adressplanung muss jeder Host mindestens eine IP-Adresse aus dem logischen Verwaltungsnetzwerk erhalten.
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.
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 der Zweck Verwaltungs- und Computerdatenverkehrstypen umfasst, müssen die physischen Switch-Ports im Trunkmodus konfiguriert werden, um alle erforderlichen VLANs für Verwaltung und Rechen-Workloads 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 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 Provider Address (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 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.
Network ATC-Absicht
Für 3-Knoten-Speichermuster ohne Switch 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 Berechnungsabsicht
- Intent-Typ: Management und Berechnung
- Absichtsmodus: Clustermodus
- Teaming: 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
Teaming: 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 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-Speicher ohne Switch, mit dualem TOR und dualem 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"
}
]
}
]
},