Netzwerksegmentierung und -konnektivität für verteilte Anwendungen im cloudübergreifenden Netzwerk

Last reviewed 2024-04-05 UTC

Dieses Dokument ist Teil einer Designanleitungsreihe für ein cloudübergreifendes Netzwerk.

Die Reihe besteht aus folgenden Teilen:

In diesem Teil werden die Struktur und die Konnektivität des Netzwerks erläutert, die die Grundlage des Designs bilden. In diesem Dokument werden die Phasen erläutert, in denen Sie folgende Entscheidungen treffen:

  • Die gesamte Netzwerksegmentierung und Projektstruktur.
  • Wo Sie Ihre Arbeitslast platzieren.
  • Wie Ihre Projekte mit externen lokalen Netzwerken und anderen Netzwerken von Cloud-Anbietern verbunden sind, einschließlich des Designs für Konnektivität, Routing und Verschlüsselung.
  • Wie Ihre VPC-Netzwerke intern miteinander verbunden sind.
  • Wie Ihre Google Cloud-VPC-Subnetze miteinander und mit anderen Netzwerken verbunden sind, einschließlich der Einrichtung von Service Erreichbarkeit und DNS.

Netzwerksegmentierung und Projektstruktur

Während der Planungsphase müssen Sie sich für eine von zwei Projektstrukturen entscheiden:

  • Ein konsolidiertes Infrastruktur-Hostprojekt, in dem Sie ein einzelnes Infrastruktur-Hostprojekt verwenden, um alle Netzwerkressourcen für alle Anwendungen zu verwalten
  • Segmentierte Hostprojekte, bei denen Sie für jede Anwendung ein Infrastruktur-Hostprojekt in Kombination mit einem anderen Hostprojekt verwenden

Wir empfehlen Ihnen, in der Planungsphase auch die administrativen Domains für Ihre Arbeitslastumgebungen festzulegen. Beschränken Sie die Berechtigungen für Ihre Infrastrukturadministratoren und Entwickler anhand des Prinzips der geringsten Berechtigung. Legen Sie die Anwendungsressourcen in verschiedenen Anwendungsprojekten fest. Da Infrastrukturadministratoren die Verbindung zum Freigeben von Ressourcen einrichten müssen, können Infrastrukturressourcen innerhalb eines Infrastrukturprojekts verarbeitet werden. Beispielsweise können Infrastrukturadministratoren ein Infrastrukturprojekt verwenden, um diese gemeinsam genutzten Ressourcen zu verarbeiten, um eine Verbindung zu freigegebenen Infrastrukturressourcen einzurichten. Gleichzeitig kann das Entwicklungsteam seine Arbeitslasten in einem Projekt und das Produktionsteam seine Arbeitslasten in einem separaten Projekt verwalten. Entwickler verwenden dann die Infrastrukturressourcen im Infrastrukturprojekt, um Ressourcen, Dienste, Load-Balancing und DNS-Routingrichtlinien für ihre Arbeitslasten zu erstellen und zu verwalten.

Außerdem müssen Sie entscheiden, wie viele VPC-Netzwerke Sie zuerst implementieren und wie sie in Ihrer Ressourcenhierarchie organisiert sind. Weitere Informationen zum Auswählen einer Ressourcenhierarchie finden Sie unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone auswählen. Weitere Informationen zur Auswahl der Anzahl der VPC-Netzwerke finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.

Für das cloudübergreifende Netzwerk empfehlen wir die Verwendung der folgenden VPCs:

  • Eine oder mehrere Anwendungs-VPCs zum Hosten der Ressourcen für die verschiedenen Anwendungen.
  • Eine Transit-VPC, in der die gesamte externe Konnektivität verarbeitet wird
  • Eine optionale zentrale Dienst-VPC, mit der die Bereitstellung des privaten Zugriffs auf veröffentlichte Dienste konsolidiert werden kann.

Das folgende Diagramm zeigt eine visuelle Darstellung der empfohlenen VPC-Struktur, die gerade beschrieben wurde. Sie können die im Diagramm gezeigte VPC-Struktur entweder mit einer konsolidierten oder einer segmentierten Struktur verwenden, wie in den folgenden Abschnitten beschrieben. Das hier gezeigte Diagramm zeigt nicht die Konnektivität zwischen den VPC-Netzwerken.

Empfohlene VPC-Struktur

Konsolidiertes Infrastruktur-Hostprojekt

Sie können ein konsolidiertes Infrastruktur-Hostprojekt verwenden, um alle Netzwerkressourcen wie Subnetze, Peering und Load-Balancer zu verwalten.

Im Hostprojekt der Infrastruktur können mehrere freigegebene VPCs für Anwendungen mit den entsprechenden Anwendungsdienstprojekten erstellt werden, damit sie der Organisationsstruktur entsprechen. Verwenden Sie mehrere Anwendungsdienstprojekte, um die Ressourcenverwaltung zu delegieren. Das gesamte Netzwerk für alle Anwendungs-VPCs wird dem konsolidierten Infrastruktur-Hostprojekt in Rechnung gestellt.

Für diese Projektstruktur können viele Anwendungsdienstprojekte eine kleinere Anzahl von Anwendungs-VPCs gemeinsam nutzen.

Das folgende Diagramm bietet eine visuelle Darstellung des konsolidierten Infrastruktur-Hostprojekts und mehrerer Anwendungsdienstprojekte, die gerade beschrieben wurden. Das Diagramm zeigt nicht die Konnektivität zwischen allen Projekten.

Konsolidiertes Infrastruktur-Hostprojekt und mehrere Anwendungsdienstprojekte

Segmentierte Hostprojekte

In diesem Muster hat jede Gruppe von Anwendungen ein eigenes Anwendungshostprojekt und VPCs. An das Hostprojekt können mehrere Anwendungsdienstprojekte angehängt werden. Die Abrechnung für Netzwerkdienste erfolgt auf das Hostprojekt der Infrastruktur und die Anwendungshostprojekte. Die Infrastrukturgebühren werden dem Infrastrukturhostprojekt und die Netzwerkgebühren für Anwendungen jedem Hostprojekt der Anwendung in Rechnung gestellt.

Das folgende Diagramm bietet eine visuelle Darstellung der verschiedenen Hostprojekte und der Anwendungsdienstprojekte, die gerade beschrieben wurden. Das Diagramm zeigt nicht die Konnektivität zwischen allen Projekten.

Mehrere Hostprojekte und mehrere Anwendungsdienstprojekte

Arbeitslastplatzierung

Viele Konnektivitätsoptionen hängen von den regionalen Standorten Ihrer Arbeitslasten ab. Anleitungen zum Platzieren von Arbeitslasten finden Sie unter Best Practices für die Auswahl der Regionen in Compute Engine. Sie sollten entscheiden, wo sich Ihre Arbeitslasten befinden werden, bevor Sie Verbindungsstandorte auswählen.

Externe und Hybridkonnektivität

In diesem Abschnitt werden die Anforderungen und Empfehlungen für die folgenden Verbindungspfade beschrieben:

  • Private Verbindungen zu anderen Cloud-Anbietern
  • Private Verbindungen zu lokalen Rechenzentren
  • Internetverbindung für Arbeitslasten, insbesondere ausgehende Verbindungen

Ein cloudübergreifendes Netzwerk umfasst die Verbindung mehrerer Cloud-Netzwerke oder lokaler Netzwerke. Externe Netzwerke können verschiedenen Organisationen gehören und von diesen verwaltet werden. Diese Netzwerke sind über eine oder mehrere Netzwerk-zu-Netzwerk-Schnittstellen (NNIs) physisch miteinander verbunden. Die Kombination von NNIs muss im Hinblick auf Leistung, Ausfallsicherheit, Datenschutz und Sicherheit entworfen, bereitgestellt und konfiguriert werden.

Für Modularität, Wiederverwendbarkeit und die Möglichkeit, Sicherheits-NVAs einzufügen, sollten Sie externe Verbindungen und das Routing in einer Transit-VPC platzieren, die dann als freigegebener Verbindungsdienst für andere VPCs dient. Routingrichtlinien für Ausfallsicherheit, Failover und Pfadeinstellung über mehrere Domains hinweg können einmal in der Transit-VPC konfiguriert und von vielen anderen VPC-Netzwerken genutzt werden.

Das Design der NNIs und der externen Konnektivität wird später für interne Konnektivität und VPC-Netzwerke verwendet.

Das folgende Diagramm zeigt die Transit-VPC, die als freigegebener Verbindungsdienst für andere VPCs dient, die über VPC-Netzwerk-Peering, Network Connectivity Center oder HA VPN verbunden sind:

Transit-VPC, die als Dienst für freigegebene Verbindungen für andere VPCs verwendet wird

Private Verbindungen zu anderen Cloud-Anbietern

Wenn Sie Dienste in anderen Netzwerken des Cloud-Dienstanbieters (CSP) ausführen, die Sie mit Ihrem Google Cloud-Netzwerk verbinden möchten, können Sie eine Verbindung über das Internet oder über private Verbindungen herstellen. Wir empfehlen private Verbindungen.

Berücksichtigen Sie bei der Auswahl der Optionen den Durchsatz, den Datenschutz, die Kosten und die betriebliche Durchführbarkeit.

Verwenden Sie eine direkte Hochgeschwindigkeitsverbindung zwischen Cloud-Netzwerken, um den Durchsatz zu maximieren und gleichzeitig den Datenschutz zu verbessern. Bei direkten Verbindungen sind keine zwischengeschalteten physischen Netzwerkgeräte erforderlich. Wir empfehlen die Verwendung von Cross-Cloud Interconnect, das diese direkten Verbindungen bereitstellt, sowie die MACsec-Verschlüsselung und eine Durchsatzrate von bis zu 100 Gbit/s pro Verbindung.

Wenn Sie Cross-Cloud Interconnect nicht verwenden können, können Sie Dedicated Interconnect oder Partner Interconnect über eine Colocations-Einrichtung verwenden.

Wählen Sie die Standorte, an denen Sie eine Verbindung zu den anderen CSPs herstellen möchten, basierend auf der Nähe des Standorts zu den Zielregionen aus. Berücksichtigen Sie bei der Standortauswahl Folgendes:

  • Sehen Sie sich die Liste der Standorte an:
    • Prüfen Sie für Cross-Cloud Interconnect die Liste der Standorte, die sowohl für Google Cloud als auch für CSPs verfügbar sind (Verfügbarkeit variiert je nach Cloud-Anbieter).
    • Wählen Sie für Dedicated Interconnect oder Partner Interconnect einen Standort mit niedriger Latenz für die Colocations-Einrichtung aus.
  • Bewerten Sie die Latenz zwischen dem angegebenen POP-Edge (Point of Presence) und der relevanten Region in jedem CSP.

Zum Maximieren der Zuverlässigkeit Ihrer cloudübergreifenden Verbindungen empfehlen wir eine Konfiguration, die ein SLA mit 99,99% Verfügbarkeit für Produktionsarbeitslasten unterstützt. Weitere Informationen finden Sie unterCross-Cloud Interconnect-Hochverfügbarkeit, 99,9% Verfügbarkeit für Dedicated Interconnect einrichten und99,99% Verfügbarkeit für Partner Interconnect einrichten “

Wenn Sie keine hohe Bandbreite zwischen verschiedenen CSPs benötigen, können Sie VPN-Tunnel verwenden. Dieser Ansatz kann Ihnen den Einstieg erleichtern und Sie können ein Upgrade auf Cross-Cloud Interconnect durchführen, wenn Ihre verteilten Anwendungen mehr Bandbreite verbrauchen. VPN-Tunnel können auch ein SLA von 99,99% erreichen. Weitere Informationen finden Sie unter HA VPN-Topologien.

Private Verbindungen zu lokalen Rechenzentren

Für die Verbindung zu privaten Rechenzentren können Sie eine der folgenden Hybridkonnektivitätsoptionen verwenden:

  • Dedicated Interconnect
  • Partner Interconnect
  • HA VPN

Die Überlegungen zum Routing für diese Verbindungen ähneln denen für private Verbindungen zu anderen Cloud-Anbietern.

Das folgende Diagramm zeigt Verbindungen zu lokalen Netzwerken und wie lokale Router über eine Peering-Richtlinie eine Verbindung zu Cloud Router herstellen können:

Verbindungen zu lokalen Netzwerken

Domainübergreifendes Routing mit externen Netzwerken

Verwenden Sie mehrere Pfade, um die Netzwerke zu verbinden, um die Ausfallsicherheit und den Durchsatz zwischen den Netzwerken zu erhöhen.

Wenn Traffic über Netzwerkdomains übertragen wird, muss er von zustandsorientierten Sicherheitsgeräten überprüft werden. Daher ist die Flusssymmetrie an der Grenze zwischen den Domains erforderlich.

Bei Netzwerken, die Daten über mehrere Regionen übertragen, können die Kosten und das Dienstqualitätsniveau der einzelnen Netzwerke erheblich abweichen. Basierend auf diesen Unterschieden möchten Sie möglicherweise einige Netzwerke statt anderer verwenden.

Richten Sie Ihre domainübergreifende Routingrichtlinie so ein, dass sie Ihre Anforderungen für die interregionale Übertragung, die Traffic-Symmetrie, den Durchsatz und die Ausfallsicherheit erfüllt.

Die Konfiguration der domainübergreifenden Routingrichtlinien hängt von den verfügbaren Funktionen am Edge jeder Domain ab. Die Konfiguration hängt auch davon ab, wie die benachbarten Domains aus einem autonomen System und aus der Perspektive der IP-Adressierung (Subnetze) über verschiedene Regionen hinweg strukturiert sind. Um die Skalierbarkeit zu verbessern, ohne Präfixlimits für Edge-Geräte zu überschreiten, empfehlen wir, dass Ihr IP-Adressierungsplan zu weniger aggregierten Präfixen für jede Region und Domain-Kombination führt.

Berücksichtigen Sie beim Entwerfen des interregionalen Routings Folgendes:

  • Google Cloud-VPC-Netzwerke und Cloud Router unterstützen beide globales regionenübergreifendes Routing. Andere CSPs haben möglicherweise regionale VPCs und BGP-Bereiche (Border Gateway Protocol). Weitere Informationen finden Sie in der Dokumentation Ihres anderen CSP.
  • Cloud Router bewirbt Routen mit vordefinierten Pfadeinstellungen automatisch basierend auf der regionalen Nähe. Dieses Routingverhalten hängt vom konfigurierten dynamischen Routingmodus der VPC ab. Möglicherweise müssen Sie diese Einstellungen für das gewünschte Routingverhalten überschreiben.
  • Verschiedene CSPs unterstützen verschiedene BGP- und Bidirectional Forwarding Detection (BFD)-Funktionen und der Cloud Router von Google bietet auch spezifische Routenrichtlinienfunktionen, wie unter BGP-Sitzungen erstellen beschrieben.
  • Verschiedene CSPs können unterschiedliche BGP-Tie-Breaking-Attribute verwenden, um die Präferenz für Routen zu bestimmen. Weitere Informationen finden Sie in der Dokumentation Ihres CSP.

Domainübergreifendes Routing in einer Region

Wir empfehlen, mit Routing zwischen Domains zu beginnen, auf dem Sie aufbauen, um Verbindungen mit mehreren Regionen mit Routing zwischen Domains zu erstellen.

Designs, die Cloud Interconnect verwenden, müssen mindestens zwei Verbindungsstandorte haben, die sich in derselben Region, aber in unterschiedlichen Edge-Verfügbarkeitsdomains befinden.

Entscheiden Sie, ob diese doppelten Verbindungen in einem Aktiv/Aktiv- oder in einem Aktiv/Passiv-Design konfiguriert werden sollen:

  • Aktiv/Aktiv verwendet ECMP-Routing (Equal Cost Multi-Path), um die Bandbreite beider Pfade zusammenzufassen und gleichzeitig für den Traffic zwischen Domains zu verwenden. Cloud Interconnect unterstützt auch die Verwendung von LACP-aggregierten Verbindungen, um eine Gesamtbandbreite von bis zu 200 Gbit/s pro Pfad zu erreichen.
  • Aktiv/Passiv erzwingt, dass eine Verbindung bereit ist und nur dann Traffic übernimmt, wenn die aktive Verbindung unterbrochen wird.

Wir empfehlen ein Aktiv/Aktiv-Design für intraregionale Verbindungen. Bestimmte lokale Netzwerktopologien in Kombination mit zustandsorientierten Sicherheitsfunktionen können jedoch ein Aktiv/Passiv-Design erfordern.

Cloud Router wird über mehrere Zonen instanziiert, was eine höhere Ausfallsicherheit als ein einzelnes Element bietet. Das folgende Diagramm zeigt, wie alle stabilen Verbindungen auf einem einzelnen Cloud Router innerhalb einer Region konvergieren. Dieses Design kann ein SLA mit einer Verfügbarkeit von 99,9% innerhalb einer einzelnen Metropolregion unterstützen, wenn Sie den Richtlinien zum Einrichten einer Verfügbarkeit von 99,9 % für Dedicated Interconnect folgen.

Das folgende Diagramm zeigt zwei lokale Router, die redundant mit dem verwalteten Cloud Router-Dienst in einer einzelnen Region verbunden sind:

Stabile Verbindungen können einen einzelnen Cloud Router verwenden

Multiregionales Inter-Domain-Routing

Für eine Sicherungsverbindung können Netzwerke über mehrere geografische Bereiche hinweg Peering-Verbindungen herstellen. Wenn Sie die Netzwerke in mehreren Regionen verbinden, kann das SLA für die Verfügbarkeit auf 99,99 % erhöht werden.

Das folgende Diagramm zeigt die SLA-Architekturen für eine Verfügbarkeit von 99,99 %. Es werden lokale Router an zwei verschiedenen Standorten angezeigt, die redundant mit den verwalteten Cloud Router-Diensten in zwei verschiedenen Regionen verbunden sind.

Cloud Interconnect-Verbindungen in mehreren Regionen

Neben der Ausfallsicherheit sollte das multiregionale Routingdesign die Ablaufsymmetrie erreichen. Außerdem sollte durch das Design das bevorzugte Netzwerk für die interregionale Kommunikation angegeben werden, was mit Hot-Potato- und Cold-Potato-Routing möglich ist. Koppeln Sie das Cold-Potato-Routing in einer Domain mit dem Hot-Potato-Routing in der Peer-Domain. Für die Cold-Potato-Domain empfehlen wir die Verwendung der Google Cloud-Netzwerkdomain, die globale VPC-Routing-Funktionen bietet.

Die Ablaufsymmetrie ist nicht immer obligatorisch, die Ablaufasymmetrie kann jedoch zu Problemen bei zustandsorientierten Sicherheitsfunktionen führen.

Das folgende Diagramm zeigt, wie Sie mithilfe von Hot-Potato- und Cold-Potato-Routing Ihr bevorzugtes interregionales Transitnetzwerk festlegen. In diesem Fall bleibt der Traffic von den Präfixen X und Y im Ursprungsnetzwerk, bis er die Region erreicht, die dem Ziel am nächsten ist (Cold-Potato-Routing). Der Traffic von den Präfixen A und B wird zum anderen Netzwerk in der Ursprungsregion gewechselt und dann durch das andere Netzwerk zum Ziel geleitet (Hot-Potato-Routing).

Hot-Potato- und Cold-Potato-Routing zur Angabe Ihres bevorzugten interregionalen Transitnetzwerks verwenden

Verschlüsselung von Traffic zwischen Domains

Sofern nicht anders angegeben, wird der Traffic über Cloud Interconnect-Verbindungen zwischen verschiedenen CSPs oder zwischen Google Cloud und lokalen Rechenzentren nicht verschlüsselt. Wenn Ihre Organisation eine Verschlüsselung für diesen Traffic benötigt, können Sie die folgenden Funktionen verwenden:

  • MACsec für Cloud Interconnect:Verschlüsselt Traffic über Cloud Interconnect-Verbindungen zwischen Ihren Routern und den Edge-Routern von Google. Weitere Informationen finden Sie unter MACsec für Cloud Interconnect.
  • HA VPN über Cloud Interconnect: Verwendet mehrere HA VPN-Tunnel, um die volle Bandbreite der zugrunde liegenden Cloud Interconnect-Verbindungen bereitstellen zu können. Die HA VPN-Tunnel sind mit IPsec verschlüsselt und werden über Cloud Interconnect-Verbindungen bereitgestellt, die auch MACsec-verschlüsselt sein können. In dieser Konfiguration sind Cloud Interconnect-Verbindungen so konfiguriert, dass nur HA VPN-Traffic zugelassen wird. Weitere Informationen finden Sie unter HA VPN über Cloud Interconnect.

Internetverbindung für Arbeitslasten

Sowohl bei eingehenden als auch bei ausgehenden Internetverbindungen wird davon ausgegangen, dass der Antworttraffic zustandsorientiert der umgekehrten Richtung der ursprünglichen Anfrage folgt.

Im Allgemeinen unterscheiden sich Funktionen für eingehende Internetverbindung von ausgehenden Internetfunktionen, mit Ausnahme von externen IP-Adressen, die beide Richtungen gleichzeitig bereitstellen.

Eingehende Internetverbindung

Eingehende Internetverbindungen dienen hauptsächlich zur Bereitstellung öffentlicher Endpunkte für Dienste, die in der Cloud gehostet werden. Beispiele hierfür sind Internetverbindung zu Webanwendungs- und Spieleservern, die in Google Cloud gehostet werden.

Die Hauptfeatures für eingehende Internetverbindung sind die Cloud Load Balancing-Produkte von Google.

Alle Arten von Cloud Load Balancing bieten einen eigenen Pfad für den Traffic, der zur Internetquelle zurückkehrt, unabhängig davon, ob Sie spezielle VPC-Rückgabepfade oder Benutzerdefinierte Proxy-Subnetze verwenden. Das Design der VPC ist im Allgemeinen unabhängig von ihrer Fähigkeit, eingehende Internetverbindung bereitzustellen.

Ausgehende Internetverbindung

Beispiele für ausgehende Internetverbindung (bei der die erste Anfrage von der Arbeitslast an ein Internetziel stammt) sind Arbeitslasten, die auf APIs von Drittanbietern zugreifen, Softwarepakete und Updates herunterladen und Push-Benachrichtigungen an Webhook-Endpunkte im Internet senden.

Für ausgehende Verbindungen können Sie die in Google Cloud integrierten Optionen verwenden, wie unter Internetverbindung für private VMs herstellen beschrieben. Alternativ können Sie zentrale NGFW NVAs verwenden, wie unter Netzwerksicherheit beschrieben.

Der Hauptpfad für die Bereitstellung ausgehender Internetverbindung ist das Standard-Internetgateway-Ziel in der VPC-Routingtabelle. Dies ist in Google VPCs häufig die Standardroute. Sowohl externe IP-Adressen als auch Cloud NAT (verwalteter NAT-Dienst von Google Cloud) erfordern eine Route, die auf das Standard-Internetgateway der VPC verweist. Daher müssen VPC-Routingdesigns, die die Standardroute überschreiben, ausgehende Verbindungen auf andere Weise bereitstellen. Weitere Informationen finden Sie in der Cloud Router-Übersicht.

Für den Schutz ausgehender Verbindungen bietet Google Cloud sowohl die Cloud Next Generation Firewall-Erzwingung als auch Secure Web Proxy, um eine tiefere Filterung nach HTTP- und HTTPS-URLs zu ermöglichen “ In allen Fällen folgt der Traffic jedoch der Standardroute zum Standard-Internetgateway oder über eine benutzerdefinierte Standardroute in der VPC-Routingtabelle.

Eigene IP-Adressen verwenden

Sie können IPv4-Adressen von Google für die Internetverbindung verwenden oder Bring your own IP address (BYOIP) nutzen, um einen IPv4-Bereich zu verwenden, der Ihrer Organisation gehört. Die meisten Google Cloud-Produkte, die eine im Internet routingfähige IP-Adresse erfordern, unterstützen die Verwendung von BYOIP-Bereichen.

Sie können den Ruf des IP-Bereichs auch durch seine exklusive Verwendung steuern. BYOIP sorgt für die Portabilität der Verbindung und spart Kosten für IP-Adressen.

Interne Konnektivität und VPC-Netzwerke

Wenn der externe und Hybrid-Konnektivitätsdienst konfiguriert ist, können Ressourcen in der Transit-VPC die externen Netzwerke erreichen. Im nächsten Schritt wird diese Verbindung für die Ressourcen verfügbar gemacht, die in anderen VPCs gehostet werden.

Das folgende Diagramm zeigt die allgemeine Struktur der VPC, unabhängig davon, wie Sie die externe Konnektivität aktiviert haben. Es zeigt eine Transit-VPC, die externe Verbindungen beendet und in jeder Region einen Cloud Router hostet. Jeder Cloud Router empfängt Routen von seinen externen Peers über die NNIs in jeder Region. Anwendungs-VPCs sind mit der Transit-VPC verbunden, sodass sie externe Verbindungen gemeinsam nutzen können. Darüber hinaus fungiert die Transit-VPC als Hub für die Spoke-VPCs. Die Spoke-VPCs können Anwendungen, Dienste oder eine Kombination aus beiden hosten.

Allgemeine Struktur des cloudübergreifenden Netzwerks

Konfigurieren Sie auch die DNS-Weiterleitung und das Peering in der Transit-VPC. Weitere Informationen finden Sie im Abschnitt zum DNS-Infrastrukturdesign.

Für eine bessere Leistung und integrierte Cloud-Netzwerkdienste empfehlen wir, VPCs mit Cross-Cloud-Netzwerk- oder VPC-Netzwerk-Peering anstelle von HA VPN zu verbinden.

Private Service Connect-Endpunkte und Front-Ends für den Zugriff auf private Dienste sind über VPC-Netzwerk-Peering oder cloudübergreifende Netzwerke nicht erreichbar. Wir empfehlen die Verwendung von HA VPN für die Konnektivität zwischen VPCs, um diese Einschränkungen zu umgehen. Da die Verwendung von HA VPN für Inter-VPC-Verbindungen zu einem geringeren Durchsatz und einem höheren operativen Aufwand führen kann, reduziert das Design der zentralisierten Dienste den Span der HA VPN-Bereitstellung.

Alternativ können Sie die transitive Inter-VPC-Konnektivität zu veröffentlichten Dienstendpunkten implementieren, indem Sie einen internen Proxy-Network Load Balancer vor den Dienstendpunkten platzieren. Dieser Ansatz weist einige Einschränkungen auf, die im Abschnitt Verbindung mit Network Connectivity Center-Spokes mit Load-Balancing erläutert werden.

In den folgenden Abschnitten werden die möglichen Designs für Hybridkonnektivität erläutert, die Basis-IP-Konnektivität sowie API-Endpunktbereitstellungen unterstützen.

Inter-VPC-Konnektivität für zentralisierte Dienste

Wenn veröffentlichte Dienstendpunkte in einer zentralen Dienst-VPC bereitgestellt werden können, empfehlen wir, dass die Anwendungs-VPCs über VPC-Netzwerk-Peering zum Hub (Transit-VPC) eine Verbindung herstellen und dass Central Services VPC über HA VPN eine Verbindung zum Hub herstellt.

Bei diesem Design ist die Transit-VPC der Hub. Sie stellen die Weiterleitungsregeln für private Dienstendpunkte in einer zentralen Dienst-VPC bereit. Machen Sie die VPC der zentralen Dienste zu einem freigegebenen VPC-Netzwerk und ermöglichen Sie Administratoren von Dienstprojekten, Dienstendpunkte im freigegebenen Netzwerk zu erstellen.

Das Design ist eine Kombination aus zwei Verbindungstypen:

  • VPC-Netzwerk-Peering: Stellt die Verbindung zwischen der Hub-VPC und den Anwendungs-VPCs her.
  • Inter-VPC-Verbindungen von HA VPN: Bieten transitive Konnektivität für die zentrale Dienst-VPC zum Hub.

Eine ausführliche Anleitung und Konfigurations-Blueprints zum Bereitstellen dieser Verbindungstypen finden Sie unter Hub-and-Spoke-Netzwerkarchitektur.

Berücksichtigen Sie beim Kombinieren dieser Architekturen die folgenden Hinweise:

  • Umverteilung von VPC-Peer-Subnetzen in dynamisches Routing (zu HA VPN und Hybrid)
  • Überlegungen zum multiregionalen Routing
  • Weitergabe dynamischer Routen in VPC-Peering (von HA VPN und Hybrid)

Das folgende Diagramm zeigt eine zentrale Dienst-VPC, die über HA VPN mit der Transit-VPC verbunden ist, und die Anwendungs-VPCs, die über VPC-Netzwerk-Peering mit der Transit-VPC verbunden sind:

Grafik: Zentrale Dienste-VPC, die über HA VPN mit der Transit-VPC verbunden ist, und die Anwendungs-VPCs, die über VPC-Netzwerk-Peering mit der Transit-VPC verbunden sind

Die im vorherigen Diagramm dargestellte Struktur enthält folgende Komponenten:

  • Kundenstandort: Ein Rechenzentrum oder ein Remote-Büro, in dem Sie Netzwerkgeräte haben. In diesem Beispiel wird davon ausgegangen, dass die Standorte über ein externes Netzwerk miteinander verbunden sind.
  • Metropole: Eine Metropolregion mit einer oder mehreren Edge-Verfügbarkeitsdomains von Cloud Interconnect. Cloud Interconnect stellt eine Verbindung zu anderen Netzwerken in solchen Metropolregionen her.
  • Hub-Projekt: Ein Projekt, in dem mindestens ein VPC-Netzwerk gehostet wird, das als Hub für andere VPC-Netzwerke dient.
  • Transit-VPC: Ein VPC-Netzwerk im Hub-Projekt, das Verbindungen von lokalen und anderen CSPs empfängt und dann als Transitpfad von anderen VPCs zu lokalen und CSP-Netzwerken dient.
  • Anwendungshostprojekte und VPCs: Projekte und VPC-Netzwerke, in denen verschiedene Anwendungen gehostet werden.
  • Dienst-VPC: Ein VPC-Netzwerk, das zentralisierten Zugriff auf Dienste hostet, die von Anwendungen in den Anwendungs-VPC-Netzwerken benötigt werden.
  • VPC mit verwalteten Diensten: Dienste, die von anderen Entitäten bereitgestellt und verwaltet, aber für Anwendungen zugänglich gemacht werden, die in VPC-Netzwerken ausgeführt werden.

Wenn beim Hub-and-Spoke-Design Anwendungs-VPCs miteinander kommunizieren müssen, können Sie die Anwendungs-VPCs als Spokes mit einem Network Connectivity Center-Hub verbinden. Dieser Ansatz stellt die Konnektivität zwischen allen VPCs im Network Connectivity Center-Hub bereit. Untergruppen der Kommunikation können mithilfe mehrerer Network Connectivity Center-Hubs erstellt werden. Alle Kommunikationseinschränkungen, die zwischen Endpunkten in einem bestimmten Hub erforderlich sind, können mithilfe von Firewallrichtlinien erreicht werden.

Konnektivität mit Spoke-VPCs des Network Connectivity Centers über Load-Balancing

Dieses Muster umfasst alle VPCs als Spokes in einem Network Connectivity Center-Hub und kann bis zu 250 miteinander verbundene VPCs aufnehmen. Ein Network Connectivity Center-Hub ist ein Konstrukt der Verwaltungsebene, das eine vollständige Mesh-Datenebenenverbindung zwischen allen VPC-Netzwerken erstellt, die als Spokes im Network Connectivity Center-Hub registriert sind. Das Muster bietet Verbindungen zu jedem beliebigen Standort und ermöglicht die Bereitstellung verwalteter Dienste in einer beliebigen VPC, sodass Sie sich nicht mehr zwischen zentralen oder verteilten Diensten entscheiden müssen.

Zur Überwindung von Transitivitätsbeschränkungen wird über interne Proxy-Network Load Balancer auf verwaltete Dienste und Hybridverbindungen zugegriffen. Arbeitslastsicherheit für Ost-West-Verbindungen kann die Cloud Next-Generation-Firewall verwenden. Sie können mit diesem Muster auch Inter-VPC-NAT verwenden.

Dieses Muster unterliegt einigen Einschränkungen. Daher muss Folgendes berücksichtigt werden, bevor Sie dieses Muster übernehmen:

  • Mit diesem Muster können Sie NVAs nicht für Perimeter-Firewalls verwenden. Perimeter-Firewalls müssen auf externen Netzwerken bleiben.
  • Nur TCP-Traffic zu und von externen Netzwerken wird unterstützt. Diese Einschränkung tritt auf, weil Verbindungen zu externen Netzwerken über einen internen Proxy-Network Load Balancer ausgeführt werden.
  • Veröffentlichte Dienste haben ein zusätzliches Frontend im Proxy-Load-Balancer. Dieses zusätzliche Frontend verbreitet zusätzliche Einträge im DNS und erfordert Split-DNS-Lookups.
  • Ebene-4-Dienste benötigen für jeden neuen Dienst einen neuen internen Proxy-Network Load Balancer. Abhängig von den erforderlichen Protokollen für die Verbindung benötigen Sie möglicherweise unterschiedliche Load-Balancer.
  • Load-Balancing-Kontingente sind für jedes VPC-Netzwerk begrenzt. Dies ist eine wichtige Überlegung, da Ebene-4-Dienste für jeden Zieldienst einen neuen internen Proxy-Network Load Balancer benötigen.
  • Die ausgewählte Designoption für Hochverfügbarkeit und regionenübergreifendes Failover hängt von Ihren Anforderungen ab.
  • Verschlüsselter Traffic über die Hybridgrenze hinweg hat Auswirkungen auf die Koordinierung der Zertifikatsverwaltung.

Wenn die oben genannten Aspekte überschaubare Kompromisse darstellen oder für Ihre Umgebung irrelevant sind, empfehlen wir dieses Muster als bevorzugte Option.

Das folgende Diagramm zeigt einen Hybrid-Hub für das Network Connectivity Center als Verwaltungsebene für die Cloud Interconnect-Verbindungen. Außerdem wird ein VPC-Hub für das Network Connectivity Center angezeigt, der die VPC-Spokes für Anwendungen und Dienste verbindet:

Anwendungs-VPCs, die als Spokes mit einem Network Connectivity Center-Hub verbunden sind

Proxy-Load-Balancing für Transitivität

Folgendes ist über Spoke-VPCs des Network Connectivity Centers nicht erreichbar:

  • Private Service Connect-Dienstendpunkte und verwaltete Dienst-Front-Ends.
  • Netzwerke hinter Hybridverbindungen (Cloud Interconnect oder HA VPN), da dynamische Routen nicht über ein cloudübergreifendes Netzwerk weitergegeben werden.

Diese Transitivitätsbeschränkungen können durch die Bereitstellung interner Proxy-Network Load Balancer mit den nicht transitiven Ressourcen überwunden werden, die als Hybrid-Netzwerk-Endpunktgruppen (NEGs) verarbeitet werden. Sie können interne Proxy-Network Load Balancer vor den Dienst-Front-Ends und vor den Endpunkten bereitstellen, die über die Hybridverbindungen erreichbar sind. Die internen Proxy-Front-Ends des Netzwerk-Load-Balancers werden in VPC-Subnetzen bereitgestellt, die über cloudübergreifende Spoke-VPCs weitergegeben werden. Die internen Proxy-Network-Load-Balancer ermöglichen die Erreichbarkeit über das cloudübergreifende Netzwerk der nicht transitiven Ressourcen. Für externe Hosts und Dienste, Private Service Connect-Endpunkte und den Zugriff auf Netzwerke auf private Dienste müssen die Back-Ends als Hybrid-NEGs konfiguriert werden. Private Service Connect-Back-Ends sind das einzige Modell, bei dem die NEGs nicht hybrid sein müssen.

DNS-Infrastrukturdesign

In einer Hybridumgebung kann entweder Cloud DNS oder ein externer (lokal oder CSP)-Anbieter einen DNS-Lookup verarbeiten. Externe DNS-Server sind für externe DNS-Zonen autoritativ, Cloud DNS ist für Google Cloud-Zonen autoritativ. Die DNS-Weiterleitung muss bidirektional zwischen Google Cloud und den externen Netzwerken aktiviert sein und Firewalls müssen so eingerichtet sein, dass der DNS-Auflösungstraffic zulässig ist.

Wenn Sie für Ihre zentrale Dienst-VPC eine freigegebene VPC verwenden, in der Administratoren verschiedener Anwendungsdienstprojekte ihre eigenen Dienste instanziieren können, sollten Sie die projektübergreifende Bindung von DNS-Zonen verwenden. “ Die projektübergreifende Bindung ermöglicht die Segmentierung und Delegierung des DNS-Namespace an die Dienstprojektadministratoren.

Im Fall der Übertragung, in dem externe Netzwerke über Google Cloud mit anderen externen Netzwerken kommunizieren, sollten die externen DNS-Zonen so konfiguriert sein, dass Anfragen direkt untereinander weitergeleitet werden. Das cloudübergreifende Google-Netzwerk stellt die Konnektivität für die DNS-Anfragen und -Antworten bereit. Google Cloud DNS ist jedoch an der Weiterleitung des Traffics zur DNS-Auflösung zwischen Zonen in externen Netzwerken beteiligt. Alle im cloudübergreifenden Netzwerk erzwungenen Firewallregeln müssen den Traffic der DNS-Auflösung zwischen den externen Netzwerken zulassen.

Das folgende Diagramm zeigt, dass ein DNS-Design mit jeder der in dieser Designanleitung vorgeschlagenen Hub-and-Spoke-VPC-Konnektivitätskonfigurationen verwendet werden kann:

DNS-Design, das mit Hub-and-Spoke-Verbindungsmustern verwendet werden kann

Das obige Diagramm zeigt die folgenden Schritte im Designablauf:

  1. Lokales DNS
    Konfigurieren Sie Ihre lokalen DNS-Server so, dass sie für lokale DNS-Zonen autoritativ sind. Konfigurieren Sie die DNS-Weiterleitung (für Google Cloud-DNS-Namen), indem Sie die IP-Adresse der eingehenden Weiterleitung von Cloud DNS als Ziel angeben, die über die Serverrichtlinien-Konfiguration für eingehenden Traffic in der Hub-VPC erstellt wird. Durch diese Konfiguration kann das lokale Netzwerk Google Cloud DNS-Namen auflösen.
  2. Transit-VPC – DNS-Ausgangs-Proxy
    Bieten Sie dem lokalen Netzwerk mithilfe der Cloud Router den Google-Bereich Ausgehender DNS-Proxy 35.199.192.0/19 an. Ausgehende DNS-Anfragen von Google an die lokale Umgebung werden aus diesem IP-Adressbereich stammen.
  3. Transit-VPC – Cloud DNS
    1. Konfigurieren Sie eine Serverrichtlinie für eingehenden Traffic für eingehende DNS-Anfragen von lokalen Systemen.
    2. Konfigurieren Sie die Cloud DNS-Weiterleitungszone (für lokale DNS-Namen), die auf lokale DNS-Server abzielt.
  4. Dienst-VPC – Cloud DNS
    1. Konfigurieren Sie die DNS-Peering-Zone für Dienste (für lokale DNS-Namen), indem Sie die Hub-VPC als Peer-Netzwerk festlegen. Die DNS-Auflösung für lokale Ressourcen und Dienstressourcen erfolgt über die Hub-VPC.
    2. Konfigurieren Sie die privaten Zonen des Dienstes im Hostprojekt des Dienstes und hängen Sie die freigegebene VPC der Dienste, die freigegebene VPC der Anwendung und die Hub-VPC an die Zone an. Dadurch können alle Hosts (lokal und in allen Dienstprojekten) die DNS-Namen der Dienste auflösen.
  5. Anwendungshostprojekt – Cloud DNS
    1. Konfigurieren Sie eine App-DNS-Peering-Zone für lokale DNS-Namen, wobei die Hub-VPC als Peer-Netzwerk festgelegt wird. Die DNS-Auflösung für lokale Hosts erfolgt über die Hub-VPC.
    2. Konfigurieren Sie private DNS-Zonen im App-Host-Projekt und hängen Sie die Anwendungs-VPC, die freigegebene VPC der Dienste und die Hub-VPC an die Zone an. Mit dieser Konfiguration können alle Hosts (lokal und in allen Dienstprojekten) die App-DNS-Namen auflösen.

Weitere Informationen finden Sie unter Hybridarchitektur mit einem Hub-VPC-Netzwerk, das mit Spoke-VPC-Netzwerken verbunden ist.

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: