Netwerkoverwegingen voor cloudimplementaties van Azure Stack HCI, versie 23H2

Van toepassing op: Azure Stack HCI, versie 23H2

In dit artikel wordt beschreven hoe u een Azure Stack HCI,versie 23H2-systeemnetwerk voor cloudimplementatie ontwerpt en plant. Voordat u verdergaat, moet u vertrouwd raken met de verschillende Azure Stack HCI-netwerkpatronen en beschikbare configuraties.

Netwerkontwerpframework

In het volgende diagram ziet u de verschillende beslissingen en stappen die het netwerkontwerpframework voor uw Azure Stack HCI-systeem definiëren: clustergrootte, clusteropslagconnectiviteit, netwerkverkeersintenties, beheerconnectiviteit en configuratie van netwerkadapters. Met elke ontwerpbeslissing worden de ontwerpopties die in de volgende stappen beschikbaar zijn, ingeschakeld of toegeslagen:

Stap 1: De clustergrootte bepalen

Als u de grootte van uw Azure Stack HCI-systeem wilt bepalen, gebruikt u het hulpprogramma Azure Stack HCI-grootte, waar u uw profiel kunt definiëren, zoals het aantal virtuele machines (VM's), de grootte van de VM's en het workloadgebruik van de VM's, zoals Azure Virtual Desktop, SQL Server of AKS.

Zoals beschreven in het artikel Systeemserververeisten voor Azure Stack HCI, is het maximum aantal servers dat wordt ondersteund op het Azure Stack HCI-systeem 16. Zodra u de planning van de workloadcapaciteit hebt voltooid, moet u een goed begrip hebben van het aantal serverknooppunten dat nodig is om workloads op uw infrastructuur uit te voeren.

• Als voor uw workloads vier of meer knooppunten nodig zijn: u kunt geen switchloze configuratie implementeren en gebruiken voor opslagnetwerkverkeer. U moet een fysieke switch opnemen met ondersteuning voor Remote Direct Memory Access (RDMA) om opslagverkeer te verwerken. Zie Overzicht van netwerkreferentiepatronen voor meer informatie over de netwerkarchitectuur van Azure Stack HCI-clusters.

• Als voor uw workloads drie of minder knooppunten nodig zijn: u kunt switchless of geschakelde configuraties kiezen voor opslagconnectiviteit.

• Als u van plan bent om later uit te schalen naar meer dan drie knooppunten: u moet een fysieke switch gebruiken voor opslagnetwerkverkeer. Elke uitschaalbewerking voor implementaties zonder schakelen vereist handmatige configuratie van uw netwerkkabels tussen de knooppunten die Microsoft niet actief valideert als onderdeel van de softwareontwikkelingscyclus voor Azure Stack HCI.

Hier volgen de samengevatte overwegingen voor de beslissing over de clustergrootte:

Besluit	Overweging
Clustergrootte (aantal knooppunten per cluster)	Configuratie zonder schakelen via de Azure Portal- of Azure Resource Manager-sjablonen is alleen beschikbaar voor clusters met 1, 2 of 3 knooppunten. Clusters met 4 of meer knooppunten vereisen een fysieke switch voor het netwerkverkeer van de opslag.
Vereisten voor uitschalen	Als u van plan bent om uw cluster uit te schalen met behulp van de orchestrator, moet u een fysieke switch gebruiken voor het opslagnetwerkverkeer.

Stap 2: Connectiviteit van clusteropslag bepalen

Zoals beschreven in Vereisten voor fysieke netwerken, ondersteunt Azure Stack HCI twee typen connectiviteit voor opslagnetwerkverkeer:

• Gebruik een fysieke netwerkswitch om het verkeer af te handelen.
• Verbind de knooppunten ertussen rechtstreeks met crossover-netwerk- of glasvezelkabels voor het opslagverkeer.

De voor- en nadelen van elke optie worden beschreven in het bovenstaande artikel.

Zoals eerder vermeld, kunt u alleen kiezen tussen de twee opties wanneer de grootte van uw cluster drie of minder knooppunten is. Elk cluster met vier of meer knooppunten wordt automatisch geïmplementeerd met behulp van een netwerkswitch voor opslag.

Als clusters minder dan drie knooppunten hebben, is de beslissing over opslagconnectiviteit van invloed op het aantal en het type netwerkintenties dat u in de volgende stap kunt definiëren.

Voor configuraties zonder schakeloptie moet u bijvoorbeeld twee intenties voor netwerkverkeer definiëren. Opslagverkeer voor oost-west-communicatie met behulp van de cross-over-kabels heeft geen noord-zuid-connectiviteit en is volledig geïsoleerd van de rest van uw netwerkinfrastructuur. Dit betekent dat u een tweede netwerkintentie moet definiëren voor het beheer van uitgaande connectiviteit en voor uw rekenworkloads.

Hoewel het mogelijk is om elke netwerkintentie te definiëren met slechts één fysieke netwerkadapterpoort, biedt dat geen fouttolerantie. Daarom raden we altijd aan ten minste twee fysieke netwerkpoorten te gebruiken voor elke netwerkintentie. Als u besluit om een netwerkswitch te gebruiken voor opslag, kunt u al het netwerkverkeer groepeer, inclusief opslag in één netwerkintentie, die ook wel een hypergeconvergeerde of volledig geconvergeerde hostnetwerkconfiguratie wordt genoemd.

Hier volgen de samengevatte overwegingen voor de beslissing over de connectiviteit van clusteropslag:

Besluit	Overweging
Geen switch voor opslag	Configuratie zonder schakelen via Azure Portal of Resource Manager sjabloonimplementatie wordt alleen ondersteund voor clusters met 1, 2 of 3 knooppunten. Opslagswitchloze clusters met 1 of 2 knooppunten kunnen worden geïmplementeerd met behulp van de Azure Portal- of Resource Manager-sjablonen. Opslagswitchloze clusters met 3 knooppunten kunnen alleen worden geïmplementeerd met behulp van Resource Manager-sjablonen. Uitschaalbewerkingen worden niet ondersteund met de implementaties zonder schakeloptie. Elke wijziging in het aantal knooppunten na de implementatie vereist een handmatige configuratie. Er zijn ten minste 2 netwerkintenties vereist bij het gebruik van een switchless-opslagconfiguratie.
Netwerkswitch voor opslag	Als u van plan bent om uw cluster uit te schalen met behulp van de orchestrator, moet u een fysieke switch gebruiken voor het opslagnetwerkverkeer. U kunt deze architectuur gebruiken met een willekeurig aantal knooppunten tussen 1 en 16. Hoewel niet wordt afgedwongen, kunt u één intentie gebruiken voor al uw netwerkverkeerstypen (Beheer, Compute en Opslag)

In het volgende diagram ziet u een overzicht van de opslagconnectiviteitsopties die voor verschillende implementaties beschikbaar zijn:

Stap 3: Intenties voor netwerkverkeer bepalen

Voor Azure Stack HCI zijn alle implementaties afhankelijk van Network ATC voor de configuratie van het hostnetwerk. De netwerkintenties worden automatisch geconfigureerd bij het implementeren van Azure Stack HCI via de Azure Portal. Zie Algemene ATC-opdrachten voor netwerken voor meer informatie over de netwerkintenties en het oplossen hiervan.

In deze sectie wordt uitgelegd wat de gevolgen zijn van uw ontwerpbeslissing voor de intenties van netwerkverkeer en hoe deze van invloed zijn op de volgende stap van het framework. Voor cloudimplementaties kunt u kiezen uit vier opties om uw netwerkverkeer te groepeert in een of meer intenties. De beschikbare opties zijn afhankelijk van het aantal knooppunten in uw cluster en het gebruikte type opslagconnectiviteit.

De beschikbare opties voor netwerkintentie worden besproken in de volgende secties.

Netwerkintentie: al het verkeer groepeer

Netwerk-ATC configureert een unieke intentie die beheer-, reken- en opslagnetwerkverkeer omvat. De netwerkadapters die aan deze intentie zijn toegewezen, delen bandbreedte en doorvoer voor al het netwerkverkeer.

• Voor deze optie is een fysieke switch vereist voor opslagverkeer. Als u een architectuur zonder schakeloptie nodig hebt, kunt u dit type intentie niet gebruiken. Azure Portal filtert deze optie automatisch uit als u een switchless-configuratie voor opslagconnectiviteit selecteert.

• Ten minste twee netwerkadapterpoorten worden aanbevolen om hoge beschikbaarheid te garanderen.

• Er zijn ten minste 10 Gbps-netwerkinterfaces vereist om RDMA-verkeer voor opslag te ondersteunen.

Netwerkintentie: groepsbeheer en rekenverkeer

Netwerk-ATC configureert twee intenties. De eerste intentie omvat beheer- en rekennetwerkverkeer, en de tweede intentie omvat alleen opslagnetwerkverkeer. Elke intentie moet een andere set netwerkadapterpoorten hebben.

U kunt deze optie gebruiken voor zowel geschakelde als switchloze opslagconnectiviteit als:

• Er zijn ten minste twee netwerkadapterpoorten beschikbaar voor elke intentie om hoge beschikbaarheid te garanderen.

• Een fysieke switch wordt gebruikt voor RDMA als u de netwerkswitch gebruikt voor opslag.

• Er zijn ten minste 10 Gbps-netwerkinterfaces vereist om RDMA-verkeer voor opslag te ondersteunen.

Netwerkintentie: reken- en opslagverkeer groep

Netwerk-ATC configureert twee intenties. De eerste intentie omvat reken- en opslagnetwerkverkeer en de tweede intentie omvat alleen netwerkverkeer voor beheer. Elke intentie moet een andere set netwerkadapterpoorten gebruiken.

• Voor deze optie is een fysieke switch vereist voor opslagverkeer, omdat dezelfde poorten worden gedeeld met rekenverkeer, waarvoor noord-zuid-communicatie is vereist. Als u een configuratie zonder schakeloptie nodig hebt, kunt u dit type intentie niet gebruiken. Azure Portal filtert deze optie automatisch uit als u een switchless-configuratie voor opslagconnectiviteit selecteert.

• Voor deze optie is een fysieke switch vereist voor RDMA.

• Ten minste twee netwerkadapterpoorten worden aanbevolen om hoge beschikbaarheid te garanderen.

• Ten minste 10 Gbps netwerkinterfaces worden aanbevolen voor de reken- en opslagintentie ter ondersteuning van RDMA-verkeer.

• Zelfs wanneer de beheerintentie wordt gedeclareerd zonder een rekenintentie, maakt Network ATC een virtuele switch Switch Embedded Teaming (SET) om hoge beschikbaarheid voor het beheernetwerk te bieden.

Netwerkintentie: aangepaste configuratie

Definieer maximaal drie intenties met behulp van uw eigen configuratie, zolang ten minste één van de intenties beheerverkeer bevat. We raden u aan deze optie te gebruiken wanneer u een tweede rekenintentie nodig hebt. Scenario's voor deze tweede rekenintentievereiste zijn onder andere verkeer van externe opslag, back-upverkeer van VM's of een afzonderlijke rekenintentie voor verschillende typen workloads.

• Gebruik deze optie voor zowel geschakelde als switchloze opslagconnectiviteit als de opslagintentie verschilt van de andere intenties.

• Gebruik deze optie wanneer een andere rekenintentie vereist is of wanneer u de verschillende typen verkeer volledig wilt scheiden via verschillende netwerkadapters.

• Gebruik ten minste twee netwerkadapterpoorten voor elke intentie om hoge beschikbaarheid te garanderen.

• Ten minste 10 Gbps-netwerkinterfaces worden aanbevolen voor de reken- en opslagintentie ter ondersteuning van RDMA-verkeer.

Het volgende diagram bevat een overzicht van de opties voor netwerkintentie die voor u beschikbaar zijn voor verschillende implementaties:

Stap 4: Beheernetwerkconnectiviteit bepalen

In deze stap definieert u de adresruimte van het subnet van de infrastructuur, hoe deze adressen worden toegewezen aan uw cluster en of er een proxy- of VLAN-id vereist is voor de knooppunten voor uitgaande connectiviteit met internet en andere intranetservices, zoals Domain Name System (DNS) of Active Directory Services.

De volgende onderdelen van het infrastructuursubnet moeten worden gepland en gedefinieerd voordat u begint met de implementatie, zodat u kunt anticiperen op eventuele vereisten voor routering, firewall of subnet.

Stuurprogramma's voor netwerkadapters

Zodra u het besturingssysteem hebt geïnstalleerd en voordat u netwerken configureert op uw knooppunten, moet u ervoor zorgen dat uw netwerkadapters het meest recente stuurprogramma hebben dat wordt geleverd door uw OEM- of netwerkinterfaceleverancier. Belangrijke mogelijkheden van de netwerkadapters komen mogelijk niet naar boven wanneer u de standaardstuurprogramma's van Microsoft gebruikt.

IP-adresgroep voor beheer

Wanneer u de eerste implementatie van uw Azure Stack HCI-systeem uitvoert, moet u een IP-bereik van opeenvolgende IP-adressen definiëren voor infrastructuurservices die standaard zijn geïmplementeerd.

Om ervoor te zorgen dat het bereik voldoende IP-adressen heeft voor huidige en toekomstige infrastructuurservices, moet u een bereik van ten minste zes opeenvolgende beschikbare IP-adressen gebruiken. Deze adressen worden gebruikt voor: het IP-adres van het cluster, de Azure Resource Bridge-VM en de bijbehorende onderdelen.

Als u verwacht andere services in het infrastructuurnetwerk uit te voeren, raden we u aan een extra buffer van infrastructuur-IP-adressen toe te wijzen aan de pool. Het is mogelijk om andere IP-groepen toe te voegen na de implementatie voor het infrastructuurnetwerk met behulp van PowerShell als de grootte van de groep die u oorspronkelijk had gepland, uitgeput raakt.

Tijdens de implementatie moet aan de volgende voorwaarden worden voldaan wanneer u uw IP-adresgroep voor het subnet van de infrastructuur definieert:

#	Voorwaarde
1	Het IP-bereik moet opeenvolgende IP-adressen gebruiken en alle IP-adressen moeten binnen dat bereik beschikbaar zijn. Dit IP-bereik kan niet worden gewijzigd na de implementatie.
2	Het bereik van IP-adressen mag niet de IP-adressen van het clusterknooppuntbeheer bevatten, maar moet zich in hetzelfde subnet bevinden als uw knooppunten.
3	De standaardgateway die is gedefinieerd voor de beheer-IP-groep moet uitgaande connectiviteit met internet bieden.
4	De DNS-servers moeten naamomzetting met Active Directory en internet garanderen.
5	Voor de beheer-IP-adressen is uitgaande internettoegang vereist.

Beheer-VLAN-id

We raden u aan dat het beheersubnet van uw Azure HCI-cluster het standaard-VLAN gebruikt, dat in de meeste gevallen wordt gedeclareerd als VLAN-id 0. Als uw netwerkvereisten echter een specifiek beheer-VLAN voor uw infrastructuurnetwerk moeten gebruiken, moet dit worden geconfigureerd op uw fysieke netwerkadapters die u wilt gebruiken voor het beheer van verkeer.

Als u van plan bent om twee fysieke netwerkadapters te gebruiken voor beheer, moet u het VLAN op beide adapters instellen. Dit moet worden gedaan als onderdeel van de bootstrapconfiguratie van uw servers en voordat ze worden geregistreerd bij Azure Arc, om ervoor te zorgen dat u de knooppunten met behulp van dit VLAN kunt registreren.

Als u de VLAN-id op de fysieke netwerkadapters wilt instellen, gebruikt u de volgende PowerShell-opdracht:

In dit voorbeeld wordt VLAN-id 44 op fysieke netwerkadapter NIC1geconfigureerd.

Set-NetAdapter -Name "NIC1" -VlanID 44

Zodra de VLAN-id is ingesteld en de IP-adressen van uw knooppunten zijn geconfigureerd op de fysieke netwerkadapters, leest de orchestrator deze VLAN-id-waarde van de fysieke netwerkadapter die wordt gebruikt voor beheer en slaat deze op, zodat deze kan worden gebruikt voor de Azure Resource Bridge-VM of elke andere infrastructuur-VM die tijdens de implementatie is vereist. Het is niet mogelijk om de beheer-VLAN-id in te stellen tijdens de cloudimplementatie vanuit Azure Portal, omdat dit het risico met zich meebrengt dat de connectiviteit tussen de knooppunten en Azure wordt verbroken als de VLAN's van de fysieke switch niet correct worden gerouteerd.

Beheer-VLAN-id met een virtuele switch

In sommige scenario's is het nodig om een virtuele switch te maken voordat de implementatie wordt gestart.

Notitie

Voordat u een virtuele switch maakt, moet u de rol Hype-V inschakelen. Zie Vereiste Windows-rol installeren voor meer informatie.

Als een configuratie van een virtuele switch vereist is en u een specifieke VLAN-id moet gebruiken, voert u de volgende stappen uit:

1. Creatie virtuele switch met aanbevolen naamconventie

Azure Stack HCI-implementaties zijn afhankelijk van Network ATC voor het maken en configureren van de virtuele switches en virtuele netwerkadapters voor beheer-, reken- en opslagintenties. Wanneer Network ATC de virtuele switch voor de intenties maakt, wordt standaard een specifieke naam voor de virtuele switch gebruikt.

We raden u aan de namen van uw virtuele switch met dezelfde naamconventie te benoemen. De aanbevolen naam voor de virtuele switches is als volgt:

'ConvergedSwitch($IntentName)', waarbij $IntentName moet overeenkomen met de naam van de intentie die tijdens de implementatie in de portal is getypt. Deze tekenreeks moet ook overeenkomen met de naam van de virtuele netwerkadapter die wordt gebruikt voor beheer, zoals beschreven in de volgende stap.

In het volgende voorbeeld ziet u hoe u de virtuele switch maakt met PowerShell met behulp van de aanbevolen naamconventie met $IntentName. De lijst met namen van netwerkadapters is een lijst met de fysieke netwerkadapters die u wilt gebruiken voor het beheren en berekenen van netwerkverkeer:

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

2. Configureer de beheer-virtuele netwerkadapter met behulp van de vereiste naamgevingsconventie voor netwerk-ATC voor alle knooppunten

Zodra de virtuele switch is geconfigureerd, moet de beheer-virtuele netwerkadapter worden gemaakt. De naam van de virtuele netwerkadapter die wordt gebruikt voor beheerverkeer moet de volgende naamconventie gebruiken:

• Naam van de netwerkadapter en de virtuele netwerkadapter: vManagement($intentname).
• Naam is hoofdlettergevoelig.
• $Intentname kan een willekeurige tekenreeks zijn, maar moet dezelfde naam hebben die voor de virtuele switch wordt gebruikt.

Gebruik de volgende opdracht om de naam van de virtuele netwerkadapter voor beheer bij te werken:

$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. VLAN-id configureren om de virtuele netwerkadapter voor alle knooppunten te beheren

Zodra de virtuele switch en de beheer-virtuele netwerkadapter zijn gemaakt, kunt u de vereiste VLAN-id voor deze adapter opgeven. Hoewel er verschillende opties zijn om een VLAN-id toe te wijzen aan een virtuele netwerkadapter, is de enige ondersteunde optie het gebruik van de Set-VMNetworkAdapterIsolation opdracht.

Zodra de vereiste VLAN-id is geconfigureerd, kunt u het IP-adres en de gateways toewijzen aan de virtuele beheernetwerkadapter om te controleren of deze verbinding heeft met andere knooppunten, DNS, Active Directory en internet.

In het volgende voorbeeld ziet u hoe u de beheer-virtuele netwerkadapter configureert voor het gebruik van de VLAN-id 8 in plaats van de standaardinstelling:

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

4. Verwijst naar fysieke netwerkadapters voor de beheerintentie tijdens de implementatie

Hoewel de zojuist gemaakte virtuele netwerkadapter als beschikbaar wordt weergegeven bij de implementatie via Azure Portal, is het belangrijk om te onthouden dat de netwerkconfiguratie is gebaseerd op netwerk-ATC. Dit betekent dat we bij het configureren van het beheer, of de beheer- en rekenintentie, nog steeds de fysieke netwerkadapters moeten selecteren die voor die intentie worden gebruikt.

Notitie

Selecteer niet de virtuele netwerkadapter voor de netwerkintentie.

Dezelfde logica is van toepassing op de Azure Resource Manager-sjablonen. U moet de fysieke netwerkadapters opgeven die u wilt gebruiken voor de netwerkintenties en nooit de virtuele netwerkadapters.

Dit zijn de samengevatte overwegingen voor de VLAN-id:

#	Overwegingen
1	VLAN-id moet worden opgegeven op de fysieke netwerkadapter voor beheer voordat de servers worden geregistreerd bij Azure Arc.
2	Gebruik specifieke stappen wanneer een virtuele switch is vereist voordat u de servers registreert bij Azure Arc.
3	De beheer-VLAN-id wordt tijdens de implementatie overgedragen van de hostconfiguratie naar de infrastructuur-VM's.
4	Er is geen VLAN-id-invoerparameter voor Azure Portal implementatie of voor Resource Manager sjabloonimplementatie.

IP-toewijzing van knooppunt en cluster

Voor het Azure Stack HCI-systeem hebt u twee opties om IP-adressen toe te wijzen voor de serverknooppunten en voor het cluster-IP-adres.

• Zowel het statische als het DHCP-protocol (Dynamic Host Configuration Protocol) worden ondersteund.

• De juiste IP-toewijzing van knooppunten is essentieel voor het beheer van de levenscyclus van clusters. Kies tussen de statische en DHCP-opties voordat u de knooppunten registreert in Azure Arc.

• Infrastructuur-VM's en -services, zoals Arc Resource Bridge en Netwerkcontroller, blijven statische IP-adressen van de beheer-IP-groep gebruiken. Dit betekent dat zelfs als u dhcp wilt gebruiken om de IP-adressen toe te wijzen aan uw knooppunten en het IP-adres van het cluster, de beheer-IP-groep nog steeds vereist is.

In de volgende secties worden de gevolgen van elke optie besproken.

Statische IP-toewijzing

Als statische IP-adressen worden gebruikt voor de knooppunten, wordt de beheer-IP-groep gebruikt om een beschikbaar IP-adres te verkrijgen en dit automatisch toe te wijzen aan het ip-adres van het cluster tijdens de implementatie.

Het is belangrijk om beheer-IP-adressen te gebruiken voor de knooppunten die geen deel uitmaken van het IP-bereik dat is gedefinieerd voor de beheer-IP-groep. Ip-adressen van serverknooppunten moeten zich in hetzelfde subnet van het gedefinieerde IP-bereik bevinden.

U wordt aangeraden slechts één beheer-IP toe te wijzen voor de standaardgateway en voor de geconfigureerde DNS-servers voor alle fysieke netwerkadapters van het knooppunt. Dit zorgt ervoor dat het IP-adres niet verandert zodra de intentie van het beheernetwerk is gemaakt. Dit zorgt er ook voor dat de knooppunten hun uitgaande connectiviteit behouden tijdens het implementatieproces, ook tijdens de Azure Arc-registratie.

Om routeringsproblemen te voorkomen en om te bepalen welk IP-adres wordt gebruikt voor uitgaande connectiviteit en Arc-registratie, valideert Azure Portal of er meer dan één standaardgateway is geconfigureerd.

Als er een virtuele switch en een virtuele beheernetwerkadapter zijn gemaakt tijdens de configuratie van het besturingssysteem, moet het beheer-IP-adres voor het knooppunt worden toegewezen aan die virtuele netwerkadapter.

DHCP IP-toewijzing

Als IP-adressen voor de knooppunten worden verkregen van een DHCP-server, wordt ook een dynamisch IP-adres gebruikt voor het cluster-IP-adres. Voor infrastructuur-VM's en -services zijn nog steeds statische IP-adressen vereist. Dit betekent dat het adresbereik van de beheer-IP-groep moet worden uitgesloten van het DHCP-bereik dat wordt gebruikt voor de knooppunten en het cluster-IP-adres.

Als het ip-adresbereik voor beheer bijvoorbeeld is gedefinieerd als 192.168.1.20/24 tot en met 192.168.1.30/24 voor de statische IP-adressen van de infrastructuur, moet het DHCP-bereik dat is gedefinieerd voor subnet 192.168.1.0/24 een uitsluiting hebben die gelijk is aan de beheer-IP-groep om IP-conflicten met de infrastructuurservices te voorkomen. We raden u ook aan DHCP-reserveringen te gebruiken voor knooppunt-IP's.

Het definiëren van het beheer-IP-adres na het maken van de beheerintentie omvat het gebruik van het MAC-adres van de eerste fysieke netwerkadapter die is geselecteerd voor de netwerkintentie. Dit MAC-adres wordt vervolgens toegewezen aan de virtuele netwerkadapter die is gemaakt voor beheerdoeleinden. Dit betekent dat het IP-adres dat de eerste fysieke netwerkadapter van de DHCP-server verkrijgt, hetzelfde IP-adres is dat de virtuele netwerkadapter gebruikt als het beheer-IP-adres. Daarom is het belangrijk om DHCP-reservering te maken voor het IP-adres van het knooppunt.

Overwegingen voor HET IP-adres van clusterknooppunten

Hier volgen de samengevatte overwegingen voor de IP-adressen:

#	Overwegingen
1	Knooppunt-IP's moeten zich in hetzelfde subnet van het gedefinieerde IP-adresbereik van het beheer bevinden, ongeacht of het statische of dynamische adressen zijn.
2	De ip-adresgroep van het beheer mag geen knooppunt-IP's bevatten. Gebruik DHCP-uitsluitingen wanneer dynamische IP-toewijzing wordt gebruikt.
3	Gebruik zo veel mogelijk DHCP-reserveringen voor de knooppunten.
4	DHCP-adressen worden alleen ondersteund voor knooppunt-IP's en het cluster-IP-adres. Infrastructuurservices maken gebruik van statische IP-adressen uit de beheergroep.
5	Het MAC-adres van de eerste fysieke netwerkadapter wordt toegewezen aan de virtuele beheernetwerkadapter zodra de beheernetwerkintentie is gemaakt.

Proxyvereisten

Een proxy is waarschijnlijk vereist voor toegang tot internet binnen uw on-premises infrastructuur. Azure Stack HCI ondersteunt alleen niet-geverifieerde proxyconfiguraties. Aangezien internettoegang vereist is om de knooppunten in Azure Arc te registreren, moet de proxyconfiguratie worden ingesteld als onderdeel van de configuratie van het besturingssysteem voordat serverknooppunten worden geregistreerd. Zie Proxy-instellingen configureren voor meer informatie.

Het Azure Stack HCI-besturingssysteem heeft drie verschillende services (WinInet, WinHTTP en omgevingsvariabelen) die dezelfde proxyconfiguratie vereisen om ervoor te zorgen dat alle onderdelen van het besturingssysteem toegang hebben tot internet. Dezelfde proxyconfiguratie die voor de knooppunten wordt gebruikt, wordt automatisch overgedragen naar de Vm en AKS van Arc Resource Bridge, zodat ze tijdens de implementatie toegang hebben tot internet.

Dit zijn de samengevatte overwegingen voor proxyconfiguratie:

#	Overweging
1	Proxyconfiguratie moet worden voltooid voordat de knooppunten in Azure Arc worden geregistreerd.
2	Dezelfde proxyconfiguratie moet worden toegepast voor WinINET-, WinHTTP- en omgevingsvariabelen.
3	De omgevingscontrole zorgt ervoor dat de proxyconfiguratie consistent is voor alle proxyonderdelen.
4	Proxyconfiguratie van Arc Resource Bridge-VM en AKS wordt automatisch uitgevoerd door de orchestrator tijdens de implementatie.
5	Alleen de niet-geverifieerde proxy's worden ondersteund.

Firewallvereisten

U moet momenteel verschillende interneteindpunten in uw firewalls openen om ervoor te zorgen dat Azure Stack HCI en de bijbehorende onderdelen er verbinding mee kunnen maken. Zie Firewallvereisten voor een gedetailleerde lijst met de vereiste eindpunten.

Firewallconfiguratie moet worden uitgevoerd voordat de knooppunten in Azure Arc worden geregistreerd. U kunt de zelfstandige versie van de omgevingscontrole gebruiken om te controleren of uw firewalls geen verkeer blokkeren dat naar deze eindpunten wordt verzonden. Zie Azure Stack HCI Environment Checker voor meer informatie om de implementatiegereedheid voor Azure Stack HCI te beoordelen.

Dit zijn de samengevatte overwegingen voor firewalls:

#	Overweging
1	Firewallconfiguratie moet worden uitgevoerd voordat de knooppunten in Azure Arc worden geregistreerd.
2	Omgevingscontrole in de zelfstandige modus kan worden gebruikt om de firewallconfiguratie te valideren.

Stap 5: configuratie van netwerkadapter bepalen

Netwerkadapters worden gekwalificeerd op basis van het type netwerkverkeer (beheer, rekenkracht en opslag) waarmee ze worden gebruikt. Terwijl u de Windows Server-catalogus bekijkt, geeft de Windows Server 2022-certificering aan voor welk netwerkverkeer de adapters zijn gekwalificeerd.

Voordat u een server voor Azure Stack HCI aanschaft, moet u ten minste één adapter hebben die gekwalificeerd is voor beheer, berekening en opslag, omdat alle drie de verkeerstypen vereist zijn in Azure Stack HCI. Cloudimplementatie is afhankelijk van netwerk-ATC om de netwerkadapters te configureren voor de juiste verkeerstypen. Het is daarom belangrijk om ondersteunde netwerkadapters te gebruiken.

De standaardwaarden die door Network ATC worden gebruikt, worden beschreven in Clusternetwerkinstellingen. U wordt aangeraden de standaardwaarden te gebruiken. Dit gezegd hebbende, kunnen de volgende opties indien nodig worden overschreven met behulp van Azure Portal of Resource Manager sjablonen:

• VLAN's voor opslag: stel deze waarde in op de vereiste VLAN's voor opslag.
• Jumbo Pakketten: Definieert de grootte van de jumbo pakketten.
• Network Direct: stel deze waarde in op false als u RDMA wilt uitschakelen voor uw netwerkadapters.
• Network Direct Technology: stel deze waarde in op RoCEv2 of iWarp.
• Verkeersprioriteiten Datacenter Bridging (DCB): stel de prioriteiten in die aan uw vereisten voldoen. U wordt ten zeerste aangeraden de standaard DCB-waarden te gebruiken, omdat deze worden gevalideerd door Microsoft en klanten.

Hier volgen de samengevatte overwegingen voor de configuratie van de netwerkadapter:

#	Overweging
1	Gebruik de standaardconfiguraties zoveel mogelijk.
2	Fysieke switches moeten worden geconfigureerd volgens de configuratie van de netwerkadapter. Zie Vereisten voor fysieke netwerken voor Azure Stack HCI.
3	Zorg ervoor dat uw netwerkadapters worden ondersteund voor Azure Stack HCI met behulp van de Windows Server-catalogus.
4	Bij het accepteren van de standaardwaarden configureert Network ATC automatisch de IP's en VLAN's van de opslagnetwerkadapter. Dit staat bekend als Automatische IP-configuratie van Opslag. In sommige gevallen wordt automatisch IP-adres voor opslag niet ondersteund en moet u het IP-adres van elke opslagnetwerkadapter declareren met behulp van Resource Manager-sjablonen.

Volgende stappen

• Over Azure Stack HCI, versie 23H2-implementatie.