Exempelarkitekturer för Azure VMware Solutions

För att upprätta en Azure VMware Solution-landningszon måste du först utforma och implementera nätverksfunktioner. Azure-nätverksprodukter och -tjänster stöder en mängd olika nätverksscenarier. Välj en lämplig arkitektur och plan för att strukturera tjänster efter dina behov genom att utvärdera organisationens arbetsbelastningar, styrning och krav.

Granska följande överväganden och viktiga krav innan du fattar distributionsbeslutet för Azure VMware Solution.

• INGRESS-krav för HTTP/S eller icke-HTTP/S 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 antingen ett virtuellt standardhubbnätverk eller virtual WAN-hubb
• Privat ExpressRoute-anslutning från lokala datacenter till Azure VMware Solution (och om du ska aktivera ExpressRoute Global Reach eller inte)
• Trafikkontrollkrav för:
  • Internet-ingress till Azure VMware Solution-program
  • Utgående åtkomst till Azure VMware Solution till Internet
  • Azure VMware Solution-åtkomst till lokala datacenter
  • Azure VMware Solution-åtkomst till Azure Virtual Network
  • Trafik i det privata azure VMware Solution-molnet

I följande tabell används trafikinspektionskrav för VMware-lösningen för att ge rekommendationer och överväganden för de vanligaste nätverksscenarierna.

Scenario	Krav för trafikkontroll	Rekommenderad lösningsdesign	Att tänka på
1	- Internet-ingress - Utgående internet	Använd en virtuell WAN-skyddad hubb med standardspridning av gateway. För HTTP/S-trafik använder du Azure Application Gateway. För icke-HTTP/S-trafik använder du Azure Firewall. Distribuera en säker Virtual WAN-hubb och aktivera offentlig IP-adress i Azure VMware Solution.	Den här lösningen fungerar inte för lokal filtrering. Global Reach kringgår Virtual WAN-hubbar.
2	- Internet-ingress - Utgående internet – Till lokalt datacenter – Till Azure Virtual Network	Använd NVA-lösningar från tredje part i ditt virtuella hubbnätverk med Azure Route Server. Inaktivera Global räckvidd. För HTTP/S-trafik använder du Azure Application Gateway. För icke-HTTP/S-trafik använder du en brandväggs-NVA från tredje part i Azure.	Välj det här alternativet om du vill använda din befintliga NVA och centralisera all trafikkontroll i det virtuella hubbnätverket.
3	- Internet-ingress - Utgående internet – Till lokalt datacenter – Till Azure Virtual Network I Azure VMware Solution	Använd NSX-T Data Center eller en NVA-brandvägg från tredje part i Azure VMware Solution. Använd Application Gateway för HTTPs eller Azure Firewall för trafik som inte är HTTPs. Distribuera den skyddade Virtual WAN-hubben och aktivera offentlig IP-adress i Azure VMware Solution.	Välj det här alternativet om du behöver inspektera trafik från två eller flera privata Azure VMware Solution-moln. Med det här alternativet kan du använda inbyggda NSX-T-funktioner. Du kan också kombinera det här alternativet med NVA:er som körs på Azure VMware Solution mellan L1 och L0.
4	- Internet-ingress – Utgående internet – Till lokalt datacenter – Till Azure Virtual Network	Använd brandväggslösningar från tredje part i ett virtuellt navnätverk med Azure Route Server. För HTTP- och HTTPS-trafik använder du Azure Application Gateway. För icke-HTTP/HTTPS-trafik använder du en brandväggs-NVA från tredje part i Azure. Använd en lokal brandväggs-NVA från tredje part. Distribuera brandväggslösningar från tredje part i ett virtuellt navnätverk med Azure Route Server.	Välj det här alternativet om du vill annonsera 0.0.0.0/0 vägen från en NVA i ditt virtuella Azure Hub-nätverk till en Azure VMware-lösning.

Viktiga punkter om nätverksscenarier:

• Alla scenarier har liknande ingressmönster via Application Gateway och Azure Firewall.
• Du kan använda LASTBALANSERARE FÖR L4-L7 i Azure VMware Solution.
• Du kan använda NSX-T Data Center Firewall för något av dessa scenarier.

I följande avsnitt beskrivs arkitekturmönster för privata moln i Azure VMware Solution. Denna lista är inte fullständig. Mer information finns i Nätverks- och sammanlänkningskoncept för Azure VMware Solution.

Säker Virtuell WAN-hubb med standardvägsspridning

Det här scenariot omfattar följande kundprofil, arkitekturkomponenter och överväganden.

Kundprofil

Det här scenariot är idealiskt om:

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

I det här scenariot använder du Azure VMware Solution som ett PaaS-erbjudande (plattform som en tjänst). I det här scenariot äger du inte de offentliga IP-adresserna. Lägg till offentliga L4- och L7-inkommande tjänster om det behövs. Du kanske eller kanske inte redan har ExpressRoute-anslutning mellan lokala datacenter och Azure.

Översikt på hög nivå

Följande diagram ger en översikt över scenariot på hög nivå.

Arkitekturkomponenter

Implementera det här scenariot med:

• Azure Firewall i en säker Virtual WAN-hubb för brandväggar
• Application Gateway för L7-belastningsutjämning
• D4-målnätverksadressöversättning (DNAT) med Azure Firewall för att översätta och filtrera inkommande nätverkstrafik
• Utgående internet via Azure Firewall i din Virtual WAN-hubb
• EXR, VPN eller SD-WAN för anslutning mellan lokala datacenter och Azure VMware Solution

Att tänka på

Om du inte vill ta emot standardvägsannonsen 0.0.0.0/0 från Azure VMware Solution eftersom den står i konflikt med din befintliga miljö måste du utföra lite extra arbete.

Azure Firewall i en skyddad Virtuell WAN-hubb annonserar 0.0.0.0/0 vägen till Azure VMware Solution. Den här vägen annonseras också lokalt via Global Reach. Implementera ett lokalt vägfilter för att förhindra 0.0.0.0/0 routningsinlärning. Undvik det här problemet med hjälp av SD-WAN eller VPN.

Om du för närvarande ansluter till en virtuell nätverksbaserad hub-and-spoke-topologi via en ExpressRoute-gateway i stället för att ansluta direkt, sprids standardvägen 0.0.0.0/0 från Virtual WAN-hubben till den gatewayen och har företräde framför den internetsystemväg som är inbyggd i ditt virtuella nätverk. Undvik det här problemet genom att implementera en 0.0.0.0/0användardefinierad väg i det virtuella nätverket för att åsidosätta den inlärda standardvägen.

Upprättade VPN-, ExpressRoute- eller virtuella nätverksanslutningar till en säker Virtual WAN-hubb som inte kräver 0.0.0.0/0 annonsering tar ändå emot annonsen. För att förhindra detta kan du antingen:

• Filtrera bort 0.0.0.0/0 vägen med en lokal gränsenhet.
• Inaktivera 0.0.0.0/0 spridning på specifika anslutningar.
  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 på de specifika anslutningarna.
  4. Återanslut dessa anslutningar.

Du kan vara värd för Application Gateway i ett virtuellt ekernätverk som är anslutet till din hubb eller i det virtuella hubbnätverket.

Virtuell nätverksinstallation i Azure Virtual Network för att inspektera all nätverkstrafik

Det här scenariot omfattar följande kundprofil, arkitekturkomponenter och överväganden.

Kundprofil

Det här scenariot är idealiskt om:

• Du måste använda brandväggs-NVA:er från tredje part i ett virtuellt hubbnätverk för att inspektera all trafik och du kan inte använda Global Reach av geopolitiska eller andra skäl.
  • Du befinner dig mellan lokala datacenter och Azure VMware Solution.
  • Du är mellan Azure Virtual Network och Azure VMware Solution.
  • Du behöver internet-ingress från Azure VMware Solution.
  • Du behöver internetutgående till Azure VMware Solution.
• Du behöver detaljerad kontroll över brandväggar utanför det privata Azure VMware Solution-molnet.
• 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 de offentliga IP-adresserna.

Det här scenariot förutsätter att du har ExpressRoute-anslutning mellan lokala datacenter och Azure.

Översikt på hög nivå

Följande diagram ger en översikt över scenariot på hög nivå.

Arkitekturkomponenter

Implementera det här scenariot med:

• Brandväggs-NVA:er från tredje part som finns i ett virtuellt nätverk för trafikkontroll och andra nätverksfunktioner.
• Azure Route Server för att dirigera trafik mellan Azure VMware Solution, lokala datacenter och virtuella nätverk.
• Application Gateway för att tillhandahålla L7 HTTP/S-belastningsutjämning.

Du måste inaktivera ExpressRoute Global Reach i det här scenariot. Tredjeparts-NVA:er ansvarar för att tillhandahålla utgående Internet till Azure VMware Solution.

Att tänka på

• Konfigurera aldrig ExpressRoute Global Reach för det här scenariot eftersom det gör att Azure VMware Solution-trafik flödar direkt mellan Microsoft Enterprise Edge-routrar (MSEE) ExpressRoute och hoppar över det virtuella hubbnätverket.
• Azure Route Server måste distribueras i ditt virtuella hubbnätverk och BGP-peeras med NVA:erna i det virtuella överföringsnätverket. Konfigurera Azure Route Server för att tillåta förgrenings-till-gren-anslutning .
• Anpassade routningstabeller och användardefinierade vägar används för att dirigera trafik till/från Azure VMware Solution till den virtuella brandväggs-NVA:ernas lastbalanserare från tredje part. Alla HA-lägen (aktiv/aktiv och aktiv/vänteläge) stöds med garanterad routningssymmetri.
• Om du behöver hög tillgänglighet för NVA:er kan du läsa nva-leverantörsdokumentationen och distribuera NVA:er med hög tillgänglighet.

Utgående från Azure VMware Solution med eller utan NSX-T eller NVA

Det här scenariot omfattar följande kundprofil, arkitekturkomponenter och överväganden.

Kundprofil

Det här scenariot är idealiskt om:

• Du måste använda den inbyggda NSX-T Data Center-plattformen, så du behöver en PaaS-distribution för Azure VMware Solution.
• Du behöver en BYOL-NVA (bring-your-own-license) i Azure VMware Solution för trafikkontroll.
• Du kanske eller 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, från Azure VMware Solution till Internet och från Azure VMware Solution till lokala datacenter dirigeras via NSX-T Data Center Tier-0/Tier-1-gatewayerna eller NVA:erna.

Översikt på hög nivå

Följande diagram ger en översikt över scenariot på hög nivå.

Arkitekturkomponenter

Implementera det här scenariot med:

• En NSX-distribuerad brandvägg (DFW) eller en NVA bakom tier-1 i Azure VMware Solution.
• Application Gateway för att tillhandahålla L7-belastningsutjämning.
• L4 DNAT med Azure Firewall.
• Internet-breakout från Azure VMware Solution.

Att tänka på

Aktivera Internetåtkomst på Azure-portalen. I den här designen kan en utgående IP-adress ändras och är inte deterministisk. Offentliga IP-adresser finns utanför NVA. NVA i Azure VMware Solution har fortfarande privata IP-adresser och avgör inte den utgående offentliga IP-adressen.

NVA är BYOL. Det är ditt ansvar att ta med en licens och implementera hög tillgänglighet för NVA.

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

Brandväggslösningar från tredje part i ett virtuellt navnätverk med Azure Route Server

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

Kundprofil

Det här scenariot är idealiskt om:

• Du vill att Azure VMware Solution internet utgående med hjälp av din nva från tredje part i Azure VNet Hub och du vill inspektera trafiken mellan Azure VMware Solution och Azure Virtual Network.
• Du vill inspektera trafik mellan lokala datacenter och Azure med hjälp av din lokala nva från tredje part.
• 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 de offentliga IP-adresserna.
• Du behöver detaljerad kontroll över brandväggar utanför det privata Azure VMware Solution-molnet.

Översikt på hög nivå

Följande diagram ger en översikt över scenariot på hög nivå.

Arkitekturkomponenter

Implementera det här scenariot med:

• NVA:er från tredje part är aktiva eller aktiva i vänteläge som finns i ett virtuellt nätverk för brandväggar och andra nätverksfunktioner.
• Azure Route Server för att utbyta vägar mellan Azure VMware Solution, lokala datacenter och virtuella nätverk.
• Dina nva:er från tredje part i azure virtual network-hubben för att tillhandahålla utgående Internet till Azure VMware Solution.
• ExpressRoute för anslutning mellan lokala datacenter och Azure VMware Solution.

Att tänka på

• I den här designen finns utgående offentliga IP-adresser med NVA:er i det virtuella Azure-nätverket.
• Nva:er från tredje part i den virtuella nätverkshubben BGP peerkopplas med Azure Route Server (ECMP) och annonserar standardvägen) 0.0.0.0/0 till Azure VMware Solution.
• Standardvägen 0.0.0.0/0 annonseras också lokalt via Global Reach. Implementera ett routningsfilter lokalt för att förhindra standardväginlärning 0.0.0.0/0 .
• Trafik mellan Azure VMware Solution och ditt lokala nätverk flödar via ExpressRoute Global Reach, enligt beskrivningen i Peer on-premises environments to Azure VMware Solution (Peer on-premises environments to Azure VMware Solution). Trafikkontroll mellan lokal och Azure VMware Solution utförs av din lokala nva från tredje part, inte av dina nva:er från tredje part i Azure Virtual Network Hub.
• Du kan vara värd för Application Gateway i ett virtuellt ekernätverk som är anslutet till en hubb eller i det virtuella hubbnätverket.

Nästa steg

• Mer information om Azure VMware Solution i hub-and-spoke-nätverk finns i Integrera Azure VMware Solution i en hubb- och ekerarkitektur.

• Mer information om VMware NSX-T Data Center-nätverkssegment finns i Konfigurera NSX-T Data Center-nätverkskomponenter med Azure VMware Solution.

• Mer information om arkitekturprinciper för molnimplementeringsramverk i företagsskala, olika designöverväganden och metodtips för Azure VMware Solution finns i nästa artikel i den här serien:

  Säkerhets-, styrnings- och efterlevnadsområden för Azure VMware Solution