Nätverkstopologi och anslutning för Azure VMware Solution

• Ingressmönster via Application Gateway och Azure Firewall är liknande för alla scenarier.
• Du kan använda NVA:er för L4-L7-lastbalanserare Azure VMware Solution.
• Du kan använda NSX-T-brandväggen med något av dessa scenarier.

I följande avsnitt beskrivs de fyra vanligaste nätverksscenarierna för Azure VMware Solution privata moln. Den här listan är inte fullständig. Fler scenarier finns i Distribuera NVA:er som stöder VXLAN med Azure Route Server och VNet för överföring.

Scenario 1: Skyddad Virtual WAN med standardvägspridning

Det här scenariot har följande kundprofil, arkitekturkomponenter och överväganden:

Kundprofil

Det här scenariot är idealiskt om:

• Du behöver inte trafikinspektion mellan Azure VMware Solution Och Azure Virtual Network.
• Du behöver inte trafikinspektion mellan Azure VMware Solution lokala datacenter.
• Du behöver trafikkontroll mellan Azure VMware Solution arbetsbelastningar och Internet.

I det här scenariot använder Azure VMware Solution som ett PaaS-erbjudande (platform as a service). Du äger inte de offentliga IP-adresserna. Du måste lägga till offentliga inkommande L4- och L7-tjänster om det behövs. Du kanske inte redan har ExpressRoute-anslutning mellan lokala datacenter och Azure.

Arkitekturkomponenter

Du kan implementera det här scenariot med:

• Azure Firewall i den skyddade Virtual WAN för brandväggar.
• Application Gateway för L7-belastningsutjämning.
• L4 DNAT (målnätverksadressöversättning) med Azure Firewall för att översätta och filtrera nätverksingresstrafik.
• Utgående internet via Azure Firewall i Virtual WAN hubben.
• ExR, VPN eller SD-WAN för anslutning mellan lokala datacenter och Azure VMware Solution.

Överväganden

Om du inte vill ta emot standardvägannonseringen från Azure VMware Solution den står i konflikt med din befintliga 0.0.0.0/0 miljö måste du vidta fler åtgärder.

Azure Firewall i den Virtual WAN hubben annonserar 0.0.0.0/0 vägen till Azure VMware Solution. Vägen 0.0.0.0/0 annonseras också lokalt via Global Reach. Implementera ett lokalt vägfilter för att förhindra 0.0.0.0/0 väginlärning. Det här problemet uppstår inte om du använder SD-WAN eller VPN.

Om du för närvarande ansluter till en virtuell nätverksbaserad topologi med nav och ekrar via en ExpressRoute-gateway i stället för direkt, sprids standardvägen från Virtual WAN-hubben till gatewayen och har företräde framför internetsystemvägen som är inbyggd i det virtuella 0.0.0.0/0 nätverket. Du kan kringgå det här problemet genom att implementera en 0.0.0.0/00.0.0.0/0 det virtuella nätverket för att åsidosätta den inlärda standardvägen.

Etablerade VPN-, ExpressRoute- eller virtuella nätverksanslutningar till den säkra Virtual WAN som inte kräver annons får 0.0.0.0/0 också annonsen. Du kan lösa problemet genom att antingen:

• Filtrera bort 0.0.0.0/0 vägen med en lokal gränsenhet.

• Eller:

  1. Koppla från ExpressRoute, VPN eller det virtuella nätverket.
  2. Aktivera 0.0.0.0/0 spridning.
  3. Inaktivera 0.0.0.0/0 spridning av dessa specifika anslutningar.
  4. Återanslut dessa anslutningar.

Du kan Application Gateway ett virtuellt ekernätverk som är anslutet till hubben eller i det virtuella navnätverket.

Scenario 2: NVA från tredje part i Azure Virtual Network med Azure Route Server, med Global Reach inaktiverad

Det här scenariot har följande kundprofil, arkitekturkomponenter och överväganden:

Kundprofil

Det här scenariot är idealiskt om:

• Du behöver mer information om brandväggar utanför Azure VMware Solution privata molnet.
• Du måste använda en säkerhetsinstallation från din aktuella leverantör i lokala eller andra Azure-miljöer.
• Du behöver flera offentliga IP-adresser för inkommande tjänster och behöver ett block med fördefinierade IP-adresser i Azure. I det här scenariot äger du inte offentliga IP-adresser.
• Du vill inspektera trafik mellan Azure VMware Solution och lokala datacenter med hjälp av NVA:er, och du kan inte använda Global Reach av geopolitiska skäl.
• Vanligtvis behöver du offentliga inkommande L4- och L7-tjänster Azure VMware Solution tjänster och behöver även utgående Internetanslutning.

I det här scenariot har du redan ExpressRoute-anslutning mellan lokala datacenter och Azure.

Arkitekturkomponenter

Du kan implementera det här scenariot med:

• NVA från tredje part som finns i ett virtuellt nätverk för brandväggar och andra nätverksfunktioner.
• Azure Route Server för att dirigera trafiken mellan Azure VMware Solution, lokala datacenter och virtuella nätverk.
• Application Gateway som den föredragna lösningen för L7 HTTP/S-belastningsutjämning.

I det här scenariot måste du inaktivera ExpressRoute-Global Reach. NVA:erna ansvarar för att tillhandahålla utgående internet till Azure VMware Solution.

Överväganden

Det här scenariot måste inspektera all trafik i det virtuella hubbnätverket, som är värd för NVA:erna, så du måste inaktivera ExpressRoute-Global Reach. Global Reach kan Azure VMware Solution trafikflödet direkt mellan ExpressRoute-routrarna för Microsoft Enterprise Edge (MSEE), vilket hoppar över det virtuella hubbnätverket.

Implementera Azure Route Server för att se till att dirigera trafik via hubben. Du ansvarar för att implementera och hantera en NVA-lösning eller använda en befintlig.

Om du behöver hög tillgänglighet för NVA:erna distribuerar du NVA:erna i en aktiv standby-konfiguration för att bevara symmetrisk routning. Mer information finns i dokumentationen för NVA-leverantören och distribuera NVA:er med hög tillgänglig.

Föregående arkitekturdiagram visar en NVA med VXLAN-stöd. Information om NVA:er utan VXLAN-stöd finns i Distribuera en icke-integrerad NVA i Virtual WAN utan VXLAN och ett VNet för överföring.

Scenario 3: Egress från Azure VMware Solution med eller utan NSX-T eller NVA

Det här scenariot har följande kundprofil, arkitekturkomponenter och överväganden:

Kundprofil

Det här scenariot är idealiskt om:

• Du måste använda den interna NSX-plattformen, så du behöver en PaaS-distribution för Azure VMware Solution.
• Eller så behöver du en BYOL-NVA (Bring Your Own License) inom Azure VMware Solution för trafikgranskning.
• Du kanske inte redan har ExpressRoute-anslutning mellan lokala datacenter och Azure.
• Du behöver inkommande HTTP/S- eller L4-tjänster.

All trafik från Azure VMware Solution till Azure Virtual Network, Azure VMware Solution till Internet och Azure VMware Solution till lokala datacenter-trattar via routrarna på NSX-nivå 0/nivå 1 eller NVA:erna.

Arkitekturkomponenter

Du kan implementera det här scenariot med:

• NSX-distribuerad brandvägg (DFW) eller NVA bakom nivå 1 i Azure VMware Solution
• Application Gateway för L7-belastningsutjämning
• L4 DNAT med Azure Firewall
• Internet-utbrytning från Azure VMware Solution

Överväganden

Du måste aktivera Internetåtkomst på Azure Portal. Med den här designen kan den utgående IP-adressen ändras och är inte deterministisk. Offentliga IP-adresser finns utanför NVA. NVA i Azure VMware Solution fortfarande privata IP-adresser och avgör inte den utgående offentliga IP-adressen.

NVA är BYOL och det är ditt ansvar att ta licensen och implementera hög tillgänglighet för NVA.

Se VMware-dokumentationen för NVA-placeringsalternativ och för information om VMware-begränsningen på upp till åtta virtuella nätverkskort (NIC) på en virtuell dator. Mer information finns i Brandväggsintegrering i Azure VMware Solution.

Scenario 4: Egress från Azure VMware Solution via 0.0.0.0/0 annons från lokal plats

Det här scenariot har följande kundprofil, arkitekturkomponenter och överväganden:

Kundprofil

Det här scenariot är idealiskt om:

• Du vill använda den lokala NVA:n och 0.0.0.0/0 annonsera från den lokala miljön.
• Du har redan eller kommer att ha ExpressRoute mellan lokala datacenter och Azure, med Global Reach aktiverat.
• Du behöver offentliga HTTP/S- eller L4-inkommande tjänster.

Trafikgranskning av utgående Internet-trafik hanteras lokalt. Den skyddade Azure Virtual WAN-hubben inspekterar trafiken mellan Azure VMware Solution och Azure Virtual Network.

Arkitekturkomponenter

Du kan implementera det här scenariot med:

• Application Gateway för L7-belastningsutjämning
• L4 DNAT med Azure Firewall
• Internet-utbrytning lokalt
• ExpressRoute för anslutning mellan lokala datacenter och Azure VMware Solution

Överväganden

Med den här designen finns de utgående offentliga IP-adresserna lokalt med lokal NVA.

Om du för närvarande ansluter till en virtuell nätverksbaserad nav-och-eker-topologi via en ExpressRoute-gateway istället för direkt, sprids standardvägen från Virtual WAN-hubben till gatewayen och prioriteras framför internetsystemvägen som är inbyggd i det virtuella 0.0.0.0/0 nätverket. Du kan kringgå det här problemet genom att implementera en 0.0.0.0/00.0.0.0/0 det virtuella nätverket för att åsidosätta den inlärda standardvägen.

Allmänna designöverväganden och rekommendationer

Här är några allmänna designöverväganden och rekommendationer för Azure VMware Solution nätverkstopologi och anslutning:

Hub-spoke kontra Virtual WAN nätverkstopologi

Virtual WAN har stöd för överföringsanslutning mellan VPN och ExpressRoute,men har inte stöd för hub-spoke-topologi.

Privata moln och kluster

• Alla kluster kan kommunicera inom ett Azure VMware Solution privat moln, eftersom alla delar samma /22-adressutrymme.

• Alla kluster delar också samma anslutningsinställningar, till exempel Internet, ExpressRoute, HCX, offentlig IP och ExpressRoute-Global Reach. Programarbetsbelastningar kan också dela vissa grundläggande nätverksinställningar som nätverkssegment, DHCP (Dynamic Host Configuration Protocol) och DNS (Domain Name System).

• Utforma dina privata moln och kluster i förväg före distributionen. Antalet privata moln påverkar dina nätverkskrav direkt. Varje privat moln kräver ett eget /22-adressutrymme för hantering av privata moln och IP-adresssegment för VM-arbetsbelastningar. Överväg att definiera dessa adressutrymmen i förväg.

• Diskutera med dina VMware- och nätverksteam hur du segmenterar och distribuerar dina privata moln, kluster och nätverkssegment för arbetsbelastningar. Planera i förväg för att undvika att slösa IP-adresser.

• Mer information om hur du hanterar IP-adresser för privata moln finns i Definiera IP-adresssegmentet för hantering av privata moln.

• Mer information om hur du hanterar IP-adresser för VM-arbetsbelastningar finns i Definiera IP-adresssegmentet för VM-arbetsbelastningar.

DNS och DHCP

För DHCP använder du DHCP-tjänsten som är inbyggd i NSX eller använder en lokal DHCP-server i det privata molnet. Dirigera inte DHCP-sändningstrafik via WAN tillbaka till lokala nätverk.

För DNS har du olika alternativ beroende på vilket scenario du använder och dina krav:

• För en Azure VMware Solution miljö distribuerar du en ny DNS-infrastruktur i ditt Azure VMware Solution privata moln.
• Använd Azure VMware Solution DNS-infrastruktur för att ansluta till en lokal miljö. Om det behövs distribuerar du DNS-vidarebefordrare för att utöka till Azure Virtual Network eller helst till Azure VMware Solution. Mer information finns i Lägga till en DNS-vidarebefordrartjänst.
• Om Azure VMware Solution till både lokala miljöer och Azure-miljöer och -tjänster använder du befintliga DNS-servrar eller DNS-vidarebefordrare i ditt virtuella hubbnätverk om det är tillgängligt. Eller så kan du utöka den befintliga lokala DNS-infrastrukturen till det virtuella Azure Hub-nätverket. Mer information finns i diagrammet landningszoner i företagsskala.

Mer information finns i:

• Överväganden för DHCP- och DNS-upplösning
• Konfigurera DHCP för Azure VMware Solution
• Konfigurera DHCP på L2-stretchade VMware HCX-nätverk
• Konfigurera en DNS-vidarebefordrare i Azure Portal

Internet

Följande lista är en snabbreferens:

Utgående alternativ för att aktivera Internet och filtrera och inspektera trafik är:

• Azure Virtual Network, NVA och Azure Route Server med Azures Internetåtkomst
• Lokal standardväg med lokal Internetåtkomst
• Virtual WAN säker hubb med Azure Firewall eller NVA med Hjälp av Azure Internetåtkomst

Inkommande alternativ för att leverera innehåll och program är:

• Azure Application Gateway med L7, Secure Sockets Layer (SSL)-avslutning och Web Application Firewall
• DNAT och lastbalanserare via lokal miljö
• Azure Virtual Network, NVA och Azure Route Server i olika scenarier
• Virtual WAN säker hubb med Azure Firewall, med L4 och DNAT
• Virtual WAN säker hubb med NVA i olika scenarier

ExpressRoute

Distributionen Azure VMware Solution in-of-the-box privat moln har automatiskt en kostnadsfri ExpressRoute-krets. Den här kretsen Azure VMware Solution till D-MSEE.

För plats bör du överväga att Azure VMware Solution i Azure-parkopplade regioner nära dina datacenter.

Global Reach

• Global Reach är ett obligatoriskt ExpressRoute-tillägg för Azure VMware Solution för att kommunicera med lokala datacenter, Azure Virtual Network och Virtual WAN. Alternativet är att utforma nätverksanslutningen med Azure Route Server.

• Du kan peer-Azure VMware Solution ExpressRoute-kretsen med andra ExpressRoute-kretsar Global Reach utan kostnad.

• Du kan använda Global Reach för peering av ExpressRoute-kretsar via en Internetleverantör och för ExpressRoute Direct kretsar.

• Global Reach stöds inte för lokala ExpressRoute-kretsar. För ExpressRoute Local, överförs Azure VMware Solution till lokala datacenter via NVA från tredje part i ett virtuellt Azure-nätverk.

• Global Reach är inte tillgängligt på alla platser.

Bandbredd

Välj en lämplig Virtual Network Gateway-SKU för optimal bandbredd mellan Azure VMware Solution och Azure Virtual Network. Azure VMware Solution stöder högst fyra ExpressRoute-kretsar till en ExpressRoute-gateway i en region.

Nätverkssäkerhet

Nätverkssäkerhet använder trafikinspektion och portspegling.

Trafikgranskning mellan öst och väst inom SDDC använder NSX-T eller NVA:er för att inspektera trafik till Azure Virtual Network mellan regioner.

Trafikgranskningen nord-syd inspekterar dubbelriktat trafikflöde mellan Azure VMware Solution och datacenter. Nord-syd-trafikinspektion kan använda:

• NVA och Azure Route Server via Azure Internet
• Lokal standardväg via lokalt Internet
• Azure Firewall och Virtual WAN via Azure Internet
• NSX-T inom SDDC via Azure VMware Solution Internet
• NVA i Azure VMware Solution SDDC via Azure VMware Solution Internet

Krav på portar och protokoll

Konfigurera alla nödvändiga portar för en lokal brandvägg för att säkerställa korrekt åtkomst till alla komponenter i Azure VMware Solution privata molnet. Mer information finns i Nödvändiga nätverksportar.

Azure VMware Solution åtkomst till hantering

• Under distributionen bör du överväga att använda Azure Bastion värd i Azure Virtual Network att komma åt Azure VMware Solution miljön.

• När routningen till den lokala miljön har upprättats respekterar Azure VMware Solution-hanteringsnätverket inte vägarna från lokala nätverk, så du måste annonsera mer specifika vägar för de 0.0.0.0/0 lokala nätverken.

Affärskontinui och haveriberedskap (BCDR) och migreringar

• Med VMware HCX-migreringar förblir standardgatewayen lokal. Mer information finns i Distribuera och konfigurera VMware HCX.

• VMware HCX-migrering kan använda HCX L2-tillägget. Migreringar som kräver Layer 2-tillägg kräver ExpressRoute. VPN stöds inte. Maximal storlek för överföringsenhet (MTU) bör vara 1 350 för att hantera overhead för HCX. Mer information om layer 2-tilläggsdesign finns i Layer 2 bridging in manager mode (VMware.com) ( Layer 2 bridging in manager mode (VMware.com).

Nästa steg

• Mer information om hur Azure VMware Solution nav- och ekernätverk finns i Integrera Azure VMware Solution en nav- och ekerarkitektur.

• Mer information om VMware NSX-nätverkssegment finns i Konfigurera NSX-nätverkskomponenter med hjälp av Azure VMware Solution.

• Om du vill lära dig Cloud Adoption Framework arkitekturprinciper för landningszoner i företagsskala, designöverväganden och metodtips för Azure VMware Solution finns i nästa artikel i serien:

  Säkerhets-, styrnings- och efterlevnadsdiscipliner för Azure VMware Solution

Användning av det programvarudefinierade VMware-datacentret (SDDC) med Azures molnekosystem ger en unik uppsättning designöverväganden för både molnbaserade scenarier och hybridscenarier. Den här artikeln går igenom viktiga överväganden och metodtips för nätverk och anslutning till, från och inom Azure Azure VMware Solution distributioner.

Artikeln bygger på flera principer Cloud Adoption Framework landningszoner i företagsskala och rekommendationer för hantering av nätverkstopologi och anslutningar i stor skala. Du kan använda den här designområdesvägledningen i företagsskala för verksamhetskritiska Azure VMware Solution plattformar. Här är några exempel på designgrunder:

• Hybridintegrering för anslutning mellan lokala, flera moln, gränsanvändare och globala användare. Mer information finns i Stöd i företagsskala för hybrider och flera moln.
• Prestanda och tillförlitlighet i stor skala för konsekvent upplevelse med låg latens och skalbarhet för arbetsbelastningar.
• Nollförtroendebaserad nätverkssäkerhet för att skydda nätverks perimeter- och trafikflöden. Mer information finns i Nätverkssäkerhetsstrategier i Azure.
• Utökningsbarhet för att enkelt utöka nätverksfotavtryck utan designarbete.

Nätverkskomponenter och begrepp

• Azure Virtual Network är den grundläggande byggstenen för privata nätverk i Azure. Med Azure Virtual Network kan många typer av Azure-resurser, till exempel Azure Virtual Machines (VM), kommunicera säkert med varandra, Internet och lokala datacenter. Ett virtuellt nätverk liknar ett traditionellt nätverk som du använder i ditt eget datacenter, men har fördelarna med skalning, tillgänglighet och isolering i Azure-infrastrukturen.

• En virtuell nätverksinstallation (NVA) är en nätverksenhet som stöder funktioner som anslutning, programleverans, WAN-optimering (Wide Area Network) och säkerhet. NVA:er innehåller Azure Firewall och Azure Load Balancer.

• Azure Virtual WAN är en nätverkstjänst som sammanför många funktioner för nätverk, säkerhet och routning i ett enda driftsgränssnitt. Dessa funktioner är:

  • Automatisering av grenanslutning från Virtual WAN partnerenheter som SD-WAN eller kundlokal utrustning (CPE)-baserade virtuella privata nätverk (VPN)
  • PLATS-till-plats-VPN-anslutning
  • Punkt-till-plats-VPN-anslutning för fjärranvändare
  • Privat Azure ExpressRoute anslutning
  • Intramolnanslutning som transitiv anslutning för virtuella nätverk
  • VPN ExpressRoute-anslutning
  • Routning
  • Azure Firewall
  • Kryptering för privat anslutning

• I nätverkstopologin hub-spokefungerar ett virtuellt navnätverk som en central anslutningspunkt till många virtuella ekernätverk. Hubben kan också vara anslutningspunkten till lokala datacenter. De virtuella ekernätverken peer-ar med hubben och kan användas för att isolera arbetsbelastningar.

• VXLAN (virtual extension LAN) är en nätverksvirtualiseringsteknik för skalning av molnnätverk. VXLAN genererar ett virtuellt nätverk som överlappar ett lokalt nätverk (LAN) med hjälp av Layer 3-teknik (L3) för att utöka nätverket.

• Layer 2-tillägget (L2) utökar en virtuell LAN- eller nätverkssändningsdomän över två platser. L2-tillägget har många namn, till exempel datacenteranslutning (DCI), datacentertillägg (DCE), utökat Layer 2-nätverk, utsträckt Layer 2-nätverk, utsträckt VLAN, utökat VLAN, stretchad distribution eller Layer 2 VPN.

• Skikt 4 (L4) refererar till det fjärde skiktet i OSI-modellen (Open Systems Interconnection). L4 tillhandahåller transparent överföring eller överföring av data mellan slutsystem eller värdar. L4 ansvarar för återställning av fel från slutet till slut, samt flödeskontroll. Några av de viktigaste protokollen som används i L4 är:

  • UDP (User Datagram Protocol)
  • UDP-Lite
  • Cyklisk UDP (CUDP)
  • Reliable UDP (RUDP)
  • AppleTalk Transaction Protocol (ATP)
  • Multipath TCP (MPTCP)
  • Transmission Control Protocol (TCP)
  • Sekvenserat paketutbyte (SPX)

• Layer 7 (L7) är det sjunde och översta lagret i OSI-modellen, som kallas programskiktet. Layer 7 identifierar de kommunicerande parterna och tjänstkvaliteten mellan dem. L7 hanterar sekretess- och användarautentisering och identifierar eventuella begränsningar för datasyntaxen. Det här lagret är helt programspecifikt. API-anrop och svar tillhör det här lagret. Några av L7-huvudprotokollen är HTTP, HTTPS och SMTP.

Nätverksscenarier

Designa och implementera nätverksfunktioner är avgörande för att upprätta Azure VMware Solution landningszon. Azure-nätverksprodukter och -tjänster stöder en mängd olika funktioner. Vilken arkitektur du ska välja och hur du strukturerar tjänster beror på organisationens arbetsbelastningar, styrning och krav.

Följande viktiga krav och överväganden påverkar ditt Azure VMware Solution beslutet om distribution:

• HTTP/S- eller icke-HTTP/S-krav för Internetanslutning i Azure VMware Solution program

• Överväganden för utgående internetsökväg

• L2-tillägg för migreringar

• NVA-användning i den aktuella arkitekturen

• Azure VMware Solution anslutning till ett virtuellt hubbnätverk eller en standardhubb Virtual WAN hubb

• Privat ExpressRoute-anslutning från lokala datacenter till Azure VMware Solution och om ExpressRoute-Global Reach är aktiverat

• Krav för trafikgranskning för:

  • Internet-ingress till Azure VMware Solution program
  • Azure VMware Solution utgående åtkomst till Internet
  • Azure VMware Solution åtkomst till lokala datacenter
  • Azure VMware Solution åtkomst till Azure Virtual Network
  • Trafik i det Azure VMware Solution privata molnet

Följande tabell innehåller rekommendationer och överväganden för de fyra vanligaste nätverksscenarierna, baserat Azure VMware Solution krav på trafikgranskning.