Planering av nätverksintegrering för Azure Stack Hub

Den här artikeln innehåller information om Azure Stack Hub-nätverksinfrastruktur som hjälper dig att bestämma hur du bäst integrerar Azure Stack Hub i din befintliga nätverksmiljö.

Anteckning

För att lösa externa DNS-namn från Azure Stack Hub (till exempel www.bing.com) måste du ange DNS-servrar som DNS-begäranden ska vidarebefordras till. Mer information om DNS-krav för Azure Stack Hub finns i Integrering av Azure Stack Hub-datacenter – DNS-.

Design av fysiskt nätverk

Azure Stack Hub-lösningen kräver en motståndskraftig och högtillgänglig fysisk infrastruktur för att stödja driften och tjänsterna. För att integrera Azure Stack Hub i nätverket kräver det överlänkar från ToR (Top-of-Rack-växlar) till närmaste växel eller router, som i den här artikeln kallas Border. ToRs kan överordnas till ett enskilt eller ett par kantlinjer. ToR är förkonfigurerad av vårt automatiseringsverktyg. Den förväntar sig minst en anslutning mellan ToR och Border när du använder BGP-routning, och minst två anslutningar (en per ToR) mellan ToR och Border när du använder statisk routning, med högst fyra anslutningar på något av routningsalternativen. Dessa anslutningar är begränsade till SFP+ eller SFP28-media och minst en GB-hastighet. Kontakta oem-maskinvaruleverantören (originalutrustningstillverkaren) för att få tillgång till den. Följande diagram visar den rekommenderade designen:

Bandbreddsallokering

Azure Stack Hub är byggt med Windows Server 2019 Failover-kluster och Spaces Direct-teknik. För att säkerställa att spaces direct-lagringskommunikationen kan uppfylla de prestanda och skalning som krävs för lösningen konfigureras en del av den fysiska nätverkskonfigurationen i Azure Stack Hub för att använda trafikseparation och bandbreddsgarantier. Nätverkskonfigurationen använder trafikklasser för att separera Spaces Direct, RDMA-baserad kommunikation från nätverksanvändningen av Azure Stack Hub-infrastrukturen och/eller klienter. För att anpassa till de aktuella bästa praxis som har definierats för Windows Server 2019, kommer Azure Stack Hub att ändra sig till att använda en ytterligare trafikklass eller prioritet för att ytterligare separera server-till-server-kommunikation till stöd för failoverklustringens kontrollkommunikation. Den här nya trafikklassdefinitionen är konfigurerad för att reservera 2% av den tillgängliga fysiska bandbredden. Den här konfigurationen av trafikklasser och bandbreddsreservation utförs genom en ändring på ToR-växlar (top-of-rack) för Azure Stack Hub-lösningen och på värden eller servrarna i Azure Stack Hub. Observera att ändringar inte krävs på kundens gränsnätverksenheter. Dessa ändringar ger bättre återhämtning för kommunikation med redundanskluster och är avsedda att undvika situationer där nätverksbandbredden förbrukas fullt ut och som ett resultat av detta avbryts redundansklusterkontrollmeddelanden. Observera att kommunikationen med failoverkluster är en kritisk komponent i Azure Stack Hub-infrastrukturen och om den störs under långa perioder kan det leda till instabilitet i Spaces Direct-lagringstjänsterna eller andra tjänster som så småningom påverkar arbetsbelastningsstabiliteten för hyresgäster eller slutanvändare.

Logiska nätverk

Logiska nätverk representerar en abstraktion av den underliggande fysiska nätverksinfrastrukturen. De används för att organisera och förenkla nätverkstilldelningar för värdar, virtuella datorer och tjänster. Som en del av skapande av logiskt nätverk skapas nätverksplatser för att definiera virtuella lokala nätverk (VLAN), IP-undernät och IP-undernät/VLAN-par som är associerade med det logiska nätverket på varje fysisk plats.

I följande tabell visas de logiska nätverk och associerade IPv4-undernätsintervall som du måste planera för:

Logiskt nätverk	Beskrivning	Storlek
Offentlig VIP	Azure Stack Hub använder totalt 31 adresser från det här nätverket och resten används av virtuella klientdatorer. Från de 31 adresserna används 8 offentliga IP-adresser för en liten uppsättning Azure Stack Hub-tjänster. Om du planerar att använda App Service och SQL-resursprovidrar används ytterligare 7 adresser. De återstående 16 IP-adresserna är reserverade för framtida Azure-tjänster.	/26 (62 värdar) – /22 (1 022 värdar) Rekommenderas = /24 (254 värdar)
Switch-infrastruktur	Punkt-till-punkt-IP-adresser för routningsändamål, dedikerade switchhanteringsgränssnitt och loopback-adresser som tilldelats växeln.	/26
Infrastruktur	Används för interna Azure Stack Hub-komponenter för kommunikation.	/24
Privat	Används för lagringsnätverket, privata VIP:er, infrastrukturcontainrar och andra interna funktioner. Mer information finns i avsnittet Privat nätverk i den här artikeln.	/20
BMC	Används för att kommunicera med BMC:erna på de fysiska värdarna.	/26

Anteckning

En avisering på portalen påminner operatorn om att köra PEP-cmdleten Set-AzsPrivateNetwork för att lägga till ett nytt /20 privat IP-utrymme. Mer information och vägledning om hur du väljer det privata IP-utrymmet /20 finns i avsnittet Privat nätverk i den här artikeln.

Nätverksinfrastruktur

Nätverksinfrastrukturen för Azure Stack Hub består av flera logiska nätverk som är konfigurerade på växlarna. Följande diagram visar dessa logiska nätverk och hur de integreras med TOR-växlarna (top-of-rack), baseboard management controller (BMC) och kundnätverksväxlar.

BMC-nätverk

Det här nätverket är avsett för att ansluta alla baskortshanteringsstyrenheter (kallas även BMC eller tjänstprocessorer) till hanteringsnätverket. Exempel är: iDRAC, iLO, iBMC och så vidare. Endast ett BMC-konto används för att kommunicera med en BMC-nod. Om maskinvarulivscykelvärden (HLH) finns i det här nätverket kan det tillhandahålla OEM-specifik programvara för maskinvaruunderhåll eller övervakning.

HLH är också värd för den virtuella distributionsdatorn (DVM). DVM används under Azure Stack Hub-distributionen och tas bort när distributionen är klar. DVM kräver internetåtkomst i anslutna distributionsscenarier för att testa, validera och komma åt flera komponenter. Dessa komponenter kan finnas i och utanför företagets nätverk (till exempel: NTP, DNS och Azure). Mer information om anslutningskrav finns i avsnittet NAT i Azure Stack Hub-brandväggsintegrering.

Privat nätverk

Det här /20-nätverket (4 096 IP-adresser) är privat för Azure Stack Hub-regionen (dirigeras inte bortom gränsväxlingsenheterna i Azure Stack Hub-systemet) och är uppdelat i flera undernät, här är några exempel:

• Storage-nätverk: Ett /25-nätverk (128 IP-adresser) som används för användning av SMB-lagringstrafik (Spaces Direct och Server Message Block) och vm-direktmigrering.
• Internt virtuellt IP-nätverk: Ett /25-nätverk som är dedikerat till endast interna VIP:er för programvarulastbalanseraren.
• containernätverk: Ett /23-nätverk (512 IP-adresser) som är dedikerat till intern trafik mellan containrar som kör infrastrukturtjänster.

Azure Stack Hub-systemet kräver ytterligare ett /20 privat internt IP-utrymme. Det här nätverket är privat för Azure Stack Hub-systemet (dirigeras inte utanför gränsväxlingsenheterna i Azure Stack Hub-systemet) och kan återanvändas på flera Azure Stack Hub-system i ditt datacenter. Även om nätverket är privat för Azure Stack får det inte överlappa andra nätverk i datacentret. Det privata IP-utrymmet /20 är uppdelat i flera nätverk som gör det möjligt att köra Azure Stack Hub-infrastrukturen på containrar. Det här nya privata IP-utrymmet gör det dessutom möjligt att kontinuerligt minska det dirigerbara IP-utrymme som krävs före distributionen. Målet med att köra Azure Stack Hub-infrastrukturen i containrar är att optimera användningen och förbättra prestandan. Dessutom används det privata IP-utrymmet /20 för att möjliggöra det pågående arbetet som ska minska det dirigerbara IP-utrymme som krävs före distributionen. Vägledning om privat IP-utrymme finns i RFC 1918.

Azure Stack Hub-infrastrukturnätverk

Det här /24-nätverket är dedikerat till interna Azure Stack Hub-komponenter så att de kan kommunicera och utbyta data sinsemellan. Det här undernätet kan dirigeras externt från Azure Stack Hub-lösningen till ditt datacenter. Vi rekommenderar inte att du använder offentliga eller internetrouterbara IP-adresser i det här undernätet. Det här nätverket annonseras till gränsen, men de flesta av dess IP-adresser skyddas av åtkomstkontroll-listor (ACL). Ip-adresserna som tillåts för åtkomst ligger inom ett litet intervall, vilket motsvarar ett /27-nätverk och värdtjänster, till exempel privilegierad slutpunkt (PEP) och Azure Stack Hub-säkerhetskopiering.

Offentligt VIP-nätverk

Det offentliga VIP-nätverket tilldelas till nätverksstyrenheten i Azure Stack. Det är inte ett logiskt nätverk på växeln. SLB använder poolen med adresser och tilldelar /32-nätverk för klientarbetsbelastningar. I växelroutningstabellen annonseras dessa /32 IP-adresser som en tillgänglig väg via BGP. Det här nätverket innehåller de externa eller offentliga IP-adresserna. Azure Stack Hub-infrastrukturen reserverar de första 31 adresserna från det här offentliga VIP-nätverket medan resten används av virtuella klientdatorer. Nätverksstorleken på det här undernätet kan variera från minst /26 (64 värdar) till högst /22 (1 022 värdar). Vi rekommenderar att du planerar för ett /24-nätverk.

Ansluta till lokala nätverk

Azure Stack Hub använder virtuella nätverk för kundresurser som virtuella datorer, lastbalanserare och andra.

Det finns flera olika alternativ för att ansluta från resurser i det virtuella nätverket till lokala/företagsresurser:

• Använd offentliga IP-adresser från det offentliga VIP-nätverket.
• Använd virtuell nätverksgateway eller virtuell nätverksinstallation (NVA).

När en S2S VPN-tunnel används för att ansluta resurser till eller från lokala nätverk kan det uppstå ett scenario där en resurs också har en tilldelad offentlig IP-adress och den inte längre kan nås via den offentliga IP-adressen. Om källan försöker komma åt den offentliga IP-adressen inom samma undernätsintervall som definieras i lokal nätverksgatewayvägar (virtuell nätverksgateway) eller användardefinierad väg för NVA-lösningar, försöker Azure Stack Hub dirigera trafiken utgående tillbaka till källan via S2S-tunneln, baserat på de routningsregler som har konfigurerats. Returtrafiken använder den virtuella datorns privata IP-adress istället för att NAT:a källan som den offentliga IP-adressen.

Det finns två lösningar på det här problemet:

• Dirigera trafiken som dirigeras till det offentliga VIP-nätverket till Internet.
• Lägg till en NAT-enhet för att NAT:a alla IP-adresser i undernäten som definierats i den lokala nätverksporten och som dirigeras till det offentliga VIP-nätverket.

Växla infrastrukturnätverk

Det här /26-nätverket är det undernät som innehåller de dirigerbara IP-undernäten för punkt-till-punkt /30 (två värd-IP:er) och loopbacks, vilka är dedikerade /32-undernät för in-band hantering av switchar och BGP-router-ID. Det här ip-adressintervallet måste vara dirigerbart utanför Azure Stack Hub-lösningen till ditt datacenter. De kan vara privata eller offentliga IP-adresser.

Byt hanteringsnätverk

Det här /29-nätverket (sex värd-IP-adresser) är dedikerat för att ansluta hanteringsportarna för växlarna. Den tillåter out-of-band-åtkomst för distribution, hantering och felsökning. Den beräknas från det switchinfrastrukturnätverk som tidigare nämnts.

Tillåtna nätverk

Distributionskalkylbladet har ett fält som gör att operatören kan ändra vissa åtkomstkontrollistor för att tillåta åtkomst till nätverksenhetshanterings-gränssnitt och maskinvarulivscykelvärd (HLH) från ett betrott datacenter-nätverksområde. När listan över åtkomstkontroll har ändrats kan operatorn tillåta att de virtuella datorerna för hanteringshoppboxen inom ett visst nätverksintervall får åtkomst till växelhanteringsgränssnittet och HLH-operativsystemet. Operatorn kan tillhandahålla ett eller flera undernät till den här listan. Om det lämnas tomt nekas åtkomsten som standard. Den här nya funktionen ersätter behovet av manuella åtgärder efter distributionen eftersom den brukade beskrivas i Ändra specifika inställningar för din Azure Stack Hub-växelkonfiguration.

Nästa steg

• Routning av virtuell nätverkstrafik
• Läs mer om nätverksplanering: Kantlinjeanslutning