NCC Cross-Cloud Network mit NVAs und regionalem Failover

Last reviewed 2026-08-24 UTC

Dieses Dokument enthält eine Referenzarchitektur, mit der Sie eine Hybrid- oder Cross-Cloud-Netzwerk-Hub-and-Spoke-Netzwerktopologie bereitstellen können, in der Netzwerk-Appliances (Network Virtual Appliances, NVAs) verwendet werden, um Traffic innerhalb Google Cloud oder mit Netzwerken außerhalbGoogle Cloudweiterzuleiten.

Dieses Dokument richtet sich an Netzwerkadministratoren, die Netzwerkkonnektivität aufbauen, und an Cloud-Architekten, die die Bereitstellung von Arbeitslasten planen. In diesem Dokument wird davon ausgegangen, dass Sie über grundlegende Kenntnisse in den Bereichen Routing, BGP-Protokoll, Internetverbindung und NVA-Software verfügen, die Sie bereitstellen möchten.

Das Design unterstützt mehrere Remote-Verbindungen zu lokalen oder CSP-Standorten (Cloud Service Provider) und mehrere VPC-Netzwerke (Virtual Private Cloud) für Arbeitslasten. Der Schwerpunkt liegt auf der Erstellung einer leistungsstarken, resilienten und multiregionalen Bereitstellung, die regionale Affinität und regionenübergreifendes Failover durch dynamisches Routing bietet. Das dynamische Routing basiert auf BGP und ermöglicht die vollständig automatisierte Erkennung und Wiederherstellung von NVA-Unterbrechungen. Bei diesem Design werden NVAs in allen Flows von Google Cloud zu lokalen oder anderen CSPs platziert und NVAs zwischen VPC-Netzwerken für Arbeitslasten.

Wenn Sie NVAs in Ihr Netzwerk einbinden, ist diese Architektur für die folgenden Designanforderungen geeignet:

  1. Regionsübergreifendes NVA-Failover unterstützen: Automatische Erkennung von NVA-Routingfehlern in einer Region und Weiterleitung des Traffics an NVAs in einer nahegelegenenGoogle Cloud -Region nach Bedarf.
  2. Regionale Affinität beibehalten: Das Routing sollte innerhalb von Google Cloud Regionen erfolgen, um Latenz und Datenübertragungskosten zu reduzieren, sofern kein Fehler auftritt. Der Traffic wird nur bei einem Fehler an Remoteregionen oder Hybridverbindungen weitergeleitet.

Dieses Design bietet kein symmetrisches Routing über NVAs hinweg, es sei denn, Sie konfigurieren es mit Optionen, die später im Abschnitt Skalierbarkeit beschrieben werden. Wenn symmetrisches Routing für Ihr Design wichtiger ist als regionales Failover und lokale Traffic-Affinität, lesen Sie VPC-Netzwerk-Peering – Cross-Cloud Network mit NVAs und regionaler Affinität.

Architektur

Das folgende Diagramm zeigt die in dieser Architektur verwendeten Komponenten. Das Diagramm zeigt nur zwei Regionen, das Design kann aber auf zusätzliche Regionen ausgeweitet werden.

CCN-Bereitstellung mit Routing- und Transit-VPC-Netzwerken, die über NVAs verbunden sind.

Architekturkomponenten

Die obige Beispielarchitektur enthält die folgenden Komponenten:

Externes Netzwerk (lokales Netzwerk oder Netzwerk eines anderen CSP)

Das externe Netzwerk kann lokal oder in einem anderen CSP sein. Sie hostet die Clients von Anwendungen, die in den VPC-Netzwerken der Arbeitslast ausgeführt werden. Im externen Netzwerk können auch Anwendungen gehostet werden, aber die NVAs verarbeiten nur Traffic, der zu oder von einem VPC-Netzwerk für Arbeitslasten gesendet wird.

Im Diagramm verbindet Cloud Interconnect das externe Netzwerk mit dem Routing-VPC-Netzwerk. Diese Architektur unterstützt auch die Verwendung von Cloud VPN anstelle von Cloud Interconnect. Das externe Netzwerk verwendet Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel, um eine Verbindung zu NCC-Hub 1 als Hybrid-Spokes herzustellen.

Routing-VPC-Netzwerk

Das Routing-VPC-Netzwerk wird über Cloud Interconnect oder Cloud VPN mit externen Netzwerken verbunden. Sie stellt über NVAs mit mehreren NICs eine Verbindung zum Transit-VPC-Netzwerk her.

Traffic, der zwischen dem Routing-VPC-Netzwerk und dem Transit-VPC-Netzwerk übertragen wird, muss über die NVAs geleitet werden. Cloud Router im Routing-VPC-Netzwerk tauschen Routen mit den Routern des externen Netzwerks und mit den NVA-NICs aus, die mit dem Routing-VPC-Netzwerk verbunden sind.

Transit-VPC-Netzwerk

Das VPC-Transit-Netzwerk wird über NVAs mit mehreren NICs mit dem Routing-VPC-Netzwerk verbunden. Über dieses Netzwerk wird der Traffic zwischen dem Routing-VPC-Netzwerk und den VPC-Netzwerken für Arbeitslasten weitergeleitet.

Das Transit-VPC-Netzwerk leitet auch Traffic von Arbeitslast-VPC-Netzwerken an die NVAs und dann zurück an die Arbeitslast-VPC-Netzwerke für Arbeitslast-Arbeitslast-Traffic weiter.

Cloud Router im Netzwerk tauschen Routen mit den NVA-NICs aus, die mit dem Transitnetzwerk verbunden sind.

NVAs

NVAs mit mehreren NICs werden paarweise in mehrerenGoogle Cloud -Regionen bereitgestellt. Jede NVA hat eine NIC, die mit dem Routing-VPC-Netzwerk verbunden ist, und eine weitere NIC, die mit dem Transit-VPC-Netzwerk verbunden ist. NVAs leiten Traffic zwischen den beiden Netzwerken weiter und können andere Funktionen wie die Traffic-Prüfung bereitstellen.

In der Architektur muss der Traffic zwischen den VPC-Netzwerken für Arbeitslasten die NVAs durchlaufen. In dieser Architektur haben NVAs mindestens zwei NICs: Eine NIC ist mit dem Routing-VPC-Netzwerk und eine andere mit dem Transit-VPC-Netzwerk verbunden. Die Architektur kann optional zusätzliche NICs für die Verwaltung oder für die Verbindung mit zusätzlichen Netzwerken unterstützen.

NCC-Hub 1

Dieser NCC-Hub bietet Konnektivität zwischen den Hybridverbindungen des externen Netzwerks und den NVA-NICs, die mit dem Routing-VPC-Netzwerk verbunden sind.

Der Hub ist in einer Mesh-Topologie konfiguriert, die die folgenden Arten von Hybrid-Spokes umfasst: Router-Appliance-Spokes, Cloud VPN-Spokes und Cloud Interconnect-VLAN-Anhang-Spokes.

NVA-NICs, die an das VPC-Routingnetzwerk angehängt sind, werden dem Hub als Router-Appliance-Spokes hinzugefügt. Bis zu acht NVAs können als einzelner Spoke hinzugefügt werden.

VPC-Netzwerke der Arbeitslast

In den VPC-Netzwerken der Arbeitslast werden Anwendungen gehostet, auf die von Clients im externen Netzwerk oder von Clients in anderen VPC-Netzwerken der Arbeitslast zugegriffen werden kann. In VPC-Netzwerken für Arbeitslasten können auch Private Service Connect-Endpunkte gehostet werden, auf die von anderen Netzwerken aus zugegriffen werden kann.

Arbeitslast-VPC-Netzwerke sind als VPC-Spokes auf NCC-Hub 2 konfiguriert. Die VPC-Netzwerke für Arbeitslasten sind über NCC-Hub 2 mit den NVA-NICs im Transit-VPC-Netzwerk verbunden. Traffic, der ein VPC-Netzwerk für Arbeitslasten verlässt, wird unabhängig vom endgültigen Ziel des Traffics an NVAs weitergeleitet.

NCC-Hub 2

Dieser NCC-Hub bietet eine Verbindung zwischen VPC-Netzwerken von Arbeitslasten und den NVA-Schnittstellen der Router-Appliance im Transit-VPC-Netzwerk.

Der Hub ist in Sterntopologie mit den folgenden Spokes konfiguriert:

  • Die NVA-Schnittstellen im Transit-VPC-Netzwerk sind als Router-Appliance-Spokes in einer Center-Spoke-Gruppe konfiguriert.
  • Die Arbeitslast-VPC-Netzwerke sind als VPC-Spokes in einer Edge-Spoke-Gruppe konfiguriert.

Der Traffic zu und von VPC-Netzwerken für Arbeitslasten muss über die NVAs geleitet werden.

Trafficabläufe

In den folgenden Abschnitten werden normale Traffic-Flüsse gezeigt, wenn alle NVAs und Verbindungen zu externen Netzwerken funktionieren, sowie Failover-Traffic-Flüsse, wenn Verbindungen oder NVAs in einer Region ausgefallen sind.

Normale Trafficflüsse

Das folgende Diagramm zeigt Trafficflüsse, wenn NVAs und Verbindungen zu externen Netzwerken aktiv sind und funktionieren:

Diagramm, das zeigt, wie Flows für Region A über Region B ein Failover ausführen.

Wenn alles korrekt funktioniert, bleibt der regionale Traffic in seiner Region:

  1. BGP-Messwerte halten den lokalen Traffic (Region A zu Region A oder Standort A) innerhalb der Region aufrecht, sodass keine Ressourcen- oder Routen-Tagging erforderlich ist.
  2. In dieser Architektur werden die NVAs so positioniert, dass sie den Traffic zwischen den VPC-Netzwerken der Arbeitslasten und zwischen den VPC-Netzwerken der Arbeitslasten und dem externen Netzwerk verarbeiten.

In der folgenden Liste werden die im Diagramm dargestellten Trafficflüsse beschrieben:

  • Externes Netzwerk zu VPC-Netzwerk für Arbeitslasten
    • Der Traffic folgt Routen über die Cloud Interconnect-Verbindungen zum Routing-VPC-Netzwerk. Die Routen werden vom Cloud Router über den Hub des Network Connectivity Center an die NVA angekündigt.
    • Im Routing-VPC-Netzwerk wird der Traffic über dynamische Routen, die von der NVA ermittelt wurden, an die NIC der aktiven NVA weitergeleitet. Der Traffic folgt Routen über die NVA zu ihrer anderen NIC, die den Traffic an das Transit-VPC-Netzwerk weiterleitet. Der Traffic folgt Routen über NCC-Peerings zum VPC-Netzwerk des Ziel-Workloads.
  • VPC-Netzwerk für Arbeitslasten zu Externes Netzwerk
    • Der Traffic folgt Routen, die über das NCC-Peering zur NVA vom NCC-Hub 2 ermittelt werden. Die aktive NVA wird über die Netzwerkkarte aufgerufen.
    • Der Traffic folgt Routen über die NVA zu ihrer anderen NIC, die den Traffic an das Routing-VPC-Netzwerk weiterleitet. Der Traffic folgt Routen, die im Routing-VPC-Netzwerk für die VLAN-Anhänge und das Remote-Netzwerk programmiert sind.
  • VPC-Netzwerk für Arbeitslasten zu VPC-Netzwerk für Arbeitslasten
    • Der Traffic folgt Routen, die über das NCC-Peering zur NVA vom NCC-Hub 2 ermittelt werden. Es gelangt über die NIC in der Transit-VPC in die NVA.
    • Wenn es mehr als eine aktive NVA gibt, wird über BGP-Messwerte festgelegt, welche NVA der nächste Hop ist. Der Traffic folgt den Routen, die von NCC-Hub 2 ermittelt wurden, zurück über dieselbe NIC und über das NCC-Peering zum anderen Arbeitslast-VPC-Netzwerk.

Failover-Trafficflüsse

Das folgende Diagramm zeigt die Trafficflüsse, wenn alle NVAs in einer Region ausgefallen sind:

Diagramm, das zeigt, wie Flows für Region A über Region B ein Failover ausführen.

Bei einem Totalausfall aller NVAs in einer Region leitet das System den Traffic automatisch über fehlerfreie NVAs in der nächstgelegenen Remote-Region um. Diese Architektur ist auch gegen Ausfälle von Hybridverbindungen in einer Region resistent.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:

  • Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPC.
  • Network Connectivity Center: Ein Orchestrierungs-Framework, das Netzwerkverbindungen zwischen Spoke-Ressourcen vereinfacht, die mit einer zentralen Verwaltungsressource verbunden sind, die als Hub bezeichnet wird.
  • Cloud Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
  • Cloud VPN: Ein Dienst, mit dem Sie Ihr Peer-Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen können.
  • Cloud Router: Ein verteiltes und vollständig verwaltetes Angebot, das BGP-Speaker- und Responder-Funktionen (Border Gateway Protocol) bietet. Cloud Router funktioniert mit Cloud Interconnect, Cloud VPN und Router-Appliances, um dynamische Routen in VPC-Netzwerken basierend auf BGP-empfangenen und benutzerdefinierten Routen zu erstellen.
  • Compute Engine: Ein sicherer und anpassbarer Computing-Dienst, mit dem Sie virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.

Designalternativen

Je nach Bedarf können Sie zwischen den folgenden Designalternativen wählen:

  • Diese Architektur bietet keinen zentralen Zugriff für bestimmte Anwendungen. Wenn Sie zentralisierten Zugriff hinzufügen möchten, können Sie ein VPC-Netzwerk für den Dienstzugriff konfigurieren, wie unter Cross-Cloud-Netzwerk für verteilte Anwendungen beschrieben.
  • Bei diesem Design wird davon ausgegangen, dass VPC-Netzwerke auf mehrere Google Cloud Projekte verteilt sind. Je nach Ihrer Projektzuweisungsstrategie können Sie Ihre VPC-Netzwerke jedoch in einem einzelnen Projekt bereitstellen.

Designaspekte

In diesem Abschnitt werden Designfaktoren, Best Practices und Designempfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, Skalierbarkeit und Leistung entspricht.

Sicherheit und Compliance

Im Folgenden finden Sie Designaspekte und Empfehlungen für das Entwerfen einer Topologie in Google Cloud , die die Sicherheits- und Compliance-Anforderungen Ihrer Arbeitslast erfüllt:

Zuverlässigkeit

Im Folgenden finden Sie Designaspekte und Empfehlungen zum Entwerfen einer Topologie in Google Cloud , die den Zuverlässigkeitsanforderungen Ihrer Arbeitslast entspricht:

Skalierbarkeit

In diesem Abschnitt werden Designüberlegungen und Empfehlungen zum Entwerfen einer Topologie in Google Cloud beschrieben, die die Skalierbarkeitsanforderungen Ihrer Arbeitslast erfüllt.

Wenn Ihr Design nicht von symmetrischem Routing abhängt, können Sie skalieren, indem Sie weitere NVA-Knoten hinzufügen.

Wenn für Ihr Design symmetrisches Routing erforderlich ist, können Sie je nach den Funktionen, die von Ihrer NVA-Software angeboten werden, die folgenden Optionen in Betracht ziehen:

  • Verwenden Sie BGP-Attribute, um einen einzelnen aktiven NVA-Knoten pro Region zu verwalten, aber passen Sie die Größe der VM an Ihren Traffic an.
  • Verwenden Sie die Funktionen des Anbieters, um Quell-NAT auf den NVAs zu konfigurieren.
  • Wenn Ihr Anbieter dies unterstützt, können Sie die Sitzungssynchronisierung über Knoten hinweg einrichten.
  • Nutzen Sie BGP-Traffic-Engineering-Optionen (z. B. BGP-Routenrichtlinien), um die Aktiv/Standby-Konfiguration pro Flow zu konfigurieren. Sie können beispielsweise bestimmte Netzwerke so konfigurieren, dass NVA-A gegenüber NVA-B bevorzugt wird, und die Einstellungen für andere Netzwerke umkehren.

Leistungsoptimierung

Im Folgenden finden Sie Designaspekte und Empfehlungen für die Entwicklung einer Topologie in Google Cloud , die die Leistungsanforderungen Ihrer Arbeitslast erfüllt:

  • Sie können die Netzwerkleistung möglicherweise verbessern, indem Sie die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) Ihrer Netzwerke und Verbindungen erhöhen. Weitere Informationen finden Sie unter Maximale Übertragungseinheit.
  • Um die Konvergenzzeit zu verkürzen, sollten Sie nach Möglichkeit BGP BFD verwenden, um die Erkennung und Behebung von BGP-Ereignisunterbrechungen zu beschleunigen. BFD wird nicht in BGP-Sitzungen unterstützt, die für Cloud VPN-Tunnel oder für NVAs konfiguriert sind, die als Router Appliance-Spokes konfiguriert sind.

Bereitstellung

Führen Sie die folgenden Schritte aus, um diese Referenzarchitektur bereitzustellen:

  1. Google Cloud Regionen identifizieren.
  2. Projektstruktur entwerfen und erstellen:
  3. Zuweisung von IP-Adressen planen
  4. Routing-VPC-Netzwerk erstellen
  5. Verbindungen zum externen Netzwerk erstellen:
  6. Transit- und Arbeitslast-VPC-Netzwerke erstellen
  7. NVAs erstellen
  8. NCC-Hub 1 erstellen
  9. NCC-Hub 2 erstellen
  10. Privaten Zugriff auf Google APIs hinzufügen
  11. Zentralen Internet-Ingress und ‑Egress einrichten
  12. Konnektivität zu Arbeitslasten testen

Google Cloud Regionen identifizieren

Im Allgemeinen sollten Sie die Konnektivität, VPC-Subnetze undGoogle Cloud -Arbeitslasten in der Nähe Ihrer lokalen Netzwerke oder anderer Cloud-Clients platzieren. Weitere Informationen zum Platzieren von Arbeitslasten finden Sie unter Google Cloud Region Picker und Best Practices für die Auswahl der Compute Engine-Regionen.

Wir empfehlen, mindestens zwei Regionen für das Hosting von NVAs auszuwählen, um von der regionenübergreifenden Failover-Unterstützung dieser Architektur zu profitieren.

Projektstruktur entwerfen und erstellen

Erstellen oder identifizieren Sie die Projekte, in denen Sie Ihre VPC-Netzwerke erstellen möchten. Sie benötigen die folgenden Projekte:

IP-Adresszuweisung planen

Erstellen Sie einen Plan für die Zuweisung von IP-Adressen für die erforderlichen Netzwerke. Um die VPC-Netzwerkadressen von Arbeitslasten einfacher zusammenzufassen, sollten Sie ihre Adressbereiche aus einem einzelnen größeren Bereich auswählen. Wir empfehlen, einen großen Supernetzbereich (z. B. /12) für die Netzwerkzuweisungen der VPC für Arbeitslasten zuzuweisen.

Ihr Plan sollte IP-Bereiche für die folgenden Netzwerke enthalten:

  • Externe Netzwerke
  • Routing-VPC-Netzwerk
  • Transit-VPC-Netzwerk
  • Ein aggregierter Bereich für alle Arbeitslast-VPC-Netzwerke

Routing-VPC-Netzwerk erstellen

Das Routing-VPC-Netzwerk hostet die folgenden Komponenten:

  • Hybridverbindungen zu externen Netzwerken.
  • Eine NIC von jeder NVA. In den Diagrammen ist diese NIC als „nic 0“ gekennzeichnet.
  • Ein Cloud Router pro Region.

Gehen Sie beim Erstellen des Routing-VPC-Netzwerk so vor:

  1. Erstellen Sie im Projekt, in dem sich Ihr Routing-VPC-Netzwerk befinden soll, das Routing-Netzwerk als globales VPC-Netzwerk im benutzerdefinierten Modus mit aktiviertem globalen dynamischen Routing. Globales dynamisches Routing ist für regionsübergreifendes Routing erforderlich.
  2. Erstellen Sie im Routing-Netzwerk ein einzelnes Subnetz pro Region. In diesen Subnetzen werden NVA-Schnittstellen gehostet, die für das private Routing zu externen Netzwerken und optional für die Kommunikation mit dem Internet verwendet werden.
  3. Erstellen Sie einen Cloud Router in jeder Region. Der Cloud Router verarbeitet BGP zwischen dem VPC-Netzwerk und dem externen Netzwerk für diese Region. Wir empfehlen, NVAs und Arbeitslast-VPC-Netzwerke in derselben Region wie die Hybridverbindung zu erstellen, um lokales Routing zwischen den Hybridverbindungen und den Arbeitslasten über die NVAs zu ermöglichen.
    • Wenn Sie NVAs und Arbeitslastnetzwerke in derselben Region erstellen, benötigen Sie nur einen Cloud Router, der in dieser Region bereitgestellt wird.
    • Wenn Sie NVAs in einer Region und VPC-Netzwerke für Arbeitslasten in einer anderen Region erstellen, benötigen Sie in jeder dieser Regionen einen Cloud Router.

Verbindungen zum externen Netzwerk herstellen

Bei diesem Design wird empfohlen, Cloud Interconnect zu verwenden, um Ihr externes Netzwerk mit Ihrem Google Cloud Routing-VPC-Netzwerk zu verbinden. Sie können jedoch ein anderes Verbindungsprodukt auswählen. Weitere Informationen finden Sie unter Network Connectivity-Produkt auswählen.

Richten Sie die Verbindung zwischen den externen Netzwerken (lokal und andere Clouds) und Ihrem Routing-VPC-Netzwerk ein. Wir empfehlen, für Produktionsarbeitslasten ein SLA mit 99,99% Verfügbarkeit anzustreben und die Best Practices von Google beim Einrichten der Verbindung zu befolgen.

Wenn Sie Hybridverbindungen zum externen Netzwerk konfigurieren und für zusätzliche Kundennetzwerke Routing von und zu Remote-Standorten erforderlich ist, bewerben Sie deren Subnetze als benutzerdefinierte Route Advertisements.

Transit- und Arbeitslast-VPC-Netzwerke erstellen

Die Aufgabe des Transit-VPC-Netzwerk besteht darin, die NVAs mit den VPC-Netzwerken der Arbeitslast zu verbinden.

  1. Erstellen Sie im Projekt, in dem sich Ihr Transitnetzwerk befinden soll, das Transitnetzwerk als globales VPC-Netzwerk im benutzerdefinierten Modus mit globalem dynamischen Routing. Globales dynamisches Routing ist für regionsübergreifendes Routing erforderlich.
  2. Erstellen Sie ein einzelnes Subnetz pro Region, um NVA-Schnittstellen zu hosten, die für das private Routing zu VPC-Netzwerken für Arbeitslasten verwendet werden.
  3. Konfigurieren Sie einen Cloud Router in jeder Region, in der Sie NVAs bereitstellen möchten.
  4. Erstellen Sie nach Bedarf VPC-Netzwerke für Arbeitslasten.

NVAs erstellen

Informationen zum Bereitstellen einer NVA, die im Google Cloud Marketplace aufgeführt ist, finden Sie in der Dokumentation des NVA-Anbieters. Beachten Sie beim Konfigurieren Ihrer NVAs für dieses Design die folgenden Richtlinien:

  1. Stellen Sie NVAs paarweise in mindestens zwei Regionen bereit, um eine multiregionale Ausfallsicherheit zu erreichen. Da NVAs als Router-Appliance-Spokes von Network Connectivity Center hinzugefügt werden, müssen Sie sie nicht in Instanzgruppen konfigurieren.
  2. NVA-VMs benötigen mindestens zwei NICs, einige Anbieter erfordern jedoch eine dedizierte NIC für die Verwaltung. Fügen Sie die NICs hinzu, die für die Unterstützung der Anbieteranforderungen erforderlich sind.
  3. Um ein symmetrisches Routing über eine einzelne aktive NVA zu gewährleisten, müssen die NVAs BGP-Messwerte wie MEDs festlegen, um Routenpräferenzen für NVAs in der Region zu ermöglichen. Wir empfehlen, niedrige MED-Werte zu verwenden, z. B. 10 für primäre und 20 für sekundäre. Da Google Cloud ein regionales Gewicht für Remote-Netzwerke hinzufügt, müssen Sie keine MEDs für die regionsübergreifende Bevorzugung festlegen. Weitere Informationen dazu, wie Sie für eine symmetrische Weiterleitung sorgen, finden Sie weiter oben in diesem Dokument im Abschnitt „Skalierbarkeit“.
  4. Wenn Sie die VPC-Subnetzbereiche der Arbeitslast als aggregierte oder zusammengefasste Supernetzroute bewerben möchten, konfigurieren Sie BGP auf der NVA-NIC, die mit dem Transitnetzwerk verbunden ist. Diese Route ist erforderlich, um die VPC-Kommunikation zwischen Arbeitslasten über die NVAs zu ermöglichen. Konfigurieren Sie NVAs so, dass alle für den Cloud Router sichtbaren Subnetze beworben werden.

NCC-Hub 1 erstellen

Die Rolle des ersten NCC-Hubs in diesem Design besteht darin, dynamische Routenankündigungen zwischen Hybridverbindungen und den NVAs zu ermöglichen. Beachten Sie beim Konfigurieren Ihres NCC-Hubs die folgenden Richtlinien:

  1. Konfigurieren Sie den NCC-Hub in einer Mesh-Topologie, damit alle Spokes direkt miteinander kommunizieren können.
  2. Fügen Sie dem Hub Hybridverbindungen (VLAN-Anhänge oder VPN) als Hybrid-Spokes hinzu.
    • Aktivieren Sie die Site-to-Site-Datenübertragung. Informationen zu unterstützten Standorten finden Sie unter Standorte, die für die Datenübertragung unterstützt werden.
    • Aktivieren Sie die Option Export von IPv4-Subnetzbereichen vom Spoke zum Hub einschließen.
    • Aktivieren Sie die Option Alle IPv4-Bereiche in Import vom Hub zum Spoke einschließen.
  3. Ermitteln Sie die NVA-NICs, die mit dem VPC-Routingnetzwerk verbunden sind, und fügen Sie sie dann NCC-Hub 1 als Router-Appliance-Spokes hinzu.
    • Aktivieren Sie die Site-to-Site-Datenübertragung.
    • Aktivieren Sie die Option Export von IPv4-Subnetzbereichen vom Spoke zum Hub einschließen.
    • Aktivieren Sie die Option Alle IPv4-Bereiche in Import vom Hub zum Spoke einschließen.
  4. Um die Ausfallsicherheit zu gewährleisten, sollten Sie beim Konfigurieren von Router-Appliances BGP-Sitzungen zu beiden Schnittstellen des Cloud Router erstellen.

NCC-Hub 2 erstellen

Der zweite NCC-Hub ermöglicht dynamisches Route Advertisement zwischen den NVAs und den VPC-Netzwerken der Arbeitslast. Dazu fügen Sie die NVA-NICs als Router-Appliance-Spokes und die Arbeitslast-VPC-Netzwerke als VPC-Spokes hinzu.

  1. Konfigurieren Sie den NCC-Hub in einer Stern-Topologie, damit der Traffic zwischen den Arbeitslast-VPC-Spokes über das Transit-VPC-Netzwerk (den Hub) geleitet werden muss.
  2. Fügen Sie NVAs als Router-Appliance-Spokes zur Center-Gruppe des Hubs hinzu.
    1. Site-to-Site-Datenübertragungen aktivieren.
    2. Aktivieren Sie die Option Alle IPv4-Bereiche in Export vom Spoke zum Hub einschließen.
    3. Aktivieren Sie die Option IPv4-Bereiche in Import vom Hub zum Spoke einschließen.
  3. Fügen Sie der Edge-Gruppe VPC-Spokes für Arbeitslasten hinzu.
  4. Um die Ausfallsicherheit zu gewährleisten, sollten Sie beim Konfigurieren von Router-Appliance-Spokes BGP-Sitzungen für beide Schnittstellen des Cloud Router erstellen.

Privaten Zugriff auf Google APIs und Google-Dienste hinzufügen

Wenn Ihre Anwendungen nicht auf Google-APIs zugreifen müssen, können Sie diesen Abschnitt bei der ersten Bereitstellung überspringen und mit Zentralen Internetzugang einrichten fortfahren.

Es gibt zwei Optionen, um den privaten Zugriff auf Google APIs und Google-Dienste zu aktivieren, je nach Anforderungen an Protokollierung und Sichtbarkeit. Weitere Informationen zu diesen Diensten finden Sie unter Arten von Google Cloud-Diensten.

Direktes Routing zu Private Service Connect-Diensten (nicht über die NVAs)

  1. Erstellen Sie in jedem VPC-Netzwerk einen Private Service Connect-Endpunkt für Google APIs.
  2. Erstellen Sie in jedem VPC-Netzwerk für Arbeitslasten, das Dienstzugriff benötigt, einen Private Service Connect-Endpunkt für von Google veröffentlichte Dienste.
  3. Wenn Sie den Zugriff über das externe Netzwerk ermöglichen möchten, stellen Sie Private Service Connect-Endpunkte im Routing-VPC-Netzwerk bereit. Informationen zum Aktivieren des privaten Zugriffs von lokalen Hosts auf Google APIs finden Sie in der Private Service Connect-Dokumentation.

Indirektes Routing über die NVA

  1. Erstellen Sie im Routing-VPC-Netzwerk einen Private Service Connect-Endpunkt für Google APIs.
  2. Erstellen Sie im Transit-VPC-Netzwerk einen Private Service Connect-Endpunkt für Google APIs.

  3. Konfigurieren Sie DNS so:

    1. Workload-VPC-Netzwerke: Konfigurieren Sie DNS so, dass API-Aufrufe in die IP-Adresse des Private Service Connect-Endpunkts in der Routing-VPC aufgelöst werden.
    2. Externe Netzwerke: Konfigurieren Sie DNS so, dass API-Aufrufe in die IP-Adresse des Private Service Connect-Endpunkts aufgelöst werden, den Sie im Transit-VPC-Netzwerk erstellt haben.

    Mit diesem Ansatz können NVAs Google APIs-Traffic weiterleiten.

  4. Erstellen Sie Private Service Connect-Endpunkte für von Google veröffentlichte Dienste nur in der Arbeitslast-VPC, die dem Dienst zugeordnet ist.

  5. Wenn Sie VPC-Netzwerkzugriff auf Private Service Connect-Endpunkte für von Google veröffentlichte Dienste ermöglichen möchten, aktivieren Sie die Private Service Connect-Weitergabe für NCC hub 2.

Zentralen ein- und ausgehenden Internet-Traffic einrichten

Wenn Ihre Anwendungen nicht über Ihre NVAs auf das Internet zugreifen müssen, können Sie diesen Abschnitt bei der ersten Bereitstellung überspringen und mit Konnektivität zu Arbeitslasten testen fortfahren.

Zentralisierter eingehender Traffic aus dem Internet

Bei eingehendem Traffic aus dem Internet müssen NVAs DNAT für den Traffic ausführen, wenn er an die Zielressource in der Spoke-VPC weitergeleitet wird. Informationen zum Konfigurieren von Ingress finden Sie unter Google-Load-Balancer mit Network Virtual Appliances (NVAs) in Google Cloud konfigurieren. In dieser Konfiguration weisen Sie dem Google-Load-Balancer, der vor den NVAs platziert ist, die ursprüngliche Zieladresse zu. Der Typ des Load Balancers, den Sie auswählen, wirkt sich auf die globale Natur des Ingress-Dienstes aus.

Zentralisierter ausgehender Internettraffic

Wenn Sie den ausgehenden Traffic zum Internet zentralisieren möchten, müssen NVAs SNAT für den Traffic ausführen, wenn er an die Zielressource im Internet weitergeleitet wird. Damit der Traffic von der Google Cloud Quelle weitergeleitet werden kann, müssen die NVAs eine Standardroute für die Spoke-VPCs ankündigen. Für dieses Routing sind keine Load Balancer erforderlich.

Verbindung zu Arbeitslasten testen

Verwenden Sie traceroute, um sich einen Überblick über die Trafficflüsse zu verschaffen. Um die Konnektivität für die verschiedenen Flows zu testen, können Sie Test-VMs in verschiedenen VPCs erstellen.

Nächste Schritte

Beitragende

Beitragende

Autor: Haider Witwit | Customer Engineer

Weitere Beitragende: