Fysiska nätverkskrav för Azure Stack HCI
Gäller för: Azure Stack HCI, version 23H2 och 22H2
I den här artikeln beskrivs fysiska nätverksöverväganden och krav för Azure Stack HCI, särskilt för nätverksväxlar.
Anteckning
Kraven för framtida Azure Stack HCI-versioner kan ändras.
Nätverksväxlar för Azure Stack HCI
Microsoft testar Azure Stack HCI enligt de standarder och protokoll som identifieras i avsnittet Krav för nätverksväxel nedan. Även om Microsoft inte certifierar nätverksväxlar samarbetar vi med leverantörer för att identifiera enheter som stöder Azure Stack HCI-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 Stack HCI 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 Stack HCI-kraven för dina angivna rolltyper. Följande leverantörer (i alfabetisk ordning) har bekräftat att deras växlar stöder Azure Stack HCI-krav:
Klicka på en leverantörsflik för att se verifierade växlar för var och en av Azure Stack HCI-trafiktyperna. Dessa nätverksklassificeringar finns här.
Viktigt
Vi uppdaterar dessa listor när vi informeras om ändringar av nätverksväxelleverantörer.
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 Azure Stack HCI-distributioner. Dessa standarder hjälper till att säkerställa tillförlitlig kommunikation mellan noder i Azure Stack HCI-klusterdistributioner.
Anteckning
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 | ✓ | ✓ | ✓ | ✓ |
| Kontroll av prioritetsflöde | ✓ | |||
| 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 | ✓ | |||
| BGP (Border Gateway Protocol) | ✓ | |||
| DHCP Relay Agent | ✓ |
Anteckning
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 Stack HCI och krävs i alla scenarier.
Standard: IEEE 802.1Qbb
Ethernet-växlar som används för Azure Stack HCI-lagringstrafik måste uppfylla 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 Azure Stack HCI-lagringstrafik måste uppfylla 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).
Anteckning
Hyperkonvergerad infrastruktur har ett stort beroende av East-West Layer-2-kommunikation i samma rack och kräver därför ETS. Microsoft testar inte Azure Stack HCI med DSCP (Differentiated Services Code Point).
Standard: IEEE 802.1AB
Ethernet-växlar måste uppfylla IEEE 802.1AB-specifikationen som definierar LLDP (Link Layer Discovery Protocol). LLDP krävs för Azure Stack HCI och möjliggör felsökning av fysiska nätverkskonfigurationer.
Konfigurationen av LLDP Type-Length-Values (TLV: er) 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 värdet LLDP TLV Type 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.
BGP (Border Gateway Protocol)
Ethernet-växlar som används för Azure Stack HCI 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 Azure Stack HCI-hanteringstrafik måste ha stöd för DHCP-reläagent. 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 Stack HCI kan fungera i olika datacenterarkitekturer, inklusive 2-nivå (Spine-Leaf) och 3-tier (Core-Aggregation-Access). Det här avsnittet handlar mer om begrepp från Spine-Leaf topologi som ofta används med arbetsbelastningar i hyperkonvergerad infrastruktur, till exempel Azure Stack HCI.
Nätverksmodeller
Nätverkstrafik kan klassificeras enligt dess riktning. Traditionella SAN-miljöer (Storage Area Network) är mycket North-South där trafiken flödar från en beräkningsnivå till en lagringsnivå över en Ip-gräns (Layer-3). Hyperkonvergerad infrastruktur är mer East-West där en betydande del av trafiken stannar inom en VLAN-gräns (Layer-2).
Viktigt
Vi rekommenderar starkt att alla klusternoder på en plats finns fysiskt i samma rack och är anslutna till samma ToR-växlar (top-of-rack).
North-South trafik för Azure Stack HCI
North-South trafik 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 stretchklustertrafik mellan platser.
- Använder en Ethernet-växel för anslutning till det fysiska nätverket.
East-West trafik för Azure Stack HCI
East-West trafik 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 kluster och (om du använder ett sträckt kluster) på samma plats.
- Kan använda en Ethernet-switch (växlad) eller en direktanslutning (switchless), enligt beskrivningen i de kommande två avsnitten.
Använda växlar
North-South trafik 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 Stack HCI är den viktigaste aspekten en korrekt storleksändring av nätverksinfrastrukturresurserna.
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 sammansättningsgruppen 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 Stack HCI stöder växellösa (direkta) anslutningar för East-West trafik för alla klusterstorlekar så länge varje nod i klustret har en redundant anslutning till varje nod i klustret. Detta kallas för en "full-mesh"-anslutning.
| Gränssnittspar | Undernät | VLAN |
|---|---|---|
| Mgmt-värd-vNIC | Kundspecifik | Kundspecifik |
| SMB01 | 192.168.71.x/24 | 711 |
| SMB02 | 192.168.72.x/24 | 712 |
| SMB03 | 192.168.73.x/24 | 713 |
Anteckning
Fördelarna med växellösa distributioner minskar med kluster som är större än tre noder på grund av det antal nätverkskort som krävs.
Fördelar med växellösa anslutningar
- Inget bytesköp krävs för East-West trafik. En växel krävs för North-South trafik. Detta kan leda till lägre kapitalutgifter (CAPEX) men är beroende av antalet noder i klustret.
- 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 klusterstorleken ökar.
Nackdelar med växellö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 North-South åtkomst kan inte använda dessa kort.
- I takt med att antalet noder i klustret växer kan kostnaden för nätverkskort överstiga kostnaden för att använda nätverksväxlar.
- Skalas inte långt bortom kluster med tre noder. Fler noder ådrar sig ytterligare kablar och konfigurationer som kan överskrida komplexiteten med att använda en växel.
- Klusterexpansionen är komplex och kräver ändringar i maskinvaru- och programvarukonfigurationen.
Nästa steg
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för