Connectiviteit voor data-landingszones tussen regio's
Als u in meer dan één Azure-regio aanwezig bent en uw gegevensplatform en gegevenstoepassingen in meerdere geografische gebieden moet hosten, wordt de connectiviteit iets ingewikkelder.
Implementaties in meerdere regio's hebben over het algemeen een connectiviteitshubabonnement op elke afzonderlijke Azure-locatie. Als u bijvoorbeeld services hebt die worden uitgevoerd in zowel VS - oost als Europa - west, stelt u een connectiviteitshubabonnement in met gedeelde netwerkbronnen in elke regio. Gedeelde netwerkbronnen zijn onder andere:
- Virtuele netwerkapparaten (zoals Azure Firewall)
- ExpressRoute-gateways
- VPN-gateways
- Virtuele hubnetwerken (in een hub- en spoke-architectuur) of vWAN Hubs (in een vWan-installatie)
afbeelding 1: Connectiviteit tussen regio's.
In hub-spoke-spoke-hub-architectuur zijn de virtuele netwerken van connectiviteitshubs vaak verbonden via globale peering van virtuele netwerken. Voor grotere omgevingen is een algemeen alternatief het gebruik van ExpressRoute Global Reach. Welke connectiviteitsoptie u ook kiest, u kunt wereldwijde routering en connectiviteit tussen spoke-netwerken in meerdere geografische gebieden bereiken. Dit betekent dat u gegevens kunt verplaatsen tussen regio's met behulp van virtuele netwerkapparaten, netwerkbeveiligingsgroepen en routetabellen, omdat uw verkeer niet wordt geblokkeerd in een van beide connectiviteitsabonnementen.
Belangrijk
Dit artikel en andere artikelen in de sectie Netwerken bevatten een overzicht van bedrijfsonderdelen die gegevens delen. Dit is echter mogelijk niet uw eerste strategie en moet u eerst op basisniveau beginnen.
Ontwerp uw netwerk zodat u uiteindelijk onze aanbevolen installatie tussen datalandingszones kunt implementeren. Zorg ervoor dat de landingszones voor gegevensbeheer rechtstreeks zijn verbonden met de landingszones voor governance.
Wereldwijde peering voor virtuele netwerken (aanbevolen)
U kunt gegevenslandingszones in verschillende regio's verbinden met behulp van directe globale virtuele netwerkpeering. Als we in deze opstelling ons vorige voorbeeldscenario voortzetten, krijgt de virtuele machine in West-Europa rechtstreeks toegang tot het privé-eindpunt van de opslagaccount in Oost-VS, zonder afhankelijk te zijn van hub-en-spoke- of vWAN-netwerkarchitecturen. Gegevens worden rechtstreeks door de virtuele machine geladen via een privé-eindpunt, verwerkt en vervolgens opgeslagen in het opslagaccount in Europa - west.
Beheer van gebruikerstoegang in globaal virtueel netwerkpeering
Er zijn geen specifieke voor- of nadelen voor een van de voorgestelde connectiviteitsopties voor gegevenslandingszones tussen regio's.
Samenvatting: 
/
Servicebeheer in peering van wereldwijde virtuele netwerken
Wereldwijde peering van virtuele netwerken beschikt niet over een virtueel netwerkapparaat dat fungeert als een enkelvoudig storingspunt of beperking van de doorvoer. Gegevens worden niet verzonden via uw connectiviteitshubs, dus u hoeft de virtuele apparaten en gateways binnen de connectiviteitshubs niet te schalen. Dit gebrek aan schaalaanpassing vermindert de beheeroverhead voor uw kernteam van het Azure-platform. U hoeft ook geen afzonderlijke verbindingen tussen regio's toe te staan. Uw gegevensteams hebben toegang tot gegevens uit gegevenslandingszones in andere regio's zonder te hoeven wachten op wijzigingen in de routetabel.
In dit netwerkontwerp kan uw centrale Azure-platformteam niet langer al het verkeer inspecteren en registreren met behulp van een laag 7-firewall. Het scenario voor analyse op cloudschaal is echter een coherent platform dat meerdere abonnementen beslaat, waardoor de schaal kan worden aangepast en beperkingen op platformniveau worden weggenomen, dus dat is geen nadeel. U kunt netwerklogboeken vastleggen met behulp van stroomlogboeken voor netwerkbeveiligingsgroepen. U kunt andere logboeken op toepassings- en serviceniveau samenvoegen en opslaan met behulp van servicespecifieke diagnostische instellingen.
U kunt al deze logboeken op schaal vastleggen met behulp van Azure Policy-definities voor diagnostische instellingen.
In sommige scenario's moet u beperken vanwege wettelijke of juridische implicaties. U hebt bijvoorbeeld een lokale regelgeving waarvoor bepaalde gegevenssets moeten blijven in een datacenter met deeltjes, zodat u ze niet kunt overdragen tussen regio's. U kunt vertrouwen op netwerkbeveiligingsgroepen om te voldoen aan dit soort regels, zodat verkeer in één richting van VS - oost naar Europa - west kan worden verplaatst en niet omgekeerd. Binnen uw netwerkbeveiligingsgroepen kunt u ervoor zorgen dat verkeer dat afkomstig is van VS - oost, wordt geweigerd terwijl verkeer dat afkomstig is van Europa - west is toegestaan.
Deze oplossingsbenadering heeft geen invloed op de bandbreedte en latentie en stelt klanten in staat om compatibel te blijven terwijl ze nog steeds gegevenssets uit meerdere regio's combineren. Deze optie heeft ook geen invloed op uw DNS-architectuur en stelt u in staat om een systeemeigen Azure-oplossing te gebruiken op basis van Privé-DNS-zones van Azure.
Samenvatting:
Kosten voor wereldwijde peering van virtuele netwerken
Notitie
Wanneer u toegang krijgt tot een privé-eindpunt in een gekoppeld netwerk, worden er alleen kosten in rekening gebracht voor het privé-eindpunt zelf en niet voor de VNet-peering. U kunt de officiële verklaring lezen in veelgestelde vragen: Hoe werkt facturering bij het openen van een privé-eindpunt vanuit een gekoppeld netwerk?.
Met dit netwerkontwerp worden kosten in rekening gebracht voor uw privé-eindpunten (per uur) en al het inkomend en uitgaand verkeer dat via deze eindpunten wordt verzonden. U moet ook een kosten voor gegevensoverdracht betalen voor verkeer tussen regio's. Er worden echter geen kosten in rekening gebracht voor Global virtual network Peering-ingangs- en uitgangskosten, en het biedt opmerkelijke kostenvoordelen vergeleken met de traditionele spoke-hub-hub-spoke-optie.
Samenvatting:
Bandbreedte en latentie in peering van wereldwijde virtuele netwerken
Impact op bandbreedte en latentie is lager in peering van wereldwijde virtuele netwerken dan in de traditionele spoke-hub-hub-spoke-optie. Wereldwijde peering van virtuele netwerken bevat een lager aantal hops voor gegevensuitwisseling in datalandingzones tussen regio's en heeft geen virtuele netwerkapparaten die de doorvoer beperken. De enige dingen die de bandbreedte en latentie dicteren die u kunt bereiken voor verkeer tussen regio's zijn de fysieke limieten van onze datacenters (snelheid van glasvezelkabels, gateways en routers).
Samenvatting:
Overzicht van peering van globale virtuele netwerken
Wereldwijde peering van virtuele netwerken tussen gegevenslandingszones in verschillende regio's biedt enorme voordelen, met name omdat gegevensverkeer tussen regio's toeneemt binnen uw gegevensplatform. Het vereenvoudigt het servicebeheer voor uw kernteam van het Azure-platform en biedt met name voordelen voor use cases waarvoor lage latentie en hoge bandbreedte is vereist. Het biedt ook aanzienlijke kostenvoordelen ten opzichte van de traditionele spoke-hub-hub-spoke-ontwerpoptie.
Traditioneel spoke-hub-spoke-ontwerp (niet aanbevolen)
Uw andere optie voor gegevensoverdracht tussen regio's is het traditionele spoke-hub-hub-spoke-ontwerp. Als in ons voorbeeldscenario een virtuele machine in gegevenslandingszone A die wordt gehost in West-Europa een gegevensset laadt die is opgeslagen in een opslagaccount van gegevenslandingszone B die wordt gehost in Oost-VS, gaat de data door twee lokale virtuele-netwerk-peerings (connectiviteit tussen hubs en spokes), één wereldwijde virtuele-netwerk-peering (connectiviteit tussen hubs) en twee gateways of virtuele netwerkapparaten voordat ze door de virtuele machine worden geladen en vervolgens weer worden verplaatst naar het lokale opslagaccount.
Beheer van gebruikerstoegang in traditioneel spoke-hub-hub-spoke-ontwerp
Er zijn geen specifieke voor- of nadelen voor een van de voorgestelde connectiviteitsopties voor gegevenslandingszones tussen regio's.
Samenvatting:
/
Beheer van diensten in een traditioneel spaak-naaf-naaf-spaak-ontwerp
Deze oplossingsbenadering is bekend en consistent met andere connectiviteitspatronen tussen regio's, waardoor u eenvoudig kunt overstappen en implementeren. Het heeft ook geen invloed op de DNS-architectuur en stelt u in staat om een systeemeigen Azure-oplossing te gebruiken op basis van Privé-DNS-zones van Azure.
Hoewel deze connectiviteitsoptie naadloos werkt als u deze juist instelt, heeft deze wel een nadeel. Verkeer tussen regio's wordt vaak standaard geweigerd en moet per geval worden ingeschakeld. Er moet een ticket worden ingediend bij uw kernteam van het Azure-platform voor elke vereiste vereiste toegang tot gegevens in meerdere regio's, zodat uw team elke specifieke verbinding tussen een virtuele machine en een opslagaccount voor meerdere regio's kan toestaan. Dit proces verhoogt de beheeroverhead aanzienlijk. Het vertraagt ook uw dataprojectteams, omdat ze geen toegang hebben tot de gegevens die ze nodig hebben.
Houd er ook rekening mee dat in deze optie connectiviteitshubs fungeren als enkele storingspunten. Tijdens een uitval van virtuele netwerkapparaten of gateways falen de connectiviteit en de bijbehorende gegevensplatforms. U hebt ook een hoog risico op het onjuist configureren van routes in de connectiviteitshubs. Deze onjuiste configuratie kan ernstigere downtime veroorzaken in uw gegevensplatform en leiden tot een reeks afhankelijke werkstroom- en gegevensproductfouten.
U moet de hoeveelheid gegevens bewaken die u moet overdragen tussen regio's terwijl u deze oplossingsbenadering gebruikt. In de loop van de tijd kan deze bewaking betrekking hebben op gigabytes of terabytes aan gegevens die door uw centrale instanties worden verplaatst. Omdat de bandbreedte van virtuele netwerkapparaten vaak beperkt is tot een gigabyte-doorvoer van één of twee cijfers, kunnen de apparaten fungeren als een kritiek knelpunt dat de verkeersstroom tussen regio's en de deelbaarheid van uw gegevensassets beperkt. Vanwege dit knelpunt kunnen uw gedeelde netwerkbronnen schaalmechanismen vereisen, die vaak tijdrovend en kostbaar zijn en van invloed kunnen zijn op andere workloads in uw tenant.
Samenvatting:
Traditionele Spoke-Hub-Hub-Spoke ontwerpkosten
Notitie
Wanneer u toegang krijgt tot een privé-eindpunt in een peernetwerk, worden er alleen kosten in rekening gebracht voor het privé-eindpunt zelf en niet voor de VNet-peering. U kunt de officiële verklaring lezen in FAQ: Hoe werkt de facturering voor toegang tot een privé-eindpunt vanuit een gekoppeld netwerk?.
In het traditionele spaken-naar-naaf ontwerp worden de privé-eindpunten van uw twee opslagrekeningen per uur in rekening gebracht, samen met al het inkomende en uitgaande verkeer dat er doorheen wordt gestuurd. Er worden ook kosten in rekening gebracht voor het inkomend en uitgaand verkeer van één lokale peering van een virtueel netwerk en de wereldwijde peering van virtuele netwerken tussen uw connectiviteitshubs. Er worden echter geen kosten in rekening gebracht voor de eerste peering van het virtuele netwerk, zoals we in de vorige opmerking hebben uitgelegd.
Voor uw virtuele centrale netwerkapparaten worden ook aanzienlijke kosten in rekening gebracht als u dit netwerkontwerp kiest. Deze kosten zijn omdat u extra licenties moet aanschaffen om de apparaten te schalen op basis van vraag of om de kosten per verwerkte gigabyte te betalen, net als bij Azure Firewall.
Samenvatting:
Bandbreedte en latentie in een traditioneel spaken-naaf-naaf-spaken-ontwerp
Dit netwerkontwerp heeft ernstige bandbreedtebeperkingen. Uw centrale virtuele netwerkapparaten worden kritieke knelpunten naarmate uw platform groeit, waardoor gebruiksscenario's voor landingszones voor meerdere regio's en het delen van uw gegevenssets worden beperkt. Het maakt ook waarschijnlijk dat meerdere kopieën van uw gegevenssets na verloop van tijd worden gemaakt. Dit ontwerp is ook sterk van invloed op latentie, wat met name essentieel is voor realtime analysescenario's, omdat uw gegevens veel hops doorkruisen.
Samenvatting:
Ontwerp van het traditionele spaak-naaf-naaf-spaak systeem
Het spoke-hub-hub-spoke-ontwerp is bekend en is ingeburgerd bij veel organisaties, waardoor het eenvoudig is om in een bestaande omgeving te implementeren. Het heeft echter aanzienlijke nadelen voor servicebeheer, kosten, bandbreedte en latentie. Deze problemen zijn vooral merkbaar omdat uw aantal gebruiksscenario's in meerdere regio's toeneemt.
Conclusie
globale virtuele netwerkpeering heeft veel voordelen ten opzichte van het traditionele spoke-hub-spoke-ontwerp, omdat het rendabel, eenvoudig te beheren is en betrouwbare connectiviteit biedt over regio's. Hoewel het traditionele spoke-hub-hub-spoke-ontwerp een haalbare optie kan zijn terwijl uw gegevensvolume en behoefte aan gegevensuitwisseling tussen regio's laag zijn, raden we u aan om de benadering voor peering van wereldwijde virtuele netwerken te gebruiken naarmate de hoeveelheid gegevens die u moet uitwisselen tussen regio's toeneemt.