Spoke-to-spoke-nätverk

De vanligaste nätverksdesignmönstren i Azure handlar om att skapa topologier för virtuella nätverk med nav och eker i en eller flera Azure-regioner, eventuellt anslutna till lokala nätverk via Azure ExpressRoute eller vpn-tunnlar (site-to-site) via det offentliga Internet.

De flesta designguider fokuserar på programtrafik till dessa virtuella nätverk från användare antingen i interna, lokala nätverk eller från Internet (vad branschen vanligtvis anger trafik mellan nord och syd, eftersom den ofta representeras av lodräta linjer i nätverksdiagram). Den här artikeln fokuserar på olika mönster som är tillgängliga för trafik mellan öst och väst. Det vill: kommunikationsflöden mellan arbetsbelastningar som distribueras i virtuella Azure-nätverk, antingen inom en region eller i olika regioner.

Att se till att nätverksdesignen uppfyller kraven för trafik mellan öst och väst är viktigt för att tillhandahålla prestanda, skalbarhet och återhämtning för dina program som körs i Azure.

Potentiella användningsfall

Eker-till-eker-trafik kan vara viktig i flera scenarier:

• Olika nivåer för ett enskilt program finns i separata virtuella nätverk. Till exempel kommunicerar perimeternätverksservrar (även kallade DMZ-servrar) i ett virtuellt perimeternätverk med programtjänster i ett internt virtuellt nätverk.
• Programarbetsbelastningar i olika miljöer (utveckling, mellanlagring, produktion) måste replikera data mellan varandra.
• Olika program eller mikrotjänster måste kommunicera med varandra.
• Databaser måste replikera data mellan regioner för att garantera affärskontinuitet i händelse av en katastrof.
• Användarna finns i virtuella Azure-nätverk. De använder till exempel Azure Virtual Desktop.

Mönster och topologier för kommunikation mellan ekrar

Det finns två huvudsakliga topologier som du kan använda i Azure-design som korsar flera virtuella nätverk: traditionell hubb och eker och Azure Virtual WAN. I en Virtual WAN-miljö hanterar Microsoft det virtuella hubbnätverket och allt i det. I en traditionell hub-and-spoke-miljö hanterar du det virtuella hubbnätverket.

Virtual WAN- och hub-and-spoke-topologier är båda exempel på arkitekturer där arbetsbelastningarna körs i virtuella ekernätverk och anslutningen till lokala enheter centraliseras i ett virtuellt navnätverk. Så många av de begrepp som förklaras i den här artikeln gäller både hubb- och ekerdesign och Virtual WAN-design.

Det finns två huvudsakliga mönster för att ansluta virtuella ekernätverk till varandra:

• Ekrar som är direkt anslutna till varandra. Peerings för virtuella nätverk eller VPN-tunnlar skapas mellan de virtuella ekernätverken för att tillhandahålla direktanslutning utan att passera det virtuella hubbnätverket.
• Ekrar kommunicerar via en nätverksinstallation. Varje virtuellt ekernätverk har en peering till Virtual WAN eller till ett virtuellt navnätverk. En installation dirigerar trafik från eker till eker. Installationen kan hanteras av Microsoft (som med Virtual WAN) eller av dig.

Mönster 1: Ekrar som är direkt anslutna till varandra

Direkta anslutningar mellan ekrar ger vanligtvis bättre dataflöde, svarstid och skalbarhet än anslutningar som går via en virtuell nätverksinstallation (NVA) över en hubb. Att skicka trafik via NVA:er kan öka svarstiden för trafiken om de virtuella nätverksinstallationerna finns i en annan tillgänglighetszon och minst två virtuella nätverkspeeringar måste korsas när trafiken skickas via hubben. Det finns flera alternativ för att ansluta två virtuella ekernätverk till varandra direkt: peering för virtuella nätverk, Azure Virtual Network Manager och VPN-tunnlar.

• Peering för virtuella nätverk. Fördelarna med direkt peering för virtuella nätverk jämfört med ekrar är:

  • Lägre kostnad eftersom färre peeringhopp för virtuella nätverk krävs.
  • Bättre prestanda, eftersom trafiken inte behöver passera någon nätverksinstallation som introducerar svarstid eller potentiella flaskhalsar.

  Andra scenarier är anslutning mellan klientorganisationer. Du kan dock behöva inspektera trafiken mellan virtuella ekernätverk, vilket kan kräva att trafik skickas via centraliserade nätverksenheter i det virtuella hubbnätverket.

• Azure Virtual Network Manager. Utöver fördelarna med peering för virtuella nätverk tillhandahåller Azure Virtual Network Manager en hanteringstjänst som gör att du kan hantera virtuella nätverksmiljöer och skapa anslutningar i stor skala. Genom att använda Azure Virtual Network Manager kan du skapa tre typer av topologier i prenumerationer för både befintliga och nya virtuella nätverk:

  • Hubb och eker med ekrar som inte är anslutna till varandra.

  • Hubb och eker med ekrar som är direkt anslutna till varandra, utan hopp i mitten.

  • En sammankopplad grupp med virtuella nätverk som är sammankopplade.

    

    Ladda ned alla Visio-diagram i den här artikeln.

    När du skapar en nav-och-eker-topologi med Azure Virtual Network Manager där ekrar är anslutna till varandra, skapas direktanslutning mellan virtuella ekernätverk i samma nätverksgrupp automatiskt dubbelriktad. Genom att använda Azure Virtual Network Manager kan du statiskt eller dynamiskt göra virtuella ekernätverk till medlemmar i en specifik nätverksgrupp, vilket automatiskt skapar anslutningen för alla virtuella nätverk.

    Du kan skapa flera nätverksgrupper för att isolera kluster av virtuella ekernätverk från direktanslutning. Varje nätverksgrupp har samma region och stöd för flera regioner för eker-till-eker-anslutning. Se till att hålla dig under de högsta gränserna för Azure Virtual Network Manager som beskrivs i vanliga frågor och svar om Azure Virtual Network Manager.

• VPN-tunnlar som ansluter virtuella nätverk. Du kan konfigurera VPN-tjänster för att ansluta virtuella ekernätverk direkt med hjälp av Microsoft VPN-gatewayer eller VPN NVA från tredje part. Fördelen med det här alternativet är att virtuella ekernätverk ansluter mellan kommersiella och nationella moln inom samma molnleverantör eller anslutningsleverantörer mellan moln. Om det finns programvarudefinierade NVA:er för wide area network (SD-WAN) i varje virtuellt ekernätverk kan den här konfigurationen underlätta användningen av tredjepartsleverantörens kontrollplan och funktionsuppsättning för att hantera virtuella nätverksanslutningar.

  Det här alternativet kan också hjälpa dig att uppfylla efterlevnadskraven för kryptering av trafik i virtuella nätverk i ett enda Azure-datacenter som inte redan tillhandahålls av MACsec-kryptering. Men det här alternativet har en egen uppsättning utmaningar på grund av bandbreddsgränserna för IPsec-tunnlar (1,25 Gbit/s per tunnel) och designbegränsningarna för att ha virtuella nätverksgatewayer i både nav- och ekernätverk: Om det virtuella ekernätverket har en virtuell nätverksgateway kan det inte anslutas till Virtual WAN eller använda en hubbs virtuella nätverksgateway för att ansluta till lokala nätverk.

Mönster 1: Enskild region

Oavsett vilken teknik du använder för att ansluta virtuella ekernätverk till varandra skulle nätverkstopologierna se ut så här för en enda region:

Mönster 1: Flera regioner

Design som ansluter alla virtuella ekernätverk till varandra kan också utökas till flera regioner. I den här topologin är Azure Virtual Network Manager ännu mer kritiskt för att minska de administrativa kostnaderna för att underhålla det nödvändiga stora antalet anslutningar.

När du ansluter virtuella ekernätverk direkt till varandra i en helt nätad topologi måste du överväga det potentiellt stora antal virtuella nätverkspeeringarna som krävs. Följande diagram illustrerar det här problemet. I det här scenariot rekommenderas Azure Virtual Network Manager starkt så att du automatiskt kan skapa virtuella nätverksanslutningar.

Mönster 2: Ekrar som kommunicerar via en nätverksinstallation

I stället för att ansluta virtuella ekernätverk direkt till varandra kan du använda nätverksinstallationer för att vidarebefordra trafik mellan ekrar. Nätverksinstallationer tillhandahåller ytterligare nätverkstjänster som djup paketinspektion och trafiksegmentering eller övervakning, men de kan introducera flaskhalsar för svarstid och prestanda om de inte är korrekt storleksanpassade. Dessa enheter finns vanligtvis i ett virtuellt navnätverk som ekrarna ansluter till. Det finns flera alternativ för att använda en nätverksinstallation för att vidarebefordra trafik mellan ekrar:

• Virtual WAN Hub-router. Virtual WAN hanteras fullständigt av Microsoft och innehåller en virtuell router som lockar trafik från ekrar och dirigerar den till antingen ett annat virtuellt nätverk som är anslutet till Virtual WAN eller till lokala nätverk via ExpressRoute eller VPN-tunnlar från plats till plats eller punkt-till-plats. Virtual WAN-routern skalas upp och ned automatiskt, så du behöver bara se till att trafikvolymen mellan ekrarna ligger inom gränserna för Virtual WAN.

• Azure Firewall. Azure Firewall är en nätverksinstallation som hanteras av Microsoft och som kan distribueras i virtuella navnätverk som du hanterar eller i Virtual WAN-hubbar. Den kan vidarebefordra IP-paket och kan även inspektera dem och tillämpa trafiksegmenteringsregler som definieras i principer. Den ger automatisk skalning upp till Azure Firewall-gränserna så att den inte blir en flaskhals. Observera att Azure Firewall endast tillhandahåller färdiga funktioner för flera regioner när de används med Virtual WAN. Utan Virtual WAN måste du implementera användardefinierade vägar för att uppnå kommunikation mellan regioner.

• Virtuella nätverksinstallationer från tredje part. Om du föredrar att använda en virtuell nätverksinstallation från en Microsoft-partner för att utföra routning och nätverkssegmentering kan du distribuera virtuella nätverksinstallationer i antingen en hub-and-spoke-topologi eller en Virtual WAN-topologi. Mer information finns i Distribuera NVA:er med hög tillgänglighet eller NVA:er i en Virtual WAN-hubb. Du måste vara säker på att den virtuella nätverksinstallationen stöder den bandbredd som kommunikationen mellan ekrar genererar.

• Azure VPN Gateway. Du kan använda en Azure VPN-gateway som en nästa hopp-typ av användardefinierad väg, men Microsoft rekommenderar inte att du använder virtuella VPN-nätverksgatewayer för att dirigera eker-till-eker-trafik. De är utformade för att kryptera trafik till lokala platser eller VPN-användare. Det finns till exempel ingen garanti för bandbredden mellan ekrar som en VPN-gateway kan dirigera.

• ExpressRoute. I vissa konfigurationer kan en ExpressRoute-gateway annonsera vägar som lockar eker-till-eker-kommunikation och skicka trafik till Microsoft Edge-routern, där den dirigeras till målekern. Microsoft avråder starkt från det här scenariot eftersom det ger svarstid genom att skicka trafik till Microsofts stambrygga och tillbaka. Dessutom rekommenderar Microsoft inte den här metoden på grund av den enda felpunkten och den stora sprängradien. Det här scenariot visar också på flera problem som orsakas av extra tryck på ExpressRoute-infrastrukturen (gatewayen och de fysiska routrarna). Detta ytterligare tryck kan orsaka att paketen sjunker.

I nätverksdesign för nav och eker som har centraliserade NVA:er placeras installationen vanligtvis i hubben. Peering för virtuella nätverk mellan virtuella hubbar och ekernätverk måste skapas manuellt eller automatiskt med Azure Virtual Network Manager:

• Manuella peerings för virtuella nätverk. Den här metoden räcker när du har ett lågt antal virtuella ekernätverk, men det skapar hanteringskostnader i stor skala.

• Azure Virtual Network Manager. Som tidigare nämnts tillhandahåller Azure Virtual Network Manager funktioner för att hantera virtuella nätverksmiljöer och peerings i stor skala. Peeringkonfigurationer mellan virtuella hubb- och ekernätverk konfigureras automatiskt dubbelriktade för nätverksgrupper.

  Azure Virtual Network Manager ger möjlighet att statiskt eller dynamiskt lägga till ekermedlemskap för virtuella nätverk i en specifik nätverksgrupp, vilket automatiskt skapar peering-anslutningen för nya medlemmar. Virtuella ekernätverk i nätverksgrupper kan använda hubb-VPN eller ExpressRoute-gatewayer för anslutning. Se till att hålla dig under de högsta gränserna för Azure Virtual Network Manager.

Mönster 2: Enskild region

Följande diagram visar en topologi med en region som skickar trafik mellan ekrar via en Azure-brandvägg som distribueras i det virtuella hubbnätverket. Trafiken vidarebefordras till den centraliserade installationen i hubben via användardefinierade vägar som tillämpas på ekerundernäten.

Under vissa omständigheter kan det vara fördelaktigt att separera de virtuella nätverksinstallationer som hanterar eker-till-eker- och Internettrafik för skalbarhet. Du kan utföra den här separationen genom att:

• Justera routningstabellerna i ekrarna för att skicka privata adresser (de som har en väg för RFC 1918-prefix) till en NVA som ansvarar för Azure-till-Azure- och Azure-till-lokal trafik (kallas även öst-västlig trafik).
• Justera internettrafik (som har en 0.0.0.0/0-väg) till en andra NVA. Den här NVA:n ansvarar för Azure-till-Internet-trafik (kallas även nord-syd-trafik).

Följande diagram visar den här konfigurationen:

Mönster 2: Flera regioner

Du kan utöka samma konfiguration till flera regioner. I en hub-and-spoke-design som använder Azure Firewall bör du till exempel använda ytterligare routningstabeller för Azure Firewall-undernäten i varje hubb för ekrarna i fjärrregionen. Den här konfigurationen säkerställer att trafik mellan regioner kan vidarebefordras mellan Azure-brandväggarna i varje virtuellt hubbnätverk. Mellanregional trafik mellan virtuella ekernätverk passerar sedan båda Azure-brandväggarna. Mer information finns i Azure Firewall för att dirigera en topologi med flera hubbar och ekrar:

Designvarianten med separata Azure-brandväggar eller virtuella nätverksinstallationer för trafik i nord-syd och öst-väst är också möjlig i en topologi för nav och eker i flera regioner:

Virtual WAN skapar en liknande topologi och tar över routningskomplexiteten. Det gör det både i hubbarna (som Microsoft hanterar) och i ekrarna (där vägar kan matas in och inte behöver definieras manuellt i routningstabeller). Nätverksadministratören behöver därför bara ansluta de virtuella ekernätverken till en Virtual WAN-hubb och behöver inte bekymra sig om vidarebefordran av trafik mellan regioner.

Hybridmönster

Många situationer kräver en hybridmetod som kombinerar de två mönster som beskrevs tidigare. I den här metoden måste trafik mellan vissa ekrar gå över direkta anslutningar, men resten av ekrarna kommunicerar via en central nätverksinstallation. I en Virtuell WAN-miljö kan du till exempel direkt ansluta två specifika ekrar som har hög bandbredd och krav på låg svarstid. Ett annat scenario omfattar virtuella ekernätverk som ingår i en enda miljö. Du kan till exempel tillåta att ett virtuellt ekernätverk för utveckling ansluter direkt till ett annat virtuellt nätverk för ekerutveckling, men tvingar arbetsbelastningar för utveckling och produktion att kommunicera via den centrala installationen.

Ett annat vanligt mönster är att ansluta ekrar i en region via direkt peering för virtuella nätverk eller Azure Virtual Network Manager-anslutna grupper, men att tillåta trafik mellan regioner att korsa NVA:er. Den huvudsakliga motivationen för den här modellen är vanligtvis att minska antalet peerings för virtuella nätverk i arkitekturen. Men jämfört med den första modellen (direkt anslutning mellan ekrar) är en nackdel som introduceras i den här modellen fler peeringhopp för virtuella nätverk för trafik mellan regioner. Dessa hopp ökar kostnaderna på grund av de flera peerings för virtuella nätverk som korsas. En annan nackdel är den extra belastningen på hubb-NVA:erna för att fronta all korsregional trafik.

Samma design gäller för Virtual WAN. Ett övervägande är dock att direktanslutning mellan virtuella ekernätverk måste konfigureras manuellt direkt mellan de virtuella nätverken och inte via Virtual WAN-resursen. Azure Virtual Network Manager stöder för närvarande inte arkitekturer som baseras på Virtual WAN. Till exempel:

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Jay Li | Senior Product Manager
• Jose Moreno | Huvudkundtekniker
• Alejandra Palacios | Senior Kundtekniker för Azure-infrastruktur

Övriga medarbetare:

• Mick Alberts | Teknisk författare
• Mohamed Hassan | Huvudansvarig PM Manager
• Andrea Michael | Programhanteraren
• Yasukuni Morishima | Kundtekniker II
• Jithin PP| Kundtekniker

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Cloud Adoption Framework: Nätverkstopologi och anslutning i landningszonen
• Peering för virtuella nätverk
• Azure Virtual Network Manager
• Virtual WAN
• Azure Firewall
• Säker nätverksanslutning i Azure
• Introduktion till virtuella Azure-nätverk

Relaterade resurser

• Nätverkstopologi för hub-spoke i Azure
• Nätverkstopologi med hub-spoke med Azure Virtual WAN
• Traditionell Azure-nätverkstopologi