Dela via

Fysiska nätverkskrav för Azure Local

  • Artikel

Gäller för: Azure Local, version 23H2 och 22H2

I den här artikeln beskrivs fysiska nätverksöverväganden och krav för Azure Local, särskilt för nätverksväxlar.

Kommentar

Kraven för framtida lokala Azure-versioner kan ändras.

Nätverksväxlar för Azure Local

Microsoft testar Azure Local enligt de standarder och protokoll som identifieras i avsnittet Krav för nätverksväxling nedan. Även om Microsoft inte certifierar nätverksväxlar samarbetar vi med leverantörer för att identifiera enheter som stöder Lokala Azure-krav.

Viktigt!

Även om andra nätverksväxlar som använder tekniker och protokoll som inte anges här kan fungera, kan Microsoft inte garantera att de fungerar med Azure Local och kanske inte kan hjälpa till med felsökningsproblem som inträffar.

När du köper nätverksväxlar kontaktar du switchleverantören och ser till att enheterna uppfyller Azure Local-kraven för dina angivna rolltyper. Följande leverantörer (i alfabetisk ordning) har bekräftat att deras växlar stöder Azure Local-krav:

Klicka på en leverantörsflik för att se verifierade växlar för var och en av de lokala Azure-trafiktyperna. Dessa nätverksklassificeringar finns här.

Viktigt!

Vi uppdaterar de här listorna när vi informeras om ändringar av leverantörer av nätverksväxlar.

Om växeln inte ingår kontaktar du switchleverantören för att se till att växelmodellen och versionen av växelns operativsystem stöder kraven i nästa avsnitt.

Krav för nätverksväxel

Det här avsnittet innehåller branschstandarder som är obligatoriska för de specifika rollerna för nätverksväxlar som används i lokala Azure-distributioner. Dessa standarder hjälper till att säkerställa tillförlitlig kommunikation mellan noder i Lokala Azure-distributioner.

Kommentar

Nätverkskort som används för beräknings-, lagrings- och hanteringstrafik kräver Ethernet. Mer information finns i Krav för värdnätverk.

Här är de obligatoriska IEEE-standarderna och specifikationerna:

Rollkrav för 23H2

Krav Hantering Storage Beräkning (Standard) Beräkning (SDN)
Virtuella LAN ✓ ✓ ✓ ✓
Prioritetsflödeskontroll ✓
Förbättrad överföringsmarkering ✓
LLDP-port-VLAN-ID ✓
LLDP VLAN-namn ✓ ✓ ✓
LLDP Link Aggregation ✓ ✓ ✓ ✓
LLDP ETS-konfiguration ✓
LLDP ETS-rekommendation ✓
LLDP PFC-konfiguration ✓
MAXIMAL RAMSTORLEK FÖR LLDP ✓ ✓ ✓ ✓
Maximal överföringsenhet ✓
Border Gateway Protocol ✓
DHCP Relay-agent ✓

Kommentar

Gäst-RDMA kräver både Compute (Standard) och Storage.

Standard: IEEE 802.1Q

Ethernet-växlar måste uppfylla IEEE 802.1Q-specifikationen som definierar VLAN. VLAN krävs för flera aspekter av Azure Local och krävs i alla scenarier.

Standard: IEEE 802.1Qbb

Ethernet-växlar som används för lokal Azure-lagringstrafik måste följa IEEE 802.1Qbb-specifikationen som definierar PFC (Priority Flow Control). PFC krävs där Data Center Bridging (DCB) används. Eftersom DCB kan användas i både RoCE- och iWARP RDMA-scenarier krävs 802.1Qbb i alla scenarier. Minst tre cos-prioriteringar (Class of Service) krävs utan att bryta ned växelfunktionerna eller porthastigheterna. Minst en av dessa trafikklasser måste tillhandahålla förlustfri kommunikation.

Standard: IEEE 802.1Qaz

Ethernet-växlar som används för Lokal Azure-lagringstrafik måste följa IEEE 802.1Qaz-specifikationen som definierar Enhanced Transmission Select (ETS). ETS krävs där DCB används. Eftersom DCB kan användas i både RoCE- och iWARP RDMA-scenarier krävs 802.1Qaz i alla scenarier.

Minst tre CoS-prioriteringar krävs utan att bryta ned växelfunktionerna eller porthastigheten. Om din enhet dessutom tillåter att inkommande QoS-priser definieras rekommenderar vi att du inte konfigurerar inkommande priser eller konfigurerar dem till exakt samma värde som utgående priser (ETS).

Kommentar

Hyperkonvergerad infrastruktur har ett stort beroende av kommunikation mellan öst och väst layer-2 i samma rack och kräver därför ETS. Microsoft testar inte Azure Local med DSCP (Differentiated Services Code Point).

Standard: IEEE 802.1AB

Ethernet-växlar måste uppfylla IEEE 802.1AB-specifikationen som definierar LINK Layer Discovery Protocol (LLDP). LLDP krävs för Azure Local och möjliggör felsökning av fysiska nätverkskonfigurationer.

Konfigurationen av LLDP Type-Length-Values (TV-apparater) måste vara dynamiskt aktiverad. Växlar får inte kräva ytterligare konfiguration utöver aktivering av en specifik TLV. Om du till exempel aktiverar 802.1 Undertyp 3 bör du automatiskt annonsera alla VLAN som är tillgängliga på växelportar.

Anpassade TLV-krav

MED LLDP kan organisationer definiera och koda sina egna anpassade TV-apparater. Dessa kallas organisatoriskt specifika TV-apparater. Alla organisationsspecifika TV-apparater börjar med ett LLDP TLV-typvärde på 127. Tabellen nedan visar vilka undertyper av organisationsspecifik anpassad TLV (TLV-typ 127) som krävs.

Organisation TLV-undertyp
IEEE 802.1 Port-VLAN-ID (undertyp = 1)
IEEE 802.1 VLAN-namn (undertyp = 3)
Minst 10 VLANS
IEEE 802.1 Länkaggregering (undertyp = 7)
IEEE 802.1 ETS-konfiguration (undertyp = 9)
IEEE 802.1 ETS-rekommendation (undertyp = A)
IEEE 802.1 PFC-konfiguration (undertyp = B)
IEEE 802.3 Maximal ramstorlek (undertyp = 4)

Maximal överföringsenhet

Den maximala överföringsenheten (MTU) är den största storleksramen eller paketet som kan överföras via en datalänk. Ett intervall mellan 1514 och 9174 krävs för SDN-inkapsling.

Border Gateway Protocol

Ethernet-växlar som används för Azure Local SDN-beräkningstrafik måste ha stöd för BGP (Border Gateway Protocol). BGP är ett standardroutningsprotokoll som används för att utbyta routnings- och nåbarhetsinformation mellan två eller flera nätverk. Vägar läggs automatiskt till i routningstabellen för alla undernät med BGP-spridning aktiverat. Detta krävs för att aktivera klientarbetsbelastningar med SDN och dynamisk peering. RFC 4271: Border Gateway Protocol 4

DHCP Relay-agent

Ethernet-växlar som används för lokal Azure-hanteringstrafik måste ha stöd för DHCP Relay-agenten. DHCP Relay-agenten är en TCP/IP-värd som används för att vidarebefordra begäranden och svar mellan DHCP-servern och klienten när servern finns i ett annat nätverk. Det krävs för PXE-starttjänster. RFC 3046: DHCPv4 eller RFC 6148: DHCPv4

Nätverkstrafik och arkitektur

Det här avsnittet är främst för nätverksadministratörer.

Azure Local kan fungera i olika datacenterarkitekturer, inklusive 2-nivå (Spine-Leaf) och 3-nivå (Core-Aggregation-Access). Det här avsnittet refererar mer till begrepp från spine-leaf-topologin som ofta används med arbetsbelastningar i hyperkonvergerad infrastruktur, till exempel Azure Local.

Nätverksmodeller

Nätverkstrafiken kan klassificeras enligt dess riktning. San-miljöer (Traditional Storage Area Network) är starkt nord-syd där trafiken flödar från en beräkningsnivå till en lagringsnivå över en Ip-gräns (Layer-3). Hyperkonvergerad infrastruktur är tyngre, öst-väst, där en betydande del av trafiken ligger inom en VLAN-gräns (Layer-2).

Viktigt!

Vi rekommenderar starkt att alla Lokala Azure-datorer på en plats finns fysiskt i samma rack och ansluts till samma ToR-växlar (top-of-rack).

Kommentar

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

Nord-syd-trafik för Azure Local

Trafiken nord-syd har följande egenskaper:

  • Trafiken flödar ut från en ToR-växel till ryggraden eller in från ryggraden till en ToR-växel.
  • Trafiken lämnar det fysiska racket eller korsar en Layer-3-gräns (IP).
  • Innehåller hantering (PowerShell, Windows Admin Center), beräkning (VM) och klustertrafik mellan platser.
  • Använder en Ethernet-växel för anslutning till det fysiska nätverket.

Trafik mellan öst och väst för Azure Local

Trafiken mellan öst och väst har följande egenskaper:

  • Trafiken ligger kvar inom ToR-växlarna och Layer-2-gränsen (VLAN).
  • Innehåller lagringstrafik eller direktmigreringstrafik mellan noder i samma system och (om du använder ett sträckt kluster) på samma plats.
  • Kan använda en Ethernet-växel (växlad) eller en direktanslutning (växellös) enligt beskrivningen i de kommande två avsnitten.

Använda växlar

Trafik mellan nord och syd kräver användning av växlar. Förutom att använda en Ethernet-växel som stöder de protokoll som krävs för Azure Local är den viktigaste aspekten korrekt storleksändring av nätverksinfrastrukturen.

Det är absolut nödvändigt att förstå den "icke-blockerande" infrastrukturbandbredd som ethernet-växlarna kan stödja och att du minimerar (eller helst eliminerar) överprenumereringen av nätverket.

Vanliga överbelastningspunkter och överprenumerationer, till exempel aggregeringsgruppen Multi-Chassis Link som används för sökvägsredundans, kan elimineras genom korrekt användning av undernät och VLAN. Se även Krav för värdnätverk.

Samarbeta med nätverksleverantören eller nätverkssupportteamet för att se till att nätverksväxlarna har rätt storlek för den arbetsbelastning som du tänker köra.

Använda switchless

Azure Local stöder växellösa (direkta) anslutningar för trafik mellan öst och väst för alla systemstorlekar så länge varje nod i systemet har en redundant anslutning till varje nod i systemet. Detta kallas för en "full mesh"-anslutning.

Diagram som visar växlingslös anslutning med fullständigt nät

Gränssnittspar Undernät VLAN
Mgmt-värd för virtuellt nätverkskort Kundspecifik Kundspecifik
SMB01 192.168.71.x/24 711
SMB02 192.168.72.x/24 712
SMB03 192.168.73.x/24 713

Kommentar

Fördelarna med växellösa distributioner minskar med system som är större än tre noder på grund av det antal nätverkskort som krävs.

Fördelar med växlingslösa anslutningar

  • Inget bytesköp krävs för trafik mellan öst och väst. En växel krävs för trafik mellan nord och syd. Detta kan leda till lägre kapitalutgifter (CAPEX) men är beroende av antalet noder i systemet.
  • Eftersom det inte finns någon växel är konfigurationen begränsad till värden, vilket kan minska det potentiella antalet konfigurationssteg som behövs. Det här värdet minskar när systemstorleken ökar.

Nackdelar med växlingslösa anslutningar

  • Mer planering krävs för IP- och undernätsadresseringsscheman.
  • Ger endast åtkomst till lokal lagring. Hanteringstrafik, VM-trafik och annan trafik som kräver åtkomst mellan nord och syd kan inte använda dessa kort.
  • När antalet noder i systemet växer kan kostnaden för nätverkskort överskrida kostnaden för att använda nätverksväxlar.
  • Skalas inte långt bortom system med tre noder. Fler noder ådrar sig ytterligare kablar och konfigurationer som kan överträffa komplexiteten med att använda en växel.
  • Systemexpansionen är komplex och kräver ändringar i maskinvaru- och programvarukonfigurationen.

Nästa steg