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

Gilt für: Azure Local, Version 23H2

In diesem Artikel wird erläutert, wie Sie ein lokales Azure, Version 23H2-Systemnetzwerk für die Cloudbereitstellung entwerfen und planen. Bevor Sie fortfahren, machen Sie sich mit den verschiedenen lokalen Azure-Netzwerkmustern und verfügbaren Konfigurationen vertraut.

Netzwerkentwurfsframework

Das folgende Diagramm zeigt die verschiedenen Entscheidungen und Schritte, die das Netzwerkentwurfsframework für Ihre lokale Azure-Instanz definieren – Clustergröße, Clusterspeicherkonnektivität, Netzwerkdatenverkehr intents, Verwaltungskonnektivität und Netzwerkadapterkonfiguration. Jede Entwurfsentscheidung ermöglicht oder lässt die in den folgenden Schritten verfügbaren Entwurfsoptionen zu:

Schritt 1: Ermitteln der Clustergröße

Um die Größe Ihrer lokalen Azure-Instanz zu ermitteln, verwenden Sie das Azure Local Sizer-Tool, in dem Sie Ihr Profil wie die Anzahl virtueller Computer (VMs), die Größe der virtuellen Computer und die Workloadnutzung der virtuellen Computer wie Azure Virtual Desktop, SQL Server oder AKS definieren können.

Wie im Artikel "Anforderungen an den lokalen Azure-Systemcomputer" beschrieben, beträgt die maximale Anzahl von Computern, die auf der lokalen Azure-Instanz unterstützt werden, 16. Nachdem Sie die Kapazitätsplanung für Arbeitsauslastung abgeschlossen haben, sollten Sie sich mit der Anzahl der Computerknoten, die zum Ausführen von Workloads in Ihrer Infrastruktur erforderlich sind, gut verstehen.

• Wenn Ihre Workloads vier oder mehr Knoten erfordern: Sie können keine switchless-Konfiguration für den Speichernetzwerkdatenverkehr bereitstellen und verwenden. Sie müssen einen physischen Switch mit Unterstützung für den Remote-Direct Memory Access (RDMA) zur Verarbeitung des Speicherdatenverkehrs einschließen. 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 entweder switchless oder switched-Konfigurationen für die Speicherkonnektivität auswählen.

• Wenn Sie beabsichtigen, später auf mehr als drei Knoten zu skalieren: Sie müssen einen physischen Switch für den Speichernetzwerkdatenverkehr verwenden. Jeder Skalierungsvorgang für switchlose Bereitstellungen 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)	Switchless Configuration via the Azure-Portal or Azure Resource Manager templates is only available for 1, 2, or 3 node clusters. Cluster mit 4 oder mehr Knoten erfordern einen physischen Switch für den Speichernetzwerkdatenverkehr.
Skalierungsanforderungen	Wenn Sie beabsichtigen, Ihren Cluster mithilfe des Orchestrators zu skalieren, müssen Sie einen physischen Switch für den Speichernetzwerkdatenverkehr verwenden.

Schritt 2: Ermitteln der Clusterspeicherkonnektivität

Wie in den Anforderungen des physischen Netzwerks beschrieben, unterstützt Azure Local zwei Arten von Konnektivität für Speichernetzwerkdatenverkehr:

• Verwenden Sie einen physischen Netzwerkswitch, um den Datenverkehr zu verarbeiten.
• Verbinden Sie die Knoten direkt zwischen ihnen mit Crossover-Netzwerk- oder Glasfaserkabeln für den Speicherdatenverkehr.

Die Vor- und Nachteile jeder Option sind im oben verlinkten Artikel dokumentiert.

Wie bereits erwähnt, können Sie nur zwischen den beiden Optionen entscheiden, wenn die Größe des 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 aufweisen, beeinflusst die Entscheidung über die Speicherkonnektivität die Anzahl und den Typ der Netzwerkabsichten, die Sie im nächsten Schritt definieren können.

Für switchlose Konfigurationen müssen Sie z. B. zwei Netzwerkdatenverkehrsabsichten definieren. Der Speicherdatenverkehr für die Ost-West-Kommunikation mit den Crossoverkabeln hat keine Nord-Süd-Konnektivität und ist vollständig von der restlichen Netzwerkinfrastruktur isoliert. Dies bedeutet, dass Sie eine zweite Netzwerkabsicht für die Verwaltung ausgehender Konnektivität und für Ihre Computeworkloads definieren müssen.

Obwohl es möglich ist, jede Netzwerkabsicht mit jeweils 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 Netzwerkswitches für den Speicher entscheiden, können Sie den gesamten Netzwerkdatenverkehr einschließlich des Speichers in einer einzelnen Netzwerkabsicht gruppieren, die auch als hyperkonvergierte oder vollständig konvergente Hostnetzwerkkonfiguration bezeichnet wird.

Hier sind die zusammengefassten Überlegungen für die Entscheidung über die Clusterspeicherkonnektivität:

Entscheidung	Aspekt
Kein Switch für Speicher	Switchless Configuration via Azure-Portal- oder Resource Manager template deployment is only supported for 1, 2 or 3 node clusters. 1 oder 2 Knoten speicherlose Cluster können mithilfe der Vorlagen Azure-Portal oder Ressourcen-Manager bereitgestellt werden. 3 Knoten speicherfreie Cluster können nur mithilfe von Ressourcen-Manager-Vorlagen bereitgestellt werden. Skalierungsvorgänge werden mit den switchlosen Bereitstellungen nicht unterstützt. Jede Änderung an der Anzahl der Knoten nach der Bereitstellung erfordert eine manuelle Konfiguration. Mindestens 2 Netzwerkabsichten sind erforderlich, wenn sie die Konfiguration ohne Speicherschalter verwenden.
Netzwerkswitch für Speicher	Wenn Sie beabsichtigen, Ihren Cluster mithilfe des Orchestrators zu skalieren, müssen Sie einen physischen Switch für den Speichernetzwerkdatenverkehr verwenden. Sie können diese Architektur mit einer beliebigen Anzahl von Knoten zwischen 1 und 16 verwenden. Obwohl nicht erzwungen wird, können Sie einen einzelnen Zweck für alle Netzwerkdatenverkehrtypen (Verwaltung, Compute und Speicher) verwenden.

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

Schritt 3: Ermitteln von Netzwerkdatenverkehrsabsichten

Für Azure Local basieren alle Bereitstellungen auf Network ATC für die Hostnetzwerkkonfiguration. Die Netzwerkabsichten werden beim Bereitstellen von Azure Local über die Azure-Portal automatisch konfiguriert. Weitere Informationen zu den Netzwerkabsichten und zur Problembehandlung finden Sie unter allgemeine ATC-Befehle für das Netzwerk.

In diesem Abschnitt werden die Auswirkungen ihrer Entwurfsentscheidung für Die Absichten des Netzwerkdatenverkehrs und deren Einfluss auf den nächsten Schritt des Frameworks erläutert. Bei Cloudbereitstellungen können Sie zwischen vier Optionen wählen, um den Netzwerkdatenverkehr in einen oder mehrere 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

Netzwerk-ATC konfiguriert eine eindeutige Absicht, die Verwaltungs-, Compute- und Speichernetzwerkdatenverkehr umfasst. Die netzwerkadapter, die dieser Absicht zugewiesen sind, teilen Bandbreite und Durchsatz für den gesamten Netzwerkdatenverkehr.

• Für diese Option ist ein physischer Switch für speicherdatenverkehr erforderlich. Wenn Sie eine switchlose Architektur benötigen, können Sie diese Art von Absicht nicht verwenden. Azure-Portal filtert diese Option automatisch aus, wenn Sie eine switchlose Konfiguration für die Speicherkonnektivität auswählen.

• Es wird empfohlen, mindestens zwei Netzwerkadapterports sicherzustellen, dass hohe Verfügbarkeit gewährleistet ist.

• Mindestens 10 GBit/s-Netzwerkschnittstellen sind erforderlich, um RDMA-Datenverkehr für den Speicher zu unterstützen.

Netzwerkabsicht: Gruppenverwaltung und Computedatenverkehr

Netzwerk-ATC konfiguriert zwei Absichten. Die erste Absicht umfasst die Verwaltung und Berechnung des Netzwerkdatenverkehrs, und der zweite Zweck umfasst nur Speichernetzwerkdatenverkehr. Jede Absicht muss über einen anderen Satz von Netzwerkadapterports verfügen.

Sie können diese Option sowohl für switched als auch switchless storage connectivity verwenden, wenn:

• Mindestens zwei Netzwerkadapterports sind für jeden Zweck verfügbar, um eine hohe Verfügbarkeit sicherzustellen.

• Ein physischer Switch wird für RDMA verwendet, wenn Sie den Netzwerkswitch für den Speicher verwenden.

• Mindestens 10 GBit/s-Netzwerkschnittstellen sind erforderlich, um RDMA-Datenverkehr für den Speicher zu unterstützen.

Netzwerkabsicht: Gruppieren von Compute- und Speicherdatenverkehr

Netzwerk-ATC konfiguriert zwei Absichten. Der erste Zweck umfasst Compute- und Speichernetzwerkdatenverkehr, und der zweite Zweck umfasst nur den Verwaltungsnetzwerkdatenverkehr. Jede Absicht muss einen anderen Satz von Netzwerkadapterports verwenden.

• Für diese Option ist ein physischer Switch für den Speicherdatenverkehr erforderlich, da dieselben Ports mit Computedatenverkehr gemeinsam genutzt werden, was eine Nord-Süd-Kommunikation erfordert. Wenn Sie eine switchlose Konfiguration benötigen, können Sie diese Art von Absicht nicht verwenden. Azure-Portal filtert diese Option automatisch aus, wenn Sie eine switchlose Konfiguration für die Speicherkonnektivität auswählen.

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

• Es wird mindestens zwei Netzwerkadapterports empfohlen, um eine hohe Verfügbarkeit sicherzustellen.

• Mindestens 10 GBit/s-Netzwerkschnittstellen werden für die Berechnungs- und Speicherabsicht empfohlen, um RDMA-Datenverkehr zu unterstützen.

• Selbst wenn die Verwaltungsabsicht ohne Rechenabsicht deklariert wird, erstellt Network ATC einen virtuellen Switch (Switch Embedded Teaming, SET), um eine hohe Verfügbarkeit für das Verwaltungsnetzwerk bereitzustellen.

Netzwerkabsicht: Benutzerdefinierte Konfiguration

Definieren Sie bis zu drei Absichten mithilfe Ihrer eigenen Konfiguration, solange mindestens einer der Absichten den Verwaltungsdatenverkehr umfasst. Es wird empfohlen, diese Option zu verwenden, wenn Sie eine zweite Berechnungsabsicht benötigen. Szenarien für diese zweite Berechnungsabsichtanforderung umfassen Remotespeicherdatenverkehr, VMs-Sicherungsdatenverkehr oder eine separate Computeabsicht für unterschiedliche Arten von Workloads.

• Verwenden Sie diese Option für switchierte und switchlose Speicherkonnektivität, wenn sich die Speicherabsicht von den anderen Absichten unterscheidet.

• Verwenden Sie diese Option, wenn eine andere Berechnungsabsicht erforderlich ist oder wenn Sie die unterschiedlichen Datenverkehrstypen vollständig über verschiedene Netzwerkadapter trennen möchten.

• Verwenden Sie mindestens zwei Netzwerkadapterports für jede Absicht, um eine hohe Verfügbarkeit sicherzustellen.

• Mindestens 10 GBit/s-Netzwerkschnittstellen werden für die Berechnungs- und Speicherabsicht empfohlen, um RDMA-Datenverkehr zu unterstützen.

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

Schritt 4: Ermitteln der Verwaltungs- und Speichernetzwerkkonnektivität

In diesem Schritt definieren Sie den Subnetzadressraum der Infrastruktur, wie diese Adressen Ihrem Cluster zugewiesen werden, und ob proxy- oder VLAN-ID für die Knoten für ausgehende Verbindungen mit dem Internet und andere Intranetdienste wie Domain Name System (DNS) oder Active Directory-Dienste erforderlich ist.

Die folgenden Infrastruktursubnetzkomponenten müssen geplant und definiert werden, bevor Sie mit der Bereitstellung beginnen, damit Sie alle Routing-, Firewall- oder Subnetzanforderungen antizipieren können.

Netzwerkadaptertreiber

Nachdem Sie das Betriebssystem installiert haben und bevor Sie netzwerke auf Ihren Knoten konfigurieren, müssen Sie sicherstellen, dass Ihre Netzwerkadapter über den neuesten Treiber verfügen, der vom OEM- oder Netzwerkschnittstellenanbieter bereitgestellt wird. Wichtige Funktionen der Netzwerkadapter werden bei Verwendung der Microsoft-Standardtreiber möglicherweise nicht angezeigt.

Verwaltungs-IP-Pool

Bei der erstbereitstellung Ihrer lokalen Azure-Instanz müssen Sie einen IP-Bereich von aufeinander folgenden IPs 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 aufeinander folgenden verfügbaren IP-Adressen verwenden. Diese Adressen werden für - die Cluster-IP, die VM der Azure Resource Bridge und die zugehörigen Komponenten verwendet.

Wenn Sie davon ausgehen, dass andere Dienste im Infrastrukturnetzwerk ausgeführt werden, empfehlen wir, dem Pool einen zusätzlichen Puffer von Infrastruktur-IPs zuzuweisen. Es ist möglich, weitere IP-Pools nach der Bereitstellung für das Infrastrukturnetzwerk mithilfe von PowerShell hinzuzufügen, wenn die Größe des ursprünglich geplanten Pools erschöpft ist.

Die folgenden Bedingungen müssen erfüllt sein, wenn Sie Ihren IP-Pool für das Infrastruktursubnetz während der Bereitstellung definieren:

#	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 Bereich von IPs darf nicht die Clusterknotenverwaltungs-IPs enthalten, sondern muss sich im selben Subnetz wie Ihre Knoten befinden.
3	Das für den VERWALTUNGS-IP-Pool definierte Standardgateway muss ausgehende Verbindungen mit dem Internet bereitstellen.
4	Die DNS-Server müssen die Namensauflösung mit Active Directory und dem Internet sicherstellen.
5	Die Verwaltungs-IPs erfordern ausgehenden Internetzugriff.

Verwaltungs-VLAN-ID

Wir empfehlen, das Verwaltungssubnetz Ihrer lokalen Azure-Instanz das Standard-VLAN zu verwenden, das in den meisten Fällen als VLAN-ID 0 deklariert wird. Wenn Ihre Netzwerkanforderungen jedoch ein bestimmtes Verwaltungs-VLAN für Ihr Infrastrukturnetzwerk verwenden möchten, muss es auf Ihren physischen Netzwerkadaptern konfiguriert sein, die Sie für den Verwaltungsdatenverkehr verwenden möchten.

Wenn Sie beabsichtigen, zwei physische Netzwerkadapter für die Verwaltung zu verwenden, müssen Sie das VLAN auf beiden Adaptern festlegen. Dies muss als Teil der Bootstrap-Konfiguration Ihrer Computer und vor der Registrierung bei Azure Arc erfolgen, um sicherzustellen, dass Sie die Knoten mithilfe dieses VLANs erfolgreich registrieren.

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 NIC1konfiguriert.

Set-NetAdapter -Name "NIC1" -VlanID 44

Sobald die VLAN-ID festgelegt ist und die IPs Ihrer Knoten auf den physischen Netzwerkadaptern konfiguriert sind, liest der Orchestrator diesen VLAN-ID-Wert aus dem physischen Netzwerkadapter, der für die Verwaltung verwendet wird, und speichert ihn, sodass er für die Azure Resource Bridge VM oder eine andere Infrastruktur-VM verwendet werden kann, die während der Bereitstellung erforderlich ist. Es ist nicht möglich, die Verwaltungs-VLAN-ID während der Cloudbereitstellung von Azure-Portal festzulegen, da dies das Risiko birgt, die Verbindung zwischen den Knoten und Azure zu unterbrechen, wenn die physische Switch-VLANs nicht ordnungsgemäß weitergeleitet 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, sollten Sie die Rolle "Hype-V" aktivieren. Weitere Informationen finden Sie unter Installieren der erforderlichen Windows-Rolle.

Wenn eine Konfiguration für einen virtuellen Switch erforderlich ist und Sie eine bestimmte VLAN-ID verwenden müssen, führen Sie die folgenden Schritte aus:

1. Erstellen eines virtuellen Switches mit empfohlener Benennungskonvention

Azure Local deployments rely on Network ATC to create and configure the virtual switches and virtual network adapters for management, compute, and storage intents. Wenn Network ATC den virtuellen Switch für die Absichten erstellt, wird standardmäßig ein bestimmter Name für den virtuellen Switch verwendet.

Es wird empfohlen, Ihre Namen für virtuelle Switche mit derselben Benennungskonvention zu benennen. Der empfohlene Name für die virtuellen Switches lautet wie folgt:

"ConvergedSwitch($IntentName)", wobei $IntentName der Name des im Portal während der Bereitstellung eingegebenen Absicht übereinstimmen muss. 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 $IntentNamePowerShell erstellen. Die Liste der Netzwerkadapternamen ist eine Liste der physischen Netzwerkadapter, die Sie für die Verwaltung und Berechnung des Netzwerkdatenverkehrs verwenden möchten:

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

2. Konfigurieren des virtuellen Netzwerkadapters für die Verwaltung mithilfe der erforderlichen Benennungskonvention für Netzwerk ATC für alle Knoten

Nachdem der virtuelle Switch und der zugeordnete virtuelle Netzwerkadapter erstellt wurden, stellen Sie sicher, dass der Name des Netzwerkadapters den Benennungsstandards für Netzwerk ATC entspricht.

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

• Der Name des Netzwerkadapters und des virtuellen Netzwerkadapters muss verwendet werden vManagement($intentname).
• Bei diesem Namen wird die Groß-/Kleinschreibung beachtet.
• $Intentname kann eine beliebige Zeichenfolge sein, muss aber derselbe Name sein, der für den virtuellen Switch verwendet wird. Stellen Sie sicher, dass Sie beim Definieren des Absichtsnamens Mgmt dieselbe Zeichenfolge in Azure-Portal verwenden.

Verwenden Sie die folgenden Befehle, um den Namen des virtuellen Netzwerkadapters für die Verwaltung 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 der VLAN-ID für die Verwaltung des virtuellen Netzwerkadapters für alle Knoten

Nachdem 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 Optionen gibt, eine VLAN-ID einem virtuellen Netzwerkadapter zuzuweisen, besteht die einzige unterstützte Option darin, den Set-VMNetworkAdapterIsolation Befehl zu verwenden.

Nachdem die erforderliche VLAN-ID konfiguriert wurde, können Sie die IP-Adresse und Gateways dem virtuellen Verwaltungsnetzwerkadapter zuweisen, um zu überprüfen, ob sie über Eine Verbindung mit anderen Knoten, DNS, Active Directory und dem Internet verfügt.

Im folgenden Beispiel wird gezeigt, wie Sie den virtuellen Verwaltungsnetzwerkadapter so konfigurieren, dass anstelle des Standards VLAN-ID 8 verwendet wird:

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 Netzwerk-ATC basiert. Dies bedeutet, dass wir bei der Konfiguration der Verwaltung oder der Verwaltungs- und Berechnungsabsicht 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 und niemals die virtuellen Netzwerkadapter verwenden möchten.

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

#	Überlegungen
1	Die VLAN-ID muss auf dem physischen Netzwerkadapter für die Verwaltung angegeben werden, bevor sie die Computer bei Azure Arc registrieren.
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 Hostkonfiguration auf die Infrastruktur-VMs übertragen.
4	Es gibt keinen VLAN-ID-Eingabeparameter für Azure-Portal Bereitstellung oder für die Bereitstellung von Ressourcen-Manager-Vorlagen.

Benutzerdefinierte IPs für den Speicher

Standardmäßig weist netzwerk-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 für den Speicher verwenden. Diese Funktionalität ist nur verfügbar, wenn Cluster mithilfe von ARM-Vorlagen bereitgestellt werden, und Sie müssen die folgenden Parameter in Ihrer Vorlage angeben.

• enableStorageAutoIP: Dieser Parameter, wenn nicht angegeben ist, ist auf "true" festgelegt. Um benutzerdefinierte Speicher-IPs während der Bereitstellung zu aktivieren, muss dieser Parameter auf "false" festgelegt sein.
• storageAdapterIPInfo: Dieser Parameter weist eine Abhängigkeit mit dem Parameter "enableStorageAutoIP" auf und ist immer erforderlich, wenn der automatische IP-Parameter des Speichers auf "false" festgelegt ist. Innerhalb des Parameters "storageAdapterIPInfo" in Ihrer ARM-Vorlage müssen Sie auch die Parameter "ipv4Address" und "subnetMask" für jeden Knoten und Netzwerkadapter mit Ihren eigenen IPs und Subnetzmaske 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 nicht in Ihrem Netzwerk funktionieren, können Sie ihre eigenen VLAN-IDs für jedes Ihrer Speichernetzwerke angeben.

Die folgende ARM-Vorlage enthält ein Beispiel für eine zwei Knoten azure Local instance with network switch for storage, where storage IPs are custom 2 Nodes deployment with custom storage IPs

Knoten- und Cluster-IP-Zuweisung

Für azure Local instance haben Sie zwei Optionen, um IPs für die Computerknoten und 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 Clusterlebenszyklusverwaltung. Entscheiden Sie zwischen den statischen und DHCP-Optionen, bevor Sie die Knoten in Azure Arc registrieren.

• Infrastruktur-VMs und -Dienste wie Arc Resource Bridge und Netzwerkcontroller 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 abzurufen und sie während der Bereitstellung automatisch der Cluster-IP 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.

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

Um Routingprobleme zu vermeiden und zu ermitteln, welche IP für ausgehende Konnektivität und Arc-Registrierung verwendet wird, überprüft Azure-Portal, ob mehr als ein Standardgateway konfiguriert ist.

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

DHCP-IP-Zuweisung

Wenn IPs für die Knoten von einem DHCP-Server abgerufen werden, wird auch eine dynamische IP für die Cluster-IP verwendet. Infrastruktur-VMs und -Dienste erfordern weiterhin statische IPs. Dies bedeutet, dass der Adressbereich des Verwaltungs-IP-Pools vom DHCP-Bereich ausgeschlossen werden muss, der für die Knoten und die Cluster-IP verwendet wird.

Wenn der IP-Verwaltungsbereich beispielsweise als 192.168.1.20/24 bis 192.168.1.30/24 für die statischen IP-Adressen der Infrastruktur definiert ist, muss der für Subnetz 192.168.1.0/24 definierte DHCP-Bereich einen Ausschluss aufweisen, der dem Verwaltungs-IP-Pool entspricht, um IP-Konflikte mit den Infrastrukturdiensten zu vermeiden. Außerdem wird empfohlen, DHCP-Reservierungen für Knoten-IPs zu verwenden.

Der Prozess der Definition der Verwaltungs-IP nach dem Erstellen der Verwaltungsabsicht umfasst die Verwendung der MAC-Adresse des ersten physischen Netzwerkadapters, der für die Netzwerkabsicht ausgewählt ist. Diese MAC-Adresse wird dann dem virtuellen Netzwerkadapter zugewiesen, der für Verwaltungszwecke erstellt wird. Dies bedeutet, dass die IP-Adresse, die der erste physische Netzwerkadapter vom DHCP-Server abruft, 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 während der Cloudbereitstellung verwendete Netzwerküberprüfungslogik schlägt fehl, wenn mehrere physische Netzwerkschnittstellen erkannt werden, die über ein Standardgateway in ihrer Konfiguration verfügen. Wenn Sie DHCP für Ihre Host-IP-Zuweisungen verwenden müssen, müssen Sie den virtuellen SET-Switch (switch embedded teaming) und den virtuellen Verwaltungsnetzwerkadapter wie oben beschrieben erstellen, sodass nur der virtuelle Netzwerkadapter für die Verwaltung eine IP-Adresse vom DHCP-Server erwirbt.

Überlegungen zur Ip-Adresse des Clusterknotens

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

#	Überlegungen
1	Knoten-IPs müssen sich im selben Subnetz des definierten 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 dynamische IP-Zuweisung verwendet wird.
3	Verwenden Sie DHCP-Reservierungen für die Knoten so weit wie möglich.
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 virtuellen Verwaltungsnetzwerkadapter zugewiesen, sobald die Absicht des Verwaltungsnetzwerks erstellt wurde.

Proxyanforderungen

Ein Proxy ist wahrscheinlich erforderlich, um innerhalb Ihrer lokalen Infrastruktur auf das Internet zuzugreifen. Azure Local unterstützt nur nicht authentifizierte Proxykonfigurationen. Da der Internetzugriff erforderlich ist, um die Knoten in Azure Arc zu registrieren, muss die Proxykonfiguration als Teil der Betriebssystemkonfiguration festgelegt werden, bevor 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 Proxykonfiguration erfordern, um sicherzustellen, dass alle Betriebssystemkomponenten auf das Internet zugreifen können. Die gleiche Proxykonfiguration, die für die Knoten verwendet wird, wird automatisch an die VM "Arc Resource Bridge" und "AKS" übertragen, um sicherzustellen, dass sie während der Bereitstellung über 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 Proxykonfiguration von Arc Resource Bridge VM und AKS erfolgt automatisch vom Orchestrator während der Bereitstellung.
5	Nur die nicht authentifizierten Proxys werden unterstützt.

Firewallanforderungen

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

Die Firewallkonfiguration muss vor dem Registrieren der Knoten in Azure Arc erfolgen. Sie können die eigenständige Version der Umgebungsprüfung verwenden, um zu überprüfen, ob Ihre Firewalls keinen Datenverkehr blockieren, der an diese Endpunkte gesendet wird. Weitere Informationen finden Sie unter Azure Local Environment Checker zur Bewertung der Bereitstellungsbereitschaft für Azure Local.

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

#	Aspekt
1	Die Firewallkonfiguration muss ausgeführt werden, bevor die Knoten in Azure Arc registriert werden.
2	Die Umgebungsprüfung im eigenständigen Modus kann verwendet werden, um die Firewallkonfiguration zu überprüfen.

Schritt 5: Ermitteln der Netzwerkadapterkonfiguration

Netzwerkadapter werden durch den Netzwerkdatenverkehr (Verwaltung, Compute und Speicher) qualifiziert, mit dem sie verwendet werden. Während Sie den Windows Server-Katalog überprüfen, gibt die Windows Server 2022-Zertifizierung an, für welchen Netzwerkdatenverkehr die Adapter qualifiziert sind.

Bevor Sie einen Computer für Azure Local erwerben, müssen Sie über mindestens einen Adapter verfügen, der für die Verwaltung, Berechnung und Speicherung qualifiziert ist, da alle drei Datenverkehrstypen in Azure Local erforderlich sind. Die Cloudbereitstellung basiert auf Netzwerk-ATC, um die Netzwerkadapter für die entsprechenden Datenverkehrstypen zu konfigurieren, daher ist es wichtig, unterstützte Netzwerkadapter zu verwenden.

Die von Network ATC verwendeten Standardwerte werden in den Clusternetzwerkeinstellungen dokumentiert. Es wird empfohlen, die Standardwerte zu verwenden. In diesem Beispiel können die folgenden Optionen bei Bedarf mit Azure-Portal- oder Ressourcen-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: Legen Sie diesen Wert auf "false" fest, wenn Sie RDMA für Ihre Netzwerkadapter deaktivieren möchten.
• Network Direct Technology: Legen Sie diesen Wert auf RoCEv2 oder iWarp.
• Datenverkehrsprioritäten Datacenter Bridging (DCB):Legen Sie die Prioritäten fest, die Ihren Anforderungen entsprechen. Es wird dringend empfohlen, die Standard-DCB-Werte zu verwenden, da diese von Microsoft und Kunden überprüft werden.

Hier sind die zusammengefassten Überlegungen zur Netzwerkadapterkonfiguration:

#	Aspekt
1	Verwenden Sie die Standardkonfigurationen so weit wie möglich.
2	Physische Switches müssen gemäß der Netzwerkadapterkonfiguration konfiguriert werden. Siehe physische Netzwerkanforderungen für Azure Local.
3	Stellen Sie sicher, dass Ihre Netzwerkadapter für Azure Local unter Verwendung des Windows Server-Katalogs unterstützt werden.
4	Bei der Annahme der Standardwerte konfiguriert Network ATC automatisch die IPs und VLANs des Speichernetzwerkadapters. Dies wird als automatische Speicher-IP-Konfiguration bezeichnet. In einigen Fällen wird die automatische Speicher-IP nicht unterstützt, und Sie müssen jede IP-Adresse des Speichernetzwerkadapters mithilfe von Ressourcen-Manager-Vorlagen deklarieren.

Nächste Schritte

• Informationen zur Lokalen Azure-Bereitstellung, Version 23H2.