Planering av nätverksintegrering för Azure Stack Hub

Den här artikeln innehåller information om nätverksinfrastrukturen i Azure Stack Hub 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 tillhandahålla DNS-servrar för att vidarebefordra DNS-begäranden. Mer information om DNS-krav för Azure Stack Hub finns i Integrering av Azure Stack Hub-datacenter – DNS.

Design för 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ävs överlänkar från ToR (Top-of-Rack-växlar) till närmaste växel eller router, som i den här dokumentationen kallas Kantlinje. ToR:erna 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å båda routningsalternativen. Dessa anslutningar är begränsade till SFP+ eller SFP28-media och minst en GB-hastighet. Kontrollera tillgängligheten hos oem-maskinvaruleverantören (originalutrustningstillverkaren). Följande diagram visar den rekommenderade designen:

Bandbreddsallokering

Azure Stack Hub skapas med windows Server 2019-tekniker för redundanskluster och blankstegsdirigering. En del av den fysiska nätverkskonfigurationen i Azure Stack Hub görs för att använda trafikseparation och bandbreddsgarantier för att säkerställa att spaces direct-lagringskommunikationen kan uppfylla de prestanda och den skalning som krävs för lösningen. Nätverkskonfigurationen använder trafikklasser för att separera Spaces Direct, RDMA-baserad kommunikation från nätverksanvändningen med Azure Stack Hub-infrastrukturen och/eller klientorganisationen. För att anpassa sig till de aktuella metodtips som definierats för Windows Server 2019 ändras Azure Stack Hub för att använda ytterligare en trafikklass eller prioritet för att ytterligare separera server-till-server-kommunikation till stöd för redundansklustringskontrollkommunikationen. Den här nya trafikklassdefinitionen konfigureras för att reservera 2 % av den tillgängliga fysiska bandbredden. Den här konfigurationen av trafikklasser och bandbreddsreservation sker genom en ändring på ToR-växlar (top-of-rack) i 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 redundanskluster är en viktig komponent i Azure Stack Hub-infrastrukturen och om den avbryts under långa perioder kan det leda till instabilitet i lagringstjänster för blankstegsdirigering eller andra tjänster som så småningom påverkar arbetsbelastningsstabiliteten för klientorganisationen eller slutanvändaren.

Anteckning

De beskrivna ändringarna läggs till på värdnivå för ett Azure Stack Hub-system i 2008-versionen. Kontakta oem-tillverkaren för att ordna nödvändiga ändringar vid ToR-nätverksväxlarna. Den här ToR-ändringen kan utföras antingen innan du uppdaterar till 2008-versionen eller efter uppdatering till 2008. Konfigurationsändringen av ToR-växlar krävs för att förbättra kommunikationen mellan redundanskluster.

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. När det logiska nätverket skapas 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.

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

Logiskt nätverk	Description	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)
Växla 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å switcharna. Följande diagram visar dessa logiska nätverk och hur de integreras med tor-växlar (top-of-rack), baseboard management controller (BMC) och gränsväxlar (kundnätverk).

BMC-nätverk

Det här nätverket är dedikerat för att ansluta alla baseboard-hanteringsstyrenheter (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 någon BMC-nod. Om det finns finns maskinvarulivscykelvärden (HLH) i det här nätverket och kan 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 i Azure Stack Hub-regionen (dirigeras inte utanför gränsväxelenheterna i Azure Stack Hub-systemet) och är indelat i flera undernät, här är några exempel:

• Lagringsnä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 virtuell dators direktmigrering.
• Internt virtuellt IP-nätverk: Ett /25-nätverk som är dedikerat till interna VIP:er för programvarans lastbalanserare.
• 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 /20 privat internt IP-utrymme. Det här nätverket kommer att vara privat för Azure Stack Hub-systemet (dirigeras inte utanför gränsväxelenheterna 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 indelat i flera nätverk som gör det möjligt att köra Azure Stack Hub-infrastrukturen på containrar. Dessutom möjliggör det här nya privata IP-utrymmet löpande arbete för att minska det dirigeringsbara IP-utrymmet 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 pågående arbete som minskar det dirigerbara IP-utrymmet före distributionen. För vägledning om privat IP-utrymme rekommenderar vi att du följer RFC 1918.

För system som distribuerats före 1910 är detta /20-undernät ytterligare ett nätverk som ska ingå i system efter uppdatering till 1910. Det ytterligare nätverket måste tillhandahållas till systemet via cmdleten Set-AzsPrivateNetwork PEP.

Anteckning

/20-indata fungerar som en förutsättning för nästa Azure Stack Hub-uppdatering efter 1910. När nästa Azure Stack Hub-uppdatering efter 1910-versioner och du försöker installera den misslyckas uppdateringen om du inte har slutfört /20-indata enligt beskrivningen i reparationsstegen på följande sätt. En avisering kommer att finnas i administratörsportalen tills ovanstående reparationssteg har slutförts. Se artikeln nätverksintegrering för datacenter för att förstå hur det nya privata utrymmet kommer att förbrukas.

Reparationssteg: Följ anvisningarna för att öppna en PEP-session för att åtgärda problemet. Förbered ett privat internt IP-intervall med storlek /20 och kör följande cmdlet i PEP-sessionen med hjälp av följande exempel: Set-AzsPrivateNetwork -UserSubnet 10.87.0.0/20. Om åtgärden utförs får du meddelandet Azs Internal Network-intervall som lagts till i konfigurationen. Om det har slutförts stängs aviseringen i administratörsportalen. Azure Stack Hub-systemet kan nu uppdateras till nästa version.

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 Internet-dirigerbara 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 Access Control Listor (ACL: er). IP-adresserna som tillåts för åtkomst ligger inom ett litet intervall som motsvarar ett /27-nätverk och värdtjänster som PEP (Privileged End Point) och Azure Stack Hub Backup.

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 adresspoolen 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 externt tillgängliga 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 i 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 med mera.

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 Virtual Network gateway 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 du stöta på 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 lokala nätverksgatewayvägar (Virtual Network Gateway) eller användardefinierad väg för NVA-lösningar, försöker Azure Stack Hub dirigera utgående trafik tillbaka till källan via S2S-tunneln, baserat på de routningsregler som har konfigurerats. Returtrafiken använder den virtuella datorns privata IP-adress i stället för att vara käll-NATed som offentlig IP-adress:

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 i NAT för alla undernäts-IP-adresser som definierats i den lokala nätverksgatewayen 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-adresser) och loopbacks, som är dedikerade /32-undernät för hantering av växel i band 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.

Växla hanteringsnätverk

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

Tillåtna nätverk

Kalkylbladet Distribution innehåller ett fält som gör att operatören kan ändra vissa åtkomstkontrollistor (ACL) så att åtkomst till nätverksenhetens hanteringsgränssnitt och maskinvarulivscykelvärden (HLH) från ett betrott datacenternätverksintervall tillåts. När åtkomstkontrollistan ändras kan operatören tillåta sina virtuella datorer i jumpbox-hantering inom ett visst nätverksintervall att komma åt gränssnittet för hantering av växlar och HLH-operativsystemet. Operatorn kan ange ett eller flera undernät till den här listan. Om den lämnas tom nekas åtkomsten som standard. Den här nya funktionen ersätter behovet av manuella åtgärder efter distributionen eftersom den tidigare beskrevs i Ändra specifika inställningar för din Azure Stack Hub-växelkonfiguration.

Nästa steg

• Trafikdirigering i virtuella nätverk
• Läs mer om nätverksplanering: Gränsanslutning.