Dela via

Värdnätverkskrav för Azure Local

  • Artikel

Gäller för: Azure Local 2311.2 och senare

I det här avsnittet beskrivs överväganden och krav för värdnätverk för Azure Local. Information om datacenterarkitekturer och fysiska anslutningar mellan datorer finns i Krav för fysiskt nätverk.

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

Azures lokala nätverkstrafik kan klassificeras enligt dess avsedda syfte:

  • Hanteringstrafik: Trafik till eller från utanför det lokala systemet. Till exempel replikeringstrafik för lagring eller trafik som används av administratören för systemhantering, såsom Remote Desktop, Windows Admin Center, Active Directory, osv.
  • 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 Storage Spaces Direct eller SMB-baserad live-migrering. Den här trafiken är layer-2-trafik och kan inte dirigeras.

Viktigt!

Lagringsreplikering använder icke-RDMA-baserad SMB-trafik. Detta och trafikens riktning (nord-syd) gör att den överensstämmer väl med "hanteringstrafiken" som anges ovan, ungefär som en traditionell fildelning.

Välj ett nätverkskort

Nätverkskort kvalificeras av de nätverkstrafiktyper (se ovan) som de stöds för att användas 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 maskin för Azure Local måste du minst ha en adapter som uppfyller kraven för hantering, beräkning och lagring, eftersom alla tre trafiktyperna krävs på Azure Local. Du kan sedan använda Network ATC för att konfigurera dina adaptrar för lämpliga trafiktyper.

Mer information om den här rollbaserade NIC-kvalificeringen finns i det här blogginlägget om Windows Server.

Viktigt!

Att använda en adapter för andra trafiktyper än de den är kvalificerad för stöds inte.

Nivå Ledningsroll Beräkningsroll Rollen för Lagring
Rollbaserad skillnad Ledning Beräkningsstandard Storage Standard
Maximalt pris Inte tillämpligt Compute Premium Storage Premium

Kommentar

Den högsta kvalificeringen för alla adaptrar i vårt ekosystem kommer att innehålla kvalifikationerna Management, Compute Premium och Storage Premium.

Skärmbild som visar kvalifikationer för

Krav för förare

Inkorgsdrivrutiner stöds inte för användning med Azure Local. Kör följande cmdlet för att identifiera om adaptern använder en inkorgsdrivrutin. En adapter använder en inkorgsdrivrutin om egenskapen DriverProvider är Microsoft.

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

Översikt över viktiga nätverkskorts funktioner

Viktiga funktioner för nätverkskort som används av Azure Local ä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 anpassning av nätverkstrafikbearbetning till processor-kärnor, vilket gör det möjligt för VM:ar att uppfylla och upprätthålla förväntad genomströmning.
  • Möjliggör för spikartade arbetslaster att ta emot den förväntade trafiken.

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 minimalt värd-CPU-resurser. 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 Local har stöd för RDMA med 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, angivna i alfabetisk ordning, som erbjuder certifierade RDMA-adaptrar. 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 adaptrar med kvalifikationen Storage (Standard) eller Storage (Premium) som kräver RDMA-stöd.

Anteckning

InfiniBand (IB) stöds inte med Azure Local.

NIC-leverantör iWARP RoCE
Broadcom Nej Ja
Intel Ja Ja (vissa modeller)
Marvell (Qlogic) Ja Ja
Nvidia Nej Ja

Om du vill ha mer information om hur du distribuerar RDMA för värdmaskinen rekommenderas det 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 ToR-växlar (top-of-rack) eller känner dig obekväm med att göra det.
  • 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 utplaceringar 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ög genomströmning.

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

Switch Embedded Teaming (SET)

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

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

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

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

Viktigt!

Azure Local stöder inte NIC teaming med den äldre lastbalanserings-/felväxlingen (LBFO). Mer information om LBFO i Azure Local finns i blogginlägget Teamindelning i Azure Local .

SET är viktigt för Azure Local 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 lokala Azure-funktioner (se Teaming in Azure Local).

SET kräver användning av symmetriska (identiska) adaptrar. 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 adaptrar som du har valt är asymmetriska. Det enklaste sättet att manuellt identifiera om adaptrarna är symmetriska är om hastigheterna och gränssnittsbeskrivningarna är exakta överensstämmelser. 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 (#):

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 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 lokala Azure-implementeringar kräver konfiguration av tre PFC-trafikklasser, inklusive standardtrafikklassen, i infrastrukturresurserna och alla värdar.

Systemtrafikklass

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

  • 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 system- eller RDMA-trafikklasserna, inklusive VM-trafik och hanteringstrafik:

  • Obligatoriskt: Som standard (ingen konfiguration krävs på värddatorn)
  • 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 Local, 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.

Anteckning

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

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

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:

Diagram som visar ett system med fyra noder i samma undernät.

Den rekommenderade metoden är att använda separata undernät och VLAN för varje uppsättning adaptrar. 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.

Diagram som visar ett system med fyra noder i olika undernät.

Allokering av trafikbandbredd

I följande tabell visas exempel på bandbreddsallokeringar av olika trafiktyper, med vanliga adaptrarshastigheter, i Azure Local. 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 grupperas 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å adaptrar per team.

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

    • Använd samma fysiska adaptrar.
    • 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 inmatning 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

    Anteckning

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

Här är exempeltabellen för bandbreddsallokering:

NIC-hastighet Samlad bandbredd SMB-bandbreddsreservation** SBL/CSV % SBL/CSV-bandbredd Direktmigrering % Maximal bandbredd för direktmigrering Pulsslag % Bandbredd för pulsslag
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å bandbreddsreservation.

Utsträckta kluster

Utsträckta kluster ger katastrofåterställning som omfattar flera datacenter. I sin enklaste form ser ett utsträckt kluster av Azure Local ut så här:

Diagram som visar ett utsträckt kluster.

Krav för utsträckta kluster

Viktigt!

Stretchklusterfunktioner är endast tillgängliga i Azure Local, version 22H2.

Följande krav och egenskaper gäller för stretchkluster:

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

  • Datorer 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. Utsträckta 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 tilldelar webbplatser 50 procent av den tillgängliga nätverkskapaciteten. Detta är dock inte ett krav om du kan tolerera lägre prestanda under en redundansväxling.

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

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

    • Måste finnas i sitt eget undernät och VLAN som kan routas 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