Connectiviteit van gegevenslandingszone met één regio

De landingszone voor gegevensbeheer, de gegevenslandingszones en alle services in deze zones worden ingesteld in dezelfde regio in een installatie met één regio. Alle landingszones bevinden zich binnen hetzelfde connectiviteitshubabonnement. Dit abonnement host gedeelde netwerkresources, waaronder een virtueel netwerkapparaat (zoals Azure Firewall), een ExpressRoute-gateway, een VPN-gateway (virtueel particulier netwerk), een virtueel hubnetwerk of een virtuele WAN (vWAN-hub).

Afbeelding 1: Single Region Verbinding maken ivity.

Op basis van de huidige mogelijkheden van Azure Networking Services raden we u aan een netwerkarchitectuur met mesh te gebruiken. U moet Vnet-peering instellen tussen:

• De Verbinding maken iviteitshub en Gegevensbeheer zone
• De Verbinding maken ivity-hub en elke gegevenslandingszone
• De Gegevensbeheer zone en elke gegevenslandingszone
• Elke gegevenslandingszone

In dit artikel worden de voor- en nadelen van elke optie voor netwerkarchitectuur beschreven die we hebben overwogen voor analyses op cloudschaal.

De eerste sectie van dit artikel is gericht op een patroon met één regio, waarbij de Gegevensbeheer Zone en alle Data Landing Zones worden gehost in dezelfde regio.

Elk ontwerppatroon wordt geëvalueerd aan de hand van de volgende criteria:

• Kosten
• Gebruikerstoegangsbeheer
• Servicebeheer
• Bandbreedte
• Latentie

We analyseren elke ontwerpoptie met de volgende use-case voor landingszones voor meerdere gegevens:

Notitie

Virtuele machine B (VM B) die wordt gehost in gegevenslandingszone B laadt een gegevensset uit opslagaccount A die wordt gehost in gegevenslandingszone A. Vervolgens verwerkt VM B die gegevensset en slaat deze op in opslagaccount B, die wordt gehost in gegevenslandingszone B.

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.

Meshed-netwerkarchitectuur (aanbevolen)

U wordt aangeraden een netwerk-mesh-architectuur te gebruiken bij het gebruik van analyses op cloudschaal. Naast het bestaande hub- en spoke-netwerkontwerp dat in uw tenant is ingesteld, moet u twee dingen doen om een netwerknetarchitectuur te implementeren:

• Vnet-peerings toevoegen tussen alle Vnet-landingszone Vnets.
• Vnetkoppelingen toevoegen tussen uw landingszone voor gegevensbeheer en alle gegevenslandingszones.

In ons voorbeeldscenario worden gegevens die vanuit opslagaccount A zijn geladen, een Vnet-peeringverbinding (2) verzonden die is ingesteld tussen de twee Vnet-landingszone Vnets. Het wordt geladen en verwerkt door VM B ((3) en (4) en wordt vervolgens verzonden via het lokale privé-eindpunt (5) dat moet worden opgeslagen in opslagaccount B.

In dit scenario worden de gegevens niet doorgegeven aan de Verbinding maken ivity Hub. Het blijft binnen het dataplatform dat bestaat uit een landingszone voor gegevensbeheer en een of meer datalandingszones.

Afbeelding 2: Meshed Network-architectuur.

Beheer van gebruikerstoegang in meshed-netwerkarchitectuur

In een ontwerp van een meshed-netwerkarchitectuur hebben gegevenstoepassingsteams slechts twee dingen nodig om nieuwe services te kunnen maken (inclusief privé-eindpunten):

• Schrijftoegang tot de toegewezen resourcegroep in de landingszone voor gegevens
• Toegang tot hun aangewezen subnet toevoegen

In dit ontwerp kunnen teams van gegevenstoepassingen privé-eindpunten zelf implementeren. Zolang ze over de benodigde toegangsrechten beschikken om privé-eindpunten te verbinden met een subnet in een bepaalde spoke, hebben uw teams geen ondersteuning nodig bij het instellen van de benodigde connectiviteit.

Samenvatting:

Servicebeheer in meshed-netwerkarchitectuur

In een ontwerp van een meshed-netwerkarchitectuur fungeert geen virtueel netwerkapparaat als een single point of failure of throttling. Het ontbreken van gegevenssets die worden verzonden via de Verbinding maken ivity Hub vermindert de overhead van uw centrale Azure-platformteam, mits u dat virtuele apparaat niet hoeft uit te schalen.

Dit impliceert dat het centrale Azure-platformteam niet langer al het verkeer kan inspecteren en registreren dat wordt verzonden tussen gegevenslandingszones. Analyses op cloudschaal zijn echter een coherent platform dat meerdere abonnementen beslaat, waardoor schaalaanpassing mogelijk is en beperkingen op platformniveau kan worden opgelost, dus dat is geen nadeel.

Als alle resources binnen één abonnement worden gehost, inspecteert uw centrale Azure-platformteam ook niet meer alle gegevens in de centrale Verbinding maken ivity Hub. U kunt nog steeds 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.

Met dit ontwerp kunt u ook een systeemeigen Azure DNS-oplossing maken op basis van Privé-DNS Zones. U kunt de levenscyclus van DNS A-records automatiseren via Azure Policy-definities voor privé-DNS-groepen.

Samenvatting:

Kosten voor meshed-netwerkarchitectuur

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, niet voor de VNet-peering. U kunt de officiële verklaring lezen in veelgestelde vragen: Hoe werkt facturering wanneer u toegang krijgt tot een privé-eindpunt vanuit een gekoppeld netwerk?.

In dit netwerkontwerp betaalt u alleen voor:

• Uw privé-eindpunten (per uur)
• Het inkomend en uitgaand verkeer dat wordt verzonden via uw privé-eindpunten om uw onbewerkte gegevensset (1) te laden en uw verwerkte gegevensset op te slaan (6)

Er worden geen kosten in rekening gebracht voor Vnet-peering (2). Daarom heeft deze optie minimale kosten.

Samenvatting:

Bandbreedte en latentie in een netwerkarchitectuur met meshed

Dit ontwerp heeft geen bekende bandbreedte- of latentiebeperkingen, omdat de doorvoer van virtuele netwerkapparaten voor de gegevensuitwisseling in de landingszone voor meerdere gegevens niet wordt beperkt. De enige beperkende factor van het ontwerp is de fysieke limiet van onze datacenters (snelheid van glasvezelkabels).

Samenvatting:

Overzicht van meshed-netwerkarchitectuur

Als u van plan bent om cloudanalyses te gebruiken, raden we u aan het meshed-netwerkontwerp te gebruiken. Een meshed-netwerk biedt maximale bandbreedte en lage latentie tegen minimale kosten, maar maakt geen compromissen met betrekking tot het beheer van gebruikerstoegang of op de DNS-laag.

Als u ander netwerkbeleid binnen het gegevensplatform wilt afdwingen, gebruikt u netwerkbeveiligingsgroepen in plaats van virtuele netwerkapparaten.

Traditionele hub- en spoke-architectuur (niet aanbevolen)

Ontwerp van hub- en spoke-netwerkarchitectuur is de meest voor de hand liggende optie en één die veel ondernemingen hebben aangenomen. Hierin wordt netwerkdoorvoer ingesteld in de Verbinding maken ivity Hub voor toegang tot gegevens in opslagaccount A van VM B. Gegevens doorkruisen twee Vnet-peerings ((2) en (5)) en een virtueel netwerkapparaat dat wordt gehost in de Verbinding maken ivity Hub ((3) en (4)). Vervolgens worden de gegevens geladen door de virtuele machine (6) en weer opgeslagen in het opslagaccount B (8).

Afbeelding 3: Hub- en spoke-architectuur.

Beheer van gebruikerstoegang in traditionele hub- en spoke-architectuur

In een traditioneel hub- en spoke-ontwerp hebben gegevenstoepassingsteams slechts twee dingen nodig om nieuwe services te kunnen maken (inclusief privé-eindpunten):

• Schrijftoegang tot de resourcegroep in de gegevenslandingszone
• Toegang tot hun aangewezen subnet toevoegen

In dit ontwerp kunnen teams van gegevenstoepassingen privé-eindpunten zelf implementeren. Zolang ze over de benodigde toegangsrechten beschikken om privé-eindpunten te verbinden met een subnet in een bepaalde spoke, hebben uw teams geen ondersteuning nodig bij het instellen van de benodigde connectiviteit.

Samenvatting:

ServiceBeheer in traditionele hub- en spoke-architectuur

Dit netwerkontwerp is bekend en consistent met de bestaande netwerkinstallatie van de meeste organisaties. Hierdoor is het ontwerp eenvoudig uit te leggen en te implementeren. U kunt ook een gecentraliseerde Azure-systeemeigen DNS-oplossing gebruiken met Privé-DNS Zones om FQDN-omzetting in uw Azure-tenant te bieden. Met Privé-DNS Zones kunt u de levenscyclus van DNS A-records automatiseren via Azure-beleid.

Een ander voordeel van dit ontwerp is dat verkeer wordt gerouteerd via een centraal netwerk virtueel apparaat, zodat netwerkverkeer dat van de ene spoke naar de andere wordt verzonden, kan worden geregistreerd en geïnspecteerd.

Een nadeel van dit ontwerp is dat uw centrale Azure Platform-team routetabellen handmatig moet beheren. Dit is nodig om transitiviteit tussen spokes te garanderen, waardoor gegevensassets kunnen worden gedeeld in meerdere landingszones voor gegevens. Routebeheer kan na verloop van tijd complex en foutgevoelig worden en moet vooraf worden overwogen.

Een ander nadeel van deze netwerkinstallatie is de manier waarop het virtuele netwerkapparaat wordt ingesteld. Het virtuele netwerkapparaat fungeert als een single point of failure en kan ernstige downtime in het gegevensplatform veroorzaken als er een fout optreedt. Naarmate de grootte van gegevenssets binnen een gegevensplatform toeneemt en het aantal gebruiksvoorbeelden voor landingszones voor meerdere gegevens toeneemt, wordt er meer verkeer verzonden via het virtuele netwerkapparaat van het centrale netwerk.

Na verloop van tijd kan dit leiden tot gigabytes of zelfs terabytes aan gegevens die via het centrale exemplaar worden verzonden. Omdat de bandbreedte van bestaande virtuele netwerkapparaten vaak beperkt is tot slechts een of tweecijferige gigabytedoorvoer, kan het virtuele netwerkapparaat een knelpunt worden dat de verkeersstroom tussen gegevenslandingszones kritiek beperkt en de shareabiliteit van gegevensassets beperkt.

De enige manier om dit probleem te voorkomen, is door het uitschalen van het virtuele netwerkapparaat op meerdere exemplaren, wat grote gevolgen heeft voor dit ontwerp.

Samenvatting:

Kosten van traditionele hub- en spoke-architectuur

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 wanneer u toegang krijgt tot een privé-eindpunt vanuit een gekoppeld netwerk?.

Voor dit netwerk worden er per uur kosten in rekening gebracht voor de privé-eindpunten van uw opslagaccounts. Er worden ook kosten in rekening gebracht voor inkomend en uitgaand verkeer dat via de privé-eindpunten wordt verzonden om een onbewerkte gegevensset (1) te laden en de verwerkte gegevensset (8) op te slaan.

Uw klant wordt in rekening gebracht voor het inkomend en uitgaand verkeer van één Vnet-peering (5). Zoals eerder vermeld, worden er geen kosten in rekening gebracht voor de eerste Vnet-peering (2).

U krijgt uiteindelijk een hoge kosten voor een virtueel netwerkapparaat als u dit netwerkontwerp ((3) en (4)) gebruikt. U moet extra licenties aanschaffen en het virtuele netwerkapparaat op basis van aanvraag schalen of de kosten betalen die per gigabyte worden verwerkt, zoals dit met Azure Firewall wordt gedaan.

Samenvatting:

Bandbreedte en latentie in traditionele hub- en spoke-architectuur

Dit netwerkontwerp heeft ernstige bandbreedtebeperkingen. Het centrale virtuele netwerkapparaat wordt een kritiek knelpunt naarmate uw platform groeit, waardoor gebruiksscenario's voor meerdere gegevenslandingszones en het delen van gegevenssets worden beperkt. Het maakt waarschijnlijk ook meerdere kopieën van gegevenssets in de loop van de tijd.

Dit ontwerp is ook sterk van invloed op latentie, wat vooral essentieel wordt in realtime analysescenario's.

Samenvatting:

Overzicht van traditionele hub- en spoke-architectuur

Dit hub- en spoke-netwerkontwerp heeft toegangsbeheer en enkele voordelen van servicebeheer, maar vanwege kritieke beperkingen van servicebeheer en bandbreedte en latentie, kunnen we dit netwerkontwerp niet aanbevelen voor gebruiksscenario's voor landingszones voor meerdere gegevens.

Projectiearchitectuur voor privé-eindpunten (niet aanbevolen)

Een andere ontwerpoptie is de projectie van privé-eindpunten in elk en elke landingszone. In dit ontwerp wordt een privé-eindpunt voor opslagaccount A gemaakt in elke landingszone. Dit leidt tot een eerste privé-eindpunt in gegevenslandingszone A die is verbonden met het Vnet in gegevenslandingszone A, een tweede privé-eindpunt dat is verbonden met het Vnet in gegevenslandingszone B, enzovoort.

Hetzelfde geldt voor opslagaccount B en mogelijk voor andere services binnen de datalandingszones. Als we het aantal gegevenslandingszones definiëren als n, eindigen we met n privé-eindpunten voor ten minste alle opslagaccounts en mogelijk andere services binnen de datalandingszones. Dit leidt tot een exponentiële toename van het aantal privé-eindpunten.

Afbeelding 4: Projectiearchitectuur voor privé-eindpunten.

Omdat alle privé-eindpunten van een bepaalde service (bijvoorbeeld opslagaccount A) dezelfde FQDN hebben (zoalsstorageaccounta.privatelink.blob.core.windows.net), zorgt deze oplossing voor uitdagingen in de DNS-laag die niet kan worden opgelost met behulp van Privé-DNS Zones. U hebt in plaats daarvan een aangepaste DNS-oplossing nodig die DNS-namen kan omzetten op basis van de oorsprong/het IP-adres van de aanvrager. Hiermee kunt u VMA verbinding maken met de privé-eindpunten die zijn verbonden met het Vnet in gegevenslandingszone A en vm B verbinding maken met de privé-eindpunten die zijn verbonden met het Vnet in gegevenslandingszone B. U kunt dit doen met een installatie op basis van Windows Server, terwijl u de levenscyclus van DNS A-records kunt automatiseren via een combinatie van activiteitenlogboek en Azure Functions.

In deze installatie kunt u de onbewerkte gegevensset in opslagaccount A in VM B laden door toegang te krijgen tot de gegevensset via het lokale privé-eindpunt (1). Nadat u de gegevensset ((2) en (3) hebt geladen en verwerkt, kunt u deze opslaan in opslagaccount B door rechtstreeks toegang te krijgen tot het lokale privé-eindpunt (4). In dit scenario mogen gegevens geen Vnet-peerings doorlopen.

Beheer van gebruikerstoegang in projectiearchitectuur voor privé-eindpunten

De benadering van dit ontwerp voor gebruikerstoegangsbeheer is vergelijkbaar met die van de meshed-netwerkarchitectuur. In dit ontwerp kunt u echter toegangsrechten vereisen voor andere gegevenslandingszones om privé-eindpunten te maken, niet alleen binnen een aangewezen landingszone en Vnet, maar ook in andere gegevenslandingszones en hun respectieve Vnets.

Daarom vereisen uw datatoepassingsteams drie dingen, niet twee, om zelf nieuwe services te kunnen maken:

• Schrijftoegang tot een resourcegroep in een aangewezen gegevenslandingszone
• Toegang tot hun aangewezen subnet toevoegen
• Toegang tot een resourcegroep en subnet binnen alle andere gegevenslandingszones om hun respectieve lokale privé-eindpunten te maken

Dit netwerkontwerp verhoogt de complexiteit in uw toegangsbeheerlaag, omdat uw datatoepassingsteams machtigingen vereisen in elke afzonderlijke gegevenslandingszone. Het ontwerp kan ook verwarrend zijn en leiden tot inconsistente RBAC in de loop van de tijd.

Als teams voor gegevenslandingszones en datatoepassingsteams geen benodigde toegangsrechten krijgen, treden er problemen op die worden beschreven in de traditionele hub- en spoke-architectuur (niet aanbevolen).

Samenvatting:

Servicebeheer in projectiearchitectuur voor privé-eindpunten

Hoewel dit netwerkontwerp vergelijkbaar is met het ontwerp van de meshed-netwerkarchitectuur, heeft dit netwerkontwerp het voordeel dat er geen virtueel netwerkapparaat fungeert als één storingspunt of bandbreedtebeperking. Het vermindert ook de beheeroverhead voor uw centrale Azure-platformteam door geen gegevenssets te verzenden via de Verbinding maken ivity Hub, omdat het virtuele apparaat niet hoeft te worden uitgeschaald. Dit impliceert dat het centrale Azure-platformteam niet langer al het verkeer kan inspecteren en registreren dat wordt verzonden tussen gegevenslandingszones. Analyses op cloudschaal zijn echter een coherent platform dat meerdere abonnementen beslaat, waardoor schaalaanpassing mogelijk is en beperkingen op platformniveau kan worden opgelost, dus dat is geen nadeel.

Wanneer alle resources binnen één abonnement worden gehost, wordt verkeer niet geïnspecteerd in de centrale Verbinding maken ivity Hub. U kunt nog steeds netwerklogboeken vastleggen met behulp van stroomlogboeken voor netwerkbeveiligingsgroepen en u kunt andere toepassings- en serviceniveaulogboeken samenvoegen en opslaan met behulp van servicespecifieke diagnostische Instellingen. U kunt al deze logboeken op schaal vastleggen met behulp van Azure-beleid. Aan de andere kant neemt de netwerkadresruimte die nodig is voor uw gegevensplatform toe vanwege de exponentiële toename van de vereiste privé-eindpunten, wat niet optimaal is.

De belangrijkste zorgen met betrekking tot deze netwerkarchitectuur zijn de eerder genoemde DNS-uitdagingen. U kunt geen systeemeigen Azure-oplossing gebruiken in de vorm van Privé-DNS Zones. Voor deze architectuur is dus een oplossing van derden vereist waarmee FQDN's kunnen worden omgezet op basis van het oorspronkelijke/IP-adres van de aanvrager. U moet ook hulpprogramma's en werkstromen ontwikkelen en onderhouden om Privé-DNS A-records te automatiseren, waardoor de beheeroverhead aanzienlijk toeneemt ten opzichte van de voorgestelde Azure Policy-oplossing.

U kunt een gedistribueerde DNS-infrastructuur maken met behulp van Privé-DNS zones, maar hiermee worden DNS-eilanden gemaakt, wat uiteindelijk problemen veroorzaakt wanneer u toegang probeert te krijgen tot private link-services die worden gehost in andere landingszones binnen uw tenant. Daarom is dit ontwerp geen haalbare optie.

Samenvatting:

Kosten voor projectiearchitectuur voor privé-eindpunten

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 veelgestelde vragen: Hoe werkt facturering wanneer u toegang krijgt tot een privé-eindpunt vanuit een gekoppeld netwerk?.

In dit netwerkontwerp worden alleen kosten in rekening gebracht voor de privé-eindpunten (per uur) en het inkomend en uitgaand verkeer dat via deze privé-eindpunten wordt verzonden om onbewerkte gegevenssets (1) te laden en verwerkte gegevenssets (4) op te slaan. Er moeten echter extra kosten worden verwacht vanwege de exponentiële toename van het aantal privé-eindpunten van uw gegevensplatform. Omdat er per uur kosten in rekening worden gebracht, is het bedrag van extra kosten sterk afhankelijk van het aantal privé-eindpunten dat wordt gemaakt.

Samenvatting:

Bandbreedte en latentie in projectiearchitectuur voor privé-eindpunten

Dit ontwerp heeft geen bekende bandbreedte- en latentiebeperkingen omdat er geen virtuele netwerkapparaten zijn die de doorvoer beperken voor gegevensuitwisseling tussen datalandingszones. De enige beperkende factor van het ontwerp is de fysieke limiet van onze datacenters (snelheid van glasvezelkabels).

Samenvatting:

Samenvatting van projectiearchitectuur voor privé-eindpunten

De exponentiële groei van privé-eindpunten in deze netwerkarchitectuur kan ertoe leiden dat u bijhoudt welke privé-eindpunten worden gebruikt voor welk doel op welke locatie. U bent ook beperkt door problemen met toegangsbeheer en complexiteit van DNS-lagen. Vanwege deze problemen kunnen we dit netwerkontwerp niet aanbevelen voor gebruiksscenario's voor landingszones voor meerdere gegevens.

Privé-eindpunten in Verbinding maken ivity Hub-architectuur (niet aanbevolen)

Een andere netwerkoptie is het hosten van privé-eindpunten in uw Verbinding maken ivity Hub en deze verbinden met het Hub-Vnet. In deze oplossing host u één privé-eindpunt voor elke service in uw bedrijfs-Vnet. Vanwege de bestaande hub- en spoke-netwerkarchitectuur bij de meeste bedrijven en het feit dat uw Verbinding maken iviteitshub als host fungeert voor uw privé-eindpunten in deze oplossing, is transitiviteit niet vereist. Vnet-peering tussen uw Verbinding maken ivity Hub en data landingszones biedt directe toegang.

Gegevens passeren één Vnet-peering tussen de Verbinding maken ivity Hub en de landingszone voor gegevens om een gegevensset te laden die is opgeslagen in opslagaccount A in VM B. Zodra die gegevensset is geladen en verwerkt ((3) en (4)), wordt dezelfde Vnet-peering een tweede keer (5) doorlopen voordat deze definitief wordt opgeslagen in opslagaccount B via het privé-eindpunt dat is verbonden met het hub-Vnet (6).

Afbeelding 5: Privé-eindpunten in Verbinding maken ivity Hub-architectuur.

Beheer van gebruikerstoegang in Verbinding maken ivity Hub-architectuur

In dit netwerkontwerp hebben uw teams voor gegevenslandingszones en datatoepassingsteams twee dingen nodig om privé-eindpunten te kunnen verbinden met het Hub-Vnet:

• Schrijfmachtigingen voor een resourcegroep in uw Verbinding maken ivity Hub-abonnement
• Joinmachtigingen voor het hub-Vnet

Uw Verbinding maken iviteitshub is aangewezen voor het Azure-platformteam van uw organisatie en is toegewezen voor het hosten van de benodigde en gedeelde netwerkinfrastructuur van uw organisatie (inclusief firewalls, gateways en hulpprogramma's voor netwerkbeheer). Deze netwerkoptie maakt dat ontwerp inconsistent, omdat het geen toegangsbeheerprincipes van de basisprincipes voor enterprise-scale landingszones volgt. Daarom zullen de meeste Azure-platformteams deze ontwerpoptie niet goedkeuren.

Samenvatting:

Servicebeheer in Verbinding maken ivity Hub-architectuur

Hoewel dit ontwerp vergelijkbaar is met het ontwerp van de meshed-netwerkarchitectuur, heeft dit ontwerp geen virtueel netwerkapparaat dat fungeert als een single point of failure of throttling doorvoer. Het vermindert ook de beheeroverhead voor uw centrale Azure-platformteam door geen gegevenssets te verzenden via de Verbinding maken ivity Hub, omdat het virtuele apparaat niet hoeft te worden uitgeschaald. Dit impliceert dat het centrale Azure-platformteam niet langer al het verkeer kan inspecteren en registreren dat wordt verzonden tussen gegevenslandingszones. Analyses op cloudschaal zijn echter een coherent platform dat meerdere abonnementen beslaat, waardoor schaalaanpassing mogelijk is en beperkingen op platformniveau kan worden opgelost, dus dat is geen nadeel.

Wanneer alle resources binnen één abonnement worden gehost, wordt verkeer niet geïnspecteerd in de centrale Verbinding maken ivity Hub. U kunt nog steeds netwerklogboeken vastleggen met behulp van stroomlogboeken voor netwerkbeveiligingsgroepen en u kunt andere toepassings- en serviceniveaulogboeken samenvoegen en opslaan met behulp van servicespecifieke diagnostische Instellingen. U kunt al deze logboeken op schaal vastleggen met behulp van Azure-beleid.

Met dit ontwerp kunt u ook een systeemeigen Azure DNS-oplossing maken op basis van Privé-DNS Zones en kunt u de levenscyclus van DNS A-records automatiseren via Azure-beleid.

Samenvatting:

kosten voor Verbinding maken iviteitshubarchitectuur

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 wanneer u toegang krijgt tot een privé-eindpunt vanuit een gekoppeld netwerk?.

In dit netwerkontwerp worden alleen kosten in rekening gebracht voor uw privé-eindpunten (per uur) en inkomend en uitgaand verkeer dat via deze privé-eindpunten wordt verzonden om een onbewerkte gegevensset (1) te laden en de verwerkte gegevensset (6) op te slaan.

Samenvatting:

Bandbreedte en latentie in Verbinding maken iviteitshubarchitectuur

Dit ontwerp heeft geen bekende bandbreedte- en latentiebeperkingen omdat er geen virtuele netwerkapparaten zijn die de doorvoer beperken voor gegevensuitwisseling tussen datalandingszones. De enige beperkende factor van het ontwerp is de fysieke limiet van onze datacenters (snelheid van glasvezelkabels).

Samenvatting:

Overzicht van privé-eindpunten in Verbinding maken iviteitshubarchitectuur

Hoewel dit ontwerp van de netwerkarchitectuur meerdere voordelen heeft, maken de eerder genoemde inconsistenties voor toegangsbeheer het subparerend. Daarom kunnen we deze ontwerpbenadering niet aanbevelen.

Connectiviteitsconclusiviteit van gegevenslandingszone met één regio

Uit alle herziene netwerkarchitectuuropties en hun voor- en nadelen is meshed netwerkarchitectuur de duidelijke winnaar. Het heeft enorme voordelen voor doorvoer en kosten en beheer. Daarom raden we u aan deze te gebruiken bij het implementeren van analyses op cloudschaal. Virtuele peering spoke-netwerken zijn nog niet eerder gebruikelijk geweest en dit heeft geleid tot problemen met het delen van gegevenssets tussen domeinen en bedrijfseenheden.

U kunt analyses op cloudschaal weergeven als een coherente oplossing die meerdere abonnementen omvat. In één abonnement is de netwerkverkeersstroom gelijk aan de stroom in de meshed-netwerkarchitectuur. Binnen één abonnement instellen hebben gebruikers waarschijnlijk de limieten en quota op abonnementsniveau van het platform bereikt. Deze analyse op cloudschaal is erop gericht om te vermijden.

Volgende stappen

• Verbinding maken iviteit van landingszone voor gegevens in meerdere regio's