Überlegungen zum Netzwerk für Cloudbereitstellungen von Azure Local, Version 23H2

Gilt für: Azure Local 2311.2 und höher

In diesem Artikel wird erläutert, wie ein Azure Local-Systemnetzwerk der Version 23H2 für die Cloud-Bereitstellung entworfen und geplant wird. Bevor Sie fortfahren, sollten Sie sich mit den verschiedenen lokalen Azure Local-Netzwerkmustern und verfügbaren Konfigurationen vertraut machen.

Netzwerkdesign-Rahmen

Das folgende Diagramm zeigt die verschiedenen Entscheidungen und Schritte, die den Netzwerk-Design-Rahmen für Ihre Azure Local-Instanz definieren – Clustergröße, Cluster-Speicherkonnektivität, Netzwerkdatenverkehrsabsichten, Verwaltungskonnektivität und Netzwerkadapterkonfiguration. Jede Designentscheidung ermöglicht oder erlaubt die in den nachfolgenden Schritten verfügbaren Designoptionen:

Schritt 1: Bestimmung der Clustergröße

Verwenden Sie das Azure Local Sizer Tool, um die Größe Ihrer Azure Local-Instanz zu bestimmen. Hier können Sie Ihr Profil definieren, z. B. die Anzahl der virtuellen Maschinen (VMs), die Größe der VMs und die Workload-Auslastung der VMs durch Anwendungen wie Azure Virtual Desktop, SQL Server oder AKS.

Wie im Artikel Azure Local Systemmaschinenanforderungen beschrieben, beträgt die maximale Anzahl der von einer Azure Local-Instanz unterstützten Maschinen 16. Sobald Sie Ihre Workload-Kapazitätsplanung abgeschlossen haben, sollten Sie ein gutes Verständnis für die Anzahl der Maschinenknoten haben, die für die Ausführung von Workloads in Ihrer Infrastruktur erforderlich sind.

• Wenn Ihre Workloads vier oder mehr Knoten erfordern: Sie können keine Konfiguration ohne Switch für den Speichernetzwerkverkehr bereitstellen und verwenden. Sie müssen einen physischen Switch mit Unterstützung für Remote Direct Memory Access (RDMA) einbinden, um den Speicherverkehr zu bewältigen. Weitere Informationen zur Netzwerkarchitektur der lokalen Azure-Instanz finden Sie unter Übersicht über Netzwerkreferenzmuster.

• Wenn Ihre Workloads drei oder weniger Knoten erfordern: Sie können Konfigurationen für die Speicherkonnektivität mit oder ohne Switches auswählen.

• Wenn Sie beabsichtigen, später auf mehr als drei Knoten horizontal zu skalieren: Sie müssen einen physischen Switch für den Speichernetzwerkdatenverkehr verwenden. Jeder horizontale Skalierungsvorgang für Bereitstellungen ohne Switch erfordert eine manuelle Konfiguration der Netzwerkverkabelung zwischen den Knoten, die Microsoft nicht aktiv als Teil seines Softwareentwicklungszyklus für Azure Local überprüft.

Hier sind die zusammengefassten Überlegungen für die Entscheidung über die Clustergröße:

Entscheidung	Aspekt
Clustergröße (Anzahl der Knoten pro Cluster)	Die Konfiguration ohne Switches über das Azure-Portal oder Azure Resource Manager-Vorlagen ist nur für Cluster mit 1, 2 oder 3 Knoten verfügbar. Cluster mit 4 oder mehr Knoten erfordern einen physischen Switch für den Speichernetzwerkverkehr.
Anforderungen für eine horizontale Skalierung	Wenn Sie beabsichtigen, Ihren Cluster mithilfe des Orchestrators horizontal zu skalieren, müssen Sie einen physischen Switch für den Speichernetzwerkverkehr verwenden.

Schritt 2: Bestimmung der Clusterspeicherkonnektivität

Wie in Physische Netzwerkanforderungen beschrieben, unterstützt Azure Local zwei Arten von Konnektivität für den Speichernetzwerkverkehr:

• Verwendung eines physischen Netzwerkswitches zur Verarbeitung des Datenverkehrs.
• Verbinden Sie die Knoten direkt untereinander mit Crossover-Netzwerk- oder Glasfaserkabeln für den Speicherverkehr.

Die Vor- und Nachteile der einzelnen Optionen sind in dem oben verlinkten Artikel dokumentiert.

Wie bereits erwähnt, können Sie sich nur zwischen den beiden Optionen entscheiden, wenn die Größe Ihres Clusters drei oder weniger Knoten beträgt. Jeder Cluster mit vier oder mehr Knoten wird automatisch mithilfe eines Netzwerkswitches für den Speicher bereitgestellt.

Wenn Cluster weniger als drei Knoten haben, beeinflusst die Entscheidung über die Speicherkonnektivität die Anzahl und Art der Netzwerkabsichten, die Sie im nächsten Schritt definieren können.

Bei Konfigurationen ohne Switch müssen Sie beispielsweise zwei Netzwerkverkehrsabsichten definieren. Der Speicherverkehr für die Ost-West-Kommunikation über die Crossover-Kabel verfügt nicht über eine Nord-Süd-Konnektivität und ist vollständig von der restlichen Netzwerkinfrastruktur isoliert. Das bedeutet, dass Sie eine zweite Netzwerkabsicht für die ausgehende Konnektivität der Verwaltung und für Ihre Compute-Workloads definieren müssen.

Obwohl es möglich ist, jede Netzwerkabsicht mit nur einem physischen Netzwerkadapterport zu definieren, bietet dies keine Fehlertoleranz. Daher wird immer empfohlen, mindestens zwei physische Netzwerkports für jede Netzwerkabsicht zu verwenden. Wenn Sie sich für die Verwendung eines Netzwerk-Switches zur Speicherung entscheiden, können Sie den gesamten Netzwerkverkehr einschließlich der Speicherung in einem einzigen Netzwerk zusammenfassen, was auch als hyperkonvergente oder vollständig konvergente Host-Netzwerkkonfiguration bezeichnet wird.

Hier sind die zusammengefassten Überlegungen für die Entscheidung über die Konnektivität des Cluster-Speichers:

Entscheidung	Aspekt
Kein Switch für Speicher	Die Konfiguration ohne Switches über das Azure-Portal oder die Bereitstellung von Resource Manager-Vorlagen wird nur für Cluster mit 1, 2 oder 3 Knoten unterstützt. Cluster mit 1 oder 2 Knoten ohne Speicher-Switch können mithilfe des Azure-Portals oder der Vorlagen des Resource Managers bereitgestellt werden. Cluster mit 3 Knoten und ohne Speicher-Switch können nur mithilfe von Resource Manager-Vorlagen bereitgestellt werden. Die horizontale Skalierung wird mit den switchlosen Bereitstellungen nicht unterstützt. Jede Änderung der Anzahl der Knoten nach der Bereitstellung erfordert eine manuelle Konfiguration. Bei Verwendung der Konfiguration ohne Speicher-Switch sind mindestens 2 Netzwerkabsichten erforderlich.
Netzwerkswitch für Speicher	Wenn Sie beabsichtigen, Ihren Cluster mithilfe des Orchestrators horizontal zu skalieren, müssen Sie einen physischen Switch für den Speichernetzwerkverkehr verwenden. Sie können diese Architektur mit einer beliebigen Zahl von Knoten zwischen 1 und 16 verwenden. Obwohl dies nicht durchgesetzt wird, können Sie eine einzige Absicht für alle Arten von Netzwerkverkehr (Verwaltung, Compute und Storage) verwenden.

Das folgende Diagramm fasst die Optionen für die Speicherkonnektivität zusammen, die Ihnen für verschiedene Bereitstellungen zur Verfügung stehen:

Schritt 3: Bestimmung von Netzwerkdatenverkehrsabsichten

Für Azure Local basieren alle Bereitstellungen auf Network ATC für die Hostnetzwerkkonfiguration. Die Netzwerkabsichten werden automatisch konfiguriert, wenn Azure Local über das Azure-Portal bereitgestellt wird. Weitere Informationen zu den Netzwerkabsichten und zur Problembehandlung finden Sie unter Allgemeine ATC-Netzwerkbefehle.

In diesem Abschnitt werden die Auswirkungen Ihrer Entwurfsentscheidung für die Absichten des Netzwerkdatenverkehrs und deren Einfluss auf den nächsten Schritt des Rahmens erläutert. Bei Cloud-Bereitstellungen können Sie zwischen vier Optionen wählen, um Ihren Netzwerkverkehr in einem oder mehreren Absichten zu gruppieren. Die verfügbaren Optionen hängen von der Anzahl der Knoten in Ihrem Cluster und dem verwendeten Speicherkonnektivitätstyp ab.

Die verfügbaren Netzwerkabsichtsoptionen werden in den folgenden Abschnitten erläutert.

Netzwerkabsicht: Gruppieren des gesamten Datenverkehrs

Network ATC konfiguriert eine eindeutige Absicht, die den Netzwerkverkehr von Verwaltung, Compute und Speicher umfasst. Die Netzwerkadapter, die dieser Absicht zugewiesen sind, teilen sich die Bandbreite und den Durchsatz für den gesamten Netzwerkverkehr.

• Diese Option erfordert einen physischen Switch für den Speicherverkehr. Wenn Sie eine Architektur ohne Switches benötigen, können Sie diese Art von Absicht nicht verwenden. Das Azure-Portal filtert diese Option automatisch heraus, wenn Sie eine Konfiguration ohne Switch für die Speicherkonnektivität auswählen.

• Es werden mindestens zwei Netzwerkadapter-Ports empfohlen, um eine hohe Verfügbarkeit zu gewährleisten.

• Mindestens 10-Gbit/s-Netzwerkschnittstellen sind erforderlich, um den RDMA-Verkehr für die Speicherung zu unterstützen.

Netzwerkabsicht: Gruppenverwaltung und Compute-Verkehr

Network ATC konfiguriert zwei Absichten. Die erste Absicht umfasst die Verwaltung und den Compute-Netzwerkverkehr, und die zweite Absicht umfasst nur den Speichernetzwerkverkehr. Jede Absicht muss über einen anderen Satz von Netzwerkadapter-Ports verfügen.

Sie können diese Option sowohl für Speicherkonnektivität mit als auch ohne Switch verwenden, wenn:

• Mindestens zwei Netzwerkadapter-Ports pro Absicht vorhanden sind, um eine hohe Verfügbarkeit zu gewährleisten.

• Für RDMA ein physischer Switch verwendet wird, wenn Sie den Netzwerk-Switch für die Speicherung verwenden.

• Mindestens 10-Gbit/s-Netzwerkschnittstellen sind erforderlich, um den RDMA-Verkehr für die Speicherung zu unterstützen.

Netzwerkabsicht: Compute- und Speicherverkehr der Gruppe

Network ATC konfiguriert zwei Absichten. Die erste Absicht umfasst den Compute- und Speichernetzwerkverkehr, und die zweite Absicht umfasst nur den Verwaltungsnetzwerkverkehr. Jede Absicht muss einen anderen Satz von Netzwerkadapter-Ports verwenden.

• Diese Option erfordert einen physischen Switch für den Speicherverkehr, da dieselben Ports mit dem Compute-Verkehr geteilt werden, der eine Nord-Süd-Kommunikation erfordert. Wenn Sie eine Konfiguration ohne Switches benötigen, können Sie diese Art von Absicht nicht verwenden. Das Azure-Portal filtert diese Option automatisch heraus, wenn Sie eine Konfiguration ohne Switch für die Speicherkonnektivität auswählen.

• Für diese Option ist ein physischer Switch für RDMA erforderlich.

• Es werden mindestens zwei Netzwerkadapter-Ports empfohlen, um eine hohe Verfügbarkeit zu gewährleisten.

• Für Compute- und Speicherzwecke werden Netzwerkschnittstellen mit mindestens 10 Gbps empfohlen, um den RDMA-Verkehr zu unterstützen.

• Selbst wenn die Verwaltungsabsicht ohne Compute-Absicht deklariert wird, erstellt Network ATC einen virtuellen Switch für Switch Embedded Teaming (SET), um eine hohe Verfügbarkeit für das Verwaltungsnetzwerk zu gewährleisten.

Netzwerkabsicht: Benutzerdefinierte Konfiguration

Sie können bis zu drei Absichten mit Ihrer eigenen Konfiguration definieren, solange mindestens eine der Absichten Verwaltungsdatenverkehr umfasst. Wir empfehlen Ihnen, diese Option zu verwenden, wenn Sie eine zweite Compute-Absicht benötigen. Zu den Szenarien für diese zweite Anforderung an die Compute-Absicht gehören Remote-Speicherverkehr, VMs-Sicherungsverkehr oder eine separate Compute-Absicht für unterschiedliche Arten von Workloads.

• Verwenden Sie diese Option sowohl für die Speicherkonnektivität mit und ohne Switch, wenn die Speicherabsicht sich von den anderen Absichten unterscheidet.

• Verwenden Sie diese Option, wenn eine andere Compute-Absicht erforderlich ist oder wenn Sie die verschiedenen Arten von Datenverkehr über verschiedene Netzwerkadapter vollständig trennen möchten.

• Verwenden Sie mindestens zwei Netzwerkadapter-Ports für jede Absicht, um eine hohe Verfügbarkeit zu gewährleisten.

• Für Compute- und Speicherzwecke werden Netzwerkschnittstellen mit mindestens 10 Gbps empfohlen, um den RDMA-Verkehr zu unterstützen.

Das folgende Diagramm fasst die Optionen für Netzwerkabsichten zusammen, die Ihnen für verschiedene Bereitstellungen zur Verfügung stehen:

Schritt 4: Bestimmung der Verwaltungs- und Speichernetzwerkkonnektivität

In diesem Schritt definieren Sie den Adressraum des Infrastruktur-Subnetzes, wie diese Adressen Ihrem Cluster zugewiesen werden und ob für die Knoten eine Proxy- oder VLAN-ID-Anforderung für die ausgehende Verbindung mit dem Internet und anderen Intranetdiensten wie dem Domain Name System (DNS) oder Active Directory Services besteht.

Die folgenden Komponenten des Infrastruktur-Subnetzes müssen vor Beginn der Bereitstellung geplant und definiert werden, damit Sie alle Anforderungen an Routing, Firewall oder Subnetz berücksichtigen können.

Netzwerkadaptertreiber

Nach der Installation des Betriebssystems und vor der Konfiguration des Netzwerks auf Ihren Knoten müssen Sie sicherstellen, dass Ihre Netzwerkadapter über den neuesten Treiber verfügen, der von Ihrem OEM oder Netzwerkschnittstellenanbieter bereitgestellt wird. Wichtige Funktionen der Netzwerkadapter werden möglicherweise nicht angezeigt, wenn die Standard-Microsoft-Treiber verwendet werden.

Verwaltungs-IP-Pool

Bei der ersten Bereitstellung Ihrer Azure Local-Instanz müssen Sie einen IP-Bereich aufeinanderfolgender IP-Adressen für standardmäßig bereitgestellte Infrastrukturdienste definieren.

Um sicherzustellen, dass der Bereich über genügend IPs für aktuelle und zukünftige Infrastrukturdienste verfügt, müssen Sie einen Bereich von mindestens sechs aufeinanderfolgenden verfügbaren IP-Adressen verwenden. Diese Adressen werden für die Cluster-IP, die Azure Resource Bridge VM und ihre Komponenten verwendet.

Wenn Sie vorhaben, andere Dienste im Infrastrukturnetzwerk auszuführen, empfehlen wir, dem Pool einen zusätzlichen Puffer an Infrastruktur-IPs zuzuweisen. Es ist möglich, nach der Bereitstellung des Infrastrukturnetzwerks mithilfe von PowerShell weitere IP-Pools hinzuzufügen, falls die Größe des ursprünglich geplanten Pools erschöpft ist.

Bei der Definition Ihres IP-Pools für das Infrastruktur-Subnetz während der Bereitstellung müssen die folgenden Bedingungen erfüllt sein:

#	Bedingung
1	Der IP-Bereich muss aufeinander folgende IPs verwenden, und alle IPs müssen innerhalb dieses Bereichs verfügbar sein. Dieser IP-Bereich kann nach der Bereitstellung nicht geändert werden.
2	Der IP-Adressbereich darf nicht die Cluster-Knoten-Verwaltungs-IPs enthalten, muss sich aber im selben Subnetz wie Ihre Knoten befinden.
3	Das für den Verwaltungs-IP-Pool definierte Standard-Gateway muss eine ausgehende Verbindung zum Internet bereitstellen.
4	Die DNS-Server müssen die Namensauflösung mit Active Directory und dem Internet sicherstellen.
5	Die Verwaltungs-IPs erfordern einen ausgehenden Internetzugang.

Verwaltungs-VLAN-ID

Wir empfehlen, dass das Verwaltungs-Subnetz Ihrer Azure Local-Instanz das Standard-VLAN verwendet, das in den meisten Fällen als VLAN-ID 0 deklariert ist. Wenn Ihre Netzwerkanforderungen jedoch die Verwendung eines bestimmten Verwaltungs-VLANs für Ihr Infrastrukturnetzwerk vorsehen, muss dieses auf Ihren physischen Netzwerkadaptern konfiguriert werden, die Sie für den Verwaltungsdatenverkehr verwenden möchten.

Wenn Sie zwei physische Netzwerkadapter für die Verwaltung verwenden möchten, müssen Sie das VLAN auf beiden Adaptern einrichten. Dies muss im Rahmen der Bootstrap-Konfiguration Ihrer Maschinen erfolgen, und zwar bevor sie bei Azure Arc registriert werden, um sicherzustellen, dass Sie die Knoten mithilfe dieses VLAN erfolgreich registrieren können.

Verwenden Sie den folgenden PowerShell-Befehl, um die VLAN-ID für die physischen Netzwerkadapter festzulegen:

In diesem Beispiel wird die VLAN-ID 44 auf dem physischen Netzwerkadapter NIC1 konfiguriert.

Set-NetAdapter -Name "NIC1" -VlanID 44

Sobald die VLAN-ID festgelegt und die IPs Ihrer Knoten auf den physischen Netzwerkadaptern konfiguriert sind, liest der Orchestrator diesen VLAN-ID-Wert vom physischen Netzwerkadapter, der für die Verwaltung verwendet wird, und speichert ihn, sodass er für die Azure Ressourcenbrücken-VM oder jede andere Infrastruktur-VM verwendet werden kann, die während der Bereitstellung benötigt wird. Es ist nicht möglich, die VLAN-ID für die Verwaltung während der Cloud-Bereitstellung über das Azure-Portal festzulegen, da dies das Risiko birgt, dass die Verbindung zwischen den Knoten und Azure unterbrochen wird, wenn die physischen Switch-VLANs nicht ordnungsgemäß geroutet werden.

Verwalten von VLAN-ID mit einem virtuellen Switch

In einigen Szenarien ist es erforderlich, einen virtuellen Switch zu erstellen, bevor die Bereitstellung beginnt.

Hinweis

Bevor Sie einen virtuellen Switch erstellen, müssen Sie unbedingt die Hype-V-Rolle aktivieren. Weitere Informationen finden Sie unter Installieren der erforderlichen Windows-Rolle.

Wenn eine virtuelle Switch-Konfiguration erforderlich ist und Sie eine bestimmte VLAN-ID verwenden müssen, gehen Sie wie folgt vor:

1. Erstellen Sie einen virtuellen Switch mit der empfohlenen Namenskonvention

Azure Local-Bereitstellungen sind auf Network ATC angewiesen, um die virtuellen Switches und virtuellen Netzwerkadapter für Verwaltungs-, Compute- und Speicherzwecke zu erstellen und zu konfigurieren. Standardmäßig verwendet Network ATC beim Erstellen des virtuellen Switches für die Absichten einen bestimmten Namen für den virtuellen Switch.

Es wird empfohlen, Ihre Namen für virtuelle Switches nach derselben Namenskonvention zu wählen. Der empfohlene Name für die virtuellen Switches lautet wie folgt:

„ConvergedSwitch($IntentName)“, wobei $IntentName mit dem Namen der Absicht übereinstimmen muss, die während der Bereitstellung in das Portal eingegeben wurde. Diese Zeichenfolge muss auch mit dem Namen des virtuellen Netzwerkadapters übereinstimmen, der für die Verwaltung verwendet wird, wie im nächsten Schritt beschrieben.

Das folgende Beispiel zeigt, wie Sie den virtuellen Switch mit PowerShell mithilfe der empfohlenen Benennungskonvention mit $IntentName erstellen. Die Liste der Netzwerkadapter-Namen ist eine Liste der physischen Netzwerkadapter, die Sie für Verwaltungs- und Compute-Netzwerkverkehr verwenden möchten:

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

Hinweis

Nachdem azure Local instance bereitgestellt wurde, wird es nicht unterstützt, den Verwaltungsabsichtsnamen oder den Namen des virtuellen Switchs zu ändern. Es ist erforderlich, denselben Absichtsnamen und virtuellen Switchnamen zu verwenden, wenn Sie die Absicht nach der Bereitstellung aktualisieren oder neu erstellen müssen.

2. Konfigurieren Sie den virtuellen Netzwerkadapter für die Verwaltung unter Verwendung der erforderlichen Network ATC-Namenskonvention für alle Knoten.

Sobald der virtuelle Switch und der zugehörige virtuelle Verwaltungs-Netzwerkadapter erstellt wurden, stellen Sie sicher, dass der Name des Netzwerkadapters den ATC-Namensstandards für Netzwerke entspricht.

Insbesondere muss der Name des virtuellen Netzwerkadapters, der für den Verwaltungsdatenverkehr verwendet wird, den folgenden Konventionen entsprechen:

• Der Name des Netzwerkadapters und des virtuellen Netzwerkadapters muss vManagement($intentname) verwenden.
• Bei diesem Namen wird zwischen Groß- und Kleinschreibung unterschieden.
• $Intentname kann eine beliebige Zeichenfolge sein, muss aber derselbe Name sein, der für den virtuellen Switch verwendet wird. Stellen Sie sicher, dass Sie dieselbe Zeichenfolge im Azure-Portal verwenden, wenn Sie den Namen der Mgmt Absicht definieren.

Verwenden Sie die folgenden Befehle, um den Namen des virtuellen Verwaltungs-Netzwerkadapters zu aktualisieren:

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string "vEthernet" to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

3. Konfigurieren Sie die VLAN-ID für den virtuellen Netzwerkadapter für alle Knoten

Sobald der virtuelle Switch und der virtuelle Netzwerkadapter für die Verwaltung erstellt wurden, können Sie die erforderliche VLAN-ID für diesen Adapter angeben. Obwohl es verschiedene Möglichkeiten gibt, einem virtuellen Netzwerkadapter eine VLAN-ID zuzuweisen, wird nur die Verwendung des Set-VMNetworkAdapterIsolation-Befehls unterstützt.

Sobald die erforderliche VLAN-ID konfiguriert ist, können Sie die IP-Adresse und die Gateways dem virtuellen Verwaltungs-Netzwerkadapter zuweisen, um zu überprüfen, ob eine Verbindung mit anderen Knoten, DNS, Active Directory und dem Internet besteht.

Das folgende Beispiel zeigt, wie der virtuelle Verwaltungsnetzwerkadapter so konfiguriert wird, dass er die VLAN-ID 8 anstelle der Standard-VLAN-ID verwendet:

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

4. Referenz für physische Netzwerkadapter für die Verwaltungsabsicht während der Bereitstellung

Obwohl der neu erstellte virtuelle Netzwerkadapter bei der Bereitstellung über Azure-Portal als verfügbar angezeigt wird, ist es wichtig zu beachten, dass die Netzwerkkonfiguration auf Network ATC basiert. Dies bedeutet, dass wir bei der Konfiguration der Verwaltung oder der Verwaltungs- und Compute-Absicht immer noch die physischen Netzwerkadapter auswählen müssen, die für diese Absicht verwendet werden.

Hinweis

Wählen Sie nicht den virtuellen Netzwerkadapter für die Netzwerkabsicht aus.

Die gleiche Logik gilt für die Azure Resource Manager-Vorlagen. Sie müssen die physischen Netzwerkadapter angeben, die Sie für die Netzwerkabsichten verwenden möchten, und niemals die virtuellen Netzwerkadapter.

Hier sind die zusammengefassten Überlegungen für die VLAN-ID:

#	Überlegungen
1	Die VLAN-ID muss auf dem Verwaltungs-Netzwerkadapter angegeben werden, bevor die Computer bei Azure Arc registriert werden.
2	Verwenden Sie bestimmte Schritte, wenn ein virtueller Switch erforderlich ist, bevor Sie die Computer bei Azure Arc registrieren.
3	Die Verwaltungs-VLAN-ID wird während der Bereitstellung von der Host-Konfiguration auf die Infrastruktur-VMs übertragen.
4	Es gibt keinen VLAN-ID-Eingabeparameter fürd ie Azure-Portal Bereitstellung oder für die Bereitstellung von Resource-Manager-Vorlagen.

Benutzerdefinierte IPs für die Speicherung

Standardmäßig weist Network ATC automatisch die IPs und VLANs für den Speicher aus der folgenden Tabelle zu:

Speicheradapter	IP-Adresse und Subnetz	VLAN
pNIC1	10.71.1.x	711
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

Wenn Ihre Bereitstellungsanforderungen jedoch nicht mit diesen Standard-IPs und VLANs übereinstimmen, können Sie Ihre eigenen IPs, Subnetze und VLANs zur Speicherung verwenden. Diese Funktionalität ist nur verfügbar, wenn Sie Cluster mithilfe von ARM-Vorlagen bereitstellen, und Sie müssen die folgenden Parameter in Ihrer Vorlage angeben.

• enableStorageAutoIP: Dieser Parameter ist auf „true“ gesetzt, wenn er nicht angegeben wird. Um benutzerdefinierte Speicher-IPs während der Bereitstellung zu aktivieren, muss dieser Parameter auf „false“ gesetzt werden.
• storageAdapterIPInfo: Dieser Parameter ist vom Parameter „enableStorageAutoIP“ abhängig und immer erforderlich, wenn der Parameter „storage auto IP“ auf „false“ gesetzt ist. Innerhalb des „storageAdapterIPInfo“-Parameters in Ihrer ARM-Vorlage müssen Sie auch die „ipv4Address“- und „subnetMask“-Parameter für jeden Knoten und Netzwerkadapter mit Ihren eigenen IP-Adressen und Subnetzmasken angeben.
• vlanId: Wie oben in der Tabelle beschrieben, verwendet dieser Parameter die Network ATC-Standard-VLANs, wenn Sie sie nicht ändern müssen. Wenn diese Standard-VLANs jedoch in Ihrem Netzwerk nicht funktionieren, können Sie für jedes Ihrer Speichernetzwerke eigene VLAN-IDs festlegen.

Die folgende ARM-Vorlage enthält ein Beispiel für eine Azure Local-Instanz mit zwei Knoten und einem Netzwerk-Switch für die Speicherung, bei der die Speicher-IPs angepasst werden. Bereitstellung mit 2 Knoten und benutzerdefinierten Speicher-IPs

Knoten- und Cluster-IP-Zuweisung

Für die Azure Local-Instanz haben Sie zwei Möglichkeiten, IPs für die Computerknoten und für die Cluster-IP zuzuweisen.

• Sowohl die statischen als auch die DHCP-Protokolle (Dynamic Host Configuration Protocol) werden unterstützt.

• Die richtige Knoten-IP-Zuweisung ist der Schlüssel für die Cluster-Lebenszyklusverwaltung. Entscheiden Sie zwischen den statischen und DHCP-Optionen, bevor Sie die Knoten in Azure Arc registrieren.

• Infrastruktur-VMs und -Dienste wie Arc-Ressourcenbrücke und Network Controller verwenden statische IPs aus dem Verwaltungs-IP-Pool. Dies bedeutet, dass selbst wenn Sie DHCP verwenden, um die IPs Ihren Knoten und Ihrer Cluster-IP zuzuweisen, der Verwaltungs-IP-Pool weiterhin erforderlich ist.

In den folgenden Abschnitten werden die Auswirkungen der einzelnen Optionen erläutert.

Statische IP-Zuweisung

Wenn statische IPs für die Knoten verwendet werden, wird der Verwaltungs-IP-Pool verwendet, um eine verfügbare IP zu erhalten und sie dem Cluster-IP automatisch während der Bereitstellung zuzuweisen.

Es ist wichtig, Verwaltungs-IPs für die Knoten zu verwenden, die nicht Teil des für den Verwaltungs-IP-Pool definierten IP-Bereichs sind. Computerknoten-IPs müssen sich im selben Subnetz des definierten IP-Bereichs befinden.

Wir empfehlen, dass Sie nur eine Verwaltungs-IP für das Standard-Gateway und für die konfigurierten DNS-Server für alle physischen Netzwerkadapter des Knotens zuweisen. Dadurch wird sichergestellt, dass sich die IP nicht ändert, sobald die Verwaltungsnetzwerks-Absicht erstellt wurde. Dadurch wird auch sichergestellt, dass die Knoten während des Bereitstellungsprozesses, einschließlich der Azure Arc-Registrierung, ihre ausgehende Konnektivität beibehalten.

Um Routing-Probleme zu vermeiden und zu ermitteln, welche IP für die ausgehende Konnektivität und die Arc-Registrierung verwendet wird, überprüft das Azure-Portal, ob mehr als ein Standard-Gateway konfiguriert ist.

Wenn während der Betriebssystemkonfiguration ein virtueller Switch und ein Verwaltungs-Netzwerkadapter erstellt wurden, muss die Verwaltungs-IP für den Knoten diesem virtuellen Netzwerkadapter zugewiesen werden.

DHCP IP-Adresszuweisung

Wenn IPs für die Knoten von einem DHCP-Server bezogen werden, wird auch eine dynamische IP für die Cluster-IP verwendet. Infrastruktur-VMs und -Dienste erfordern nach wie vor statische IP-Adressen, was bedeutet, dass der IP-Adressbereich des Verwaltungs-Pools aus dem DHCP-Bereich ausgeschlossen werden muss, der für die Knoten und die Cluster-IP verwendet wird.

Wenn beispielsweise der IP-Bereich für die Verwaltung als 192.168.1.20/24 bis 192.168.1.30/24 für die statischen IPs der Infrastruktur definiert ist, muss der für das Subnetz 192.168.1.0/24 definierte DHCP-Bereich einen Ausschluss enthalten, der dem IP-Pool für die Verwaltung entspricht, um IP-Konflikte mit den Infrastrukturdiensten zu vermeiden. Wir empfehlen außerdem, DHCP-Reservierungen für Knoten-IPs zu verwenden.

Der Prozess der Definition des Verwaltungs-IP nach der Erstellung der Verwaltungs-Absicht umfasst die Verwendung der MAC-Adresse des ersten physischen Netzwerkadapters, der für die Netzwerk-Absicht ausgewählt wird. Diese MAC-Adresse wird dann dem virtuellen Netzwerkadapter zugewiesen, der für Verwaltungszwecke erstellt wird. Das bedeutet, dass die IP-Adresse, die der erste physische Netzwerkadapter vom DHCP-Server erhält, dieselbe IP-Adresse ist, die der virtuelle Netzwerkadapter als Verwaltungs-IP verwendet. Daher ist es wichtig, DHCP-Reservierungen für Knoten-IP zu erstellen.

Die bei der Cloud-Bereitstellung verwendete Netzwerkvalidierungslogik schlägt fehl, wenn sie mehrere physische Netzwerkschnittstellen erkennt, die in ihrer Konfiguration ein Standard-Gateway haben. Wenn Sie DHCP für Ihre Host-IP-Zuweisungen verwenden müssen, müssen Sie den virtuellen SET (Switch Embedded Teaming)-Switch und den Verwaltungs-Netzwerkadapter wie oben beschrieben vorab erstellen, sodass nur der Verwaltungs-Netzwerkadapter eine IP-Adresse vom DHCP-Server erhält.

Überlegungen zur IP-Adresse von Clusterknoten

Hier sind die zusammengefassten Überlegungen für die IP-Adressen:

#	Überlegungen
1	Die Knoten-IPs müssen sich im selben Subnetz des definierten Verwaltungs-IP-Poolbereichs befinden, unabhängig davon, ob es sich um statische oder dynamische Adressen handelt.
2	Der Verwaltungs-IP-Pool darf keine Knoten-IPs enthalten. Verwenden Sie DHCP-Ausschlüsse, wenn eine dynamische IP-Zuweisung verwendet wird.
3	Verwenden Sie so oft wie möglich DHCP-Reservierungen für die Knoten.
4	DHCP-Adressen werden nur für Knoten-IPs und die Cluster-IP unterstützt. Infrastrukturdienste verwenden statische IPs aus dem Verwaltungspool.
5	Die MAC-Adresse des ersten physischen Netzwerkadapters wird dem Verwaltungs-Netzwerkadapter zugewiesen, sobald die Verwaltungs-Netzwerkabsicht erstellt wurde.

Überlegungen zu DNS-Servern

Azure-Lokalbereitstellungen basieren auf Active Directory und benötigen einen DNS-Server, der die lokale Domäne und die öffentlichen Internetendpunkte auflösen kann. Im Rahmen der Bereitstellung ist es erforderlich, dieselben DNS-Server für den IP-Adressbereich der Infrastruktur zu definieren, der auf den Knoten konfiguriert ist. Azure Resource Bridge Control Plane VM und AKS Control Plane verwenden dieselben DNS-Server für die Namensauflösung. Nach Abschluss der Bereitstellung wird das Ändern der DNS-Server-IPs nicht unterstützt, und es wird nicht möglich sein, die Adressen auf der Plattform von Azure Local zu aktualisieren.

Die für Azure Local verwendeten DNS-Server müssen vor der Bereitstellung extern und betriebsbereit sein. Es wird nicht unterstützt, sie als virtuelle Azure-Computer auszuführen.

Hier sind die zusammengefassten Überlegungen für DNS-Serveradressen:

#	Überlegungen
1	DNS-Server müssen auf allen Knoten des Clusters identisch sein.
2	Der IP-Adressbereich der Infrastruktur und die DNS-Server müssen die gleichen sein, die für die Knoten verwendet werden.
3	Die VM-Steuerungsebene der Azure Resource Bridge und die AKS-Steuerungsebene verwenden die DNS-Server, die im IP-Adressbereich der Infrastruktur konfiguriert sind.
4	Die Änderung der DNS-Server nach der Bereitstellung wird nicht unterstützt. Stellen Sie sicher, dass Sie Ihre DNS-Strategie planen, bevor Sie die lokale Azure-Bereitstellung durchführen.
5	Stellen Sie beim Definieren eines Arrays mehrerer DNS-Server in einer ARM-Vorlage für das Infrastrukturnetzwerk sicher, dass jeder Wert in Anführungszeichen "" steht und durch Kommas getrennt ist, wie im folgenden Beispiel gezeigt.
6	Es wird nicht unterstützt, die von der lokalen Azure-Infrastruktur verwendeten DNS-Server auf virtuellen Computern auszuführen, die in der lokalen Azure-Instanz ausgeführt werden.

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

Proxyanforderungen

Für den Internetzugang innerhalb Ihrer lokalen Infrastruktur ist höchstwahrscheinlich ein Proxy erforderlich. Azure Local unterstützt nur nicht authentifizierte Proxykonfigurationen. Da für die Registrierung der Knoten in Azure Arc ein Internetzugang erforderlich ist, muss die Proxy-Konfiguration als Teil der Betriebssystemkonfiguration festgelegt werden, bevor die Computerknoten registriert werden. Weitere Informationen finden Sie unter Konfigurieren von Proxy-Einstellungen.

Das Azure Stack HCI-Betriebssystem verfügt über drei verschiedene Dienste (WinInet, WinHTTP und Umgebungsvariablen), die dieselbe Proxy-Konfiguration erfordern, um sicherzustellen, dass alle Betriebssystemkomponenten auf das Internet zugreifen können. Die gleiche Proxy-Konfiguration, die für die Knoten verwendet wird, wird automatisch auf die Arc-Ressourcenbrücken-VM und AKS übertragen, um sicherzustellen, dass sie während der Bereitstellung über einen Internetzugang verfügen.

Hier sind die zusammengefassten Überlegungen für die Proxykonfiguration:

#	Aspekt
1	Die Proxykonfiguration muss abgeschlossen werden, bevor die Knoten in Azure Arc registriert werden.
2	Die gleiche Proxykonfiguration muss für WinINET-, WinHTTP- und Umgebungsvariablen angewendet werden.
3	Die Umgebungsprüfung stellt sicher, dass die Proxykonfiguration für alle Proxykomponenten konsistent ist.
4	Die Proxy-Konfiguration von Arc Resource Bridge VM und AKS wird während der Bereitstellung automatisch vom Orchestrator vorgenommen.
5	Nur die nicht authentifizierten Proxys werden unterstützt.

Firewallanforderungen

Sie müssen derzeit mehrere Internet-Endpunkte in Ihren Firewalls öffnen, um sicherzustellen, dass Azure Local und seine Komponenten erfolgreich eine Verbindung zu ihnen herstellen können. Eine detaillierte Liste der erforderlichen Endpunkte finden Sie unter Firewallanforderungen.

Die Firewall-Konfiguration muss vor der Registrierung der Knoten in Azure Arc erfolgen. Sie können die eigenständige Version des Umgebungsprüfers verwenden, um zu überprüfen, ob Ihre Firewalls den an diese Endpunkte gesendeten Datenverkehr nicht blockieren. Weitere Informationen finden Sie unter Azure Local-Umgebungsüberprüfung zur Bewertung der Bereitstellungsbereitschaft für Azure Local.

Hier sind die zusammengefassten Überlegungen für die Firewall:

#	Aspekt
1	Die Firewall-Konfiguration muss vor der Registrierung der Knoten in Azure Arc erfolgen.
2	Der Environment Checker kann im Standalone-Modus zur Validierung der Firewall-Konfiguration verwendet werden.

Schritt 5: Bestimmung der Konfiguration des Netzwerkadapters

Netzwerkadapter werden nach der Art des Netzwerkverkehrs (Verwaltung, Compute und Speicherung) qualifiziert, für den sie verwendet werden. Wenn Sie den Windows Server-Katalog durchsehen, zeigt die Windows Server 2022-Zertifizierung an, für welchen Netzwerkverkehr die Adapter qualifiziert sind.

Vor dem Kauf eines Computers für Azure Local benötigen Sie mindestens einen Adapter, der für die Verwaltung, Compute und Speicherung qualifiziert ist, da alle drei Datenverkehrstypen auf Azure Local erforderlich sind. Die Cloud-Bereitstellung ist darauf angewiesen, dass Network ATC die Netzwerkadapter für die entsprechenden Verkehrstypen konfiguriert. Daher ist es wichtig, unterstützte Netzwerkadapter zu verwenden.

Die von Network ATC verwendeten Standardwerte werden in den Clusternetzwerkeinstellungen dokumentiert. Wir empfehlen Ihnen, die Standardwerte zu verwenden. Davon abgesehen können die folgenden Optionen bei Bedarf mithilfe von Azure-Portal- oder Resource-Manager-Vorlagen überschrieben werden:

• Speicher-VLANs: Legen Sie diesen Wert auf die erforderlichen VLANs für den Speicher fest.
• Jumbo-Pakete: Definiert die Größe der Jumbo-Pakete.
• Netzwerk direct: Setzen Sie diesen Wert auf „false“, wenn Sie RDMA für Ihre Netzwerkadapter deaktivieren möchten.
• Network Direct Technology: Setzen Sie diesen Wert auf RoCEv2 oder iWarp.
• Traffic Priorities Datacenter Bridging (DCB): Stellen Sie die Prioritäten so ein, dass sie Ihren Anforderungen entsprechen. Wir empfehlen Ihnen dringend, die Standard-DCB-Werte zu verwenden, da diese von Microsoft und Kunden validiert wurden.

Hier sind die zusammengefassten Überlegungen zur Konfiguration des Netzwerkadapters:

#	Aspekt
1	Verwenden Sie die Standardkonfigurationen so weit wie möglich.
2	Physische Switches müssen entsprechend der Konfiguration des Netzwerkadapters konfiguriert werden. Siehe Physische Netzwerkanforderungen für Azure Local.
3	Stellen Sie sicher, dass Ihre Netzwerkadapter für Azure Local über den Windows Server-Katalog unterstützt werden.
4	Wenn die Standardwerte akzeptiert werden, konfiguriert Network ATC automatisch die IP-Adressen und VLANs des Speichernetzwerkadapters. Dies wird als automatische Speicher-IP-Konfiguration bezeichnet. In einigen Fällen wird Storage Auto IP nicht unterstützt und Sie müssen jede IP-Adresse des Speichernetzwerkadapters mithilfe von Vorlagen für den Resource Manager deklarieren.

Nächste Schritte

• Informationen zur Bereitstellung von Azure Local, Version 23H2