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

Artikel
03/14/2024

Gilt für: Azure Stack HCI, Version 23H2

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

Netzwerkentwurfsframework

Das folgende Diagramm zeigt die verschiedenen Entscheidungen und Schritte, die das Netzwerkentwurfsframework für Ihr Azure Stack HCI-System definieren: Clustergröße, Clusterspeicherkonnektivität, Absichten für Netzwerkdatenverkehr, Verwaltungskonnektivität und Netzwerkadapterkonfiguration. Jede Entwurfsentscheidung ermöglicht oder lässt die in den nachfolgenden Schritten verfügbaren Entwurfsoptionen zu:

Schritt 1: Bestimmen der Clustergröße

Um die Größe Ihres Azure Stack HCI-Systems zu bestimmen, verwenden Sie das Azure Stack HCI-Größentool, in dem Sie Ihr Profil definieren können, z. B. Anzahl der virtuellen Computer (VMs), Größe der VMs und Workloadnutzung der virtuellen Computer wie Azure Virtual Desktop, SQL Server oder AKS.

Wie im Artikel Azure Stack HCI-Systemserveranforderungen beschrieben, beträgt die maximale Anzahl von Servern, die im Azure Stack HCI-System unterstützt werden, 16. Nachdem Sie ihre Workloadkapazitätsplanung abgeschlossen haben, sollten Sie über ein gutes Verständnis der Anzahl von Serverknoten verfügen, die zum Ausführen von Workloads in Ihrer Infrastruktur erforderlich sind.

Wenn Ihre Workloads vier oder mehr Knoten erfordern: Sie können keine switchlose Konfiguration für den Speichernetzwerkdatenverkehr bereitstellen und verwenden. Sie müssen einen physischen Switch mit Unterstützung für remote direct memory access (RDMA) zur Verarbeitung des Speicherdatenverkehrs einschließen. Weitere Informationen zur Netzwerkarchitektur des Azure Stack HCI-Clusters finden Sie unter Übersicht über Netzwerkreferenzmuster.
Wenn Ihre Workloads drei oder weniger Knoten erfordern: Sie können entweder switchlose oder switched-Konfigurationen für die Speicherkonnektivität auswählen.
Wenn Sie planen, später auf mehr als drei Knoten hochzuskalieren: Sie müssen einen physischen Switch für den Speichernetzwerkdatenverkehr verwenden. Jeder Horizontalskalierungsvorgang für switchlose Bereitstellungen erfordert eine manuelle Konfiguration Ihrer Netzwerkverkabelung zwischen den Knoten, die Microsoft im Rahmen des Softwareentwicklungszyklus für Azure Stack HCI nicht aktiv überprüft.

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

Entscheidung	Aspekt
Clustergröße (Anzahl der Knoten pro Cluster)	Die switchlose Konfiguration über die Azure-Portal- oder ARM-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 Speichernetzwerkdatenverkehr.
Anforderungen für horizontales Hochskalieren	Wenn Sie ihren Cluster mithilfe des Orchestrators aufskalieren möchten, müssen Sie einen physischen Switch für den Speichernetzwerkdatenverkehr verwenden.

Schritt 2: Ermitteln der Clusterspeicherkonnektivität

Wie unter Anforderungen für physische Netzwerke beschrieben, unterstützt Azure Stack HCI zwei Arten von Konnektivität für Speichernetzwerkdatenverkehr:

Verwenden Sie einen physischen Netzwerkswitch, um den Datenverkehr zu verarbeiten.
Verbinden Sie die Knoten zwischen ihnen direkt 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 Ihres Clusters drei oder weniger Knoten beträgt. Jeder Cluster mit vier oder mehr Knoten wird automatisch mithilfe eines Netzwerkswitches für die Speicherung bereitgestellt.

Wenn Cluster über weniger als drei Knoten verfügen, beeinflusst die Entscheidung zur 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 beispielsweise zwei Absichten für Netzwerkdatenverkehr definieren. Der Speicherdatenverkehr für die Ost-West-Kommunikation über die Crossover-Kabel verfügt nicht über Eine Nord-Süd-Verbindung und ist vollständig von der restlichen Netzwerkinfrastruktur isoliert. Das 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 Speicher in einer einzelnen Netzwerkabsicht gruppieren, die auch als hyperkonvergente oder vollständig konvergente Hostnetzwerkkonfiguration bezeichnet wird.

Hier sind die zusammengefassten Überlegungen für die Entscheidung zur Clusterspeicherkonnektivität aufgeführt:

Entscheidung	Aspekt
Kein Switch für den Speicher	Die switchlose Konfiguration über Azure-Portal- oder ARM-Vorlagenbereitstellung wird nur für Cluster mit 1, 2 oder 3 Knoten unterstützt. Switchlose Speichercluster mit einem oder zwei Knoten können mithilfe der Azure-Portal- oder ARM-Vorlagen bereitgestellt werden. Switchlose Speichercluster mit drei Knoten können nur mithilfe von ARM-Vorlagen bereitgestellt werden. Horizontales Hochskalieren wird bei den switchlosen Bereitstellungen nicht unterstützt. Jede Änderung der Anzahl der Knoten nach der Bereitstellung erfordert eine manuelle Konfiguration. Bei Verwendung einer switchlosen Speicherkonfiguration sind mindestens zwei Netzwerkabsichten erforderlich.
Netzwerkswitch für Speicher	Wenn Sie ihren Cluster mithilfe des Orchestrators aufskalieren möchten, 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 eine einzelne Absicht für alle Netzwerkdatenverkehrtypen (Verwaltung, Compute und Speicher) verwenden.

Entscheidung

Aspekt

Kein Switch für den Speicher

Die switchlose Konfiguration über Azure-Portal- oder ARM-Vorlagenbereitstellung wird nur für Cluster mit 1, 2 oder 3 Knoten unterstützt.

Switchlose Speichercluster mit einem oder zwei Knoten können mithilfe der Azure-Portal- oder ARM-Vorlagen bereitgestellt werden.

Switchlose Speichercluster mit drei Knoten können nur mithilfe von ARM-Vorlagen bereitgestellt werden.

Horizontales Hochskalieren wird bei den switchlosen Bereitstellungen nicht unterstützt. Jede Änderung der Anzahl der Knoten nach der Bereitstellung erfordert eine manuelle Konfiguration.

Bei Verwendung einer switchlosen Speicherkonfiguration sind mindestens zwei Netzwerkabsichten erforderlich.

Netzwerkswitch für Speicher

Wenn Sie ihren Cluster mithilfe des Orchestrators aufskalieren möchten, 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 eine einzelne Absicht für alle Netzwerkdatenverkehrtypen (Verwaltung, Compute und Speicher) verwenden.

Im folgenden Diagramm sind die Optionen für die Speicherkonnektivität zusammengefasst, die Ihnen für verschiedene Bereitstellungen zur Verfügung stehen:

Schritt 3: Bestimmen der Absichten für Netzwerkdatenverkehr

Für Azure Stack HCI basieren alle Bereitstellungen auf Network ATC für die Hostnetzwerkkonfiguration. Die Netzwerkabsichten werden automatisch konfiguriert, wenn Azure Stack HCI über die Azure-Portal bereitgestellt wird. Weitere Informationen zu den Netzwerkabsichten und deren Problembehandlung finden Sie unter Allgemeine ATC-Befehle im Netzwerk.

In diesem Abschnitt werden die Auswirkungen Ihrer Entwurfsentscheidung auf Die Absichten des Netzwerkdatenverkehrs und deren Einfluss auf den nächsten Schritt des Frameworks erläutert. Bei Cloudbereitstellungen können Sie zwischen vier Optionen auswählen, um Ihren Netzwerkdatenverkehr in eine 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: Gruppierung des gesamten Datenverkehrs

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

Diese Option erfordert einen physischen Switch für den Speicherdatenverkehr. Wenn Sie eine switchlose Architektur benötigen, können Sie diese Art von Absicht nicht verwenden. Azure-Portal diese Option automatisch heraus, wenn Sie eine switchlose Konfiguration für die Speicherkonnektivität auswählen.
Es werden mindestens zwei Netzwerkadapterports empfohlen, um Hochverfügbarkeit sicherzustellen.
Mindestens 10 GBit/s-Netzwerkschnittstellen sind erforderlich, um RDMA-Datenverkehr für die Speicherung zu unterstützen.

Netzwerkabsicht: Gruppenverwaltung und Computedatenverkehr

Network ATC konfiguriert zwei Absichten. Die erste Absicht umfasst Verwaltung und Compute-Netzwerkdatenverkehr, und die zweite Absicht 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:

Für jede Absicht sind mindestens zwei Netzwerkadapterports verfügbar, um Hochverfügbarkeit zu gewährleisten.
Ein physischer Switch wird für RDMA verwendet, wenn Sie den Netzwerkswitch für die Speicherung verwenden.
Mindestens 10 GBit/s-Netzwerkschnittstellen sind erforderlich, um RDMA-Datenverkehr für die Speicherung zu unterstützen.

Netzwerkabsicht: Gruppierung von Compute- und Speicherdatenverkehr

Network ATC konfiguriert zwei Absichten. Die erste Absicht umfasst Compute- und Speichernetzwerkdatenverkehr, und die zweite Absicht umfasst nur Verwaltungsnetzwerkdatenverkehr. Jede Absicht muss einen anderen Satz von Netzwerkadapterports verwenden.

Diese Option erfordert einen physischen Switch für Den Speicherdatenverkehr, 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 diese Option automatisch heraus, wenn Sie eine switchlose Konfiguration für die Speicherkonnektivität auswählen.
Diese Option erfordert einen physischen Switch für RDMA.
Es werden mindestens zwei Netzwerkadapterports empfohlen, um Hochverfügbarkeit sicherzustellen.
Für die Compute- und Speicherabsicht zur Unterstützung von RDMA-Datenverkehr werden mindestens 10 GBit/s-Netzwerkschnittstellen empfohlen.
Selbst wenn die Verwaltungsabsicht ohne Computeabsicht deklariert wird, erstellt Network ATC einen virtuellen Switch (Switch Embedded Teaming, SET), um Hochverfügbarkeit für das Verwaltungsnetzwerk bereitzustellen.

Netzwerkabsicht: Benutzerdefinierte Konfiguration

Definieren Sie bis zu drei Absichten mit Ihrer eigenen Konfiguration, sofern mindestens eine der Absichten Verwaltungsdatenverkehr enthält. Es wird empfohlen, diese Option zu verwenden, wenn Sie eine zweite Computeabsicht benötigen. Szenarien für diese zweite Computeabsichtsanforderung umfassen Remotespeicherdatenverkehr, VMs-Sicherungsdatenverkehr oder eine separate Computeabsicht für unterschiedliche Arten von Workloads.

Verwenden Sie diese Option sowohl für switched als auch für switchless-Speicherkonnektivität, wenn sich die Speicherabsicht von den anderen Absichten unterscheidet.
Verwenden Sie diese Option, wenn eine andere Computeabsicht erforderlich ist oder wenn Sie die verschiedenen Arten von Datenverkehr über verschiedene Netzwerkadapter vollständig trennen möchten.
Verwenden Sie mindestens zwei Netzwerkadapterports für jede Absicht, um Hochverfügbarkeit sicherzustellen.
Es werden mindestens 10 GBit/s-Netzwerkschnittstellen für die Compute- und Speicherabsicht empfohlen, um RDMA-Datenverkehr zu unterstützen.

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

Schritt 4: Bestimmen der Netzwerkkonnektivität des Verwaltungsnetzwerks

In diesem Schritt definieren Sie den Adressraum des Infrastruktursubnetzes, 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 anderen Intranetdiensten 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

Nach der Installation des Betriebssystems und vor dem Konfigurieren 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 wurde. Wichtige Funktionen der Netzwerkadapter werden bei Verwendung der Microsoft-Standardtreiber möglicherweise nicht angezeigt.

Verwaltungs-IP-Pool

Bei der ersten Bereitstellung Ihres Azure Stack HCI-Systems müssen Sie einen IP-Bereich mit aufeinanderfolgenden IP-Adressen für standardmäßig bereitgestellte Infrastrukturdienste definieren.

Um sicherzustellen, dass der Bereich über genügend IP-Adressen 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-Adresse, die Azure Resource Bridge-VM und die zugehörigen Komponenten verwendet.

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

Beim Definieren Ihres IP-Pools für das Infrastruktursubnetz während der Bereitstellung müssen die folgenden Bedingungen erfüllt sein:

#	Bedingung
1	Der IP-Bereich muss aufeinanderfolgende IP-Adressen verwenden, und alle IP-Adressen müssen innerhalb dieses Bereichs verfügbar sein.
2	Der Bereich der IP-Adressen darf nicht die Clusterknoten-Verwaltungs-IPs enthalten, sondern muss sich im selben Subnetz wie Ihre Knoten befinden.
3	Das Standardgateway, das für den Verwaltungs-IP-Pool definiert ist, muss ausgehende Verbindungen mit dem Internet bereitstellen.
4	Die DNS-Server müssen die Namensauflösung mit Active Directory und dem Internet sicherstellen.

Verwaltungs-VLAN-ID

Es wird empfohlen, dass das Verwaltungssubnetz Ihres Azure HCI-Clusters das Standard-VLAN verwendet, das in den meisten Fällen als VLAN-ID 0 deklariert wird. Wenn Ihre Netzwerkanforderungen jedoch darin bestehen, ein bestimmtes Verwaltungs-VLAN für Ihr Infrastrukturnetzwerk zu verwenden, muss es auf Ihren physischen Netzwerkadaptern konfiguriert werden, die Sie für den Verwaltungsdatenverkehr verwenden möchten.

Wenn Sie planen, zwei physische Netzwerkadapter für die Verwaltung zu verwenden, müssen Sie das VLAN für beide Adapter festlegen. Dies muss im Rahmen der Bootstrap-Konfiguration Ihrer Server und vor der Registrierung bei Azure Arc erfolgen, um sicherzustellen, dass Sie die Knoten mit diesem VLAN 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 für den physischen Netzwerkadapter NIC1konfiguriert.

Set-NetAdapter -Name "NIC1" -VlanID 44

Sobald die VLAN-ID festgelegt und die IP-Adressen 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 Konnektivität zwischen den Knoten und Azure zu unterbrechen, wenn die VLANs des physischen Switches nicht ordnungsgemäß weitergeleitet werden.

Verwaltungs-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 die Rolle Hype-V aktivieren. Weitere Informationen finden Sie unter Installieren der erforderlichen Windows-Rolle.

Wenn eine Konfiguration des virtuellen Switches 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 Stack HCI-Bereitstellungen basieren auf Network ATC, um die virtuellen Switches und virtuellen Netzwerkadapter für Verwaltungs-, Compute- und Speicherabsichten zu erstellen und zu konfigurieren. Wenn Network ATC den virtuellen Switch für die Absichten erstellt, wird standardmäßig ein bestimmter Name für den virtuellen Switch verwendet.

Obwohl dies nicht erforderlich ist, wird empfohlen, Ihre virtuellen Switches mit der gleichen Benennungskonvention zu benennen. Der empfohlene Name für die virtuellen Switches lautet wie folgt:

Name des virtuellen Switches: "ConvergedSwitch($IntentName)", Wobei $IntentName eine beliebige Zeichenfolge sein kann. Diese Zeichenfolge sollte mit dem Namen des virtuellen Netzwerkadapters für die Verwaltung übereinstimmen, wie im nächsten Schritt beschrieben.

Im folgenden Beispiel wird gezeigt, wie Sie den virtuellen Switch mit PowerShell mithilfe der empfohlenen Benennungskonvention $IntentName erstellen und den Zweck des virtuellen Switches beschreiben. Die Liste der Netzwerkadapternamen ist eine Liste der physischen Netzwerkadapter, die Sie für die Verwaltung und Compute von Netzwerkdatenverkehr verwenden möchten:

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

2. Konfigurieren des Verwaltungsadapters für virtuelle Netzwerke mithilfe der erforderlichen Netzwerk-ATC-Benennungskonvention für alle Knoten

Nachdem der virtuelle Switch konfiguriert wurde, muss der Virtuelle Netzwerkadapter für die Verwaltung erstellt werden. Der Name des virtuellen Netzwerkadapters, der für den Verwaltungsdatenverkehr verwendet wird, muss die folgende Benennungskonvention verwenden:

Name des Netzwerkadapters und des virtuellen Netzwerkadapters: vManagement($intentname).
Bei Name wird die Groß-/Kleinschreibung beachtet.
$Intentname kann eine beliebige Zeichenfolge sein, muss aber derselbe Name sein, der für den virtuellen Switch verwendet wird.

Verwenden Sie den folgenden Befehl, um den Namen des Verwaltungsadapters für virtuelle Netzwerke zu aktualisieren:

$IntentName = "MgmtCompute"
Add-VMNetworkAdapter -ManagementOS -SwitchName "ConvergedSwitch($IntentName)" -Name "vManagement($IntentName)"

#NetAdapter needs to be renamed because during creation, Hyper-V adds the string “vEthernet “ to the beginning of the name

Rename-NetAdapter -Name "vEthernet (vManagement($IntentName))" -NewName "vManagement($IntentName)"

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. Es gibt zwar verschiedene Optionen zum Zuweisen einer VLAN-ID zu einem virtuellen Netzwerkadapter, aber die einzige unterstützte Option besteht darin, den Set-VMNetworkAdapterIsolation Befehl zu verwenden.

Nachdem die erforderliche VLAN-ID konfiguriert wurde, können Sie die IP-Adresse und Gateways dem Verwaltungs-VNET-Adapter zuweisen, um zu überprüfen, ob er über Konnektivität mit anderen Knoten, DNS, Active Directory und dem Internet verfügt.

Das folgende Beispiel zeigt, wie Sie den Verwaltungsadapter für virtuelle Netzwerke so konfigurieren, dass er VLAN-ID 8 anstelle des Standardwerts verwendet:

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

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, sich daran zu erinnern, dass die Netzwerkkonfiguration auf Netzwerk-ATC basiert. Dies bedeutet, dass beim Konfigurieren der Verwaltung oder der Verwaltungs- und Computeabsicht weiterhin die physischen Netzwerkadapter ausgewählt werden 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 (ARM). Sie müssen die physischen Netzwerkadapter angeben, die Sie für die Netzwerkabsichten und nie die virtuellen Netzwerkadapter verwenden möchten.

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

#	Überlegungen
1	Die VLAN-ID muss für die Verwaltung auf dem physischen Netzwerkadapter angegeben werden, bevor die Server bei Azure Arc registriert werden.
2	Führen Sie bestimmte Schritte aus, wenn ein virtueller Switch erforderlich ist, bevor Sie die Server 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 arm-Vorlagenbereitstellung.

Knoten- und Cluster-IP-Zuweisung

Für das Azure Stack HCI-System haben Sie zwei Optionen zum Zuweisen von IP-Adressen für die Serverknoten und die Cluster-IP.

Sowohl das statische als auch das DHCP-Protokoll (Dynamic Host Configuration Protocol) werden unterstützt.
Die richtige Knoten-IP-Zuweisung ist der Schlüssel für die Clusterlebenszyklusverwaltung. Entscheiden Sie sich 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 weiterhin statische IP-Adressen aus dem Verwaltungs-IP-Pool. Dies bedeutet, dass der Verwaltungs-IP-Pool weiterhin erforderlich ist, auch wenn Sie dhcp zum Zuweisen der IP-Adressen zu Ihren Knoten und Ihrer Cluster-IP-Adresse verwenden möchten.

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

Zuweisung statischer IPs

Wenn statische IP-Adressen für die Knoten verwendet werden, wird der Verwaltungs-IP-Pool verwendet, um eine verfügbare IP-Adresse abzurufen und während der Bereitstellung automatisch der Cluster-IP zuzuweisen.

Es ist wichtig, Verwaltungs-IP-Adressen für die Knoten zu verwenden, die nicht Teil des für den Verwaltungs-IP-Pool definierten IP-Bereichs sind. Serverknoten-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-Adresse nicht ändert, sobald die Verwaltungsnetzwerkabsicht erstellt wird. Dadurch wird auch sichergestellt, dass die Knoten während des Bereitstellungsprozesses, einschließlich der Azure Arc-Registrierung, ihre ausgehende Konnektivität beibehalten.

Um Routingprobleme zu vermeiden und zu ermitteln, welche IP-Adresse für ausgehende Konnektivität und Arc-Registrierung verwendet wird, überprüft Azure-Portal, ob mehrere Standardgateways konfiguriert sind.

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

DHCP-IP-Zuweisung

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

Wenn der Verwaltungs-IP-Bereich beispielsweise für die statischen IP-Adressen der Infrastruktur als 192.168.1.20/24 bis 192.168.1.30/24 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.

Beim Definieren der Verwaltungs-IP-Adresse nach dem Erstellen der Verwaltungsabsicht wird die MAC-Adresse des ersten physischen Netzwerkadapters verwendet, der für die Netzwerkabsicht ausgewählt ist. Diese MAC-Adresse wird dann dem virtuellen Netzwerkadapter zugewiesen, der zu Verwaltungszwecken 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, eine DHCP-Reservierung für die Knoten-IP zu erstellen.

Überlegungen zur Clusterknoten-IP

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

#	Überlegungen
1	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-IP-Adressen enthalten. Verwenden Sie DHCP-Ausschlüsse, wenn die dynamische IP-Zuweisung verwendet wird.
3	Verwenden Sie so weit 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 IP-Adressen aus dem Verwaltungspool.
5	Die MAC-Adresse des ersten physischen Netzwerkadapters wird dem virtuellen Verwaltungsnetzwerkadapter zugewiesen, sobald die Verwaltungsnetzwerkabsicht erstellt wurde.

Proxyanforderungen

Für den Zugriff auf das Internet in Ihrer lokalen Infrastruktur ist höchstwahrscheinlich ein Proxy erforderlich. Azure Stack HCI unterstützt nur nicht authentifizierte Proxykonfigurationen. Da internetzugriff erforderlich ist, um die Knoten in Azure Arc zu registrieren, muss die Proxykonfiguration als Teil der Betriebssystemkonfiguration festgelegt werden, bevor Serverknoten registriert werden. Weitere Informationen finden Sie unter Konfigurieren von Proxyeinstellungen.

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 auf die Arc Resource Bridge-VM und AKS übertragen, um sicherzustellen, dass diese während der Bereitstellung über Internetzugriff verfügen.

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

#	Aspekt
1	Die Proxykonfiguration muss abgeschlossen sein, 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 der Arc Resource Bridge-VM und AKS wird während der Bereitstellung automatisch vom Orchestrator durchgeführt.
5	Nur die nicht authentifizierten Proxys werden unterstützt.

Firewallanforderungen

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

Die Firewallkonfiguration muss vor der Registrierung der Knoten in Azure Arc erfolgen. Sie können die eigenständige Version der Umgebungsprüfung verwenden, um zu überprüfen, ob Ihre Firewalls den an diese Endpunkte gesendeten Datenverkehr nicht blockieren. Weitere Informationen finden Sie unter Azure Stack HCI Environment Checker zum Bewerten der Bereitstellungsbereitschaft für Azure Stack HCI.

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

#	Aspekt
1	Die Firewallkonfiguration muss vor der Registrierung der Knoten in Azure Arc erfolgen.
2	Die Umgebungsprüfung im eigenständigen Modus kann verwendet werden, um die Firewallkonfiguration zu überprüfen.

Schritt 5: Ermitteln der Netzwerkadapterkonfiguration

Netzwerkadapter werden anhand des Netzwerkdatenverkehrstyps (Verwaltung, Compute und Speicher) qualifiziert, mit dem sie verwendet werden. Wenn 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 Server für Azure Stack HCI erwerben, benötigen Sie mindestens einen Adapter, der für Verwaltung, Compute und Speicher qualifiziert ist, da alle drei Datenverkehrstypen in Azure Stack HCI erforderlich sind. Die Cloudbereitstellung basiert auf Network 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 sind unter Clusternetzwerkeinstellungen dokumentiert. Es wird empfohlen, die Standardwerte zu verwenden. Daher können die folgenden Optionen bei Bedarf mithilfe von Azure-Portal- oder ARM-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 Jumbopakete.
Direktes Netzwerk: Legen Sie diesen Wert auf false fest, wenn Sie RDMA für Ihre Netzwerkadapter deaktivieren möchten.
Network Direct-Technologie: Legen Sie diesen Wert auf oder iWarpfestRoCEv2.
Datenverkehrsprioritäten Datacenter Bridging (DCB): Legen Sie die Prioritäten fest, die Ihren Anforderungen entsprechen. Es wird dringend empfohlen, die DCB-Standardwerte zu verwenden, da diese von Microsoft und Kunden überprüft werden.

Dies sind die zusammengefassten Überlegungen zur Konfiguration des Netzwerkadapters:

#	Aspekt
1	Verwenden Sie die Standardkonfigurationen so weit wie möglich.
2	Physische Switches müssen gemäß der Netzwerkadapterkonfiguration konfiguriert werden. Weitere Informationen finden Sie unter Physische Netzwerkanforderungen für Azure Stack HCI.
3	Stellen Sie sicher, dass Ihre Netzwerkadapter für Azure Stack HCI mithilfe des Windows Server-Katalogs 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 die automatische Speicher-IP-Adresse nicht unterstützt, und Sie müssen jede Ip-Adresse des Speichernetzwerkadapters mithilfe von ARM-Vorlagen deklarieren.

Nächste Schritte

Informationen zu Azure Stack HCI, Version 23H2-Bereitstellung.