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

Ramverk för nätverksdesign

Följande diagram visar de olika beslut och steg som definierar nätverksdesignramverket för ditt Azure Stack HCI-system – klusterstorlek, klusterlagringsanslutning, avsikter för nätverkstrafik, 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 Sizer, där du kan definiera din profil, till exempel antalet 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 systemserverkrav för Azure Stack HCI ä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 antalet 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ätverksarkitekturen 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 antingen 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 utskalningså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)	Konfiguration utan växel via Azure Portal- eller ARM-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 hjälp av 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 ovan.

Som tidigare nämnts kan du bara välja mellan de två alternativen när klustrets storlek ä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äxlingslösa konfigurationer måste du till exempel definiera två avsikter för nätverkstrafik. Lagringstrafiken för kommunikation mellan öst och väst som använder crossover-kablarna har ingen anslutning 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 anslutningar 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, som inte ger någon 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 en enda nätverksinsikt, som även kallas en hyperkonvergerad eller fullständigt konvergerad värdnätverkskonfiguration .

Här är de sammanfattade övervägandena för beslutet om anslutning till klusterlagring:

Beslut	Att tänka på
Ingen växel för lagring	Växlingsfri konfiguration via Azure Portal- eller ARM-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 Portal- eller ARM-mallar. Växlingslösa kluster med 3 noder kan bara distribueras med ARM-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 2 nätverks avsikter krävs när du använder lagringsväxlingsfri konfiguration.
Nätverksväxel för lagring	Om du tänker skala ut klustret med hjälp av 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 inte tillämpas kan du använda en enda avsikt för alla typer av nätverkstrafik (hantering, beräkning och lagring)

I följande diagram sammanfattas tillgängliga alternativ för lagringsanslutning 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 Portal. 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 typ av lagringsanslutning som används.

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

Nätverks avsikt: Gruppera all trafik

Network ATC konfigurerar en unik avsikt som omfattar hanterings-, beräknings- och lagringsnätverkstrafik. Nätverkskorten 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 Portal 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ätverkskortsportar.

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

• Minst två portar för nätverkskort ä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äknings- 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ätverkskortsportar.

• 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 Portal 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 om hanterings avsikten deklareras utan en beräknings avsikt, skapar Network ATC en virtuell switch för Switch Embedded Teaming (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 här andra kravet på beräkningsavsikt är fjärrlagringstrafik, vm-säkerhetskopieringstrafik 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 lagrings avsikten 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 olika typer av trafik helt och hållet över olika nätverkskort.

• Använd minst två nätverkskortsportar 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 avsikter för olika distributioner:

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

I det här steget definierar du infrastrukturundernätets adressutrymme, 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ätstjänster, till exempel DNS (Domain Name System) eller Active Directory Services.

Följande infrastrukturundernätskomponenter måste planeras och definieras innan du påbörjar 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 från OEM-tillverkaren eller nätverksgränssnittsleverantören. Viktiga funktioner i nätverkskorten kanske inte visas när standarddrivrutinerna för Microsoft används.

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 uttömd.

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.
2	Ip-adressintervallet får inte innehålla IP-adresser för klusternodhantering utan måste finnas i samma undernät som dina noder.
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.

Hanterings-VLAN-ID

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 hantering av trafik.

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 registrerar noderna med hjälp av det här VLAN:et.

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 orkestreraren 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 Portal eftersom detta 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 måste du skapa en virtuell växel innan distributionen startar.

Anteckning

Innan du skapar en virtuell växel måste du aktivera Hype-V-rollen. Mer information finns i Installera den Windows-roll som krävs.

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.

Även om det inte krävs rekommenderar vi att du namnger dina virtuella växlar med samma namngivningskonvention. Det rekommenderade namnet på de virtuella växlarna är följande:

• Namnet på den virtuella växeln: "ConvergedSwitch($IntentName)", Var $IntentName kan vara vilken sträng som helst. Den här strängen ska matcha namnet på det virtuella nätverkskortet 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 en beskrivning av syftet med $IntentName den virtuella växeln. 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 $false

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 har konfigurerats måste det virtuella nätverkskortet för hantering skapas. Namnet på det virtuella nätverkskort som används för hanteringstrafik måste använda följande namngivningskonvention:

• Namnet på nätverkskortet och det virtuella nätverkskortet: vManagement($intentname).
• 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.

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

$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. 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 VLAN-ID som krävs 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

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

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

Anteckning

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

Samma logik gäller för ARM-mallarna (Azure Resource Manager). 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:

#	Överväganden
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 till Azure Arc.
3	Hanterings-VLAN-ID:t överförs från värdkonfigurationen till de virtuella infrastrukturdatorerna under distributionen.
4	Det finns ingen VLAN ID-indataparameter för Azure Portal distribution eller distribution av ARM-mallar.

Ip-tilldelning av noder 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 And 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 datorer och tjänster för infrastruktur 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 bara tilldelar en hanterings-IP för standardgatewayen och för de konfigurerade DNS-servrarna för alla fysiska nätverkskort för noden. 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 Portal om det finns fler än en konfigurerad standardgateway.

Om en virtuell växel och ett hanterat virtuellt nätverkskort skapades under OS-konfigurationen måste hanterings-IP 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 statiska IP-adresser för infrastrukturen, måste DHCP-omfånget som definierats för undernätet 192.168.1.0/24 ha ett undantag som motsvarar hanterings-IP-poolen 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-adressen 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.

Ip-överväganden för klusternoder

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

#	Överväganden
1	Nod-IP-adresser måste finnas i samma undernät för 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 det virtuella nätverkskortet för hantering när avsikten för hanteringsnätverket har skapats.

Proxykrav

En proxyserver 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 servernoderna registreras. Mer information finns i Konfigurera proxyinställningar.

Azure Stack HCI-operativsystemet 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 säkerställer att proxykonfigurationen är konsekvent för alla proxykomponenter.
4	Proxykonfigurationen av den virtuella Arc Resource Bridge-datorn och AKS utförs automatiskt av orkestreraren under distributionen.
5	Endast de icke-autentiserade proxyservrarna stöds.

Brandväggsförutsättningar

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 nödvändiga slutpunkterna finns i Brandväggskrav.

Brandväggskonfigurationen måste gö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 distributionsberedskap 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 kvalificeras 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å nätverks-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 Portal- eller ARM-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 nätverkskortskonfiguration:

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

Nästa steg

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