Netzwerksegmentierung und -verbindung für verteilte Anwendungen im Cross-Cloud Network

Last reviewed 2024-04-05 UTC

Dieses Dokument ist Teil einer Designanleitungsreihe für Cross-Cloud Network.

Die Reihe besteht aus folgenden Teilen:

In diesem Teil werden die Struktur der Netzwerksegmentierung erläutert, die die Grundlage des Designs bilden. In diesem Dokument werden die Phasen erläutert, in denen Sie die folgenden Entscheidungen treffen:

  • Die gesamte Netzwerksegmentierung und Projektstruktur.
  • Wo Sie Ihre Arbeitslast platzieren.
  • Wie Ihre Projekte mit externen lokalen Netzwerken und Netzwerken anderer Cloud-Anbieter verbunden sind, einschließlich des Designs für Konnektivität, Routing und Verschlüsselung.
  • Gibt an, 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 eine 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 die Google Cloud-Landingpage festlegen. Weitere Informationen zum Auswählen der Anzahl von VPC-Netzwerken finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.

Für das Cross-Cloud Network empfehlen wir die 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 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 dargestellte VPC-Struktur entweder mit einer konsolidierten oder segmentierten Projektstruktur 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 gerade beschriebener Anwendungsdienstprojekte. 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. Es können mehrere Anwendungsdienstprojekte an das Hostprojekt angehängt werden. Die Abrechnung für Netzwerkdienste erfolgt auf das Hostprojekt der Infrastruktur und die Anwendungshostprojekte. Die Infrastrukturgebühren werden dem Infrastruktur-Hostprojekt 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 mehrerer 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. Eine Anleitung zum Platzieren von Arbeitslasten finden Sie unter Best Practices für die Auswahl der Compute Engine-Regionen. 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 Cross-Cloud Network 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 die externe Konnektivität werden 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 freigegebener Konnektivitätsdienst für andere VPCs verwendet wird

Private Verbindungen zu anderen Cloud-Anbietern

Wenn Sie Dienste haben, die in den Netzwerken anderer Cloud-Dienstanbieter (Cloud Service Provider, CSP) ausgeführt werden und Sie eine Verbindung zu Ihrem Google Cloud-Netzwerk herstellen möchten, können Sie über das Internet oder private Verbindungen eine Verbindung zu ihnen 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 basierend auf der Nähe des Standorts zu den Zielregionen die Standorte aus, an denen Sie eine Verbindung zu den anderen CSPs herstellen. 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 (die 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.

Zur Maximierung 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 unter Cross-Cloud Interconnect-Hochverfügbarkeit, 99,99 % Verfügbarkeit für Dedicated Interconnect einrichten und 99,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 Optionen für Hybridkonnektivität verwenden:

  • Dedicated Interconnect
  • Partner Interconnect
  • HA VPN

Das Routing für diese Verbindungen ähnelt dem 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 an der Grenze zwischen den Domains eine Flusssymmetrie erforderlich.

Bei Netzwerken, die Daten über mehrere Regionen hinweg übertragen, können die Kosten und das Dienstqualitätsniveau der einzelnen Netzwerke erheblich variieren. 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 an interregionale Übertragung, Trafficsymmetrie, Durchsatz und 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 Ihrer CSP.

Domainübergreifendes Routing in einer Region

Wir empfehlen, mit dem domainübergreifenden Routing in einer Region zu beginnen, auf dem Sie aufbauen, um mehrere regionale Verbindungen mit domainübergreifendem Routing 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 zu aggregieren und sie 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.
  • Durch Aktiv/Passiv wird eine Verbindung als Bereitschaftszustand erzwungen. Traffic wird nur übernommen, wenn die aktive Verbindung unterbrochen wird.

Wir empfehlen ein Aktiv/Aktiv-Design für intraregionale Verbindungen. Für bestimmte lokale Netzwerktopologien in Kombination mit zustandsorientierten Sicherheitsfunktionen kann jedoch ein Aktiv/Passiv-Design erforderlich sein.

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-Routingfunktionen bietet.

Die Flusssymmetrie ist nicht immer obligatorisch, aber sie kann Probleme mit zustandsorientierten Sicherheitsfunktionen verursachen.

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 ursprünglichen Netzwerk, bis er in die Region gelangt, 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 wird 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 in der Übersicht zu 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 bereitzustellen. 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 in der Übersicht zu 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. Das Design eines VPC-Netzwerks ist unabhängig von ihrer Fähigkeit, eingehende Internetverbindungen 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 erstellen beschrieben. Alternativ können Sie die zentrale NGFW NVAs verwenden, wie unter Netzwerksicherheit beschrieben.

Der Hauptpfad für die Bereitstellung ausgehender Internetverbindungen ist das Ziel des Standard-Internetgateways in der VPC-Routingtabelle. Dies ist in Google VPCs häufig die Standardroute. Sowohl externe IP-Adressen als auch Cloud NAT (der verwalteter NAT-Dienst von Google Cloud) erfordern einen Routenverweis auf das Standard-Internetgateway der VPC. Daher müssen VPC-Routingdesigns, die die Standardroute überschreiben, ausgehende Verbindungen auf andere Weise bereitstellen. Weitere Informationen finden Sie unter 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 Google-eigene IPv4-Adressen für die Internetverbindung oder Bring your own IP-Adressen (BYOIP) verwenden, um einen IPv4-Bereich Ihrer Organisation zu nutzen. 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 verbessert die Übertragbarkeit von Konnektivität und kann Kosten für IP-Adressen sparen.

Interne Konnektivität und VPC-Netzwerk

Wenn der externe und Hybridkonnektivitätsdienst konfiguriert ist, können Ressourcen in der Transit-VPC die externen Netzwerke erreichen. Im nächsten Schritt stellen Sie diese Verbindung für die Ressourcen zur Verfügung, die in anderen VPCs gehostet werden.

Das folgende Diagramm zeigt die allgemeine VPC-Struktur, unabhängig davon, wie Sie externe Verbindungen 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 die externe Konnektivität teilen können. Darüber hinaus dient 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 DNS-Infrastrukturdesign.

Für eine bessere Leistung und integrierte Cloud-Netzwerkdienste empfehlen wir, statt HA VPN VPCs über Cloud-übergreifendes Netzwerk- oder VPC-Netzwerk-Peering zu verbinden.

Private Service Connect-Endpunkte und Front-Ends für den Zugriff auf private Dienste sind über VPC-Netzwerk-Peering oder Cross-Cloud Network 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 die Inter-VPC-Konnektivität zu einem niedrigeren Durchsatz und einem höheren operativen Aufwand führen kann, reduziert das Design der zentralisierten Dienste die Spanne der HA VPN-Bereitstellung.

Alternativ können Sie eine inter-VPC-transitive Konnektivität zu veröffentlichten Dienstendpunkten implementieren, indem Sie vor den Dienstendpunkten einen internen Proxy-Network Load Balancer platzieren. Bei diesem Ansatz müssen einige Einschränkungen berücksichtigt werden. Diese werden im Abschnitt Konnektivität mit Network Connectivity Center-Spokes, die Load Balancing verwenden erläutert.

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 den Zugriff auf freigegebene Dienste

Wenn veröffentlichte Dienstendpunkte in einer Dienst-VPC bereitgestellt werden, empfehlen wir, dass die Anwendungs-VPCs über VPC-Netzwerk-Peering eine Verbindung zum Hub (Transit-VPC) herstellen und dass die Dienst-VPC wird über HA VPN mit dem Hub verbunden.

Bei diesem Design ist die Transit-VPC der Hub und Sie stellen die Nutzerzugriffspunkte für private Dienstendpunkte in einer Dienst-VPC bereit.

Das Design ist eine Kombination aus zwei Konnektivitätstypen:

  • VPC-Netzwerk-Peering: stellt die Verbindung zwischen der Hub-VPC und den Anwendungs-VPCs her.
  • Zwischen-VPC-Verbindungen von HA VPN: Damit stellen Sie eine tran sitive Konnektivität für die Dienst-VPC zum Hub bereit.

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

Beachten Sie beim Kombinieren dieser Architekturen Folgendes:

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

Das folgende Diagramm zeigt eine Dienst-VPC, die über HA VPN mit der Transit-VPC verbunden ist, und die Anwendungs-VPCs, die per 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 gezeigte Struktur enthält diese 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, das mindestens ein VPC-Netzwerk hostet, 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.
  • App-Hostprojekte 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 eine Verbindung zwischen allen VPCs im Network Connectivity Center-Hub her. Untergruppen der Kommunikation können mithilfe mehrerer Network Connectivity Center-Hubs erstellt werden. Alle Kommunikationseinschränkungen, die zwischen Endpunkten innerhalb eines bestimmten Hubs erforderlich sind, können mithilfe von Firewallrichtlinien erreicht werden.

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

Dieses Muster umfasst alle VPCs als Spokes in einem Network Connectivity Center-Hub und kann bis zu 250 verbundene VPCs aufnehmen. Ein Network Connectivity Center-Hub ist ein Konstrukt der Verwaltungsebene, das eine vollständige Mesh-Verbindung der Datenebene zwischen allen VPC-Netzwerken erstellt, die als Spokes beim Network Connectivity Center-Hub registriert sind. Das Muster ermöglicht eine beliebige Verbindung und ermöglicht die Bereitstellung von Zugangspunkten für verwaltete Dienste in jeder VPC.

Zur Überwindung von Transitivitätsbeschränkungen wird über interne Proxy-Network Load Balancer auf Zugangspunkte auf verwaltete Dienste und Hybridverbindungen zugegriffen. Die Arbeitslastsicherheit für Ost-West-Verbindungen kann die Firewall der nächsten Generation 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 anwenden:

  • Sie können NVAs nicht für Perimeter-Firewalls mit diesem Muster 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 im Proxy-Load Balancer ein zusätzliches Front-End. Dieses zusätzliche Frontend verbreitet zusätzliche Einträge im DNS und erfordert Split-DNS-Lookups.
  • Layer 4-Dienste benötigen für jeden neuen Dienst einen neuen internen Proxy-Network Load Balancer. Je nach 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 Layer 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 des Network Connectivity Center als Verwaltungsebene für die Cloud Interconnect-Verbindungen. Außerdem wird ein VPC-Hub des Network Connectivity Centers 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 Übertragungsfähigkeit

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

  • Private Service Connect-Dienstendpunkte und Front-Ends von verwalteten Diensten.
  • Netzwerke hinter Hybridverbindungen (Cloud Interconnect oder HA VPN), da dynamische Routen nicht über ein Cross-Cloud Network 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-Frontends und vor den Endpunkten bereitstellen, die über die Hybridverbindungen erreichbar sind. Die internen Proxy-Front-Ends des Network 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 Cross-Cloud Network 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-Backends 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 (lokaler 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 Traffic zur DNS-Auflösung 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. Durch die projektübergreifende Bindung wird die Segmentierung und Delegierung des DNS-Namespace an die Dienstprojektadministratoren aktiviert.

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 Cross-Cloud Network von Google 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 Cross-Cloud Network 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 lokale Standorte stammen aus diesem IP-Adressbereich.
  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: