Spoke-to-spoke-netwerken

De meest voorkomende ontwerppatronen voor netwerken in Azure omvatten het maken van hub-and-spoke-topologieën voor virtuele netwerken in een of meerdere Azure-regio's, optioneel verbonden met on-premises netwerken via Azure ExpressRoute of site-naar-site VPN-tunnels (virtual private network) via het openbare internet.

De meeste ontwerphandleidingen richten zich op toepassingsverkeer naar die virtuele netwerken van gebruikers in interne, on-premises netwerken of van internet (wat de branche doorgaans noord-zuidverkeer aanwijst, omdat het vaak wordt vertegenwoordigd door verticale lijnen in netwerkdiagrammen). Dit artikel richt zich op verschillende patronen die beschikbaar zijn voor oost-west-verkeer. Communicatiestromen tussen workloads die zijn geïmplementeerd in virtuele Azure-netwerken, binnen één regio of in verschillende regio's.

Zorg ervoor dat uw netwerkontwerp voldoet aan de vereisten voor oost-west-verkeer, is essentieel voor het bieden van prestaties, schaalbaarheid en tolerantie voor uw toepassingen die worden uitgevoerd in Azure.

Potentiële gebruikscases

Spoke-to-spoke-verkeer kan in verschillende scenario's belangrijk zijn:

• Verschillende lagen van één toepassing bevinden zich in afzonderlijke virtuele netwerken. Perimeternetwerkservers (ook wel DMZ-servers genoemd) in een virtueel perimeternetwerk communiceren bijvoorbeeld met toepassingsservices in een intern virtueel netwerk.
• Toepassingsworkloads in verschillende omgevingen (ontwikkeling, fasering, productie) moeten gegevens tussen elkaar repliceren.
• Verschillende toepassingen of microservices moeten met elkaar communiceren.
• Databases moeten gegevens repliceren tussen regio's om bedrijfscontinuïteit te garanderen in het geval van een noodgeval.
• Gebruikers bevinden zich in virtuele Azure-netwerken. Ze gebruiken bijvoorbeeld Azure Virtual Desktop.

Patronen en topologieën voor communicatie tussen spokes

Er zijn twee belangrijkste topologieën die u kunt gebruiken in Azure-ontwerpen die meerdere virtuele netwerken kruisen: traditionele hub en spoke en Azure Virtual WAN. In een Virtual WAN-omgeving beheert Microsoft het virtuele hubnetwerk en alles erin. In een traditionele hub-and-spoke-omgeving beheert u het virtuele hubnetwerk.

Virtual WAN- en hub-and-spoke-topologieën zijn beide voorbeelden van architecturen waarin de workloads worden uitgevoerd in virtuele spoke-netwerken en connectiviteit met on-premises worden gecentraliseerd in een virtueel hubnetwerk. Veel van de concepten die in dit artikel worden uitgelegd, zijn van toepassing op zowel hub-and-spoke- als Virtual WAN-ontwerpen.

Er zijn twee hoofdpatronen voor het verbinden van virtuele spoke-netwerken met elkaar:

• Spokes die rechtstreeks met elkaar zijn verbonden. Peerings van virtuele netwerken of VPN-tunnels worden gemaakt tussen de virtuele spoke-netwerken om directe connectiviteit te bieden zonder het virtuele hubnetwerk te doorlopen.
• Spokes communiceren via een netwerkapparaat. Elk virtueel spoke-netwerk heeft een peering naar Virtual WAN of naar een virtueel hubnetwerk. Een apparaat stuurt verkeer van spoke naar spoke. Het apparaat kan worden beheerd door Microsoft (zoals met Virtual WAN) of door u.

Patroon 1: Spokes rechtstreeks met elkaar verbonden

Directe verbindingen tussen spokes bieden doorgaans betere doorvoer, latentie en schaalbaarheid dan verbindingen die via een virtueel netwerkapparaat (NVA) in een hub lopen. Het verzenden van verkeer via NVA's kan latentie toevoegen aan het verkeer als de NVA's zich in een andere beschikbaarheidszone bevinden en ten minste twee peerings voor virtuele netwerken moeten worden overschreden wanneer verkeer via de hub wordt verzonden. Er zijn verschillende opties voor het rechtstreeks verbinden van twee virtuele spoke-netwerken met elkaar: peering van virtuele netwerken, Azure Virtual Network Manager en VPN-tunnels.

• Peering van virtuele netwerken. De voordelen van directe peerings van virtuele netwerken via spokes zijn:

  • Lagere kosten, omdat er minder peeringhops voor virtuele netwerken nodig zijn.
  • Betere prestaties, omdat verkeer geen netwerkapparaat hoeft te doorlopen dat latentie of potentiële knelpunten introduceert.

  Andere scenario's omvatten connectiviteit tussen tenants. Mogelijk moet u echter het verkeer tussen virtuele spoke-netwerken inspecteren. Dit kan vereisen dat verkeer wordt verzonden via gecentraliseerde netwerkapparaten in het virtuele hubnetwerk.

• Azure Virtual Network Manager. Naast de voordelen van peering van virtuele netwerken biedt Azure Virtual Network Manager een beheerservice waarmee u omgevingen van virtuele netwerken kunt beheren en connectiviteit op schaal kunt maken. Met Behulp van Azure Virtual Network Manager kunt u drie typen topologieën maken voor zowel bestaande als nieuwe virtuele netwerken:

  • Hub en spoke met spokes die niet met elkaar zijn verbonden.

  • Hub en spoke met spokes die rechtstreeks met elkaar zijn verbonden, zonder hop in het midden.

  • Een meshed groep virtuele netwerken die zijn verbonden.

    

    Download alle Visio-diagrammen in dit artikel.

    Wanneer u een hub-and-spoke-topologie maakt met Azure Virtual Network Manager waarin spokes met elkaar zijn verbonden, wordt directe connectiviteit tussen virtuele spoke-netwerken in dezelfde netwerkgroep automatisch in twee richtingen gemaakt. Met Behulp van Azure Virtual Network Manager kunt u statisch of dynamisch spoke virtuele netwerken leden van een specifieke netwerkgroep, waarmee automatisch de connectiviteit voor elk virtueel netwerk wordt gemaakt.

    U kunt meerdere netwerkgroepen maken om clusters van virtuele spoke-netwerken te isoleren van directe connectiviteit. Elke netwerkgroep biedt dezelfde regio- en ondersteuning voor meerdere regio's voor spoke-to-spoke-connectiviteit. Zorg ervoor dat u onder de maximumlimieten blijft voor Azure Virtual Network Manager die worden beschreven in de veelgestelde vragen over Azure Virtual Network Manager.

• VPN-tunnels die virtuele netwerken verbinden. U kunt VPN-services configureren om virtuele spoke-netwerken rechtstreeks te verbinden met behulp van Microsoft VPN-gateways of VPN-NVA's van derden. Het voordeel van deze optie is dat spoke-virtuele netwerken verbinding maken tussen commerciële en onafhankelijke clouds binnen dezelfde cloudprovider of connectiviteit tussen cloudproviders. Als er softwaregedefinieerde SD-WAN-NVA's (Wide Area Network) aanwezig zijn in elk virtueel spoke-netwerk, kan deze configuratie het gebruik van het besturingsvlak en de functie van de externe provider vergemakkelijken om de connectiviteit van virtuele netwerken te beheren.

  Met deze optie kunt u ook voldoen aan de nalevingsvereisten voor de versleuteling van verkeer in virtuele netwerken in één Azure-datacenter dat nog niet is geleverd door MACsec-versleuteling. Maar deze optie wordt geleverd met een eigen reeks uitdagingen vanwege de bandbreedtelimieten van IPsec-tunnels (1,25 Gbps per tunnel) en de ontwerpbeperkingen voor het hebben van virtuele netwerkgateways in zowel hub- als spoke-virtuele netwerken: als het virtuele spoke-netwerk een virtuele netwerkgateway heeft, kan deze niet worden verbonden met Virtual WAN of de virtuele netwerkgateway van een hub gebruiken om verbinding te maken met on-premises netwerken.

Patroon 1: Enkele regio

Ongeacht de technologie die u gebruikt om virtuele spoke-netwerken met elkaar te verbinden, zien de netwerktopologieën er als volgt uit voor één regio:

Patroon 1: Meerdere regio's

Ontwerpen die alle virtuele spoke-netwerken met elkaar verbinden, kunnen ook worden uitgebreid naar meerdere regio's. In deze topologie is Azure Virtual Network Manager nog belangrijker om de administratieve overhead te verminderen van het onderhouden van het vereiste grote aantal verbindingen.

Wanneer u spoke-virtuele netwerken rechtstreeks met elkaar verbindt in een volledig meshed topologie, moet u rekening houden met het potentieel grote aantal vereiste peerings voor virtuele netwerken. In het volgende diagram ziet u dit probleem. In dit scenario wordt Azure Virtual Network Manager sterk aanbevolen, zodat u automatisch virtuele netwerkverbindingen kunt maken.

Patroon 2: Spokes communiceren via een netwerkapparaat

In plaats van virtuele spoke-netwerken rechtstreeks met elkaar te verbinden, kunt u netwerkapparaten gebruiken om verkeer tussen spokes door te sturen. Netwerkapparaten bieden aanvullende netwerkservices, zoals grondige pakketinspectie en verkeerssegmentatie of -bewaking, maar ze kunnen latentie- en prestatieknelpunten veroorzaken als ze niet op de juiste grootte zijn. Deze apparaten bevinden zich meestal in een virtueel hubnetwerk waarmee de spokes verbinding maken. Er zijn meerdere opties voor het gebruik van een netwerkapparaat om verkeer tussen spokes door te sturen:

• Virtual WAN-hubrouter. Virtual WAN wordt volledig beheerd door Microsoft en bevat een virtuele router die verkeer van spokes trekt en routeert naar een ander virtueel netwerk dat is verbonden met Virtual WAN of met on-premises netwerken via ExpressRoute of site-naar-site- of punt-naar-site-VPN-tunnels. De Virtual WAN-router wordt automatisch omhoog en omlaag geschaald, dus u hoeft er alleen voor te zorgen dat het verkeersvolume tussen spokes binnen de limieten van Virtual WAN blijft.

• Azure Firewall.Azure Firewall is een netwerkapparaat dat wordt beheerd door Microsoft en kan worden geïmplementeerd in virtuele hubnetwerken die u beheert of in Virtual WAN-hubs. Het kan IP-pakketten doorsturen en kan deze ook inspecteren en verkeersegmentatieregels toepassen die zijn gedefinieerd in beleid. Het biedt automatisch schalen tot de Limieten van Azure Firewall , zodat het geen knelpunt wordt. Houd er rekening mee dat Azure Firewall out-of-the-box mogelijkheden voor meerdere regio's biedt wanneer deze worden gebruikt met Virtual WAN. Zonder Virtual WAN moet u door de gebruiker gedefinieerde routes implementeren om cross-regional spoke-to-spoke-communicatie te bereiken.

• Virtuele netwerkapparaten van derden. Als u liever een virtueel netwerkapparaat van een Microsoft-partner gebruikt om routering en netwerksegmentatie uit te voeren, kunt u virtuele netwerkapparaten implementeren in een hub-and-spoke- of een Virtual WAN-topologie. Zie Maximaal beschikbare NVA's of NVA's implementeren in een Virtual WAN-hub voor meer informatie. U moet ervoor zorgen dat het virtuele netwerkapparaat de bandbreedte ondersteunt die de communicatie tussen spokes genereert.

• Azure VPN Gateway. U kunt een Azure VPN-gateway gebruiken als een volgend hoptype van door de gebruiker gedefinieerde route, maar Microsoft raadt het gebruik van virtuele VPN-netwerkgateways niet aan om spoke-to-spoke-verkeer te routeren. Ze zijn ontworpen voor het versleutelen van verkeer naar on-premises sites of VPN-gebruikers. Er is bijvoorbeeld geen garantie voor de bandbreedte tussen spokes die een VPN-gateway kan routeren.

• ExpressRoute. In bepaalde configuraties kan een ExpressRoute-gateway routes adverteren die spoke-to-spoke-communicatie aantrekken, verkeer verzenden naar de Microsoft Edge-router, waar deze wordt gerouteerd naar de doelspaak. Microsoft raadt dit scenario sterk af, omdat het latentie introduceert door verkeer naar de Microsoft-backbonerand en -terug te sturen. Bovendien raadt Microsoft deze benadering niet aan, vanwege het single point of failure en de grote straal van de explosie. In dit scenario worden ook meerdere problemen veroorzaakt door extra druk op de ExpressRoute-infrastructuur (de gateway en fysieke routers). Deze extra druk kan leiden tot pakketdruppels.

In hub-and-spoke-netwerkontwerpen met gecentraliseerde NVA's wordt het apparaat meestal in de hub geplaatst. Peerings voor virtuele netwerken tussen hub-and-spoke-netwerken moeten handmatig of automatisch worden gemaakt met Azure Virtual Network Manager:

• Handmatige peerings voor virtuele netwerken. Deze benadering is voldoende wanneer u een laag aantal virtuele spoke-netwerken hebt, maar er wordt beheeroverhead op schaal gecreëerd.

• Azure Virtual Network Manager. Zoals eerder vermeld, biedt Azure Virtual Network Manager functies voor het beheren van virtuele netwerkomgevingen en peerings op schaal. Peeringconfiguraties tussen hub-and-spoke virtuele netwerken worden automatisch in twee richtingen geconfigureerd voor netwerkgroepen.

  Azure Virtual Network Manager biedt de mogelijkheid om statisch of dynamisch spoke virtueel netwerklidmaatschappen toe te voegen aan een specifieke netwerkgroep, waarmee automatisch de peeringverbinding voor nieuwe leden wordt gemaakt. Virtuele spoke-netwerken in netwerkgroepen kunnen de hub-VPN of ExpressRoute-gateways gebruiken voor connectiviteit. Zorg ervoor dat u onder de maximale limieten voor Azure Virtual Network Manager blijft.

Patroon 2: Enkele regio

In het volgende diagram ziet u een hub-en-spoke-topologie met één regio die verkeer tussen spokes verzendt via een Azure-firewall die is geïmplementeerd in het virtuele hubnetwerk. Verkeer wordt doorgestuurd naar het gecentraliseerde apparaat in de hub via door de gebruiker gedefinieerde routes die worden toegepast op de spoke-subnetten.

In bepaalde omstandigheden kan het nuttig zijn om de virtuele netwerkapparaten te scheiden die spoke-to-spoke- en internetverkeer verwerken voor schaalbaarheid. U kunt deze scheiding bereiken door:

• De routetabellen in de spokes afstemmen om privéadressen (die een route voor RFC 1918-voorvoegsels hebben) te verzenden naar een NVA die verantwoordelijk is voor Azure-naar-Azure- en Azure-naar-on-premises verkeer (ook wel oost-west-verkeer genoemd).
• Internetverkeer afstemmen (met een route van 0.0.0.0/0) naar een tweede NVA. Deze NVA is verantwoordelijk voor Azure-naar-internetverkeer (ook wel noord-zuidverkeer genoemd).

In het volgende diagram ziet u deze configuratie:

Patroon 2: Meerdere regio's

U kunt dezelfde configuratie uitbreiden naar meerdere regio's. In een hub-and-spoke-ontwerp dat gebruikmaakt van Azure Firewall, moet u bijvoorbeeld extra routetabellen toepassen op de Azure Firewall-subnetten in elke hub voor de spokes in de externe regio. Deze configuratie zorgt ervoor dat verkeer tussen regio's kan worden doorgestuurd tussen de Azure-firewalls in elk virtueel hubnetwerk. Interregionaal verkeer tussen virtuele spoke-netwerken doorkruist vervolgens beide Azure-firewalls. Zie Azure Firewall voor meer informatie om een multi-hub- en spoke-topologie te routeren:

De ontwerpvariatie met afzonderlijke Azure-firewalls of virtuele netwerkapparaten voor noord-zuid- en oost-westverkeer is ook mogelijk in een hub-en-spoke-topologie met meerdere regio's:

Virtual WAN maakt een vergelijkbare topologie en neemt de routeringscomplexiteit over. Het doet dit zowel in de hubs (die Door Microsoft worden beheerd) als in de spokes (waar routes kunnen worden geïnjecteerd en die niet handmatig hoeven te worden gedefinieerd in routetabellen). De netwerkbeheerder hoeft dus alleen de spoke-virtuele netwerken te verbinden met een Virtual WAN-hub en hoeft zich geen zorgen te maken over het doorsturen van verkeer tussen regio's.

Hybride patronen

Veel situaties vereisen een hybride benadering die de twee eerder beschreven patronen combineert. In deze benadering moet verkeer tussen bepaalde spokes via directe verbindingen gaan, maar de rest van de spokes communiceren via een centraal netwerkapparaat. In een Virtual WAN-omgeving kunt u bijvoorbeeld rechtstreeks twee specifieke spokes verbinden met hoge bandbreedte- en lage latentievereisten. Een ander scenario omvat spoke-virtuele netwerken die deel uitmaken van één omgeving. U kunt bijvoorbeeld toestaan dat een virtueel spoke development-netwerk rechtstreeks verbinding maakt met een ander virtueel netwerk voor spoke-ontwikkeling, maar dwingt u ontwikkel- en productieworkloads af om te communiceren via het centrale apparaat.

Een ander veelvoorkomend patroon omvat het verbinden van spokes in één regio via directe peerings voor virtuele netwerken of verbonden azure Virtual Network Manager-groepen, maar het toestaan van interregionaal verkeer om meerdere NVA's te kruisen. De belangrijkste motivatie voor dit model is doorgaans om het aantal peerings van virtuele netwerken in de architectuur te verminderen. In vergelijking met het eerste model (directe connectiviteit tussen spokes) is een nadeel dat in dit model is geïntroduceerd, meer peeringhops voor virtuele netwerken voor verkeer tussen regio's. Deze hops verhogen de kosten vanwege de meerdere peerings van virtuele netwerken die worden gekruist. Een ander nadeel is de extra belasting voor de hub NVA's om al het cross-regional verkeer voor te komen.

Dezelfde ontwerpen zijn van toepassing op Virtual WAN. Een overweging is echter dat directe connectiviteit tussen virtuele spoke-netwerken handmatig moet worden geconfigureerd tussen de virtuele netwerken en niet via de Virtual WAN-resource. Azure Virtual Network Manager biedt momenteel geen ondersteuning voor architecturen die zijn gebaseerd op Virtual WAN. Voorbeeld:

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

• Jay Li | Senior Product Manager
• Jose Moreno | Principal Customer Engineer
• Spanjaarda Palacios | Senior klanttechnicus voor Azure-infrastructuur

Andere Inzenders:

• Mick Alberts | Technische schrijver
• Mohammed Mohammed | Principal PM Manager
• Andrea Michael | Program Manager
• Yasukuni Morishima | Klanttechnicus II
• Jithin PP | Klanttechnicus

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Cloud Adoption Framework: Topologie en connectiviteit van landingszones
• Peering op virtueel netwerk
• Azure Virtual Network Manager
• Virtual WAN
• Azure Firewall
• Netwerkconnectiviteit beveiligen in Azure
• Inleiding tot Azure Virtual Networks

Verwante resources

• Hub-spoke-netwerktopologie in Azure
• Sternetwerktopologie met Azure Virtual WAN
• Traditionele Azure-netwerktopologie