Värdnätverkskrav för Azure Stack HCI

Gäller för: Azure Stack HCI, versionerna 23H2 och 22H2

I det här avsnittet beskrivs överväganden och krav för värdnätverk för Azure Stack HCI. Information om datacenterarkitekturer och fysiska anslutningar mellan servrar finns i Fysiska nätverkskrav.

Information om hur du förenklar värdnätverk med hjälp av Network ATC finns i Förenkla värdnätverk med Network ATC.

Typer av nätverkstrafik

Azure Stack HCI-nätverkstrafik kan klassificeras efter avsett syfte:

• Hanteringstrafik: Trafik till eller utanför det lokala klustret. Till exempel lagringsrepliktrafik eller trafik som används av administratören för hantering av klustret, till exempel Fjärrskrivbord, Windows Admin Center, Active Directory osv.
• Beräkningstrafik: Trafik som kommer från eller är avsedd för en virtuell dator (VM).
• Lagringstrafik: Trafik som använder SMB (Server Message Block), till exempel Lagringsdirigering eller SMB-baserad direktmigrering. Den här trafiken är layer-2-trafik och kan inte dirigeras.

Viktigt

Lagringsreplik använder icke-RDMA-baserad SMB-trafik. Detta och trafikens riktning (nord-syd) gör att den är nära anpassad till den för "hanteringstrafik" som anges ovan, ungefär som för en traditionell filresurs.

Välj ett nätverkskort

Nätverkskort kvalificeras av de typer av nätverkstrafik (se ovan) som de stöds för användning med. När du granskar Windows Server-katalogen anger Windows Server 2022-certifieringen nu en eller flera av följande roller. 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 trafiktyper krävs på Azure Stack HCI. Du kan sedan använda Network ATC för att konfigurera korten för lämpliga trafiktyper.

Mer information om den här rollbaserade NIC-kvalificeringen finns i den här länken.

Viktigt

Det går inte att använda ett kort utanför den kvalificerade trafiktypen.

Nivå	Hanteringsroll	Beräkningsroll	Lagringsroll
Rollbaserad skillnad	Hantering	Compute Standard	Storage Standard
Högsta utmärkelse	Ej tillämpligt	Compute Premium	Storage Premium

Anteckning

Den högsta kvalificeringen för alla kort i vårt ekosystem innehåller kvalifikationerna Hantering, Compute Premium och Storage Premium .

Krav för drivrutin

Inkorgsdrivrutiner stöds inte för användning med Azure Stack HCI. Kör följande cmdlet för att identifiera om adaptern använder en inkorgsdrivrutin. Ett kort använder en inkorgsdrivrutin om egenskapen DriverProvider är Microsoft.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Översikt över viktiga funktioner för nätverkskort

Viktiga funktioner för nätverkskort som används av Azure Stack HCI är:

• Dynamisk virtuell dator med flera köer (dynamisk VMMQ eller d.VMMQ)
• Fjärråtkomst till direkt minne (RDMA)
• Gäst-RDMA
• Växla inbäddad teamindelning (SET)

Dynamisk VMMQ

Alla nätverkskort med kvalificeringen Compute (Premium) stöder dynamisk VMMQ. Dynamisk VMMQ kräver användning av Switch Embedded Teaming.

Tillämpliga trafiktyper: beräkning

Certifieringar som krävs: Compute (Premium)

Dynamisk VMMQ är en intelligent teknik på mottagarsidan. Den bygger vidare på föregående aktiviteter för VmQ (Virtual Machine Queue), Virtual Receive Side Scaling (vRSS) och VMMQ för att ge tre huvudsakliga förbättringar:

• Optimerar värdeffektiviteten med färre processorkärnor.
• Automatisk justering av bearbetning av nätverkstrafik till CPU-kärnor, vilket gör det möjligt för virtuella datorer att uppfylla och upprätthålla förväntat dataflöde.
• Gör att "bursty"-arbetsbelastningar kan ta emot den förväntade mängden trafik.

Mer information om dynamisk VMMQ finns i blogginlägget Syntetiska accelerationer.

RDMA

RDMA är en avlastning från nätverksstacken till nätverkskortet. Det gör att SMB-lagringstrafik kan kringgå operativsystemet för bearbetning.

RDMA möjliggör nätverk med högt dataflöde och låg latens med minimala processorresurser för värden. Dessa värd-CPU-resurser kan sedan användas för att köra ytterligare virtuella datorer eller containrar.

Tillämpliga trafiktyper: värdlagring

Certifieringar som krävs: Lagring (standard)

Alla kort med Storage -kvalifikation (Standard) eller Storage (Premium) stöder RDMA på värdsidan. Mer information om hur du använder RDMA med gästarbetsbelastningar finns i avsnittet "Gäst-RDMA" senare i den här artikeln.

Azure Stack HCI stöder RDMA med antingen IWARP (Internet Wide Area RDMA Protocol) eller RDMA over Converged Ethernet (RoCE) protokollimplementeringar.

Viktigt

RDMA-kort fungerar bara med andra RDMA-kort som implementerar samma RDMA-protokoll (iWARP eller RoCE).

Alla nätverkskort från leverantörer stöder inte RDMA. I följande tabell visas de leverantörer (i alfabetisk ordning) som erbjuder certifierade RDMA-kort. Det finns dock maskinvaruleverantörer som inte ingår i den här listan som också stöder RDMA. Se Windows Server-katalogen för att hitta kort med kvalifikationen Storage (Standard) eller Storage (Premium) som kräver RDMA-stöd.

Anteckning

InfiniBand (IB) stöds inte med Azure Stack HCI.

NIC-leverantör	iWARP	Roce
Broadcom	Inga	Ja
Intel	Yes	Ja (vissa modeller)
Marvell (Qlogic)	Ja	Yes
Nvidia	Inga	Ja

Om du vill ha mer information om hur du distribuerar RDMA för värden rekommenderar vi starkt att du använder Network ATC. Information om manuell distribution finns på SDN GitHub-lagringsplatsen.

iWARP

iWARP använder TCP (Transmission Control Protocol) och kan eventuellt utökas med prioritetsbaserad flödeskontroll (PFC) och förbättrad överföringstjänst (ETS).

Använd iWARP om:

• Du har inte erfarenhet av att hantera RDMA-nätverk.
• Du hanterar inte eller känner dig obekväm med att hantera toR-växlar (top-of-rack).
• Du kommer inte att hantera lösningen efter distributionen.
• Du har redan distributioner som använder iWARP.
• Du är osäker på vilket alternativ du ska välja.

Roce

RoCE använder UDP (User Datagram Protocol) och kräver att PFC och ETS tillhandahåller tillförlitlighet.

Använd RoCE om:

• Du har redan distributioner med RoCE i ditt datacenter.
• Du är bekväm med att hantera DCB-nätverkskraven.

Gäst-RDMA

Gäst-RDMA gör det möjligt för SMB-arbetsbelastningar för virtuella datorer att få samma fördelar med att använda RDMA på värdar.

Tillämpliga trafiktyper: Gästbaserad lagring

Certifieringar som krävs: Beräkning (Premium)

De främsta fördelarna med att använda RDMA för gäst är:

• CPU-avlastning till nätverkskortet för bearbetning av nätverkstrafik.
• Extremt låg svarstid.
• Högt dataflöde.

Mer information finns i ladda ned dokumentet från SDN GitHub-lagringsplatsen.

Växla inbäddad teamindelning (SET)

SET är en programvarubaserad teamindelningsteknik som har inkluderats i Windows Server-operativsystemet sedan Windows Server 2016. SET är den enda teamindelningstekniken som stöds av Azure Stack HCI. SET fungerar bra med beräknings-, lagrings- och hanteringstrafik och stöds med upp till åtta kort i samma team.

Tillämpliga trafiktyper: beräkning, lagring och hantering

Certifieringar som krävs: Compute (Standard) eller Compute (Premium)

SET är den enda teamindelningstekniken som stöds av Azure Stack HCI. SET fungerar bra med beräknings-, lagrings- och hanteringstrafik.

Viktigt

Azure Stack HCI stöder inte NIC-teamindelning med den äldre lastbalanserings-/redundansväxlingen (LBFO). Mer information om LBFO i Azure Stack HCI finns i blogginlägget Teaming in Azure Stack HCI (Teamindelning i Azure Stack HCI ).

SET är viktigt för Azure Stack HCI eftersom det är den enda teamtekniken som möjliggör:

• Teamindelning av RDMA-kort (om det behövs).
• Gäst-RDMA.
• Dynamisk VMMQ.
• Andra viktiga Azure Stack HCI-funktioner (se Teaming in Azure Stack HCI).

SET kräver användning av symmetriska (identiska) kort. Symmetriska nätverkskort är de som har samma:

• fabrikat (leverantör)
• modell (version)
• hastighet (dataflöde)
• konfiguration

I 22H2 identifierar och informerar Network ATC automatiskt om de kort som du har valt är asymmetriska. Det enklaste sättet att manuellt identifiera om korten är symmetriska är om hastigheterna och gränssnittsbeskrivningarna är exakta matchningar. De kan endast avvika i siffror som anges i beskrivningen. Använd cmdleten Get-NetAdapterAdvancedProperty för att säkerställa att den rapporterade konfigurationen visar samma egenskapsvärden.

Se följande tabell för ett exempel på gränssnittsbeskrivningar som endast avviker med siffror (#):

Name	Gränssnittsbeskrivning	Länkhastighet
NIC1	Nätverkskort nr 1	25 Gbit/s
NIC2	Nätverkskort nr 2	25 Gbit/s
NIC3	Nätverkskort nr 3	25 Gbit/s
NIC4	Nätverkskort nr 4	25 Gbit/s

Anteckning

SET stöder endast växeloberoende konfiguration med hjälp av algoritmer för dynamisk eller Hyper-V-portbelastningsutjämning. För bästa prestanda rekommenderas Hyper-V-Port för användning på alla nätverkskort som används med 10 Gbit/s eller mer. Network ATC gör alla nödvändiga konfigurationer för SET.

Överväganden för RDMA-trafik

Om du implementerar DCB måste du se till att PFC- och ETS-konfigurationen implementeras korrekt över alla nätverksportar, inklusive nätverksväxlar. DCB krävs för RoCE och valfritt för iWARP.

Om du vill ha detaljerad information om hur du distribuerar RDMA laddar du ned dokumentet från SDN GitHub-lagringsplatsen.

RoCE-baserade Azure Stack HCI-implementeringar kräver konfiguration av tre PFC-trafikklasser, inklusive standardtrafikklassen, i infrastrukturresurserna och alla värdar.

Klustertrafikklass

Den här trafikklassen säkerställer att det finns tillräckligt med bandbredd reserverad för klusterpulsslag:

• Krävs: Ja
• PFC-aktiverad: Nej
• Rekommenderad trafikprioritet: Prioritet 7
• Rekommenderad bandbreddsreservation:
  • 10 GbE eller lägre RDMA-nätverk = 2 procent
  • 25 GbE eller högre RDMA-nätverk = 1 procent

RDMA-trafikklass

Den här trafikklassen säkerställer att det finns tillräckligt med bandbredd reserverad för förlustfri RDMA-kommunikation med hjälp av SMB Direct:

• Krävs: Ja
• PFC-aktiverat: Ja
• Rekommenderad trafikprioritet: Prioritet 3 eller 4
• Rekommenderad bandbreddsreservation: 50 procent

Standardtrafikklass

Den här trafikklassen transporterar all annan trafik som inte definierats i kluster- eller RDMA-trafikklasserna, inklusive VM-trafik och hanteringstrafik:

• Obligatoriskt: Som standard (ingen konfiguration krävs på värden)
• Flödeskontroll (PFC)-aktiverad: Nej
• Rekommenderad trafikklass: Som standard (prioritet 0)
• Rekommenderad bandbreddsreservation: Som standard (ingen värdkonfiguration krävs)

Lagringstrafikmodeller

SMB ger många fördelar som lagringsprotokoll för Azure Stack HCI, inklusive SMB Multichannel. SMB Multichannel beskrivs inte i den här artikeln, men det är viktigt att förstå att trafik multiplexeras över alla möjliga länkar som SMB Multichannel kan använda.

Anteckning

Vi rekommenderar att du använder flera undernät och VLAN för att separera lagringstrafik i Azure Stack HCI.

Tänk dig följande exempel på ett kluster med fyra noder. Varje server har två lagringsportar (vänster och höger sida). Eftersom varje kort finns i samma undernät och VLAN sprider SMB Multichannel anslutningar över alla tillgängliga länkar. Därför upprättar den vänstra porten på den första servern (192.168.1.1) en anslutning till den vänstra porten på den andra servern (192.168.1.2). Den högra porten på den första servern (192.168.1.12) ansluter till den högra porten på den andra servern. Liknande anslutningar upprättas för den tredje och fjärde servern.

Detta skapar dock onödiga anslutningar och orsakar överbelastning vid interlänken (aggregeringsgruppen för flera chassin eller MC-LAG) som ansluter ToR-växlarna (markerade med X). Se följande diagram:

Den rekommenderade metoden är att använda separata undernät och VLAN för varje uppsättning kort. I följande diagram använder de högra portarna nu undernätet 192.168.2.x /24 och VLAN2. På så sätt kan trafik på portarna på vänster sida finnas kvar på TOR1 och trafiken på portarna på höger sida kan finnas kvar på TOR2.

Allokering av trafikbandbredd

I följande tabell visas exempel på bandbreddsallokeringar av olika trafiktyper, med vanliga korthastigheter, i Azure Stack HCI. Observera att detta är ett exempel på en konvergerad lösning, där alla trafiktyper (beräkning, lagring och hantering) körs över samma fysiska kort och teamindelade med hjälp av SET.

Eftersom det här användningsfallet utgör mest begränsningar representerar det en bra baslinje. Men med tanke på permutationerna för antalet kort och hastigheter bör detta betraktas som ett exempel och inte ett supportkrav.

Följande antaganden görs för det här exemplet:

• Det finns två kort per team.

• Storage Bus Layer (SBL), klusterdelad volym (CSV) och Hyper-V-trafik (direktmigrering):

  • Använd samma fysiska kort.
  • Använd SMB.

• SMB tilldelas en bandbreddsallokering på 50 procent med hjälp av DCB.

  • SBL/CSV är den trafik som har högst prioritet och tar emot 70 procent av reservationen för SMB-bandbredd.
  • Direktmigrering (LM) begränsas med hjälp av cmdleten Set-SMBBandwidthLimit och tar emot 29 procent av den återstående bandbredden.

    • Om den tillgängliga bandbredden för direktmigrering är >= 5 Gbit/s och nätverkskorten är kompatibla använder du RDMA. Använd följande cmdlet för att göra det:

      Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
      

    • Om den tillgängliga bandbredden för direktmigrering är < 5 Gbit/s använder du komprimering för att minska antalet strömavbrott. Använd följande cmdlet för att göra det:

      Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
      

• Om du använder RDMA för direktmigreringstrafik kontrollerar du att direktmigreringstrafiken inte kan använda hela bandbredden som allokerats till RDMA-trafikklassen med hjälp av en bandbreddsgräns för SMB. Var försiktig, eftersom denna cmdlet tar post i byte per sekund (bps), medan nätverkskort listas i bitar per sekund (bps). Använd följande cmdlet för att ange en bandbreddsgräns på 6 Gbit/s, till exempel:

  Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
  

  Anteckning

  750 MB/s i det här exemplet motsvarar 6 Gbit/s.

Här är exempeltabellen för bandbreddsallokering:

NIC-hastighet	Teamindelade bandbredder	Reservation av SMB-bandbredd**	SBL/CSV %	SBL/CSV-bandbredd	Direktmigrering %	Maximal bandbredd för direktmigrering	Pulsslag %	Pulsslagsbandbredd
10 Gbit/s	20 Gbit/s	10 Gbit/s	70 %	7 Gbit/s	**	200 Mbit/s
25 Gbit/s	50 Gbit/s	25 Gbit/s	70 %	17,5 Gbit/s	29%	7,25 Gbit/s	1 %	250 Mbit/s
40 Gbit/s	80 Gbit/s	40 Gbit/s	70 %	28 Gbit/s	29%	11,6 Gbit/s	1 %	400 Mbit/s
50 Gbit/s	100 Gbit/s	50 Gbit/s	70 %	35 Gbit/s	29%	14,5 Gbit/s	1 %	500 Mbit/s
100 Gbit/s	200 Gbit/s	100 Gbit/s	70 %	70 Gbit/s	29%	29 Gbit/s	1 %	1 Gbit/s
200 Gbit/s	400 Gbit/s	200 Gbit/s	70 %	140 Gbit/s	29%	58 Gbit/s	1 %	2 Gbit/s

* Använd komprimering i stället för RDMA eftersom bandbreddsallokeringen för direktmigreringstrafik är <5 Gbit/s.

** 50 procent är ett exempel på en bandbreddsreservation.

Stretchkluster

Stretchkluster ger haveriberedskap som omfattar flera datacenter. I sin enklaste form ser ett stretchat Azure Stack HCI-klusternätverk ut så här:

Krav för stretchkluster

Stretchkluster har följande krav och egenskaper:

• RDMA är begränsat till en enda plats och stöds inte på olika platser eller undernät.

• Servrar på samma plats måste finnas i samma rack och Layer-2-gräns.

• Värdkommunikation mellan platser måste korsa en Layer-3-gräns. stretch Layer-2-topologier stöds inte.

• Ha tillräckligt med bandbredd för att köra arbetsbelastningarna på den andra platsen. I händelse av en redundansväxling måste den alternativa platsen köra all trafik. Vi rekommenderar att du etablerar platser med 50 procent av deras tillgängliga nätverkskapacitet. Detta är dock inte ett krav om du kan tolerera lägre prestanda under en redundansväxling.

• Replikering mellan platser (nord-/sydtrafik) kan använda samma fysiska nätverkskort som den lokala lagringen (öst/väst-trafik). Om du använder samma fysiska kort måste dessa kort vara teamindelade med SET. Korten måste också ha ytterligare virtuella nätverkskort etablerade för dirigerbar trafik mellan platser.

• Kort som används för kommunikation mellan platser:

  • Kan vara fysiskt eller virtuellt (värd-vNIC). Om korten är virtuella måste du etablera ett virtuellt nätverkskort i ett eget undernät och VLAN per fysiskt nätverkskort.

  • Måste finnas i ett eget undernät och VLAN som kan dirigeras mellan platser.

  • RDMA måste inaktiveras med hjälp av cmdleten Disable-NetAdapterRDMA . Vi rekommenderar att du uttryckligen kräver att Storage Replica använder specifika gränssnitt med hjälp av cmdleten Set-SRNetworkConstraint .

  • Måste uppfylla eventuella ytterligare krav för Storage Replica.

Stretchklusterexempel

I följande exempel visas en stretchklusterkonfiguration. För att säkerställa att ett specifikt virtuellt nätverkskort har mappats till ett specifikt fysiskt kort använder du cmdleten Set-VMNetworkAdapterTeammapping .

Nedan visas information om exemplet på stretchklusterkonfiguration.

Anteckning

Din exakta konfiguration, inklusive nätverkskortsnamn, IP-adresser och VLAN, kan skilja sig från vad som visas. Detta används endast som en referenskonfiguration som kan anpassas till din miljö.

SiteA – lokal replikering, RDMA-aktiverad, icke-dirigerbar mellan platser

Nodnamn	vNIC-namn	Fysiskt nätverkskort (mappat)	VLAN	IP och undernät	Trafikomfång
NodeA1	vSMB01	pNIC01	711	192.168.1.1/24	Endast lokal webbplats
NodeA2	vSMB01	pNIC01	711	192.168.1.2/24	Endast lokal webbplats
NodeA1	vSMB02	pNIC02	712	192.168.2.1/24	Endast lokal webbplats
NodeA2	vSMB02	pNIC02	712	192.168.2.2/24	Endast lokal webbplats

SiteB – lokal replikering, RDMA-aktiverad, icke-dirigerbar mellan platser

Nodnamn	vNIC-namn	Fysiskt nätverkskort (mappat)	VLAN	IP och undernät	Trafikomfång
NodeB1	vSMB01	pNIC01	711	192.168.1.1/24	Endast lokal webbplats
NodeB2	vSMB01	pNIC01	711	192.168.1.2/24	Endast lokal webbplats
NodeB1	vSMB02	pNIC02	712	192.168.2.1/24	Endast lokal webbplats
NodeB2	vSMB02	pNIC02	712	192.168.2.2/24	Endast lokal webbplats

SiteA – Stretchad replikering, RDMA inaktiverad, dirigerbar mellan platser

Nodnamn	vNIC-namn	Fysiskt nätverkskort (mappat)	IP och undernät	Trafikomfång
NodeA1	Stretch1	pNIC01	173.0.0.1/8	Routningsbar mellan platser
NodeA2	Stretch1	pNIC01	173.0.0.2/8	Routningsbar mellan platser
NodeA1	Stretch2	pNIC02	174.0.0.1/8	Routningsbar mellan platser
NodeA2	Stretch2	pNIC02	174.0.0.2/8	Routningsbar mellan platser

SiteB – Utsträckt replikering, RDMA inaktiverad, dirigerbar mellan platser

Nodnamn	vNIC-namn	Fysiskt nätverkskort (mappat)	IP och undernät	Trafikomfång
NodeB1	Stretch1	pNIC01	175.0.0.1/8	Routningsbar mellan platser
NodeB2	Stretch1	pNIC01	175.0.0.2/8	Routningsbar mellan platser
NodeB1	Stretch2	pNIC02	176.0.0.1/8	Routningsbar mellan platser
NodeB2	Stretch2	pNIC02	176.0.0.2/8	Routningsbar mellan platser

Nästa steg

• Läs mer om nätverksväxel och fysiska nätverkskrav. Se Krav för fysiskt nätverk.
• Lär dig hur du förenklar värdnätverk med hjälp av Network ATC. Se Förenkla värdnätverk med Network ATC.
• Borsta upp grunderna för redundansklustring i nätverk.
• Se Distribuera med Azure Portal.
• Se Distribuera med ARM-mall.