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

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 Ihre Google Cloud Landing-Zone 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 oder mehrere Transit-VPCs, in denen die gesamte externe Konnektivität verarbeitet wird
  • Eine oder mehrere VPCs für den Dienstzugriff, mit denen 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 VPC-Netzwerke und Subnetze, Network Connectivity Center-Hubs, VPC-Netzwerk-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 VPC-Netzwerke. 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, z. B. für die Datenübertragung 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 eine Transit-VPC, die als freigegebener Verbindungsdienst für andere VPCs dient, die über VPC-Netzwerk-Peering, Network Connectivity Center oder HA VPN verbunden sind. Aus Gründen der Übersichtlichkeit ist im Diagramm nur eine Transit-VPC dargestellt. Sie können jedoch mehrere Transit-VPCs für die Konnektivität in verschiedenen Regionen verwenden.

Transit-VPC als freigegebener Verbindungsdienst für andere VPCs

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 derGoogle 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 inGoogle Cloudgehostet 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 Alternativen zur Verwendung einer externen IP-Adresse beschrieben. Alternativ können Sie die zentralen 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 verwaltete NAT-Dienst vonGoogle 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 unter Cloud Router – Übersicht.

Um die ausgehende Verbindung zu schützen, bietet Google Cloud sowohl die Durchsetzung der Cloud Next Generation Firewall als auch den Secure Web Proxy, um eine detailliertere Filterung von 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 VPC-Netzwerken 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

Für optimale Leistung und Skalierbarkeit mit den integrierten Cloud-Netzwerkdiensten sollten VPCs über Network Connectivity Center verbunden werden, wie unter VPC-übergreifende Verbindung mit Network Connectivity Center beschrieben. Network Connectivity Center bietet Folgendes:

  • Transitiver Zugriff auf Private Service Connect-Endpunkte der Schicht 4 und Schicht 7 und die zugehörigen Dienste
  • Transitiver Zugriff auf lokale Netzwerke, die über BGP gelernt wurden
  • VPC-Netzwerk mit 250 Netzwerken pro Hub

Wenn Sie virtuelle Netzwerk-Appliances (NVAs) für Firewalling oder andere Netzwerkfunktionen einfügen möchten, müssen Sie VPC-Netzwerk-Peering verwenden. Perimeter-Firewalls können in externen Netzwerken verbleiben. Wenn das Einfügen von NVAs erforderlich ist, verwenden Sie das Muster Inter-VPC connectivity with VPC Network Peering (Inter-VPC-Verbindung mit VPC-Netzwerk-Peering), um Ihre VPCs zu verbinden.

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

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

Inter-VPC-Konnektivität mit Network Connectivity Center

Wir empfehlen, dass die Anwendungs-VPCs, Transit-VPCs und VPCs für den Dienstzugriff alle über VPC-Spokes des Network Connectivity Centers verbunden werden.

Zugriffspunkte für Dienstnutzer werden in VPCs für den Dienstzugriff bereitgestellt, wenn sie von anderen Netzwerken (anderen VPCs oder externen Netzwerken) aus erreichbar sein müssen. Sie können Dienstnutzer-Zugriffspunkte in Anwendungs-VPCs bereitstellen, wenn diese Zugriffspunkte nur von innerhalb der Anwendungs-VPC aus erreichbar sein müssen.

Wenn Sie Zugriff auf Dienste hinter dem Zugriff auf private Dienste gewähren müssen, erstellen Sie eine VPC für den Zugriff auf Dienste, die über HA VPN mit einer Transit-VPC verbunden ist. Verbinden Sie dann die VPC für verwaltete Dienste mit der VPC für den Dienstzugriff. HA VPN ermöglicht transitives Routing von anderen Netzwerken.

Das Design ist eine Kombination aus zwei Konnektivitätstypen:

  • Network Connectivity Center: stellt die Verbindung zwischen Transit-VPCs, Anwendungs-VPCs und Dienstzugriffs-VPCs her, auf denen Private Service Connect-Endpunkte gehostet werden.
  • Zwischen-VPC-Verbindungen von HA VPN: Damit stellen Sie eine transitive Konnektivität für Subnetze für den Zugriff auf private Dienste bereit, die in VPCs für den Zugriff auf Dienste gehostet werden. Diese VPCs für den Dienstzugriff sollten nicht als Spoke des Network Connectivity Center-Hubs hinzugefügt werden.

Beachten Sie beim Kombinieren dieser Verbindungstypen Folgendes:

  • Umverteilung von VPC-Netzwerk-Peering- und Network Connectivity Center-Peer-Subnetzen in dynamisches Routing (zur Services-Access-VPC über HA VPN und zu externen Netzwerken über Hybridverbindungen)
  • Überlegungen zum multiregionalen Routing
  • Weitergabe dynamischer Routen in VPC-Netzwerk-Peering und Network Connectivity Center-Peering (von der VPC für den Dienstzugriff über HA VPN und von externen Netzwerken über Hybridverbindungen)

Das folgende Diagramm zeigt eine VPC für den Zugriff auf Dienste, in der Subnetze für den Zugriff auf private Dienste gehostet werden, die über HA VPN mit der Transit-VPC verbunden sind. Das Diagramm zeigt auch die Anwendungs-VPCs, Transit-VPCs und VPCs für den Dienstzugriff, die Private Service Connect-Nutzerendpunkte hosten, die über Network Connectivity Center verbunden sind:

Allgemeine Struktur des cloudübergreifenden Netzwerks mit Network Connectivity Center-VPC-Spokes

Die im vorherigen Diagramm gezeigte Struktur enthält diese Komponenten:

  • Externes Netzwerk: 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.
  • Transit-VPC-Netzwerk: 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-VPCs: Projekte und VPC-Netzwerke, in denen verschiedene Anwendungen gehostet werden.
  • VPC des Nutzers für den Zugriff auf private Dienste: Ein VPC-Netzwerk, das zentralisierten Zugriff über den Zugriff auf private Dienste auf Dienste hostet, die von Anwendungen in anderen 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.
  • Nutzer-VPC für Private Service Connect: Ein VPC-Netzwerk, in dem Private Service Connect-Zugriffspunkte für Dienste gehostet werden, die in anderen Netzwerken gehostet werden.

Verwenden Sie das Network Connectivity Center, um die Anwendungs-VPCs mit den Cloud Interconnect-VLAN-Anhängen und HA VPN-Instanzen in den Transit-VPCs zu verbinden. Machen Sie alle VPCs zu Spokes des Network Connectivity Center-Hubs und die VLAN-Anhänge und HA VPNs zu Hybrid-Spokes desselben Network Connectivity Center-Hubs. Verwenden Sie die standardmäßige Mesh-Topologie des Network Connectivity Center, um die Kommunikation zwischen allen Spokes (VPC und Hybrid) zu ermöglichen. Diese Topologie ermöglicht auch die Kommunikation zwischen den Anwendungs-VPCs, die Cloud NGFW-Richtlinien unterliegen. Alle VPCs von Nutzerdiensten, die über HA VPN verbunden sind, dürfen keine Spokes des Network Connectivity Center-Hubs sein. Private Service Connect-Endpunkte können in Network Connectivity Center-VPC-Spokes bereitgestellt werden und erfordern keine HA VPN-Verbindung für die VPC-übergreifende Transitivität, wenn Network Connectivity Center verwendet wird.

Inter-VPC-Konnektivität mit VPC-Netzwerk-Peering

Wenn veröffentlichte Dienstnutzer-Zugriffspunkte in einer Dienstzugriffs-VPC bereitgestellt werden, empfehlen wir, dass die Anwendungs-VPCs über VPC-Netzwerk-Peering eine Verbindung zur Transit-VPC herstellen und dass die Dienstzugriffs-VPCs über HA VPN eine Verbindung zur Transit-VPC herstellen.

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

Das Design ist eine Kombination aus zwei Konnektivitätstypen:

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

Beachten Sie beim Kombinieren dieser Architekturen Folgendes:

  • Umverteilung von VPC-Peer-Subnetzen in dynamisches Routing (zur Dienstzugriffs-VPC über HA VPN und zu externen Netzwerken über Hybridverbindungen)
  • Überlegungen zum multiregionalen Routing
  • Weitergabe dynamischer Routen in VPC-Peering (von der VPC für den Dienstzugriff über HA VPN und von externen Netzwerken über Hybridverbindungen)

Das folgende Diagramm zeigt eine VPC für den Dienstzugriff, 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 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.
  • VPC für den Zugriff auf Dienste: 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 VPC-Netzwerk-Peering-Design Anwendungs-VPCs miteinander kommunizieren müssen, können Sie die Anwendungs-VPCs als VPC-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.

Die Arbeitslastsicherheit für Ost-West-Verbindungen zwischen Anwendungs-VPCs kann die Firewall der nächsten Generation verwenden.

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

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ürGoogle Cloud -Zonen autoritativ. Die DNS-Weiterleitung muss bidirektional zwischenGoogle 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 VPC für den Dienstzugriff 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 Cloudmit 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-Konnektivitätsmustern 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. VPC für Dienstzugriff – 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: