Aktivera anslutning från Azure VMware Solution

Introduktion

I det här designmönstret har trafiken en dedikerad sökväg över Microsofts stamnät från det lokala datacentret till det privata molnet Azure VMware Solution (AVS). Den här anslutningen sker via Expressroute Global Reach, en mekanism som tillhandahåller en direkt sökväg mellan den kundhanterade som sedan kan ansluta till AVS-dedikerade Expressroute-kretsar. Det privata molnet har också en separat, isolerad utbrytning från NSX Edge till Internet så att den här trafiken inte passerar över Expressroute.

Kundprofil

Den här arkitekturen är perfekt för:

• Låg svarstid, utgående internt från Azure VMware Solution SDDC (programvarudefinierade datacenter) till Internet.
• Dirigera trafik från en lokal plats direkt till Azure via Expressroute eller VPN.
• Inkommande L4/L7-tjänster för arbetsbelastningar i SDDC, till exempel HTTPS

Trafiken, som flödar genom AVS NSX-routrarna, som beskrivs i den här designen är:

• Azure VMware Solution to Azure native virtual networks (Azure VMware Solution to Azure native virtual networks)
• Azure VMware-lösning till Internet
• Azure VMware-lösning till lokala datacenter

Arkitekturkomponenter

Implementera det här scenariot med:

• En avancerad NSX-lastbalanserare
• Offentlig IP för Internet-breakout från Azure VMware Solution för både käll- och måladressöversättning (SNAT/DNAT)

Nyckelbeslut

Det här dokumentet förutsätter och rekommenderar standardvägsannonsering från antingen lokalt eller AVS. Om du behöver standardvägen för att komma från Azure kan du läsa avsnittet Trafikinspektion och Standardvägsannons.

Att tänka på

• Aktivera offentlig IP-adress till NSX Edge i Azure-portalen. Detta möjliggör direktanslutningar med låg latens till Azure VMware Solution och möjlighet att skala antalet utgående anslutningar.
• Använd skapande av NSX-brandväggens regel.
• Använd den avancerade NSX-lastbalanseraren för att jämnt distribuera trafik till arbetsbelastningar.
• Aktivera översvämningsskydd (distribuerad och gateway).

Utgående från AVS med NSX-T eller NVA

Utgående från Azure VMware Solution via 0.0.0.0/0-annons från en lokal plats

NVA-integrering från tredje part i AVS

Integrering med tredjepartsutrustning är möjlig med noggrant övervägande. I den här designen sitter nva:er från tredje part bakom en eller flera T-1-kantroutrar.

Det är användarnas ansvar att ta med en licens och implementera alla funktioner för hög tillgänglighet som är inbyggda på enheten.

Tänk på gränserna när du väljer den här implementeringen. Det finns till exempel en gräns på upp till åtta nätverkskort (NIC) på en virtuell dator. Mer information om hur du placerar NVA:er i AVS finns i: NSX-T-brandväggsmönster

Överväganden för landningszon

Det här avsnittet refererar till metodtips för att integrera AVS med azure-landningszonen.

Azure Route Server

Azure Route Server (ARS) används för att dynamiskt sprida inlärda vägar från AVS och tillhandahålla branch-till-gren-anslutning till VPN-gatewayer. Virtuella nätverk som är peer-kopplade till det virtuella nätverket där ARS bor lär sig också dynamiskt vägarna, vilket gör det möjligt att lära sig vägar från AVS till hubb- och ekermiljöer i Azure. Användningsfall för Azure Route Server är:

Dynamisk routningsspridning:

• Lär dig specifika vägar från AVS till lokala virtuella nätverk via BGP (Border Gateway Protocol). De peerkopplade virtuella nätverken kan sedan också lära sig vägarna.
• NVA-integrering från tredje part
  • Peer ARS med NVA:er så att du inte behöver UDR för varje AVS-segment för att filtrera trafik.
  • Returnera trafik från peer-kopplade virtuella nätverk behöver en UDR (användardefinierade vägar) tillbaka till brandväggens lokala gränssnitt
• Överföringsmekanism från Expressroute till VPN Gateways
• VPN Gateway måste vara av typen Plats-till-plats och konfigurerad i Active-Active

Om du vill använda Azure Route Server måste du:

• Aktivera gren till gren

• Använd routningssammanfattning för > 1 000 vägar eller använd NO_ADVERTISE BGP communities flaggan refenced i vanliga frågor och svar om Azure Route Server

• Peer-NVA med specifika asn-nätverk som inte är Azure. Eftersom ARS till exempel använder 65515 kan ingen annan installation i det virtuella nätverket använda asn (autonomt systemnummer).

• Inget stöd för IPV6

Integrering med Azure NetApp Files

Azure NetApp Files (ANF) tillhandahåller ett nätverksanslutet datalager via NFS-protokollet. ANF finns i ett virtuellt Azure-nätverk och ansluter till arbetsbelastningar i AVS. Genom att använda NFS-datalager som backas upp av Azure NetApp Files kan du expandera lagringen i stället för att skala klustren.

• Skapa Azure NetApp Files-volymer med standardnätverksfunktioner för att aktivera optimerad anslutning från ditt privata AVS-moln via ExpressRoute FastPath
• Distribuera ANF i ett delegerat undernät
• Hub &spoke-distribution stöder ER GW SKU på upp till 10 Gbit/s
• Ultra & ErGw3AZ SKU krävs för att kringgå gatewayportens hastighetsgränser
• Lästrafik-ingresser och skrivtrafik är utgående över Expressroute. Utgående trafik över Expressroute-kretsar kringgår gatewayen och går direkt till gränsroutern
• Avgifter för inkommande/utgående trafik undertrycks från AVS, men det finns en utgående avgift om data går över peer-kopplade virtuella nätverk.
• Endast NFS v3 stöds idag.

Om du får oväntade svarstider kontrollerar du att ditt privata AVS-moln och ANF-distributionen är fästa på samma AZ (Azure-tillgänglighetszoner). För hög tillgänglighet skapar du ANF-volymer i separata AZs och aktiverar Cross Zone Replication

VPN-anslutning från lokal plats

En Expressroute-krets rekommenderas, men det är också möjligt att ansluta till AVS lokalt med IPSEC med hjälp av ett virtuellt transithubbnätverk i Azure. Det här scenariot kräver en VPN-gateway och Azure Route Server. Som tidigare nämnts möjliggör Azure Route Server transitivitet mellan VPN-gatewayen och AVS Expressroute-gatewayen.

Trafikkontroll

Som vi såg tidigare sker standardvägsannonseringen från AVS med den offentliga IP-adressen ned till alternativet NSX Edge, men det är också möjligt att fortsätta annonsera standardvägen lokalt. Slutpunkt till slutpunkt-trafikfiltrering från lokal till AVS är möjlig med brandväggen placerad på någon av dessa slutpunkter.

Standardvägannonsering från Azure är möjlig med en NVA från tredje part i antingen ett virtuellt hubbnätverk eller när du använder Azure vWAN. I en hubb- och ekerdistribution är Azure Firewall inte möjligt eftersom den inte talar BGP, men du kan använda en BGP-kompatibel enhet från tredje part. Det här scenariot fungerar för att inspektera trafik från:

• Lokalt till Azure
• Azure till Internet
• AVS till Internet
• AVS till Azure

En nva från tredje part i det virtuella hubbnätverket inspekterar trafik mellan AVS och Internet och mellan AVS och virtuella Azure-nätverk

Ytterligare Information

• Få åtkomst till vCenter med hjälp av den virtuella datorn Bastion + Jumpbox – Om du använder vCenter lokalt måste du ha en väg från dina lokala nätverk till avs-hanteringsnätverket /22. Verifiera att vägen i CLI genom att skriva Test-NetConnection x.x.x.2 -port 443
• DNS-överväganden – Om du använder privata slutpunkter följer du anvisningarna här: DNS-konfiguration för privat slutpunkt i Azure | Microsoft Learn

Nästa steg

• Mer information om hur du överför från lokal VPN till Azure VMware Solution finns i artikeln om följande VPN till ExR-överföring:
• 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 Azure Router Server finns i produktöversikten Vad är Azure Route Server?

Observera sedan andra designmönster för att upprätta anslutning till Azure VMware-lösningen