Überregionale Datenzielzonenkonnektivität
Wenn Sie eine Präsenz in mehr als einer Azure-Region haben und Ihre Datenplattform und Datenanwendungen in mehreren Regionen hosten müssen, wird die Konnektivität etwas komplizierter.
Bereitstellungen in mehreren Regionen verfügen in der Regel über ein Konnektivitätshubabonnement an jedem einzelnen Azure-Standort. Wenn Sie beispielsweise Dienste sowohl in den USA, Osten als auch in Europa, Westen, ausführen, müssen Sie ein Konnektivitätshubabonnement mit freigegebenen Netzwerkressourcen in jeder Region einrichten. Zu den freigegebenen Netzwerkressourcen gehören:
- Virtuelle Netzwerkgeräte (z. B. Azure Firewall)
- ExpressRoute-Gateways
- VPN-Gateways
- Virtuelle Hubnetzwerke (in einer Hub-and-Spoke-Architektur) oder vWAN Hubs (in einem vWan-Setup)
Abbildung 1: Regionsübergreifende Konnektivität.
In einer Hub-Spoke-Hub-Architektur werden die virtuellen Netzwerke von Konnektivitätshubs häufig mithilfe von globalem VNET-Peering verbunden. Für größere Umgebungen ist die Verwendung von ExpressRoute Global Reach eine häufig genutzte Alternative. Unabhängig davon, welche Konnektivitätsoption Sie wählen, können Sie globales Routing und Konnektivität zwischen Spoke-Netzwerken über mehrere Regionen hinweg erreichen. Dies bedeutet, dass Sie Daten mithilfe von virtuellen Netzwerkgeräten, Netzwerksicherheitsgruppen und Routentabellen regionsübergreifend verschieben können, da Ihr Datenverkehr in keinem Konnektivitätsabonnement blockiert 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.
Globales VNET-Peering (empfohlen)
Sie können Datenzielzonen mithilfe von direktem globalem VNET-Peering regionsübergreifend verbinden. Setzen wir unser vorheriges Beispiel fort: In diesem Setup greift der virtuelle Computer in Europa, Westen direkt auf den privaten Endpunkt des Speicherkontos USA, Osten zu, ohne sich Hub-and-Spoke- oder vWAN-Netzwerkarchitekturen zurückgreifen zu müssen. Die Daten werden direkt von der VM über einen privaten Endpunkt geladen, verarbeitet und dann wieder im Speicherkonto in Europa, Westen gespeichert.
Benutzerzugriffsverwaltung im globalen VNET-Peering
Es gibt keine besonderen Vor- oder Nachteile für eine der vorgeschlagenen Konnektivitätsoptionen für regionsübergreifende Datenzielzonen.
Zusammenfassung: 
/
Dienstverwaltung im globalen VNET-Peering
Globales VNET-Peering verfügt über kein virtuelles Netzwerkgerät, das als Single Point of Failure oder zur Drosselung des Durchsatzes dient. Daten werden nicht über Ihre Konnektivitätshubs gesendet, sodass Sie die virtuellen Geräte und Gateways innerhalb der Konnektivitätshubs nicht skalieren müssen. Diese fehlende Skalierung reduziert den Verwaltungsaufwand für Ihr zentrales Azure-Plattformteam. Sie müssen auch keine einzelnen regionsübergreifenden Verbindungen zu Ihrer Positivliste hinzufügen. Ihre Datenteams können auf Daten aus Datenzielzonen in anderen Regionen zugreifen, ohne auf Änderungen der Routingtabelle warten zu müssen.
In diesem Netzwerkentwurf kann Ihr zentrales Azure-Plattformteam den gesamten Datenverkehr nicht mehr mithilfe einer Firewall der Ebene 7 überprüfen und protokollieren. Das Szenario mit Analysen auf Cloudebene ist jedoch eine kohärente Plattform, die mehrere Abonnements umfasst, was Skalieren ermöglicht und Beschränkungen auf Plattformebene überwindet, sodass kein Nachteil entsteht. Sie können Netzwerkprotokolle mithilfe der Datenflussprotokolle 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.
In einigen Szenarien müssen Sie aufgrund regulatorischer oder rechtlicher Implikationen Einschränkungen vornehmen. Beispielsweise verfügen Sie möglicherweise über eine lokale Regelung, die erfordert, dass bestimmte Datasets in einem bestimmten Rechenzentrum verbleiben müssen, sodass Sie sie nicht regionsübergreifend übertragen dürfen. Sie können auf Netzwerksicherheitsgruppen zurückgreifen, die Ihnen bei der Einhaltung dieser Regel helfen und nur zulassen, dass der Datenverkehr lediglich in eine Richtung (von den USA, Osten nach Europa, Westen) und nicht umgekehrt, übertragen wird. Innerhalb Ihrer Netzwerksicherheitsgruppen können Sie sicherstellen, dass Datenverkehr, der aus den USA, Osten stammt, verweigert wird, während Datenverkehr, der aus Europa, Westen stammt, zugelassen wird.
Dieser Lösungsansatz wirkt sich nicht auf Bandbreite und Latenz aus und ermöglicht es Kunden, mit lokalen Regelungen konform zu bleiben und gleichzeitig Datasets aus mehreren Regionen zu kombinieren. Diese Option hat auch keine Auswirkungen auf Ihre DNS-Architektur und ermöglicht Ihnen die Verwendung einer nativen Azure-Lösung, die auf privaten Azure DNS-Zonen basiert.
Zusammenfassung:
Kosten für globales VNET-Peering
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?.
Bei diesem Netzwerkdesign werden Ihnen Ihre privaten Endpunkte (pro Stunde) und der gesamte eingehende und ausgehende Datenverkehr in Rechnung gestellt, der über sie gesendet wird. Außerdem müssen Sie für den Datenverkehr zwischen Regionen die Kosten für die Datenübertragung tragen. Ihnen fallen jedoch KEINE Kosten für ein- und ausgehendes globales VNET-Peering an. Aus diesem Gründen hat die Option des globalen VNET-Peerings bemerkenswerte Kostenvorteile gegenüber einer herkömmlichen Spoke-Hub-Hub-Spoke-Architektur, die weiter unten in diesem Artikel beschrieben wird.
Zusammenfassung:
Bandbreite und Latenz im globalen VNET-Peering
Die Auswirkungen auf Bandbreite und Latenz sind beim globalen VNET-Peering viel geringer als bei der herkömmlichen Spoke-Hub-Hub-Spoke-Option. Globales VNET-Peering enthält eine geringere Anzahl von Hops für den regionsübergreifenden Datenzielzonendatenaustausch und verfügt über keine virtuellen Netzwerkgeräte, die den Durchsatz einschränken. Die Bandbreite und Latenz, die Sie für den regionsübergreifenden Datenverkehr erzielen können, werden einzig durch die physischen Grenzen unserer Rechenzentren (Geschwindigkeit von Glasfaserkabeln, Gateways und Routern) begrenzt.
Zusammenfassung:
Globales VNet-Peerings: Zusammenfassung
Das globale VNET-Peering zwischen Datenzielzonen in verschiedenen Regionen bietet enorme Vorteile, insbesondere wenn der regionsübergreifende Datenverkehr auf Ihrer Datenplattform zunimmt. Es vereinfacht die Dienstverwaltung für Ihr zentrales Azure-Plattformteam und bietet insbesondere bei Anwendungsfällen Vorteile, die geringe Latenz und hohe Bandbreite erfordern. Darüber hinaus bietet es erhebliche Kostenvorteile gegenüber der herkömmlichen Spoke-Hub-Hub-Spoke-Designoption.
Herkömmliches Spoke-Hub-Hub-Spoke-Design (nicht empfohlen)
Ihre andere Option für regionsübergreifende Datenübertragung ist das herkömmliche Spoke-Hub-Hub-Spoke-Design. Wenn in unserem Beispielszenario eine VM in der Datenzielzone A, die in Europa, Westen gehostet wird, ein in einem Speicherkonto gespeichertes Dataset aus der in den USA, Osten gehosteten Datenzielzone B lädt, durchlaufen Daten zwei lokale VNET-Peerings (Konnektivität zwischen Hubs und Spokes), ein globales VNET-Peering (Konnektivität zwischen Hubs) und zwei Gateways oder virtuelle Netzwerkgeräte, bevor sie von der VM geladen und dann wieder in das lokale Speicherkonto verschoben werden.
Benutzerzugriffsverwaltung im herkömmlichen Spoke-Hub-Hub-Spoke-Design
Es gibt keine besonderen Vor- oder Nachteile für eine der vorgeschlagenen Konnektivitätsoptionen für regionsübergreifende Datenzielzonen.
Zusammenfassung:
/
Dienstverwaltung im herkömmlichen Spoke-Hub-Hub-Spoke-Design
Dieser Lösungsansatz ist gur bekannt und mit anderen regionsübergreifenden Konnektivitätsmustern konsistent, was die Einführung und Implementierung erleichtert. Er hat auch keine Auswirkungen auf die DNS-Architektur und ermöglicht Ihnen die Verwendung einer nativen Azure-Lösung, die auf privaten Azure DNS-Zonen basiert.
Diese Konnektivitätsoption funktioniert zwar nahtlos, wenn Sie sie ordnungsgemäß einrichten, hat jedoch Nachteile. Regionsübergreifender Datenverkehr wird häufig standardmäßig verweigert und muss fallweise aktiviert werden. Dies bedeutet, dass für jede einzelne erforderliche regionsübergreifende Datenzugriffsanforderung ein Ticket an Ihr zentrales Azure-Plattformteam übermittelt werden muss, damit Ihr Team jede einzelne Verbindung zwischen einer VM und einem regionsübergreifenden Speicherkonto auf die Positivliste setzen kann. Dieser Prozess erhöht den Verwaltungsaufwand erheblich. Er verlangsamt außerdem Ihre Datenprojektteams, da sie nicht auf die benötigten Daten zugreifen können.
Beachten Sie auch, dass Konnektivitätshubs bei dieser Option als Single Points of Failure fungieren. Bei einer Downtime von virtuellen Netzwerkgeräten oder Gateways treten Fehler bei der Konnektivität und entsprechend auf den Datenplattformen auf. Außerdem besteht ein hohes Risiko, dass Routen in den Konnektivitätshubs falsch konfiguriert werden. Diese Fehlkonfiguration kann zu schwerwiegenden Downtimes auf Ihrer Datenplattform führen und zu einer Reihe von davon abhängigen Workflow- und Datenproduktfehlern führen.
Sie sollten die Datenmenge überwachen, die Sie regionsübergreifend übertragen müssen, wenn Sie diesen Lösungsansatz verwenden. Im Laufe der Zeit kann diese Überwachung Gigabytes oder sogar Terabytes an Daten umfassen, die durch Ihre zentralen Instanzen fließen. Da die Bandbreite virtueller Netzwerkgeräte häufig auf einen Durchsatz im ein- oder zweistelligen Gigabytebereich beschränkt ist, können die Geräte zu einem kritischen Engpass werden, der den Datenverkehr zwischen Regionen und die gemeinsame Nutzung Ihrer Datenressourcen einschränkt. Aus diesem Grund können Ihre freigegebenen Netzwerkressourcen Skalierungsmechanismen erfordern, die häufig zeitaufwändig und kostspielig sind und sich möglicherweise auf andere Workloads in Ihrem Mandanten auswirken.
Zusammenfassung:
Kosten für das herkömmliche Spoke-Hub-Hub-Spoke-Design
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?.
Im herkömmlichen Spoke-Hub-Hub-Spoke-Design werden Ihnen die privaten Endpunkte Ihrer beiden Speicherkonten (pro Stunde) und der gesamte eingehende und ausgehende Datenverkehr, der über sie gesendet wird, in Rechnung gestellt. Außerdem müssen Sie die Kosten für den eingehenden und ausgehenden Datenverkehr eines lokalen VNET-Peerings und für das globale VNET-Peering zwischen Ihren Konnektivitätshubs tragen. Wie im vorherigen Hinweis erläutert, fallen für das erste VNET-Peering jedoch keine Gebühren an.
Wenn Sie sich für dieses Netzwerkdesign entscheiden, tragen ihre zentralen virtuellen Netzwerkgeräte ebenfalls erheblich zu den Kosten bei. Dies liegt daran, dass Sie entweder zusätzliche Lizenzen erwerben müssen, um die Geräte je nach Bedarf zu skalieren, oder die Gebühr pro verarbeitetem Gigabyte für sie bezahlen müssen, wie beispielsweise für Azure Firewall.
Zusammenfassung:
Bandbreite und Latenz im herkömmlichen Spoke-Hub-Hub-Spoke-Design
Dieser Netzwerkentwurf weist aus Bandbreitensicht erhebliche Einschränkungen auf. Wenn Ihre Plattform größer wird, werden Ihre zentralen virtuellen Netzwerkgeräte zu kritischen Engpässen, was Anwendungsfälle für regionsübergreifende Datenzielzonen und Freigabe Ihrer Datasets einschränkt. Außerdem besteht eine hohe Wahrscheinlichkeit, dass im Laufe der Zeit mehrere Kopien Ihrer Datasets erstellt werden. Dieser Entwurf wirkt sich auch stark auf die Latenz aus, was besonders wichtig für Szenarien mit Echtzeitanalysen ist, da Ihre Daten dabei viele Hops durchlaufen.
Zusammenfassung:
Herkömmliche Spoke-Hub-Hub-Spoke-Design: Zusammenfassung
Das Spoke-Hub-Hub-Spoke-Design ist in vielen Organisationen bekannt und etabliert, wodurch es einfach ist, es in einer vorhandenen Umgebung bereitzustellen. Es hat jedoch erhebliche Nachteile hinsichtlich der Dienstverwaltung, der Kosten, der Bandbreite und der Latenz. Diese Probleme sind besonders auffällig, da die Zahl regionsübergreifender Anwendungsfälle zunimmt.
Zusammenfassung
Globales VNET-Peering bietet gegenüber dem herkömmlichen Spoke-Hub-Hub-Spoke-Design viele Vorteile, da es kostengünstig und einfach zu verwalten ist und zuverlässig regionsübergreifende Konnektivität bietet. Während das herkömmliche Spoke-Hub-Hub-Spoke-Design eine praktikable Lösung sein kann, solange Ihr Datenvolumen und der Bedarf an regionsübergreifendem Datenaustausch gering ist, empfehlen wir den Global VNet Peering-Ansatz, wenn die Datenmenge,wächst die Sie für den Austausch zwischen Regionen benötigen.