Netwerkoverwegingen voor cloudimplementaties van Azure Local, versie 23H2

Van toepassing op: Azure Local, versie 23H2

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

Framework voor netwerkontwerp

In het volgende diagram ziet u de verschillende beslissingen en stappen die het framework voor netwerkontwerp definiëren voor uw lokale Azure-instantie: clustergrootte, clusteropslagconnectiviteit, intenties voor netwerkverkeer, beheerconnectiviteit en configuratie van netwerkadapters. Bij elke ontwerpbeslissing kunt u de ontwerpopties in de volgende stappen in- of toestaan:

Stap 1: Clustergrootte bepalen

Als u de grootte van uw Lokale Azure-exemplaar wilt bepalen, gebruikt u het hulpprogramma Azure Local sizer, 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 met vereisten voor lokale systeemcomputers van Azure, is het maximum aantal machines dat wordt ondersteund in het lokale Azure-exemplaar 16. Zodra u de capaciteitsplanning van uw workload hebt voltooid, moet u een goed beeld hebben van het aantal computerknooppunten dat nodig is om workloads uit te voeren op uw infrastructuur.

• Als uw workloads vier of meer knooppunten vereisen: 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 het overzicht van netwerkpatronen voor netwerkreferentiepatronen in Azure Local Instance voor meer informatie over de netwerkarchitectuur.

• Als uw workloads drie of minder knooppunten nodig hebben: u kunt switchloze of switchconfiguraties 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 switchloze implementaties vereist handmatige configuratie van uw netwerkbekabeling tussen de knooppunten die Microsoft niet actief valideert als onderdeel van de softwareontwikkelingscyclus voor Azure Local.

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

Beslissing	Overweging
Clustergrootte (aantal knooppunten per cluster)	Switchless configuratie via Azure Portal of Azure Resource Manager-sjablonen is alleen beschikbaar voor clusters met 1, 2 of 3 knooppunten. Voor clusters met 4 of meer knooppunten is een fysieke switch vereist 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 fysieke netwerkvereisten, ondersteunt Azure Local twee typen connectiviteit voor opslagnetwerkverkeer:

• Gebruik een fysieke netwerkswitch om het verkeer te verwerken.
• Verbind de knooppunten er rechtstreeks tussen 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, heeft de beslissing tot opslagconnectiviteit invloed op het aantal en het type netwerkintentie dat u in de volgende stap kunt definiëren.

Voor switchloze configuraties moet u bijvoorbeeld twee netwerkverkeersintenties definiëren. Opslagverkeer voor oost-west-communicatie met behulp van de cross-overkabels 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 met slechts één fysieke netwerkadapterpoort elk te definiëren, biedt dat geen fouttolerantie. Daarom raden we u altijd aan ten minste twee fysieke netwerkpoorten te gebruiken voor elke netwerkintentie. Als u besluit een netwerkswitch voor opslag te gebruiken, kunt u al het netwerkverkeer groeperen, inclusief opslag in één netwerkintentie, dat ook wel een hypergeconvergeerde of volledig geconvergeerde hostnetwerkconfiguratie wordt genoemd.

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

Beslissing	Overweging
Geen switch voor opslag	Switchless configuratie via Azure Portal of Resource Manager-sjabloonimplementatie wordt alleen ondersteund voor clusters met 1, 2 of 3 knooppunten. 1 of 2 knooppuntopslagclusters kunnen worden geïmplementeerd met behulp van Azure Portal of Resource Manager-sjablonen. 3 knooppunt opslag switchless clusters kunnen alleen worden geïmplementeerd met behulp van Resource Manager-sjablonen. Uitschalen wordt niet ondersteund met de switchloze implementaties. 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 switchloze 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 dit 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 beschikbaar zijn voor verschillende implementaties:

Stap 3: Intenties voor netwerkverkeer bepalen

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

In deze sectie worden de gevolgen van uw ontwerpbeslissing voor netwerkverkeersintenties uitgelegd en hoe deze van invloed zijn op de volgende stap van het framework. Voor cloudimplementaties kunt u kiezen tussen vier opties om uw netwerkverkeer te groeperen 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 groeperen

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 switchloze architectuur nodig hebt, kunt u dit type intentie niet gebruiken. Azure Portal filtert deze optie automatisch uit als u een switchloze 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 overgeschakelde 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 voor opslag gebruikt.

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

Netwerkintentie: Reken- en opslagverkeer groeperen

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

• Voor deze optie is een fysieke switch vereist voor opslagverkeer als dezelfde poorten worden gedeeld met rekenverkeer, waarvoor noord-zuidcommunicatie is vereist. Als u een switchloze configuratie nodig hebt, kunt u dit type intentie niet gebruiken. Azure Portal filtert deze optie automatisch uit als u een switchloze 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 rekenintentie, maakt Network ATC een virtuele Switch Embedded Teaming -switch (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 omvat. U wordt aangeraden deze optie te gebruiken wanneer u een tweede rekenintentie nodig hebt. Scenario's voor deze tweede rekenintentievereiste omvatten extern opslagverkeer, back-upverkeer van VM's of een afzonderlijke rekenintentie voor verschillende typen workloads.

• Gebruik deze optie voor zowel overgeschakelde 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.

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

Stap 4: De netwerkverbinding voor beheer en opslag bepalen

In deze stap definieert u de adresruimte van het infrastructuursubnet, hoe deze adressen worden toegewezen aan uw cluster en of er een proxy- of VLAN-id-vereiste 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 de implementatie start, zodat u kunt anticiperen op eventuele routerings-, firewall- of subnetvereisten.

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 beschikken over het meest recente stuurprogramma van uw OEM- of netwerkinterfaceleverancier. Belangrijke mogelijkheden van de netwerkadapters komen mogelijk niet voor wanneer u de standaardstuurprogramma's van Microsoft gebruikt.

IP-adresgroep voor beheer

Wanneer u de eerste implementatie van uw Lokale Azure-exemplaar 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 dat er andere services in het infrastructuurnetwerk worden uitgevoerd, raden we u aan een extra buffer van IP-adressen van infrastructuur toe te wijzen aan de pool. Het is mogelijk om andere IP-adresgroepen toe te voegen na de implementatie voor het infrastructuurnetwerk met behulp van PowerShell als de grootte van de groep die u oorspronkelijk hebt gepland, uitgeput raakt.

Aan de volgende voorwaarden moet worden voldaan bij het definiëren van uw IP-pool voor het infrastructuursubnet tijdens de implementatie:

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

VLAN-id voor beheer

Het is raadzaam dat het beheersubnet van uw lokale Azure-exemplaar gebruikmaakt van het standaard-VLAN, 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 deze worden geconfigureerd op uw fysieke netwerkadapters die u wilt gebruiken voor beheerverkeer.

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 machines en voordat ze worden geregistreerd bij Azure Arc, om ervoor te zorgen dat u de knooppunten met behulp van dit VLAN kunt registreren.

Gebruik de volgende PowerShell-opdracht om de VLAN-id op de fysieke netwerkadapters in te stellen:

In dit voorbeeld wordt VLAN ID 44 geconfigureerd op de fysieke netwerkadapter NIC1.

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 Vm van Azure Resource Bridge of een 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 loopt dat de connectiviteit tussen de knooppunten en Azure wordt verbroken als de VLAN's van de fysieke switch niet correct worden gerouteerd.

VLAN-id beheren met een virtuele switch

In sommige scenario's is er een vereiste 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 De 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. Virtuele switch maken met aanbevolen naamconventie

Lokale Azure-implementaties zijn afhankelijk van Network ATC om de virtuele switches en virtuele netwerkadapters te maken en te configureren 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.

U wordt aangeraden de namen van uw virtuele switch te benoemen met dezelfde naamconventie. 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 netwerkadapternamen is een lijst met de fysieke netwerkadapters die u wilt gebruiken voor beheer en rekennetwerkverkeer:

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

2. Beheer van virtuele netwerkadapter configureren met behulp van de vereiste netwerk-ATC-naamconventie voor alle knooppunten

Zodra de virtuele switch en de bijbehorende virtuele netwerkadapter voor beheer zijn gemaakt, moet u ervoor zorgen dat de naam van de netwerkadapter voldoet aan de naamgevingsstandaarden van Network ATC.

De naam van de virtuele netwerkadapter die wordt gebruikt voor beheerverkeer, moet de volgende conventies gebruiken:

• De naam van de netwerkadapter en de virtuele netwerkadapter moeten worden gebruikt vManagement($intentname).
• Deze naam is hoofdlettergevoelig.
• $Intentname kan elke tekenreeks zijn, maar moet dezelfde naam hebben als voor de virtuele switch. Zorg ervoor dat u dezelfde tekenreeks gebruikt in Azure Portal bij het definiëren van de naam van de Mgmt intentie.

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

$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. 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 om de Set-VMNetworkAdapterIsolation opdracht te gebruiken.

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 virtuele netwerkadapter voor beheer configureert voor het gebruik van VLAN-id 8 in plaats van de standaardwaarde:

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

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

Hoewel de zojuist gemaakte virtuele netwerkadapter beschikbaar is bij de implementatie via Azure Portal, is het belangrijk om te onthouden dat de netwerkconfiguratie is gebaseerd op Network ATC. Dit betekent dat we bij het configureren van het beheer of de intentie voor beheer en rekenkracht 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.

Hier volgen de samengevatte overwegingen voor de VLAN-id:

#	Overwegingen
1	VLAN-id moet worden opgegeven op de fysieke netwerkadapter voor beheer voordat u de machines registreert bij Azure Arc.
2	Gebruik specifieke stappen wanneer een virtuele switch is vereist voordat u de machines 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 de implementatie van De Azure-portal of voor resourcebeheersjabloonimplementatie.

Aangepaste IP-adressen voor opslag

Standaard wijst netwerk-ATC automatisch de IP's en VLAN's voor opslag toe vanuit de volgende tabel:

Opslagadapter	IP-adres en subnet	VLAN
pNIC1	10.71.1.x	711
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

Als uw implementatievereisten echter niet passen bij deze standaard-IP's en VLAN's, kunt u uw eigen IP-adressen, subnet en VLAN's gebruiken voor opslag. Deze functionaliteit is alleen beschikbaar bij het implementeren van clusters met ARM-sjablonen en u moet de volgende parameters opgeven in uw sjabloon.

• enableStorageAutoIP: deze parameter, wanneer niet is opgegeven, is ingesteld op true. Als u aangepaste opslag-IP-adressen wilt inschakelen tijdens de implementatie, moet deze parameter zijn ingesteld op false.
• storageAdapterIPInfo: deze parameter heeft een afhankelijkheid met de parameter enableStorageAutoIP en is altijd vereist wanneer de parameter voor automatisch IP-adres van opslag is ingesteld op false. Binnen de parameter storageAdapterIPInfo in uw ARM-sjabloon moet u ook de parameters ipv4Address en subnetMask opgeven voor elk knooppunt en elke netwerkadapter met uw eigen IP-adressen en subnetmasker.
• vlanId: Zoals hierboven beschreven in de tabel, gebruikt deze parameter de standaard-VLAN's van Network ATC als u deze niet hoeft te wijzigen. Als deze standaard-VLAN's echter niet werken in uw netwerk, kunt u uw eigen VLAN-id's opgeven voor elk van uw opslagnetwerken.

De volgende ARM-sjabloon bevat een voorbeeld van een Azure Local-exemplaar van twee knooppunten met een netwerkswitch voor opslag, waarbij opslag-IP's zijn aangepast met 2 knooppuntenimplementatie met aangepaste OPSLAG-IP's

IP-toewijzing van knooppunt en cluster

Voor het lokale Azure-exemplaar hebt u twee opties om IP-adressen toe te wijzen voor de computerknooppunten en voor het IP-adres van het cluster.

• Zowel de statische als de DHCP-protocollen (Dynamic Host Configuration Protocol) worden ondersteund.

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

• Infrastructuur-VM's en -services, zoals Arc Resource Bridge en Netwerkcontroller, blijven statische IP-adressen van de beheer-IP-pool gebruiken. Dat betekent dat zelfs als u besluit DHCP te gebruiken om de IP-adressen toe te wijzen aan uw knooppunten en het IP-adres van uw cluster, de beheer-IP-adresgroep 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-adresgroep gebruikt om een beschikbaar IP-adres te verkrijgen en deze automatisch toe te wijzen aan het cluster-IP-adres tijdens de implementatie.

Het is belangrijk om beheer-IP's te gebruiken voor de knooppunten die geen deel uitmaken van het IP-bereik dat is gedefinieerd voor de beheer-IP-pool. IP-adressen van computerknooppunten 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 wordt gewijzigd zodra de intentie van het beheernetwerk is gemaakt. Dit zorgt er ook voor dat de knooppunten hun uitgaande connectiviteit behouden tijdens het implementatieproces, inclusief tijdens de Azure Arc-registratie.

Om routeringsproblemen te voorkomen en 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 tijdens de configuratie van het besturingssysteem een virtuele switch en een virtuele beheernetwerkadapter zijn gemaakt, 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 er ook een dynamisch IP-adres gebruikt voor het cluster-IP. Infrastructuur-VM's en -services vereisen nog steeds statische IP-adressen en dat betekent dat het adresbereik van de beheer-IP-adresgroep moet worden uitgesloten van het DHCP-bereik dat wordt gebruikt voor de knooppunten en het ip-adres van het cluster.

Als het IP-beheerbereik 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-adresgroep om IP-conflicten met de infrastructuurservices te voorkomen. U wordt ook aangeraden DHCP-reserveringen te gebruiken voor IP-adressen van knooppunten.

Het proces van 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 wordt gemaakt voor beheerdoeleinden. Dit betekent dat het IP-adres dat de eerste fysieke netwerkadapter verkrijgt van de DHCP-server hetzelfde IP-adres is dat de virtuele netwerkadapter als het beheer-IP gebruikt. Daarom is het belangrijk om DHCP-reservering te maken voor knooppunt-IP.

De netwerkvalidatielogica die tijdens de cloudimplementatie wordt gebruikt, mislukt als er meerdere fysieke netwerkinterfaces met een standaardgateway in hun configuratie worden gedetecteerd. Als u DHCP wilt gebruiken voor uw host-IP-toewijzingen, moet u de virtuele SET -switch (ingesloten koppeling) en de virtuele beheernetwerkadapter vooraf maken, zoals hierboven beschreven, zodat alleen de virtuele netwerkadapter van het beheer een IP-adres van de DHCP-server verkrijgt.

Overwegingen voor IP-adressen van clusterknooppunten

Hier volgen de samengevatte overwegingen voor de IP-adressen:

#	Overwegingen
1	Ip-adressen van knooppunten moeten zich in hetzelfde subnet van het gedefinieerde IP-adresbereik voor beheer bevinden, ongeacht of het statische of dynamische adressen zijn.
2	De beheer-IP-adresgroep mag geen IP-adressen van knooppunten bevatten. Dhcp-uitsluitingen gebruiken wanneer dynamische IP-toewijzing wordt gebruikt.
3	Gebruik ZO veel mogelijk DHCP-reserveringen voor de knooppunten.
4	DHCP-adressen worden alleen ondersteund voor IP-adressen van knooppunten en het IP-adres van het cluster. 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 intentie van het beheernetwerk is gemaakt.

Proxy-vereisten

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

Het Azure Stack HCI-besturingssysteem heeft drie verschillende services (WinInet, WinHTTP en omgevingsvariabelen) waarvoor dezelfde proxyconfiguratie is vereist 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 van Arc Resource Bridge en AKS, zodat deze tijdens de implementatie internettoegang hebben.

Hier volgen de samengevatte overwegingen voor proxyconfiguratie:

#	Overweging
1	De proxyconfiguratie moet worden voltooid voordat u de knooppunten in Azure Arc registreert.
2	Dezelfde proxyconfiguratie moet worden toegepast op WinINET-, WinHTTP- en omgevingsvariabelen.
3	De omgevingscontrole zorgt ervoor dat de proxyconfiguratie consistent is voor alle proxyonderdelen.
4	Proxyconfiguratie van de VM van Arc Resource Bridge 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 Local en de bijbehorende onderdelen verbinding kunnen maken met deze eindpunten. Zie Firewallvereisten voor een gedetailleerde lijst met de vereiste eindpunten.

Firewallconfiguratie moet worden uitgevoerd voordat u de knooppunten in Azure Arc registreert. U kunt de zelfstandige versie van de omgevingscontrole gebruiken om te controleren of uw firewalls het verkeer dat naar deze eindpunten wordt verzonden, niet blokkeert. Zie Azure Local Environment Checker voor meer informatie om de gereedheid van de implementatie voor Azure Local te beoordelen.

Hier volgen de samengevatte overwegingen voor de firewall:

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

Stap 5: Configuratie van netwerkadapter bepalen

Netwerkadapters worden gekwalificeerd door het netwerkverkeerstype (beheer, berekening 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 machine aanschaft voor Azure Local, moet u ten minste één adapter hebben die is gekwalificeerd voor beheer, berekening en opslag, omdat alle drie de verkeerstypen vereist zijn in Azure Local. Cloudimplementatie is afhankelijk van Netwerk-ATC voor het configureren van de netwerkadapters voor de juiste verkeerstypen, dus het is belangrijk om ondersteunde netwerkadapters te gebruiken.

De standaardwaarden die door Network ATC worden gebruikt, worden beschreven in de netwerkinstellingen van het cluster. U wordt aangeraden de standaardwaarden te gebruiken. Met dat gezegd kunnen de volgende opties worden overschreven met behulp van Azure Portal of Resource Manager-sjablonen, indien nodig:

• VLAN's voor opslag: stel deze waarde in op de vereiste VLAN's voor opslag.
• Jumbo Pakketten: Definieert de grootte van de jumbopakketten.
• Netwerk 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. We raden u ten zeerste aan de standaard DCB-waarden te gebruiken, omdat deze door Microsoft en klanten worden gevalideerd.

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 netwerkadapterconfiguratie. Zie de vereisten voor het fysieke netwerk voor Azure Local.
3	Zorg ervoor dat uw netwerkadapters worden ondersteund voor Azure Local met behulp van de Windows Server-catalogus.
4	Bij het accepteren van de standaardwaarden configureert Network ATC automatisch de IP-adressen en VLAN's van de opslagnetwerkadapter. Dit wordt automatische IP-configuratie voor opslag genoemd. In sommige gevallen wordt het automatische IP-adres van opslag niet ondersteund en moet u elk IP-adres van de opslagnetwerkadapter declareren met behulp van Resource Manager-sjablonen.

Volgende stappen

• Over de implementatie van Azure Local, versie 23H2.