Värdnätverkskrav för Azure Stack HCI

Gäller för: Azure Stack HCI, version 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 storage replica traffic or traffic used by the administrator for management of the cluster like Remote Desktop, Windows Admin Center, Active Directory, etc.
• Beräkningstrafik: Trafik som kommer från eller är avsedd för en virtuell dator (VM).
• Lagringstrafik: Trafik med hjälp av SMB (Server Message Block), till exempel Lagringsdirigering eller SMB-baserad direktmigrering. Den här trafiken är layer-2-trafik och kan inte dirigeras.

Välj ett nätverkskort

Nätverkskort är kvalificerade av nätverkstrafiktyperna (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 trafiktyperna krävs på Azure Stack HCI. Du kan sedan använda Network ATC för att konfigurera dina kort för lämpliga trafiktyper.

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

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 funktioner för nyckelnä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)
• RDMA-gäst
• 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-teamindelning.

Tillämpliga trafiktyper: beräkning

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

Dynamisk VMMQ är en intelligent teknik på mottagarsidan. Den bygger på dess föregångare virtual machine queue (VMQ), virtual receive side scaling (vRSS) och VMMQ för att tillhandahålla tre primära förbättringar:

• Optimerar värdeffektiviteten med färre CPU-kä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 det möjligt för "bursty"-arbetsbelastningar att 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 av 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 nätverkskort 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 iWARP (Internet Wide Area RDMA Protocol) eller RDMA via konvergerade Ethernet-protokollimplementeringar (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.

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 i SDN GitHub-lagringsplatsen.

iWARP

iWARP använder TCP (Transmission Control Protocol) och kan eventuellt utökas med PFC (Priority-based Flow Control) och Enhanced Transmission Service (ETS).

Använd iWARP om:

• Du har inte erfarenhet av att hantera RDMA-nätverk.
• Du hanterar inte eller är 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 PFC och ETS för att ge 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.

RDMA-gäst

Med gäst-RDMA kan SMB-arbetsbelastningar för virtuella datorer 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: Beräkning (Standard) eller Beräkning (Premium)

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

SET är viktigt för Azure Stack HCI eftersom det är den enda teamindelningstekniken 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 i 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 den siffra som anges i beskrivningen. Använd cmdleten Get-NetAdapterAdvancedProperty för att se till att den rapporterade konfigurationen visar samma egenskapsvärden.

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

Överväganden för RDMA-trafik

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

Detaljerad information om hur du distribuerar RDMA finns i ladda ned dokumentet från SDN GitHub-lagringsplatsen.

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

Klustertrafikklass

Den här trafikklassen ser till att det finns tillräckligt med bandbredd reserverad för klusterpulsslag:

• Obligatoriskt: Ja
• PFC-aktiverat: 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 ser till att det finns tillräckligt med bandbredd reserverad för förlustfri RDMA-kommunikation med hjälp av SMB Direct:

• Obligatoriskt: 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)

Modeller för lagringstrafik

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 trafiken multiplexeras över alla möjliga länkar som SMB Multichannel kan använda.

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 Xs). 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å vänster portar finnas kvar på TOR1 och trafiken på de högra portarna förblir 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 samarbetar med SET.

Eftersom det här användningsfallet utgör de flesta 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), klusterdelade volymer (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 högst prioriterade trafiken och tar emot 70 procent av SMB-bandbreddsreservationen.
  • 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 den här cmdleten tar post i byte per sekund (bps), medan nätverkskort visas 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
  

  Kommentar

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

Här är exempeltabellen för bandbreddsallokering:

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

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

Utsträckta kluster

Stretchkluster ger haveriberedskap som omfattar flera datacenter. I sin enklaste form ser ett utsträckt 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 till 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.

• 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 sitt eget undernät och VLAN per fysiskt nätverkskort.

  • Måste finnas i sitt 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.

Nästa steg

• Lär dig mer om nätverksväxel och krav på fysiskt nätverk. 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 redundansklustringsnätverk.
• Se Distribuera med Hjälp av Azure-portalen.
• Se Distribuera med Hjälp av Azure Resource Manager-mall.