Freigeben über

Datenzielzonenkonnektivität in einer Region

  • Artikel

Die Datenverwaltungszielzone, die Datenzielzonen und alle darin enthaltenen Dienste werden in derselben Region in einer Einzelregion eingerichtet. Alle Zielzonen befinden sich innerhalb des gleichen Konnektivitätshubabonnements. Dieses Abonnement hostet freigegebene Netzwerkressourcen, die eine virtuelle Netzwerkanwendung (z. B. Azure-Firewall), ein ExpressRoute-Gateway, ein VPN-Gateway (Virtual Private Network), ein virtuelles Hubnetzwerk oder ein virtuelles WAN (vWAN Hub) enthalten können.

Einzelregionsübergreifende Verbindungen

Abbildung 1: Konnektivität zwischen einzelnen Regionen.

Basierend auf den aktuellen Funktionen von Azure-Network Services empfehlen wir, eine Gittermodell-Netzwerkarchitektur zu verwenden. Diese umfasst die Einrichtung von VNet-Peerings zwischen:

  • Konnektivitätshub und Datenverwaltungszone
  • Konnektivitätshub und jede einzelne Datenzielzone
  • Datenverwaltungszone und jede einzelne Datenzielzonen
  • Jede Datenzielzone

In diesem Artikel werden die Vor- und Nachteile jeder Netzwerkarchitekturoption beschrieben, die wir für Analysen auf Cloudebene betrachtet haben.

Der erste Abschnitt dieses Artikels konzentriert sich auf ein Einzelbereichsmuster, in dem die Datenverwaltungszone und alle Datenzielzonen in derselben Region gehostet werden.

Jedes Entwurfsmuster wird mithilfe der folgenden Kriterien ausgewertet:

  • Kosten
  • Verwaltung des Benutzerzugriffs
  • Dienstverwaltung
  • Bandbreite
  • Latency

Wir werden jede Designoption im Hinblick auf den folgenden datenübergreifenden Zielzonen-Anwendungsfall analysieren:

Hinweis

Der virtuelle Computer B (VM B), der in Datenzielzone B gehostet wird, lädt ein Dataset aus dem Speicherkonto A, das in der Datenzielzone A gehostet wird. Anschließend verarbeitet VM B dieses Dataset und speichert es im Speicherkonto B, das in der Datenzielzone B gehostet wird.

Wichtig

In diesem Artikel und anderen Artikeln im Abschnitt „Netzwerk“ werden geschäftsbereichsübergreifende Einheiten beschrieben, die Daten gemeinsam nutzen. Dies ist jedoch möglicherweise nicht Ihre anfängliche Strategie und sie müssen zuerst auf Basisebene beginnen.

Entwerfen Sie Ihr Netzwerk so, dass Sie schließlich unser empfohlenes Setup zwischen Datenzielzonen implementieren können. Stellen Sie sicher, dass die Datenverwaltungszielzonen direkt mit den Zielzonen für die Governance verbunden sind.

Es wird empfohlen, bei der Einführung von Analysen auf Cloudebene eine Netzwerkgitterarchitektur zu verwenden. Zusätzlich zu dem bestehenden Hub-and-Spoke-Netzwerkdesign, das in Ihrem Mandanten eingerichtet ist, müssen Sie zwei Dinge tun, um eine Netzwerk-Gittermodell-Architektur zu implementieren:

  • Fügen Sie Vnet-Peerings zwischen allen Datenzielzonen-Vnets hinzu.
  • Fügen Sie Vnet-Kopplungen zwischen Ihrer Datenverwaltungszielzone und allen Datenzielzonen hinzu.

In unserem Beispielszenario durchlaufen die von Speicherkonto A geladenen Daten eine Vnet-Peering-Verbindung (2), die zwischen den beiden Vnets der Datenzielzone eingerichtet wurde. Sie werden von VM B ((3) und (4)) geladen und verarbeitet, dann über den lokalen privaten Endpunkt (5) gesendet, um in Speicherkonto B gespeichert zu werden.

In diesem Szenario durchlaufen die Daten den Connectivity Hub nicht. Sie verbleibt in der Datenplattform, die aus einer Datenverwaltungszielzone und einer oder mehreren Datenzielzonen besteht.

Vermaschte Netzwerkarchitektur

Abbildung 2: Vermaschte Netzwerkarchitektur.

Benutzerzugriffsverwaltung in vermaschter Netzwerkarchitektur

In einem vermaschten Netzwerkarchitekturdesign erfordern Datenanwendungsteams nur zwei Dinge, um neue Dienste (einschließlich privater Endpunkte) zu erstellen:

  • Schreiben des Zugriffs auf ihre dedizierte Ressourcengruppe in der Datenzielzone
  • Verknüpfen des Zugriffs auf ihr angegebenes Subnetz

In diesem Entwurf können Datenanwendungsteams private Endpunkte selbst bereitstellen. Solange sie über die erforderlichen Zugriffsberechtigungen verfügen, um private Endpunkte mit einem Subnetz in einem bestimmten Spoke zu verbinden, benötigen Ihre Teams keine Unterstützung, wenn Sie die erforderliche Konnektivität einrichten.

Zusammenfassung:

Dienstverwaltung in vermaschter Netzwerkarchitektur

In einem vermaschten Netzwerkarchitekturdesign fungiert keine virtuelle Netzwerkanwendung als einzelner Fehlerpunkt oder Drosselungspunkt. Das Fehlen von Datasets, die über den Connectivity Hub gesendet werden, reduziert den Aufwand Ihres zentralen Azure-Plattformteams, sofern Sie dieses virtuelle Gerät nicht skalieren müssen.

Dies hat die Folge, dass das zentrale Azure-Plattformteam nicht mehr den Datenverkehr zwischen den Datenzielzonen überprüfen und protokollieren kann, der zwischen Datenzielzonen gesendet wird. Analysen auf Cloudebene sind jedoch eine kohärente Plattform, die mehrere Abonnements umfasst, die Skalieren ermöglicht und Beschränkungen auf Plattformebene überwindet, sodass dies kein Nachteil ist.

Mit allen Ressourcen, die in einem einzigen Abonnement gehostet werden, überprüft Ihr zentrales Azure-Plattformteam nicht mehr alle Daten im zentralen Connectivity Hub. Sie können weiterhin Netzwerkprotokolle mithilfe der Datenflussprotokoll der Netzwerksicherheitsgruppe erfassen. Mithilfe von dienstspezifischen Diagnose-Einstellungen können Sie andere Anwendungs- und Dienstebenenprotokolle konsolidieren und speichern.

Sie können alle diese Protokolle im Maßstab erfassen, indem Sie Azure Policy-Definitionen für Diagnoseeinstellungen verwenden.

Mit diesem Design können Sie auch eine Azure-native DNS-Lösung basierend auf Zonen für Privates DNS erstellen. Sie können den DNS-A-Datensatzlebenszyklus über Azure Policy-Definitionen für private DNS-Gruppen automatisieren.

Zusammenfassung:

Vermaschte Netzwerkarchitektur: Kosten

Hinweis

Beim Zugriff auf einen privaten Endpunkt über ein Peer-Netzwerk ist für Kunden immer der private Endpunkt selbst und nicht das VNet-Peering kostenpflichtig. Die offizielle Anweisung finden Sie unter Häufig gestellte Fragen: Welche Gebühren fallen beim Zugriff auf einen privaten Endpunkt von einem Peer-Netzwerk aus an?.

In diesem Netzwerkdesign bezahlen Sie nur für:

  • Ihre privaten Endpunkte (pro Stunde)
  • Den eingehenden und ausgehenden Datenverkehr, der über Ihre privaten Endpunkte gesendet wird, um Ihr rohes Dataset (1) zu laden und Ihr verarbeitetes Dataset (6) zu speichern

Vnet-Peering wird nicht berechnet (2), weshalb diese Option minimale Kosten hat.

Zusammenfassung:

Bandbreite und Latenz in einer vermaschten Netzwerkarchitektur

Dieses Design verfügt über keine bekannten Bandbreiten- oder Latenzbeschränkungen, da keine virtuellen Netzwerkgeräte den Durchsatz für datenübergreifenden Zielzonen-Datenaustausch beschränken. Der einzige Begrenzungsfaktor des Designs ist der physische Grenzwert unserer Rechenzentren (Geschwindigkeit von Glasfaserkabeln).

Zusammenfassung:

Vermaschte Netzwerkarchitektur: Zusammenfassung

Wenn Sie die Analysen auf Cloudebene einführen möchten, empfehlen wir, das vermaschte Netzwerkdesign zu verwenden. Ein vermaschtes Netzwerk bietet maximale Bandbreite und geringe Latenz bei minimalen Kosten, macht jedoch keine Kompromisse hinsichtlich der Benutzerzugriffsverwaltung oder auf der DNS-Ebene.

Wenn Sie andere Netzwerkrichtlinien innerhalb der Datenplattform erzwingen müssen, verwenden Sie Netzwerksicherheitsgruppen anstelle von zentralen virtuellen Netzwerkgeräten.

Das Design der Hub-and-Spoke-Netzwerkarchitektur ist die offensichtlichste Option, und eine, die viele Unternehmen angenommen haben. Darin wird die Netzwerktransitivität im Connectivity Hub eingerichtet, um auf Daten in Speicherkonto A von VM B zuzugreifen. Daten durchlaufen zwei Vnet-Peerings ((2) und (5)) und ein virtuelles Netzwerkgerät, das im Connectivity Hub ((3) und (4)) gehostet wird. Anschließend werden die Daten vom virtuellen Computer (6) geladen und wieder in das Speicherkonto B (8) gespeichert.

Hub-Spoke-Architektur

Abbildung 3: Hub-and-Spoke-Architektur.

Verwaltung des Benutzerzugriffs in herkömmlicher Hub-and-Spoke-Architektur

In einem herkömmlichen Hub-and-Spoke-Design erfordern Datenanwendungsteams nur zwei Dinge, um neue Dienste (einschließlich privater Endpunkte) zu erstellen:

  • Schreiben des Zugriffs auf ihre Ressourcengruppe in der Datenzielzone
  • Verknüpfen des Zugriffs auf ihr angegebenes Subnetz

In diesem Entwurf können Datenanwendungsteams private Endpunkte selbst bereitstellen. Solange sie über die erforderlichen Zugriffsberechtigungen verfügen, um private Endpunkte mit einem Subnetz in einem bestimmten Spoke zu verbinden, benötigen Ihre Teams keine Unterstützung, wenn Sie die erforderliche Konnektivität einrichten.

Zusammenfassung:

Dienstverwaltung in herkömmlicher Hub-and-Spoke-Architektur

Dieses Netzwerkdesign ist den meisten Unternehmen bekannt und steht mit ihrer bestehenden Netzwerkstruktur im Einklang. Dadurch ist es einfach, das Design zu erläutern und zu implementieren. Sie können auch eine zentralisierte Azure-native DNS-Lösung mit Zonen für Privates DNS verwenden, um die FQDN-Auflösung innerhalb Ihres Azure-Mandanten bereitzustellen. Mithilfe von Zonen für Privates DNS können Sie den DNS-A-Datensatzlebenszyklus über Azure-Richtlinien automatisieren.

Ein weiterer Vorteil dieses Konzepts ist, dass der Datenverkehr über ein zentrales virtuelles Netzwerkgerät geleitet wird, sodass der von einer Spoke zu einer anderen gesendete Netzwerkverkehr protokolliert und geprüft werden kann.

Ein Nachteil dieses Designs besteht darin, dass Ihr zentrales Azure Platform-Team die Routentabellen manuell verwalten muss. Dies ist erforderlich, um die Transitivität zwischen Spokes sicherzustellen, wodurch die Datenressourcenfreigabe über mehrere Datenzielzonen hinweg ermöglicht wird. Die Routenverwaltung kann im Laufe der Zeit komplex und fehleranfällig werden und muss im Voraus betrachtet werden.

Ein weiterer Nachteil für diese Netzwerkeinrichtung ist die Einrichtung ihres virtuellen zentralen Netzwerkgeräts. Das virtuelle Netzwerkgerät stellt einen Single Point of Failure dar, sodass es bei einem Ausfall zu gravierenden Ausfallzeiten der Datenplattform kommen kann. Außerdem wird mit zunehmender Größe des Datasets innerhalb einer Datenplattform und der Anzahl der datenübergreifenden Zielzonen-Anwendungsfälle mehr Datenverkehr über das zentrale virtuelle Netzwerkgerät gesendet.

Im Laufe der Zeit kann dies zu Daten im Gigabyte- oder sogar Terabytebereich führen, die über die zentrale Instanz gesendet werden. Da die Bandbreite der vorhandenen virtuellen Netzwerkgeräte häufig nur auf einen 1- oder zweistelligen Gigabyte-Durchsatz beschränkt ist, kann das zentrale virtuelle Netzwerkgerät zu einem Engpass werden, der den Datenverkehr zwischen Datenzielzonen und die Freigabe von Datenobjekten kritisch begrenzt.

Die einzige Möglichkeit, dieses Problem zu vermeiden, besteht darin, Ihr zentrales virtuelles Netzwerkgerät auf mehrere Instanzen zu skalieren, was erhebliche Auswirkungen auf die Kosten für dieses Design hat.

Zusammenfassung:

Kosten für herkömmliche Hub-and-Spoke-Architektur

Hinweis

Beim Zugriff auf einen privaten Endpunkt über ein Peer-Netzwerk ist für Kunden immer der private Endpunkt selbst und nicht das VNet-Peering kostenpflichtig. Die offizielle Anweisung finden Sie unter Häufig gestellte Fragen: Welche Gebühren fallen beim Zugriff auf einen privaten Endpunkt von einem Peer-Netzwerk aus an?.

Für dieses Netzwerk werden Sie pro Stunde für die privaten Endpunkte Ihrer Speicherkonten berechnet. Außerdem fallen Gebühren für den Eingangs- und Ausgangsdatenverkehr an, der über die privaten Endpunkte gesendet wird, um ein rohes Dataset (1) zu laden und das verarbeitete Dataset (8) zu speichern.

Ihrem Kunden wird der ein- und ausgehende Datenverkehr eines VNet-Peerings (5) in Rechnung gestellt. Wie zuvor erwähnt, wird das erste Vnet-Peering nicht berechnet (2).

Bei diesem Netzwerkdesign ((3) und (4)) entstehen hohe Kosten für das zentrale virtuelle Netzwerkgerät. Sie müssen entweder zusätzliche Lizenzen kaufen und das zentrale virtuelle Netzwerkgerät basierend auf bedarfsbezogener Anforderung skalieren oder die kostenbezogene Zahlung pro Gigabyte bezahlen, da sie mit Azure Firewall erledigt wird.

Zusammenfassung:

Bandbreite und Latenz in herkömmlicher Hub-and-Spoke-Architektur

Dieser Netzwerkentwurf weist aus Bandbreitensicht erhebliche Einschränkungen auf. Das zentrale virtuelle Netzwerkgerät wird zu einem kritischen Engpass, da Ihre Plattform wächst, was die Einsatzfälle und die Datasetfreigabe durch datenübergreifende Zielzonen beschränkt. Es erstellt wahrscheinlich mehrere Kopien von Datasets im Laufe der Zeit.

Dieses Design wirkt sich auch stark auf die Latenz aus, die in Echtzeitanalyseszenarien besonders kritisch wird.

Zusammenfassung:

Zusammenfassung zur herkömmlichen Hub-and-Spoke-Architektur

Dieses Hub-and-Spoke-Netzwerkdesign verfügt über Zugriffsverwaltungs- und einige Dienstverwaltungsvorteile, aber aufgrund kritischer Einschränkungen der Dienstverwaltung und Bandbreite und Latenz können wir dieses Netzwerkdesign für Anwendungsfälle für datenübergreifende Zielzonen nicht empfehlen.

Eine weitere Entwurfsoption ist die Projektion von privaten Endpunkten in alle Zielzonen. In diesem Entwurf wird ein privater Endpunkt für Speicherkonto A in jeder Zielzone erstellt. Daher führt diese Option zu einem ersten privaten Endpunkt in der Datenzielzone A, der mit dem VNet in der Datenzielzone A verbunden ist, einem zweiten privaten Endpunkt, der mit dem VNet in der Datenzielzone B verbunden ist, und so weiter.

Gleiches gilt für Speicherkonto B und u. U. für andere Dienste innerhalb der Datenzielzonen. Wenn wir die Anzahl der Datenzielzonen als n definieren, enden wir mit n privaten Endpunkten für mindestens alle Speicherkonten und potenziell andere Dienste innerhalb der Datenzielzonen. Dies führt zu einer exponentiellen Erhöhung der Anzahl privater Endpunkte.

Projektion privater Endpunkte

Abbildung 4: Architektur mit Projektion privater Endpunkte.

Da alle privaten Endpunkte eines bestimmten Diensts (z. B. Speicherkonto A) denselben FQDN (z. B. storageaccounta.privatelink.blob.core.windows.net) haben, führt diese Lösung zu Herausforderungen auf der DNS-Ebene, die nicht mit der Verwendung privater DNS-Zonen gelöst werden können. Stattdessen benötigen Sie eine benutzerdefinierte DNS-Lösung, die DNS-Namen basierend auf der Ursprungs-/IP-Adresse des Anforderers auflösen kann. Dadurch können Sie für die VM A eine Verbindung mit den privaten Endpunkten herstellen, die mit dem Vnet in der Datenzielzone A verbunden sind, und für die VM B eine Verbindung mit den privaten Endpunkten herstellen, die mit dem Vnet in der Datenzielzone B verbunden sind. Sie können dies mit einem Windows Server-basierten Setup erreichen, während Sie den Lebenszyklus von DNS-A-Datensätzen über eine Kombination aus Aktivitätsprotokoll und Azure Functions automatisieren können.

Bei dieser Einrichtung können Sie das rohe Dataset in Speicherkonto A in VM B laden, indem Sie über den lokalen privaten Endpunkt (1) auf das Dataset zugreifen. Nachdem Sie das Dataset ((2) und (3)) geladen und verarbeitet haben, können Sie es auf Speicherkonto B speichern, indem Sie direkt auf den lokalen privaten Endpunkt (4) zugreifen. In diesem Szenario dürfen keine Daten VNet-Peerings durchlaufen.

Benutzerzugriffsverwaltung in privater Endpunkt-Projektionsarchitektur

Der Ansatz dieses Designs für die Benutzerzugriffsverwaltung ähnelt der vermaschten Netzwerkarchitektur. In diesem Design können Sie jedoch Zugriffsrechte für andere Datenzielzonen benötigen, um private Endpunkte nicht nur innerhalb einer bestimmten Datenzielzone und Vnet, sondern auch in anderen Datenzielzonen und ihren jeweiligen Vnets zu erstellen.

Aus diesem Gründen benötigen Ihre Datenanwendungsteams drei Dinge, nicht zwei, um neue Dienste selbst zu erstellen:

  • Schreiben des Zugriffs auf eine Ressourcengruppe in einer bestimmten Datenzielzone
  • Verknüpfen des Zugriffs auf ihr angegebenes Subnetz
  • Zugreifen auf eine Ressourcengruppe und ein Subnetz innerhalb aller anderen Datenzielzonen, um ihre jeweiligen lokalen privaten Endpunkte zu erstellen

Dieses Netzwerkdesign erhöht die Komplexität in Ihrer Zugriffsverwaltungsebene, da Ihre Datenanwendungsteams Berechtigungen in jeder einzelnen Datenzielzone erfordern. Das Design kann auch verwirrend sein und im Laufe der Zeit zu uneinheitlicher RBAC führen.

Wenn Datenzielzonenteams und Datenanwendungsteams nicht über erforderliche Zugriffsrechte verfügen, treten Probleme auf, die unter Herkömmliche Hub-and-Spoke-Architektur (nicht empfohlen) beschrieben werden.

Zusammenfassung:

Dienstverwaltung in privater Endpunkt-Projektionsarchitektur

Das Design dieser Netzwerkarchitektur ähnelt dem Design der vermaschten Netzwerkarchitektur, aber dieses Netzwerkdesign hat den Vorteil, dass kein virtuelles Netzwerkgerät als einzelner Fehlerpunkt oder Drosselungspunkt fungiert. Außerdem wird der Verwaltungsaufwand für Ihr zentrales Azure-Plattformteam reduziert, indem Datasets nicht über den Konnektivitätshub gesendet werden, da es keine Notwendigkeit gibt, das virtuelle Gerät zu skalieren. Dies hat die Folge, dass das zentrale Azure-Plattformteam nicht mehr den Datenverkehr zwischen den Datenzielzonen überprüfen und protokollieren kann, der zwischen Datenzielzonen gesendet wird. Analysen auf Cloudebene sind jedoch eine kohärente Plattform, die mehrere Abonnements umfasst, die Skalieren ermöglicht und Beschränkungen auf Plattformebene überwindet, sodass dies kein Nachteil ist.

Bei allen Ressourcen, die in einem einzelnen Abonnement gehostet werden, wird der Datenverkehr nicht im zentralen Konnektivitätshub überprüft. Sie können weiterhin Netzwerkprotokolle mithilfe von Datenflussprotokollen der Netzwerksicherheitsgruppe erfassen und andere Anwendungs- und Dienstprotokolle mithilfe von dienstspezifischen Diagnoseeinstellungen konsolidieren und speichern. Sie können alle diese Protokolle in großem Stil mit Azure-Richtlinien erfassen. Andererseits erhöht sich der von Ihrer Datenplattform erforderliche Netzwerkadressraum aufgrund der exponentiellen Erhöhung der erforderlichen privaten Endpunkte, was nicht optimal ist.

Die wichtigsten Bedenken hinsichtlich dieser Netzwerkarchitektur sind ihre zuvor erwähnten DNS-Herausforderungen. Sie können keine Azure-native Lösung in Form von Zonen für Privates DNS verwenden, sodass diese Architektur eine Drittanbieterlösung erfordert, die FQDNS basierend auf der Ursprungs-/IP-Adresse des Anforderer auflösen kann. Sie müssen auch Tools und Workflows entwickeln und verwalten, um A-Datensätze für Privates DNS zu automatisieren, was den Verwaltungsaufwand im Vergleich zu der vorgeschlagenen Azure Policy-gesteuerten Lösung drastisch erhöht.

Sie können eine verteilte DNS-Infrastruktur mit Zonen für Privates DNS erstellen, aber dadurch werden DNS-Inseln erstellt, die letztlich Probleme verursachen, wenn Sie versuchen, auf private Verbindungsdienste zuzugreifen, die in anderen Zielzonen in Ihrem Mandanten gehostet werden. Daher ist dieses Design keine funktionsfähige Option.

Zusammenfassung:

Kosten der Architektur mit Projektion privater Endpunkte

Hinweis

Beim Zugriff auf einen privaten Endpunkt über ein Peer-Netzwerk ist für Kunden immer der private Endpunkt selbst und nicht das VNet-Peering kostenpflichtig. Die offizielle Anweisung finden Sie unter Häufig gestellte Fragen: Welche Gebühren fallen beim Zugriff auf einen privaten Endpunkt von einem Peer-Netzwerk aus an?.

In diesem Netzwerkdesign werden Ihnen nur die privaten Endpunkte (pro Stunde) und der Eingangs- und Ausgangsdatenverkehr berechnet, der über diese privaten Endpunkte gesendet wird, um rohe Datasets (1) zu laden und verarbeitete Datasets (4) zu speichern. Jedoch müssen aufgrund der exponentiellen Erhöhung der Anzahl der privaten Endpunkte Ihrer Datenplattform zusätzliche Kosten erwartet werden. Da Sie pro Stunde abgerechnet werden, hängt die Höhe der zusätzlichen Kosten stark davon ab, wie viele private Endpunkte erstellt werden.

Zusammenfassung:

Bandbreite und Latenz in privater Endpunkt-Projektionsarchitektur

Dieses Design verfügt über keine bekannten Bandbreiten- und Latenzbeschränkungen, da es keine virtuellen Netzwerkgeräte besitzt, die den Durchsatz für datenübergreifenden Zielzonen-Datenaustausch beschränken. Der einzige Begrenzungsfaktor des Designs ist der physische Grenzwert unserer Rechenzentren (Geschwindigkeit von Glasfaserkabeln).

Zusammenfassung:

Zusammenfassung der Architektur mit Projektion privater Endpunkte

Das exponentielle Wachstum privater Endpunkte in dieser Netzwerkarchitektur kann dazu führen, dass Sie den Überblick verlieren, welche privaten Endpunkte für welchen Zweck an welchem Standort verwendet werden. Sie sind auch durch Zugriffsverwaltungsprobleme und DNS-Ebenen-Komplexitäten eingeschränkt. Aufgrund dieser Probleme können wir dieses Netzwerkdesign für datenübergreifende Zielzonen-Anwendungsfälle nicht empfehlen.

Eine weitere Netzwerkoption besteht darin, private Endpunkte in Ihrem Konnektivitätshub zu hosten und sie mit dem Hub-Vnet zu verbinden. In dieser Lösung hosten Sie einen einzelnen privaten Endpunkt für jeden Dienst in Ihrem Unternehmens-Vnet. Aufgrund der vorhandenen Hub-and-Spoke-Architektur bei den meisten Unternehmen und der Tatsache, dass Ihr Konnektivitätshub Ihre privaten Endpunkte in dieser Lösung hostet, ist die Transitivität nicht erforderlich. Das VNet-Peering zwischen dem Konnektivitätshub und den Datenzielzonen ermöglicht einen direkten Zugriff.

Daten durchlaufen ein einzelnes Vnet-Peering zwischen dem Konnektivitätshub und der Datenzielzone, um ein Dataset zu laden, das in Speicherkonto A in VM B gespeichert ist. Sobald dieses Dataset geladen und verarbeitet wird ((3) und (4)), durchläuft er dasselbe Vnet-Peering ein zweites Mal (5), bevor er schließlich in Speicherkonto B über den privaten Endpunkt gespeichert wird, der mit dem Hub-Vnet (6) verbunden ist.

Private Endpunkte im Konnektivitätshub

Abbildung 5: Private Endpunkte in Konnektivitäs-Hub-Architektur (nicht empfohlen).

Benutzerzugriffsverwaltung in der Konnektivitätshub-Architektur

In diesem Netzwerkdesign benötigen Ihre Datenzielzonenteams und Datenanwendungsteams zwei Dinge, um private Endpunkte mit dem Hub-Vnet zu verbinden:

  • Schreiben von Berechtigungen in einer Ressourcengruppe in Ihrem Konnektivitätshub-Abonnement
  • Verknüpfen der Berechtigungen auf das Hub-Vnet

Ihr Konnektivitätshub ist für das Azure-Plattformteam Ihrer Organisation bestimmt und dient zum Hosten der erforderlichen und freigegebenen Netzwerkinfrastruktur Ihrer Organisation (einschließlich Firewalls, Gateways und Netzwerkverwaltungstools). Diese Netzwerkoption macht das Design uneinheitlich, da sie nicht den Zugriffsverwaltungsprinzipien der unternehmensweiten Zielzonen-Basisprinzipien folgt. Daher genehmigen die meisten Azure-Plattformteams diese Designoption nicht.

Zusammenfassung:

Dienstverwaltung in der Konnektivitätshub-Architektur

Das Design dieser Netzwerkarchitektur ähnelt dem Design der vermaschten Netzwerkarchitektur, aber dieses Netzwerkdesign hat kein virtuelles Netzwerkgerät, das als einzelner Fehlerpunkt oder Drosselungspunkt fungiert. Außerdem wird der Verwaltungsaufwand für Ihr zentrales Azure-Plattformteam reduziert, indem Datasets nicht über den Konnektivitätshub gesendet werden, da es keine Notwendigkeit gibt, das virtuelle Gerät zu skalieren. Dies hat die Folge, dass das zentrale Azure-Plattformteam nicht mehr den Datenverkehr zwischen den Datenzielzonen überprüfen und protokollieren kann, der zwischen Datenzielzonen gesendet wird. Analysen auf Cloudebene sind jedoch eine kohärente Plattform, die mehrere Abonnements umfasst, die Skalieren ermöglicht und Beschränkungen auf Plattformebene überwindet, sodass dies kein Nachteil ist.

Bei allen Ressourcen, die in einem einzelnen Abonnement gehostet werden, wird der Datenverkehr nicht im zentralen Konnektivitätshub überprüft. Sie können weiterhin Netzwerkprotokolle mithilfe von Datenflussprotokollen der Netzwerksicherheitsgruppe erfassen und andere Anwendungs- und Dienstprotokolle mithilfe von dienstspezifischen Diagnoseeinstellungen konsolidieren und speichern. Sie können alle diese Protokolle in großem Stil mit Azure-Richtlinien erfassen.

Mit diesem Design können Sie auch eine Azure-native DNS-Lösung basierend auf Zonen für Privates DNS erstellen und den DNS-A-Datensatzlebenszyklus über Azure-Richtlinien automatisieren.

Zusammenfassung:

Kosten für die Konnektivitätshub-Architektur

Hinweis

Beim Zugriff auf einen privaten Endpunkt über ein Peer-Netzwerk ist für Kunden immer der private Endpunkt selbst und nicht das VNet-Peering kostenpflichtig. Die offizielle Anweisung finden Sie unter Häufig gestellte Fragen: Welche Gebühren fallen beim Zugriff auf einen privaten Endpunkt von einem Peer-Netzwerk aus an?.

In diesem Netzwerkdesign werden Ihnen nur Ihre privaten Endpunkte (pro Stunde) und Eingangs- und Ausgangsdatenverkehr berechnet, der über diese privaten Endpunkte gesendet wird, um ein rohes Dataset (1) zu laden und das verarbeitete Dataset (6) zu speichern.

Zusammenfassung:

Bandbreite und Latenz in der Konnektivitätshub-Architektur

Dieses Design verfügt über keine bekannten Bandbreiten- und Latenzbeschränkungen, da es keine virtuellen Netzwerkgeräte besitzt, die den Durchsatz für datenübergreifenden Zielzonen-Datenaustausch beschränken. Der einzige Begrenzungsfaktor des Designs ist der physische Grenzwert unserer Rechenzentren (Geschwindigkeit von Glasfaserkabeln).

Zusammenfassung:

Zusammenfassung privater Endpunkte in Konnektivitäs-Hub-Architektur

Diese Netzarchitektur bietet zwar zahlreiche Vorteile, ist aber aufgrund der bereits erwähnten Unstimmigkeiten bei der Zugangsverwaltung nicht optimal. Daher können wir diesen Designansatz nicht empfehlen.

Fazit zu Datenzielzonenkonnektivität in einer Region

Aus allen überprüften Netzwerkarchitekturoptionen und ihren Vor- und Nachteilen ist die vermaschte Netzwerkarchitektur der klare Gewinner. Sie bietet enorme Vorteile für den Durchsatz und für die Kosten und Verwaltung, weshalb wir sie bei der Bereitstellung von Analysen auf Cloudebene verwenden. Virtuelle Peering-Spoke-Netzwerke wurden bisher nicht häufig verwendet, und dies hat zu Problemen bei der Freigabe von Datasets in Domänen und Geschäftseinheiten geführt.

Sie können Analysen auf Cloudebene als kohärente Lösung ansehen, die mehrere Abonnements umfasst. In einer Einrichtung mit Einzelabonnement entspricht der Netzwerkdatenverkehr dem Fluss in der vermaschten Netzwerkarchitektur. Innerhalb einer Einrichtung mit Einzelabonnement werden die Benutzer wahrscheinlich auf die Begrenzungen auf Abonnementebene und Kontingente der Plattform treffen, was Analysen auf Cloudebene vermeiden möchten.

Nächste Schritte