Nätverksöverväganden för molndistributioner av Azure Stack HCI, version 23H2

Gäller för: Azure Stack HCI, version 23H2

Den här artikeln beskriver hur du utformar och planerar ett Azure Stack HCI, version 23H2-systemnätverk för molndistribution. Innan du fortsätter bör du bekanta dig med de olika Azure Stack HCI-nätverksmönstren och tillgängliga konfigurationerna.

Ramverk för nätverksdesign

Följande diagram visar de olika beslut och steg som definierar ramverket för nätverksdesign för ditt Azure Stack HCI-system – klusterstorlek, klusterlagringsanslutning, nätverkstrafikavsikter, hanteringsanslutning och konfiguration av nätverkskort. Varje designbeslut möjliggör eller tillåter de designalternativ som är tillgängliga i efterföljande steg:

Steg 1: Fastställa klusterstorlek

För att avgöra storleken på ditt Azure Stack HCI-system använder du verktyget Azure Stack HCI-storlek, där du kan definiera din profil, till exempel antal virtuella datorer (VM), storleken på de virtuella datorerna och arbetsbelastningsanvändningen av de virtuella datorerna, till exempel Azure Virtual Desktop, SQL Server eller AKS.

Enligt beskrivningen i artikeln om krav för Azure Stack HCI-systemserver är det maximala antalet servrar som stöds i Azure Stack HCI-systemet 16. När du har slutfört kapacitetsplaneringen för arbetsbelastningen bör du ha en god förståelse för hur många servernoder som krävs för att köra arbetsbelastningar i infrastrukturen.

• Om dina arbetsbelastningar kräver fyra eller fler noder: Du kan inte distribuera och använda en växellös konfiguration för lagringsnätverkstrafik. Du måste inkludera en fysisk växel med stöd för fjärråtkomst till direkt minne (RDMA) för att hantera lagringstrafik. Mer information om Nätverksarkitektur för Azure Stack HCI-kluster finns i Översikt över nätverksreferensmönster.

• Om dina arbetsbelastningar kräver tre eller färre noder: Du kan välja växlingslösa eller växlade konfigurationer för lagringsanslutning.

• Om du planerar att skala ut senare till fler än tre noder: Du måste använda en fysisk växel för lagringsnätverkstrafik. Alla skalbara åtgärder för växellösa distributioner kräver manuell konfiguration av nätverkskablar mellan de noder som Microsoft inte aktivt validerar som en del av sin programutvecklingscykel för Azure Stack HCI.

Här är de sammanfattade övervägandena för beslutet om klusterstorlek:

Beslut	Att tänka på
Klusterstorlek (antal noder per kluster)	Växellös konfiguration via Azure-portalen eller Azure Resource Manager-mallar är endast tillgängligt för 1, 2 eller 3 nodkluster. Kluster med 4 eller fler noder kräver fysisk växel för lagringsnätverkstrafiken.
Utskalningskrav	Om du tänker skala ut klustret med orchestrator måste du använda en fysisk växel för lagringsnätverkstrafiken.

Steg 2: Fastställa klusterlagringsanslutning

Enligt beskrivningen i fysiska nätverkskrav stöder Azure Stack HCI två typer av anslutningar för lagringsnätverkstrafik:

• Använd en fysisk nätverksväxel för att hantera trafiken.
• Anslut noderna direkt mellan dem med crossover-nätverk eller fiberkablar för lagringstrafiken.

Fördelarna och nackdelarna med varje alternativ dokumenteras i artikeln som är länkad ovan.

Som tidigare nämnts kan du bara välja mellan de två alternativen när storleken på klustret är tre eller färre noder. Alla kluster med fyra eller fler noder distribueras automatiskt med hjälp av en nätverksväxel för lagring.

Om kluster har färre än tre noder påverkar beslutet om lagringsanslutning antalet och typen av nätverksavsikter som du kan definiera i nästa steg.

För växellösa konfigurationer måste du till exempel definiera två avsikter för nätverkstrafik. Lagringstrafiken för kommunikation mellan öst och väst med hjälp av crossover-kablarna har inte anslutningar mellan nord och syd och är helt isolerad från resten av nätverksinfrastrukturen. Det innebär att du måste definiera en andra nätverks avsikt för hantering av utgående anslutning och för dina beräkningsarbetsbelastningar.

Även om det är möjligt att definiera varje nätverks avsikt med endast en fysisk nätverkskortport var, ger det ingen feltolerans. Därför rekommenderar vi alltid att du använder minst två fysiska nätverksportar för varje nätverks avsikt. Om du bestämmer dig för att använda en nätverksväxel för lagring kan du gruppera all nätverkstrafik, inklusive lagring i ett enda nätverk, vilket även kallas en hyperkonvergerad eller fullständigt konvergerad värdnätverkskonfiguration .

Här är de sammanfattade övervägandena för anslutningsbeslutet för klusterlagring:

Beslut	Att tänka på
Ingen växel för lagring	Växellös konfiguration via Azure-portalen eller Resource Manager-malldistribution stöds endast för 1, 2 eller 3 nodkluster. Växlingslösa kluster med 1 eller 2 noder kan distribueras med hjälp av Azure-portalen eller Resource Manager-mallar. Växlingslösa kluster med tre noder kan bara distribueras med Hjälp av Resource Manager-mallar. Utskalningsåtgärder stöds inte med växellösa distributioner. Alla ändringar av antalet noder efter distributionen kräver en manuell konfiguration. Minst två nätverks avsikter krävs när du använder lagringsväxlingslös konfiguration.
Nätverksväxel för lagring	Om du tänker skala ut klustret med orchestrator måste du använda en fysisk växel för lagringsnätverkstrafiken. Du kan använda den här arkitekturen med valfritt antal noder mellan 1 och 16. Även om det inte tillämpas kan du använda en enda avsikt för alla nätverkstrafiktyper (hantering, beräkning och lagring)

I följande diagram sammanfattas tillgängliga lagringsanslutningsalternativ för olika distributioner:

Steg 3: Fastställa avsikterna för nätverkstrafik

För Azure Stack HCI förlitar sig alla distributioner på Network ATC för värdnätverkskonfigurationen. Nätverks avsikterna konfigureras automatiskt när du distribuerar Azure Stack HCI via Azure-portalen. Mer information om nätverks avsikterna och hur du felsöker dem finns i Vanliga ATC-kommandon för nätverk.

I det här avsnittet beskrivs konsekvenserna av ditt designbeslut för avsikterna med nätverkstrafik och hur de påverkar nästa steg i ramverket. För molndistributioner kan du välja mellan fyra alternativ för att gruppera nätverkstrafiken i en eller flera avsikter. Vilka alternativ som är tillgängliga beror på antalet noder i klustret och vilken lagringsanslutningstyp som används.

De tillgängliga alternativen för nätverks avsikt beskrivs i följande avsnitt.

Nätverks avsikt: Gruppera all trafik

Nätverks-ATC konfigurerar en unik avsikt som omfattar hanterings-, beräknings- och lagringsnätverkstrafik. De nätverkskort som tilldelats den här avsikten delar bandbredd och dataflöde för all nätverkstrafik.

• Det här alternativet kräver en fysisk växel för lagringstrafik. Om du behöver en switchless-arkitektur kan du inte använda den här typen av avsikt. Azure-portalen filtrerar automatiskt bort det här alternativet om du väljer en växellös konfiguration för lagringsanslutning.

• Minst två portar för nätverkskort rekommenderas för att säkerställa hög tillgänglighet.

• Minst 10 Gbit/s-nätverksgränssnitt krävs för att stödja RDMA-trafik för lagring.

Nätverks avsikt: Grupphantering och beräkningstrafik

Network ATC konfigurerar två avsikter. Den första avsikten omfattar hanterings- och beräkningsnätverkstrafik, och den andra avsikten omfattar endast lagringsnätverkstrafik. Varje avsikt måste ha en annan uppsättning nätverkskortportar.

Du kan använda det här alternativet för både växlad och växellös lagringsanslutning om:

• Minst två nätverkskortportar är tillgängliga för varje avsikt för att säkerställa hög tillgänglighet.

• En fysisk växel används för RDMA om du använder nätverksväxeln för lagring.

• Minst 10 Gbit/s-nätverksgränssnitt krävs för att stödja RDMA-trafik för lagring.

Nätverks avsikt: Gruppberäkning och lagringstrafik

Network ATC konfigurerar två avsikter. Den första avsikten omfattar beräknings- och lagringsnätverkstrafik, och den andra avsikten omfattar endast hantering av nätverkstrafik. Varje avsikt måste använda en annan uppsättning nätverkskortportar.

• Det här alternativet kräver en fysisk växel för lagringstrafik eftersom samma portar delas med beräkningstrafik, vilket kräver kommunikation mellan nord och syd. Om du behöver en växellös konfiguration kan du inte använda den här typen av avsikt. Azure-portalen filtrerar automatiskt bort det här alternativet om du väljer en växellös konfiguration för lagringsanslutning.

• Det här alternativet kräver en fysisk växel för RDMA.

• Minst två portar för nätverkskort rekommenderas för att säkerställa hög tillgänglighet.

• Minst 10 Gbit/s-nätverksgränssnitt rekommenderas för beräknings- och lagringsavsikten för att stödja RDMA-trafik.

• Även när hanterings avsikten deklareras utan en beräknings avsikt skapar Network ATC en virtuell Switch Embedded Teaming-växel (SET) för att ge hög tillgänglighet till hanteringsnätverket.

Nätverks avsikt: Anpassad konfiguration

Definiera upp till tre avsikter med din egen konfiguration så länge minst en av avsikterna innehåller hanteringstrafik. Vi rekommenderar att du använder det här alternativet när du behöver en andra beräknings avsikt. Scenarier för det andra kravet på beräkningsavsikt är fjärrlagringstrafik, säkerhetskopieringstrafik för virtuella datorer eller en separat beräkningsavsikt för olika typer av arbetsbelastningar.

• Använd det här alternativet för både växlad och växellös lagringsanslutning om lagringssyftet skiljer sig från de andra avsikterna.

• Använd det här alternativet när en annan beräkningsavsikt krävs eller när du vill separera de olika typerna av trafik helt över olika nätverkskort.

• Använd minst två nätverkskortportar för varje avsikt för att säkerställa hög tillgänglighet.

• Minst 10 Gbit/s-nätverksgränssnitt rekommenderas för beräknings- och lagringsavsikten för att stödja RDMA-trafik.

I följande diagram sammanfattas tillgängliga alternativ för nätverks avsikt för olika distributioner:

Steg 4: Fastställa nätverksanslutning för hantering

I det här steget definierar du infrastrukturens undernätsadressutrymme, hur dessa adresser tilldelas till klustret och om det finns några proxy- eller VLAN-ID-krav för noderna för utgående anslutning till Internet och andra intranättjänster, till exempel DNS (Domain Name System) eller Active Directory Services.

Följande infrastrukturundernätskomponenter måste planeras och definieras innan du startar distributionen så att du kan förutse eventuella routnings-, brandväggs- eller undernätskrav.

Drivrutiner för nätverkskort

När du har installerat operativsystemet och innan du konfigurerar nätverk på noderna måste du se till att nätverkskorten har den senaste drivrutinen som tillhandahålls av OEM-tillverkaren eller nätverksgränssnittsleverantören. Viktiga funktioner i nätverkskorten kanske inte visas när du använder standarddrivrutinerna för Microsoft.

Hanterings-IP-pool

När du gör den första distributionen av ditt Azure Stack HCI-system måste du definiera ett IP-intervall med efterföljande IP-adresser för infrastrukturtjänster som distribueras som standard.

För att säkerställa att intervallet har tillräckligt med IP-adresser för aktuella och framtida infrastrukturtjänster måste du använda ett intervall på minst sex på varandra följande tillgängliga IP-adresser. Dessa adresser används för – klustrets IP-adress, den virtuella Azure Resource Bridge-datorn och dess komponenter.

Om du förväntar dig att köra andra tjänster i infrastrukturnätverket rekommenderar vi att du tilldelar en extra buffert med infrastruktur-IP-adresser till poolen. Det går att lägga till andra IP-pooler efter distributionen för infrastrukturnätverket med hjälp av PowerShell om storleken på poolen som du planerade ursprungligen blir förbrukad.

Följande villkor måste uppfyllas när du definierar DIN IP-pool för infrastrukturundernätet under distributionen:

#	Villkor
1	IP-intervallet måste använda efterföljande IP-adresser och alla IP-adresser måste vara tillgängliga inom det intervallet. Det går inte att ändra det här IP-intervallet efter distributionen.
2	Ip-adressintervallet får inte innehålla IP-adresser för klusternodhantering utan måste finnas i samma undernät som noderna.
3	Standardgatewayen som definierats för hanterings-IP-poolen måste tillhandahålla utgående anslutning till Internet.
4	DNS-servrarna måste säkerställa namnmatchning med Active Directory och Internet.
5	Hanterings-IP-adresserna kräver utgående Internetåtkomst.

VLAN-ID för hantering

Vi rekommenderar att hanteringsundernätet för ditt Azure HCI-kluster använder standard-VLAN, som i de flesta fall deklareras som VLAN-ID 0. Men om dina nätverkskrav ska använda ett specifikt hanterings-VLAN för infrastrukturnätverket måste det konfigureras på de fysiska nätverkskort som du planerar att använda för hanteringstrafik.

Om du planerar att använda två fysiska nätverkskort för hantering måste du ange VLAN på båda korten. Detta måste göras som en del av bootstrap-konfigurationen för dina servrar, och innan de registreras i Azure Arc för att säkerställa att du har registrerat noderna med hjälp av detta VLAN.

Om du vill ange VLAN-ID på de fysiska nätverkskorten använder du följande PowerShell-kommando:

Det här exemplet konfigurerar VLAN ID 44 på det fysiska nätverkskortet NIC1.

Set-NetAdapter -Name "NIC1" -VlanID 44

När VLAN-ID:t har angetts och IP-adresserna för dina noder har konfigurerats på de fysiska nätverkskorten läser orkestratorn det här VLAN-ID-värdet från det fysiska nätverkskort som används för hantering och lagrar det, så att det kan användas för den virtuella Azure Resource Bridge-datorn eller någon annan virtuell infrastrukturdator som krävs under distributionen. Det går inte att ange hanterings-VLAN-ID under molndistributionen från Azure-portalen eftersom det medför risk för att anslutningen mellan noderna och Azure bryts om de fysiska växel-VLAN:erna inte dirigeras korrekt.

Hantera VLAN-ID med en virtuell växel

I vissa scenarier finns det ett krav på att skapa en virtuell växel innan distributionen startar.

Kommentar

Innan du skapar en virtuell växel måste du aktivera Hype-V-rollen. Mer information finns i Installera nödvändig Windows-roll.

Om en konfiguration av en virtuell växel krävs och du måste använda ett specifikt VLAN-ID följer du dessa steg:

1. Skapa virtuell växel med rekommenderad namngivningskonvention

Azure Stack HCI-distributioner förlitar sig på NETWORK ATC för att skapa och konfigurera virtuella växlar och virtuella nätverkskort för hantering, beräkning och lagring. När Network ATC som standard skapar den virtuella växeln för avsikterna använder den ett specifikt namn för den virtuella växeln.

Vi rekommenderar att du namnger namn på virtuella växlar med samma namngivningskonvention. Det rekommenderade namnet på de virtuella växlarna är följande:

"ConvergedSwitch($IntentName)", där $IntentName måste matcha namnet på avsikten som angavs i portalen under distributionen. Den här strängen måste också matcha namnet på det virtuella nätverkskort som används för hantering enligt beskrivningen i nästa steg.

I följande exempel visas hur du skapar den virtuella växeln med PowerShell med hjälp av den rekommenderade namngivningskonventionen med $IntentName. Listan över nätverkskortsnamn är en lista över de fysiska nätverkskort som du planerar att använda för hantering och beräkning av nätverkstrafik:

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

2. Konfigurera hantering av virtuellt nätverkskort med den nätverks-ATC-namngivningskonvention som krävs för alla noder

När den virtuella växeln och det associerade virtuella nätverkskortet för hantering har skapats kontrollerar du att nätverkskortets namn är kompatibelt med namngivningsstandarderna för nätverks-ATC.

Mer specifikt måste namnet på det virtuella nätverkskortet som används för hanteringstrafik använda följande konventioner:

• Namnet på nätverkskortet och det virtuella nätverkskortet måste använda vManagement($intentname).
• Det här namnet är skiftlägeskänsligt.
• $Intentname kan vara valfri sträng, men måste vara samma namn som används för den virtuella växeln. Se till att du använder samma sträng i Azure-portalen när du definierar avsiktsnamnet Mgmt .

Om du vill uppdatera namnet på det virtuella nätverkskortet för hantering använder du följande kommandon:

$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. Konfigurera VLAN-ID för hantering av virtuellt nätverkskort för alla noder

När den virtuella växeln och det virtuella nätverkskortet för hantering har skapats kan du ange det nödvändiga VLAN-ID:t för det här kortet. Även om det finns olika alternativ för att tilldela ett VLAN-ID till ett virtuellt nätverkskort är det enda alternativet som stöds att använda Set-VMNetworkAdapterIsolation kommandot.

När det nödvändiga VLAN-ID:t har konfigurerats kan du tilldela IP-adressen och gatewayerna till det virtuella nätverkskortet för hantering för att verifiera att det har anslutning till andra noder, DNS, Active Directory och Internet.

I följande exempel visas hur du konfigurerar det virtuella nätverkskortet för hantering så att det använder VLAN-ID 8 i stället för standardvärdet:

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

4. Referera till fysiska nätverkskort för hanteringssyftet under distributionen

Även om det nyligen skapade virtuella nätverkskortet visas som tillgängligt när du distribuerar via Azure-portalen är det viktigt att komma ihåg att nätverkskonfigurationen baseras på Nätverks-ATC. Det innebär att när vi konfigurerar hanterings- eller hanterings- och beräkningssyftet måste vi fortfarande välja de fysiska nätverkskort som används för avsikten.

Kommentar

Välj inte det virtuella nätverkskortet för nätverks avsikten.

Samma logik gäller för Azure Resource Manager-mallarna. Du måste ange de fysiska nätverkskort som du vill använda för nätverksinsikterna och aldrig de virtuella nätverkskorten.

Här är de sammanfattade övervägandena för VLAN-ID:t:

#	Att tänka på
1	VLAN-ID måste anges på det fysiska nätverkskortet för hantering innan servrarna registreras med Azure Arc.
2	Använd specifika steg när en virtuell växel krävs innan du registrerar servrarna i Azure Arc.
3	Hanterings-VLAN-ID:t överförs från värdkonfigurationen till de virtuella infrastrukturdatorerna under distributionen.
4	Det finns ingen indataparameter för VLAN-ID för Distribution av Azure-portalen eller distribution av Resource Manager-mallar.

IP-tilldelning för nod och kluster

För Azure Stack HCI-system har du två alternativ för att tilldela IP-adresser för servernoderna och för klustrets IP-adress.

• Både DHCP-protokoll (Static Och Dynamic Host Configuration Protocol) stöds.

• Rätt nod-IP-tilldelning är nyckeln för klusterlivscykelhantering. Bestäm mellan alternativen statisk och DHCP innan du registrerar noderna i Azure Arc.

• Virtuella infrastrukturdatorer och tjänster som Arc Resource Bridge och Nätverksstyrenheten fortsätter att använda statiska IP-adresser från hanterings-IP-poolen. Det innebär att även om du bestämmer dig för att använda DHCP för att tilldela IP-adresser till dina noder och klustrets IP-adress, krävs fortfarande hanterings-IP-poolen.

I följande avsnitt beskrivs konsekvenserna av varje alternativ.

Statisk IP-tilldelning

Om statiska IP-adresser används för noderna används hanterings-IP-poolen för att hämta en tillgänglig IP-adress och tilldela den till klustrets IP-adress automatiskt under distributionen.

Det är viktigt att använda hanterings-IP-adresser för de noder som inte ingår i DET IP-intervall som definierats för hanterings-IP-poolen. Ip-adresser för servernoder måste finnas i samma undernät för det definierade IP-intervallet.

Vi rekommenderar att du endast tilldelar en hanterings-IP för standardgatewayen och för de konfigurerade DNS-servrarna för nodens alla fysiska nätverkskort. Detta säkerställer att IP-adressen inte ändras när avsikten för hanteringsnätverket har skapats. Detta säkerställer också att noderna behåller sin utgående anslutning under distributionsprocessen, inklusive under Azure Arc-registreringen.

För att undvika routningsproblem och för att identifiera vilken IP-adress som ska användas för utgående anslutning och Arc-registrering kontrollerar Azure-portalen om det finns fler än en konfigurerad standardgateway.

Om en virtuell växel och ett virtuellt nätverkskort för hantering skapades under OS-konfigurationen måste hanterings-IP-adressen för noden tilldelas till det virtuella nätverkskortet.

DHCP IP-tilldelning

Om IP-adresser för noderna hämtas från en DHCP-server används även en dynamisk IP-adress för klustrets IP-adress. Virtuella datorer och tjänster för infrastruktur kräver fortfarande statiska IP-adresser, och det innebär att adressintervallet för hanterings-IP-poolen måste undantas från DHCP-omfånget som används för noderna och klustrets IP-adress.

Om hanterings-IP-intervallet till exempel definieras som 192.168.1.20/24 till 192.168.1.30/24 för infrastrukturens statiska IP-adresser måste DHCP-omfånget som definierats för undernätet 192.168.1.0/24 ha ett undantag som motsvarar ip-hanteringspoolen för att undvika IP-konflikter med infrastrukturtjänsterna. Vi rekommenderar också att du använder DHCP-reservationer för nod-IP-adresser.

Processen för att definiera hanterings-IP när du har skapat hanteringssyftet innebär att använda MAC-adressen för det första fysiska nätverkskortet som har valts för nätverks avsikten. Den här MAC-adressen tilldelas sedan till det virtuella nätverkskortet som skapas i hanteringssyfte. Det innebär att IP-adressen som det första fysiska nätverkskortet hämtar från DHCP-servern är samma IP-adress som det virtuella nätverkskortet använder som hanterings-IP. Därför är det viktigt att skapa DHCP-reservation för nod-IP.

Den nätverksverifieringslogik som används under molndistributionen misslyckas om den identifierar flera fysiska nätverksgränssnitt som har en standardgateway i sin konfiguration. Om du behöver använda DHCP för dina värd-IP-tilldelningar måste du i förväg skapa den virtuella växeln SET (växla inbäddad teamindelning) och det virtuella nätverkskortet för hantering enligt beskrivningen ovan, så att endast det virtuella nätverkskortet för hantering hämtar en IP-adress från DHCP-servern.

IP-överväganden för klusternoder

Här är de sammanfattade övervägandena för IP-adresserna:

#	Att tänka på
1	Nod-IP-adresser måste finnas i samma undernät i det definierade IP-poolintervallet för hantering, oavsett om de är statiska eller dynamiska adresser.
2	Hanterings-IP-poolen får inte innehålla nod-IP-adresser. Använd DHCP-undantag när dynamisk IP-tilldelning används.
3	Använd DHCP-reservationer för noderna så mycket som möjligt.
4	DHCP-adresser stöds endast för nod-IP-adresser och klustrets IP-adress. Infrastrukturtjänster använder statiska IP-adresser från hanteringspoolen.
5	MAC-adressen från det första fysiska nätverkskortet tilldelas till det virtuella nätverkskortet för hantering när avsikten för hanteringsnätverket har skapats.

Krav för proxy

En proxy krävs troligen för att få åtkomst till Internet i din lokala infrastruktur. Azure Stack HCI stöder endast icke-autentiserade proxykonfigurationer. Eftersom Internetåtkomst krävs för att registrera noderna i Azure Arc måste proxykonfigurationen anges som en del av OS-konfigurationen innan servernoder registreras. Mer information finns i Konfigurera proxyinställningar.

Azure Stack HCI OS har tre olika tjänster (WinInet, WinHTTP och miljövariabler) som kräver samma proxykonfiguration för att säkerställa att alla OS-komponenter kan komma åt Internet. Samma proxykonfiguration som används för noderna överförs automatiskt till den virtuella Arc Resource Bridge-datorn och AKS, vilket säkerställer att de har internetåtkomst under distributionen.

Här är de sammanfattade övervägandena för proxykonfiguration:

#	Att tänka på
1	Proxykonfigurationen måste slutföras innan noderna registreras i Azure Arc.
2	Samma proxykonfiguration måste tillämpas för WinINET-, WinHTTP- och miljövariabler.
3	Miljökontrollen ser till att proxykonfigurationen är konsekvent för alla proxykomponenter.
4	Proxykonfigurationen för den virtuella Arc Resource Bridge-datorn och AKS görs automatiskt av orkestreraren under distributionen.
5	Endast de icke-autentiserade proxyservrarna stöds.

Brandväggskrav

För närvarande måste du öppna flera Internetslutpunkter i brandväggarna för att säkerställa att Azure Stack HCI och dess komponenter kan ansluta till dem. En detaljerad lista över de slutpunkter som krävs finns i Brandväggskrav.

Brandväggskonfigurationen måste utföras innan noderna registreras i Azure Arc. Du kan använda den fristående versionen av miljökontrollen för att verifiera att brandväggarna inte blockerar trafik som skickas till dessa slutpunkter. Mer information finns i Azure Stack HCI Environment Checker för att utvärdera distributionsberedskapen för Azure Stack HCI.

Här är de sammanfattade övervägandena för brandväggen:

#	Att tänka på
1	Brandväggskonfigurationen måste göras innan noderna registreras i Azure Arc.
2	Miljökontroll i fristående läge kan användas för att verifiera brandväggskonfigurationen.

Steg 5: Fastställa konfiguration av nätverkskort

Nätverkskort är kvalificerade efter nätverkstrafiktyp (hantering, beräkning och lagring) som de används med. När du granskar Windows Server-katalogen anger Windows Server 2022-certifieringen för vilken nätverkstrafik korten är kvalificerade för.

Innan du köper en server för Azure Stack HCI måste du ha minst ett kort som är kvalificerat för hantering, beräkning och lagring eftersom alla tre trafiktyperna krävs på Azure Stack HCI. Molndistributionen förlitar sig på Network ATC för att konfigurera nätverkskorten för lämpliga trafiktyper, så det är viktigt att använda nätverkskort som stöds.

Standardvärdena som används av Network ATC dokumenteras i Klusternätverksinställningar. Vi rekommenderar att du använder standardvärdena. Med detta sagt kan följande alternativ åsidosättas med hjälp av Azure-portalen eller Resource Manager-mallar om det behövs:

• Lagrings-VLAN: Ange det här värdet till de VLAN som krävs för lagring.
• Jumbopaket: Definierar storleken på jumbopaketen.
• Nätverksdirigering: Ange värdet falskt om du vill inaktivera RDMA för dina nätverkskort.
• Nätverksdirigeringsteknik: Ange det här värdet till RoCEv2 eller iWarp.
• Trafikprioriteringar datacenterbryggning (DCB): Ange de prioriteringar som passar dina krav. Vi rekommenderar starkt att du använder standardvärdena för DCB eftersom dessa verifieras av Microsoft och kunder.

Här är de sammanfattade övervägandena för konfiguration av nätverkskort:

#	Att tänka på
1	Använd standardkonfigurationerna så mycket som möjligt.
2	Fysiska växlar måste konfigureras enligt nätverkskortkonfigurationen. Se Fysiska nätverkskrav för Azure Stack HCI.
3	Kontrollera att dina nätverkskort stöds för Azure Stack HCI med hjälp av Windows Server-katalogen.
4	När du godkänner standardvärdena konfigurerar Network ATC automatiskt IP-adresser för lagringsnätverkskort och VLAN. Detta kallas automatisk IP-konfiguration för lagring. I vissa fall stöds inte automatisk IP-adress för lagring och du måste deklarera varje IP-adress för lagringsnätverkskortet med hjälp av Resource Manager-mallar.

Nästa steg

• Om Azure Stack HCI, version 23H2-distribution.