Overwegingen bij het ontwerpen van azure VMware Solution-netwerken
Azure VMware Solution biedt een VMware-privécloudomgeving waartoe gebruikers en toepassingen toegang hebben vanuit on-premises omgevingen of resources op basis van Azure. Netwerkservices zoals Azure ExpressRoute- en VPN-verbindingen (Virtual Private Network) leveren de connectiviteit.
Er zijn verschillende aandachtspunten voor netwerken die u moet controleren voordat u uw Azure VMware Solution-omgeving instelt. Dit artikel bevat oplossingen voor gebruiksvoorbeelden die kunnen optreden wanneer u Azure VMware Solution gebruikt om uw netwerken te configureren.
Compatibiliteit van Azure VMware Solution met AS-Path Prepend
Azure VMware Solution heeft overwegingen met betrekking tot het gebruik van AS-Path Prepend voor redundante ExpressRoute-configuraties. Als u twee of meer ExpressRoute-paden tussen on-premises en Azure uitvoert, kunt u de volgende richtlijnen overwegen voor het beïnvloeden van verkeer van Azure VMware Solution naar uw on-premises locatie via ExpressRoute GlobalReach.
Vanwege asymmetrische routering kunnen er verbindingsproblemen optreden wanneer Azure VMware Solution geen AS-Path Prepend observeert en daarom ecmp-routering (equal-cost multipath) gebruikt om verkeer naar uw omgeving te verzenden via beide ExpressRoute-circuits. Dit gedrag kan problemen veroorzaken met stateful firewallinspectieapparaten die achter bestaande ExpressRoute-circuits worden geplaatst.
Vereisten
Houd rekening met de volgende vereisten voor AS-path Prepend:
- Het belangrijkste punt is dat u openbare ASN-nummers moet voorbereiden om te beïnvloeden hoe Azure VMware Solution verkeer terugstuurt naar on-premises. Als u gebruikmaakt van privé-ASN , negeert Azure VMware Solution de prepend en treedt het eerder genoemde ECMP-gedrag op. Zelfs als u een privé-BGP ASN on-premises gebruikt, is het nog steeds mogelijk om uw on-premises apparaten te configureren voor het gebruik van een openbare ASN wanneer uitgaande routes worden voorbereid, om compatibiliteit met Azure VMware Solution te garanderen.
- Ontwerp uw verkeerspad voor privé-ASN's nadat de openbare ASN moet worden gehonoreerd door Azure VMware Solution. Het ExpressRoute-circuit van Azure VMware Solution stript geen privé-ASN's die aanwezig zijn in het pad nadat de openbare ASN is verwerkt.
- Beide of alle circuits zijn verbonden met Azure VMware Solution via Azure ExpressRoute Global Reach.
- Dezelfde netblocks worden geadverteerd vanaf twee of meer circuits.
- U wilt AS-Path Prepend gebruiken om ervoor te zorgen dat de Azure VMware-oplossing de voorkeur geeft aan het ene circuit boven het andere.
- Gebruik openbare ASN-nummers van 2 bytes of 4 bytes.
Beheer-VM's en standaardroutes van on-premises
Belangrijk
Virtuele machines (VM's) van Azure VMware Solution-beheer bieden geen standaardroute van on-premises voor RFC1918 bestemmingen.
Als u terugleidt naar uw on-premises netwerken door alleen een standaardroute te gebruiken die naar Azure wordt geadverteerd, volgt verkeer van vCenter Server- en NSX Manager-VM's die worden gebruikt naar on-premises bestemmingen met privé-IP-adressen die niet worden gevolgd.
Als u vCenter Server en NSX-beheer vanaf on-premises wilt bereiken, geeft u specifieke routes op waarmee verkeer een retourpad naar die netwerken kan hebben. U kunt bijvoorbeeld de samenvattingen van de RFC1918 (10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16) adverteren.
Standaardroute naar Azure VMware Solution voor inspectie van internetverkeer
Voor bepaalde implementaties moet al het uitgaande verkeer van Azure VMware Solution naar internet worden gecontroleerd. Hoewel het mogelijk is om virtuele netwerkapparaten (NVA's) te maken in Azure VMware Solution, zijn er gebruiksvoorbeelden waarin deze apparaten al aanwezig zijn in Azure en kunnen worden toegepast om internetverkeer van Azure VMware Solution te inspecteren. In dit geval kan een standaardroute worden geïnjecteerd vanuit de NVA in Azure om verkeer van Azure VMware Solution aan te trekken en het verkeer te inspecteren voordat het naar het openbare internet gaat.
In het volgende diagram wordt een eenvoudige hub-and-spoke-topologie beschreven die is verbonden met een Azure VMware Solution-cloud en met een on-premises netwerk via ExpressRoute. In het diagram ziet u hoe de NVA in Azure afkomstig is van de standaardroute (0.0.0.0/0). Azure Route Server geeft de route door naar Azure VMware Solution via ExpressRoute.
Belangrijk
De standaardroute die door de NVA wordt aangekondigd, wordt doorgegeven aan het on-premises netwerk. U moet door de gebruiker gedefinieerde routes (UDR's) toevoegen om ervoor te zorgen dat verkeer van Azure VMware Solution wordt overgedragen via de NVA.
Communicatie tussen Azure VMware Solution en het on-premises netwerk vindt meestal plaats via ExpressRoute Global Reach, zoals wordt beschreven in on-premises peeromgevingen naar Azure VMware Solution.
Verbinding maken iviteit tussen Azure VMware Solution en een on-premises netwerk
Er zijn twee hoofdscenario's voor connectiviteit tussen Azure VMware Solution en een on-premises netwerk via een NVA van derden:
- Organisaties moeten verkeer verzenden tussen Azure VMware Solution en het on-premises netwerk via een NVA (meestal een firewall).
- ExpressRoute Global Reach is niet beschikbaar in een bepaalde regio om de ExpressRoute-circuits van Azure VMware Solution en het on-premises netwerk te verbinden.
Er zijn twee topologieën die u kunt toepassen om te voldoen aan alle vereisten voor deze scenario's: supernet en transit spoke virtueel netwerk.
Belangrijk
De voorkeursoptie voor het verbinden van Azure VMware Solution en on-premises omgevingen is een directe ExpressRoute Global Reach-verbinding. De patronen die in dit artikel worden beschreven, voegen complexiteit toe aan de omgeving.
Supernetontwerptopologie
Als beide ExpressRoute-circuits (naar Azure VMware Solution en on-premises) worden beëindigd in dezelfde ExpressRoute-gateway, kunt u ervan uitgaan dat de gateway pakketten erin gaat routeren. Een ExpressRoute-gateway is echter niet ontworpen om dat te doen. U moet het verkeer hairpinen naar een NVA die het verkeer kan routeren.
Er zijn twee vereisten voor het hairpinen van netwerkverkeer naar een NVA:
De NVA moet een supernet adverteren voor de Azure VMware Solution en on-premises voorvoegsels.
U kunt een supernet gebruiken dat zowel Azure VMware Solution als on-premises voorvoegsels bevat. U kunt ook afzonderlijke voorvoegsels gebruiken voor Azure VMware Solution en on-premises (altijd minder specifiek dan de werkelijke voorvoegsels die worden geadverteerd via ExpressRoute). Houd er rekening mee dat alle supernetvoorvoegsels die worden aangekondigd bij Route Server, worden doorgegeven aan zowel Azure VMware Solution als on-premises.
UDR's in het gatewaysubnet, die exact overeenkomen met de voorvoegsels die worden geadverteerd vanuit Azure VMware Solution en on-premises, veroorzaken haarpinverkeer van het gatewaysubnet naar de NVA.
Deze topologie resulteert in een hoge beheeroverhead voor grote netwerken die na verloop van tijd veranderen. Houd rekening met deze beperkingen:
- Telkens wanneer een workloadsegment wordt gemaakt in Azure VMware Solution, moeten UDR's mogelijk worden toegevoegd om ervoor te zorgen dat verkeer van Azure VMware Solution wordt overgedragen via de NVA.
- Als uw on-premises omgeving een groot aantal routes heeft die veranderen, moet de configuratie van Border Gateway Protocol (BGP) en UDR in het supernet mogelijk worden bijgewerkt.
- Omdat één ExpressRoute-gateway netwerkverkeer in beide richtingen verwerkt, zijn de prestaties mogelijk beperkt.
- Er is een azure Virtual Network-limiet van 400 UDR's.
In het volgende diagram ziet u hoe de NVA voorvoegsels moet adverteren die algemener zijn (minder specifiek) en die de netwerken van on-premises en Azure VMware Solution omvatten. Wees voorzichtig met deze aanpak. De NVA kan mogelijk verkeer aantrekken dat het niet zou moeten, omdat het bredere bereiken aan het adverteren is (bijvoorbeeld het hele 10.0.0.0/8 netwerk).
Transit spoke virtual network topologie
Notitie
Als reclamevoorvoegsels die minder specifiek zijn, niet mogelijk zijn vanwege de eerder beschreven limieten, kunt u een alternatief ontwerp implementeren dat gebruikmaakt van twee afzonderlijke virtuele netwerken.
In deze topologie kunnen in plaats van routes die minder specifiek zijn om verkeer aan te trekken naar de ExpressRoute-gateway, twee verschillende NVA's in afzonderlijke virtuele netwerken routes tussen elkaar uitwisselen. De virtuele netwerken kunnen deze routes doorgeven aan hun respectieve ExpressRoute-circuits via BGP en Azure Route Server. Elke NVA heeft volledige controle over welke voorvoegsels worden doorgegeven aan elk ExpressRoute-circuit.
In het volgende diagram ziet u hoe één 0.0.0.0/0 route wordt geadverteerd naar Azure VMware Solution. Ook ziet u hoe de afzonderlijke Voorvoegsels van Azure VMware Solution worden doorgegeven aan het on-premises netwerk.
Belangrijk
Een inkapselingsprotocol, zoals VXLAN of IPsec, is vereist tussen de NVA's. Inkapseling is nodig omdat de NVA-netwerkadapter (NIC) de routes van Azure Route Server zou leren met de NVA als de volgende hop en een routeringslus zou maken.
Er is een alternatief voor het gebruik van een overlay. Pas secundaire NIC's toe in de NVA die de routes niet leren van Azure Route Server. Configureer vervolgens UDR's zodat Azure verkeer kan routeren naar de externe omgeving via die NIC's. Meer informatie vindt u in de topologie en connectiviteit op ondernemingsniveau voor Azure VMware Solution.
Voor deze topologie is een complexe eerste installatie vereist. De topologie werkt vervolgens zoals verwacht met minimale beheeroverhead. Complexe instellingen zijn onder andere:
- Er zijn extra kosten verbonden aan het toevoegen van een ander virtueel transitnetwerk met Azure Route Server, een ExpressRoute-gateway en een andere NVA. De NVA's moeten mogelijk ook grote VM-grootten gebruiken om te voldoen aan de doorvoervereisten.
- IPsec- of VXLAN-tunneling is vereist tussen de twee NVA's, wat betekent dat de NVA's zich ook in het gegevenspad bevinden. Afhankelijk van het type NVA dat u gebruikt, kan dit leiden tot een aangepaste en complexe configuratie voor deze NVA's.
Volgende stappen
Nadat u meer hebt geleerd over overwegingen bij het ontwerpen van netwerken voor Azure VMware Solution, kunt u de volgende artikelen bekijken: