Zentralisierte Netzwerkanwendungen in Google Cloud

Dieses Dokument richtet sich an Netzwerkadministratoren, Lösungsarchitekten und Betriebsexperten, die zentralisierte Netzwerk-Appliances in Google Cloud ausführen. Kenntnisse der Compute Engine- und VPC-Netzwerke (Virtual Private Cloud) in Google Cloud sind erforderlich.

Geschäftsumgebungen müssen häufig Traffic an das Internet, ein lokales Netzwerk, andere Clouds oder sogar in andere Teile derselben Cloud-Umgebung über virtualisierte VM-basierte Appliances senden, die diese überwachen, transformieren und umwandeln oder Traffic blockieren.

In diesem Dokument werden verschiedene Designoptionen behandelt, mit denen VPC-Netzwerke segmentiert und mit einer zentralisierten, virtualisierten Netzwerk-Appliance verbunden werden. Die gesamte Kommunikation zwischen VPC-Netzwerken, lokalen Netzwerken und dem Internet wird über das zentralisierte Gerät geleitet. Sie können eine Gruppe redundanter Appliances bereitstellen, um eine Konfiguration für hohe Verfügbarkeit zu erhalten. Wenn Sie keine hohe Verfügbarkeit benötigen, können Sie eine einzelne Netzwerk-Appliance bereitstellen.

Es ist nicht immer einfach, Traffic über virtuelle Appliances zu leiten. In Google Cloud können Sie beispielsweise die Route zum Internet ersetzen und den Traffic an eine Reihe von virtuellen Appliances weiterleiten. Es ist jedoch nicht möglich, das Routingverhalten zwischen Subnetzwerken innerhalb einer VPC zu ändern. Das Routing zwischen Subnetzwerken erfolgt automatisch und diese Routen können weder gelöscht noch überschrieben werden.

Aufgrund der wichtigen Rolle von virtualisierten Appliances müssen sie auch in hochverfügbaren Konfigurationen bereitgestellt werden. Dies ist eine Herausforderung, da Sie dafür sorgen müssen, dass der gesamte Traffic über eine der virtuellen Appliances geleitet wird und dass das Failover zwischen diesen Appliances automatisch erfolgt.

Das folgende Diagramm zeigt einen typischen Anwendungsfall mit mehreren Designoptionen, die eine zentrale, virtualisierte Netzwerk-Appliance beinhalten.

Designoptionen mit einer zentralisierten, virtualisierten Netzwerk-Appliance.

Das obige Diagramm zeigt die Kommunikationspfade zwischen segmentierten VPC-Netzwerken, lokalen Netzwerken und dem Internet und wie sie durch die zentralisierte, virtualisierte Netzwerk-Appliance geleitet werden.

Wichtigste Anwendungsfälle für diese Architektur

Sie können diese Architektur für mehrere Anwendungsfälle verwenden, bei denen virtuelle Netzwerkgeräte einbezogen werden, für die der Traffic weitergeleitet wird. Beachten Sie dabei Folgendes:

  • Viele Appliances verschiedener Anbieter finden Sie im Google Cloud Marketplace.
  • Einige Appliance-Anbieter bieten auf ihren Websites oder Support-Seiten auch benutzerdefinierte Compute Engine-Images für Google Cloud an.
  • Sie können Ihre eigenen virtualisierten Appliances mit Open-Source-Netzwerksoftware erstellen. Sie können auch eigene Images erstellen.

Anbieter stellen häufig eigene Referenzarchitekturen oder Bereitstellungsanleitungen für die Ausführung ihrer virtuellen Appliances in einer Konfiguration mit Hochverfügbarkeit bereit. Weitere Informationen finden Sie auf der Website des Anbieters.

Referenzarchitekturen des Anbieters umfassen möglicherweise nicht alle in diesem Dokument enthaltenen Optionen.

Es ist wichtig, die Vor- und Nachteile der einzelnen Ansätze zu verstehen. Typische Anwendungsfälle für virtuelle Appliances, über die Traffic weitergeleitet wird, sind:

  • Firewalls der nächsten Generation (NGFWs) Ein zentralisierter Satz von Firewalls wird als virtuelle Maschinen ausgeführt, die Funktionen bereitstellen, die nicht verfügbar sind, wenn Sie VPC-Firewallregeln verwenden. Dies ist der gängigste Anwendungsfall. Zu den typischen Features von NGFW-Produkten gehören eine detaillierte Paketüberprüfung (Deep Packet Inspection = DPI) und eine Firewall auf der Anwendungsebene. Einige NGFW-Firewalls bieten außerdem eine TLS/SSL-Traffic-Prüfung sowie weitere Netzwerkfunktionen, die in den Anwendungsfällen unter den folgenden Aufzählungspunkten beschrieben sind.
  • System zur Angriffserkennung (Intrusion Detection System, IDS/IPS): Bei einem netzwerkbasierten IDS ist die Sichtbarkeit des gesamten potenziell schädlichen Traffics erforderlich. Der Traffic wird normalerweise direkt durch eine IPS im Trafficpfad blockiert, um Eindringen zu verhindern.
  • Transparenter Proxy. Ein transparenter Proxy wird häufig verwendet, um den HTTP(S)-Traffic zu überwachen und Einschränkungen für den Webzugriff zu erzwingen.
  • NAT-Gateway (Network Address Translation): Ein NAT-Gateway übersetzt IP-Adressen und Ports. Damit lassen sich beispielsweise überlappende IP-Adressen vermeiden. Google Cloud bietet Cloud NAT als verwalteten Dienst. Dieser Dienst ist jedoch nur für Traffic zum Internet und nicht für lokalen Traffic oder für andere VPC-Netzwerke in Google Cloud verfügbar.
  • Web Application Firewall (WAF). Eine WAF blockiert böswilligen HTTP-Traffic an eine Webanwendung. Google Cloud bietet im Rahmen der Sicherheitsrichtlinien von Google Cloud Armor eine WAF-Funktion. Die genaue Funktionalität unterscheidet sich je nach WAF-Anbieter. Daher ist es wichtig, genau zu bestimmen, was Sie benötigen.

Typische Anforderungen

Die Anforderungen für die Weiterleitung von Traffic über zentralisierte virtuelle Appliances unterscheiden sich je nach Anwendungsfall. Die folgenden Anforderungen gelten jedoch im Allgemeinen:

  • Der gesamte Traffic zwischen verschiedenen Netzwerksegmenten, z. B. Umgebungen, die von verschiedenen Teams verwaltet werden, mit eigenen Sicherheitsanforderungen oder zwischen verschiedenen Modulen einer Anwendung, muss über eine zentrale virtuelle Appliance erfolgen.
  • Der gesamte Traffic zum oder vom Internet in sichere Umgebungen muss über eine zentrale virtuelle Appliance geleitet werden.
  • Der gesamte Traffic zu oder von lokalen Systemen, die über Cloud VPN, Dedicated Interconnect oder Partner Interconnect mit Google Cloud verbunden sind, muss eine zentralisierte virtuelle Appliance durchlaufen.
  • Mehrere zentralisierte virtuelle Appliances werden in einer Konfiguration mit hoher Verfügbarkeit in einer Aktiv/Aktiv- oder Aktiv/Passiv-Konfiguration eingerichtet. Ein Failover erfolgt automatisch, wenn auf einer der virtualisierten Appliances Software- oder Hardwareprobleme auftreten.
  • Der gesamte Traffic wird ordnungsgemäß weitergeleitet, sodass ein Trafficfluss zwischen zwei virtuellen Maschinen immer über dieselbe virtuelle Appliance läuft.
  • Der Durchsatz des Systems von zentralisierten virtuellen Appliances wird mit einer der beiden folgenden Optionen skaliert:
    • Vertikale Skalierung der virtuellen Appliances: Erhöhen der Anzahl der Kerne oder des Arbeitsspeichers auf jeder virtuellen Maschine.
    • Skalieren der virtuellen Appliances: Die Anzahl der für die Verteilung des Traffics verwendeten virtuellen Appliances wird erhöht.

Architekturoptionen

Es gibt mehrere Möglichkeiten, Hochverfügbarkeit zwischen virtuellen Appliances zu gewährleisten. Es gibt auch mehrere Möglichkeiten, Netzwerksegmente an die virtuellen Appliances anzuhängen.

Sie können jede beliebige Option für Hochverfügbarkeit mit jeder beliebigen Option zum Anhängen von Netzwerksegmenten kombinieren. Eine weiter unten in diesem Dokument beschriebene Option ist eine Architektur, in der VPC-Netzwerk-Peering und der interne TCP/UDP-Load-Balancer als nächster Hop verwendet werden.

Hochverfügbarkeitsoption auswählen

Sie können eine Architektur erstellen, um eine hohe Verfügbarkeit für die zentrale Appliance zu erreichen. Verwenden Sie dazu zwei Instanzen:

  • Verwenden Sie einen internen TCP/UDP-Load-Balancer als nächsten Hop. Bei diesem Ansatz platzieren Sie mehrere virtuelle Appliances in einer verwalteten Instanzgruppe hinter einem internen TCP/UDP-Load-Balancer. Dieser Load-Balancer wird als nächster Hop für eine Standardroute verwendet, die die Standardroute in den VPC-Netzwerken ersetzt, die mit den Appliances verbunden sind. Sie können Appliances entweder in einer Aktiv/Aktiv-Konfiguration, der Standardkonfiguration oder in einer Aktiv/Passiv-Konfiguration verwenden, indem Sie ein Failover für das interne TCP/UDP-Load-Balancing verwenden. Systemdiagnosen leiten Traffic an fehlerfreie Instanzen weiter. Wenn Sie bei einem Fehler eine automatische Neuerstellung vornehmen möchten, können Sie die automatische Reparatur verwenden. Wenn Ihr Gerät mehrere Netzwerkschnittstellen verwendet, kann ein interner TCP/UDP-Load-Balancer als nächster Hop Back-Ends auf jeder Netzwerkschnittstelle haben.

    Das folgende Diagramm zeigt die Topologie der Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop.

    Topologie der Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop.

    Das vorherige Diagramm zeigt eine verwaltete Instanzgruppe in einem VPC-Netzwerk, einschließlich mehrerer virtueller Appliances hinter einem internen TCP/UDP-Load-Balancer, der als nächster Hop fungiert.

  • Verwenden Sie Routing. Bei diesem Ansatz leitet Google Cloud den Traffic von den verbundenen VPC-Netzwerken an die virtuellen Appliances weiter. Sie können Appliances entweder in einer Aktiv/Passiv-Konfiguration verwenden, indem Sie verschiedene Prioritätsrouten nutzen oder in einer Aktiv/Aktiv-Konfiguration, wenn Routen dieselbe Priorität haben. In diesem Fall verwenden Sie ECMP-Routing (Equal Cost Multi Path) zur Verteilung des Traffics. Sie können die automatische Reparatur verwenden, damit Appliances neu gestartet werden, wenn sie fehlerhaft sind.

    Das folgende Diagramm zeigt die Topologie für die Verwendung des Routings.

    Topologie für das Routing.

    Das obige Diagramm zeigt eine verwaltete Instanzgruppe in einem VPC-Netzwerk mit Google Cloud-Routen, die den Traffic an die virtuellen Appliances vom verbundenen VPC-Netzwerk weiterleitet.

Bei beiden Ansätzen kann in einer Aktiv/Aktiv-Konfiguration der eingehende Traffic an eine andere virtuelle Maschine als der ausgehende Traffic weitergeleitet werden, sofern Sie nicht für den gesamten Traffic Quell-NAT verwenden. Die Unterstützung der Sitzungssynchronisierung hängt von der Unterstützung der virtuellen Appliance ab.

Die Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop hat folgende Vorteile gegenüber der Verwendung von Google Cloud-Routing für Hochverfügbarkeit:

  • Systemdiagnosen entscheiden, wohin der Traffic weitergeleitet wird, um sicherzustellen, dass der Traffic nur an fehlerfreie Instanzen weitergeleitet wird. Sie können Systemdiagnosen bereitstellen, damit die lokale Instanz überprüft wird oder ein End-to-End-Pfad verifiziert wird.
  • Sie können die Systemdiagnose-Timer für ein schnelleres Failover optimieren. Dieser Ansatz bietet die schnellsten Failover-Zeiten bei fehlerhaften Instanzen.

Die Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop hat jedoch folgende Nachteile:

  • Nur TCP- und UDP-Traffic kann einen internen TCP/UDP-Load-Balancer passieren. Andere Protokolle, einschließlich Internet Control Message Protocol (ICMP) werden nicht unterstützt.
  • Der interne TCP/UDP-Load-Balancer als nächster Hop unterstützt keine Netzwerktags.

Die Verwendung von Google Cloud-Routing bietet folgende Vorteile:

  • Es werden alle Protokolle (ohne immer blockierten Traffic) unterstützt. Es gibt keine Beschränkung auf bestimmte Protokolle.
  • Google Cloud-Routen lassen sich auf bestimmte Netzwerktags beschränken. Beispielsweise können VM-Instanzen nach Regionen segmentiert werden, um unterschiedliche Gruppen von Appliances zu verwenden.

Die Verwendung von Google Cloud-Routing hat die folgenden Nachteile:

  • Bei Systemdiagnosen werden fehlerhafte Instanzen aus dem Knotenpool gelöscht und neu erstellt. Der Trafficfluss ändert sich jedoch nicht sofort aufgrund fehlgeschlagener Systemdiagnosen, da das Löschen fehlerhafter Instanzen und das Erstellen neuer fehlerfreier Instanzen einige Zeit in Anspruch nimmt. Dies führt zu langsameren Failover-Zeiten.
  • Wenn Sie Systemdiagnosen einrichten, um Instanzen nicht unnötig zu löschen und Instanzen neu zu erstellen, verzögert sich das Failover.

Option zum Anhängen von Netzwerksegmenten auswählen

Da das Routing zwischen Subnetzwerken nicht überschrieben werden kann, werden Netzwerksegmente mit separaten VPC-Netzwerken implementiert. Der Traffic zwischen diesen VPC-Netzwerken, in eine lokale Umgebung und ins Internet muss über die zentralisierten Appliances weitergeleitet werden. Beachten Sie, dass alle diese Netzwerksegmente entweder eigenständige VPC-Netzwerke oder freigegebene VPC-Netzwerke sein können.

Es gibt mehrere Möglichkeiten, Netzwerksegmente anzuhängen:

  • Mehrere Netzwerkschnittstellen. Am einfachsten verbinden Sie mehrere VPC-Netzwerke über eine virtuelle Appliance mit mehreren Netzwerkschnittstellen, wobei jede Schnittstelle mit einem der VPC-Netzwerke verbunden ist. Internet- und lokale Verbindungen werden über eine oder zwei separate Netzwerkschnittstellen bereitgestellt. Bei vielen NGFW-Produkten ist die Internetverbindung über eine Schnittstelle verbunden, die in der NGFW-Software als nicht vertrauenswürdig markiert ist.

    Diese Topologie ist im folgenden Diagramm dargestellt.

    Topologie mehrerer VPC-Netzwerke, die über eine virtuelle Appliance mit mehreren Netzwerkschnittstellen verbunden sind.

    Das obige Diagramm zeigt mehrere VPC-Netzwerke, die über eine virtuelle Appliance mit mehreren Netzwerkschnittstellen verbunden sind. Jede Schnittstelle stellt eine Verbindung zu einem der VPC-Netzwerke her. Das Diagramm zeigt auch Internet- und lokale Verbindungen über separate Netzwerkschnittstellen, einschließlich einer Internetverbindung über eine nicht vertrauenswürdige Schnittstelle.

  • VPC-Netzwerk-Peering. Diese Topologie verwendet das Hub-and-Spoke-Konzept in Verbindung mit VPC-Netzwerk-Peering. Die Netzwerksegmente werden als eine Reihe von Spoke-VPC-Netzwerken implementiert. Dabei wird das VPC-Netzwerk-Peering mit einem Hub-VPC-Netzwerk verwendet, in dem der Traffic durch den zentralen Pool virtualisierter Appliances weitergeleitet wird. Die Standardroute oder Routen, die auf den internen TCP/UDP-Load-Balancer als nächster Hop oder direkt auf die virtuellen Appliances verweisen, werden als benutzerdefinierte Routen über das VPC-Netzwerk-Peering exportiert. Internet- und lokale Verbindungen werden über eine oder zwei separate Netzwerkschnittstellen bereitgestellt.

    Diese Topologie ist im folgenden Diagramm dargestellt.

    Topologie der Kombination mehrerer Netzwerkschnittstellen mit VPC-Netzwerk-Peering.

    Das obige Diagramm zeigt einen zentralisierten Pool von virtualisierten Appliances mit mehreren Netzwerkschnittstellen, die mit mehreren Hub-VPC-Netzwerken verknüpft sind. Jedes Hub-VPC-Netzwerk ist über das VPC-Netzwerk-Peering mit mehreren VPC-Netzwerken verknüpft. Der Traffic zwischen zwei VPC-Netzwerken wird über den zentralen Pool virtualisierter Appliances weitergeleitet.

  • Mehrere Netzwerkschnittstellen mit VPC-Netzwerk-Peering kombinieren Bei diesem Ansatz werden die beiden vorherigen Optionen kombiniert, um die Skalierbarkeit zu erhöhen. Mehrere Netzwerkschnittstellen sind mit mehreren Hub-VPC-Netzwerken verknüpft, von denen jede über das VPC-Netzwerk-Peering mit mehreren Spoke-VPC-Netzwerken verbunden ist. Verwenden Sie für jedes Hub-and-Spoke-VPC-Netzwerk denselben Ansatz wie im VPC-Netzwerk-Peering-Fall beschrieben.

    Diese Topologie ist im folgenden Diagramm dargestellt.

    Topologie des Hub-and-Spoke-Ansatzes mit VPC-Netzwerk-Peering.

    Das obige Diagramm zeigt ein Hub-VPC-Netzwerk, das über VPC-Netzwerk-Peering mit mehreren VPC-Netzwerken verknüpft ist. Der Traffic wird über den zentralisierten Pool virtualisierter Appliances mit einer Netzwerkschnittstelle im Hub-Netzwerk weitergeleitet.

Der folgende Entscheidungsbaum kann Ihnen bei der Auswahl des besten Ansatzes für das Anhängen von Netzwerksegmenten helfen.

Entscheidungsbaum für die Auswahl der besten Methode zum Anhängen von Netzwerksegmenten.

Die Verwendung mehrerer Netzwerkschnittstellen – der erste in den vorherigen Fällen oben – ist die einfachste Implementierung.

Die Verwendung mehrerer Netzwerkschnittstellen hat jedoch folgende Nachteile:

  • Sie sind auf acht Netzwerkschnittstellen pro VM-Instanz beschränkt. Wenn Sie eine Netzwerkschnittstelle für die Internetverbindung und eine für lokale Verbindungen verwenden, können Sie nur sechs Netzwerksegmente in Google Cloud verbinden. Einige Appliances erfordern eine zusätzliche Verwaltungsoberfläche, die Sie auf fünf Netzwerksegmente beschränkt.
  • Sie können keine Netzwerkschnittstellen hinzufügen oder entfernen, nachdem eine Instanz erstellt wurde.

Das VPC-Netzwerk-Peering bietet folgende Vorteile:

Die Verwendung von VPC-Netzwerk-Peering hat jedoch die folgenden Nachteile:

  • Dieser Ansatz ist etwas komplexer als der Ansatz, der mehrere Netzwerkschnittstellen verwendet.
  • Die Anzahl der VPCs, die verbunden werden können, ist im Vergleich zum kombinierten Ansatz weiterhin eingeschränkt.

Der kombinierte Ansatz – mehrere Netzwerkschnittstellen und VPC-Netzwerk-Peering – bietet den folgenden Vorteil:

  • Dieser Ansatz ist besonders skalierbar, weil das Limit ein Produkt der Beschränkung von Netzwerkschnittstellen und der Grenze von VPC-Peering-Verbindungen ist. Sie können beispielsweise 6 Hub-VPC-Netzwerke mit separaten Netzwerkschnittstellen verbinden, wobei jede Schnittstelle 25 Spoke-VPC-Netzwerke verbunden hat. Dadurch gilt ein Limit von 150 VPC-Netzwerken, die Traffic durch eine Gruppe von virtuellen Appliances austauschen.

Dieser Ansatz hat jedoch den folgenden Nachteil:

  • Die Implementierung ist der komplexeste Ansatz.

Beispielarchitekturen

Im Folgenden finden Sie zwei Beispielarchitekturen. Die erste Beispielarchitektur zeigt, wie der interne TCP/UDP-Load-Balancer für Hochverfügbarkeit verwendet wird, und wird mit VPC-Netzwerk-Peering für das Anhängen von Netzwerksegmenten kombiniert. Die zweite Beispielarchitektur, ein spezieller Anwendungsfall, zeigt, wie Sie Traffic von einem einzelnen freigegebenen VPC-Netzwerk in Google Cloud an eine lokale Umgebung und zum Internet weiterleiten.

Beispielarchitektur für VPC Network Peering und interne TCP/UDP-Load-Balancer als nächsten Hop

Diese Architektur ist ein typischer Anwendungsfall für Unternehmensumgebungen. Er verwendet den internen TCP/UDP-Load-Balancer für Hochverfügbarkeit, kombiniert mit VPC-Netzwerk-Peering für das Anhängen von Netzwerksegmenten.

Das folgende Diagramm zeigt die Topologie dieser Architektur.

Topologie der Verwendung von VPC-Netzwerk-Peering und internem TCP/UDP-Load-Balancer als nächsten Hop.

Das obige Diagramm zeigt ein Hub-VPC-Netzwerk und mehrere Spoke-VPC-Netzwerke, die per VPC-Netzwerk-Peering mit dem Hub-VPC-Netzwerk verbunden sind. Das Hub-VPC-Netzwerk hat zwei Instanzen einer virtuellen Appliance in einer verwalteten Instanzgruppe hinter einem internen TCP/UDP-Load-Balancer. Eine statische Standardroute verweist auf den internen TCP/UDP-Load-Balancer als nächsten Hop. Diese statische Standardroute wird über VPC-Netzwerk-Peering mithilfe von benutzerdefinierten Routen exportiert. Die Standardroute zum Internet-Gateway in den Spoke-VPC-Netzwerken wird gelöscht.

Sie können die Anforderungen so erfüllen:

  • Die Verbindung zwischen Spoken wird automatisch durch die Firewall weitergeleitet, da das VPC-Netzwerk-Peering nicht transitiv ist und daher Spoke-VPC-Netzwerke Daten nicht direkt austauschen können. Sie können die virtuellen Appliances so konfigurieren, dass die Bedingungen und Richtlinien festgelegt werden, unter denen die Spokes den Traffic austauschen können.
  • Die Internetverbindung ist nur über die virtuellen Appliances möglich, da die Standardroute zum Internet-Gateway aus den Spoke-VPC-Netzwerken entfernt wurde. Die virtuellen Appliances haben eine Standardroute über eine separate Netzwerkschnittstelle, die im Fall eines NGFW als nicht vertrauenswürdig markiert werden kann.
  • Die Verbindung zu lokalen Netzwerken wird über ein Konnektivitäts-VPC-Netzwerk hergestellt, das über eine separate Netzwerkschnittstelle mit der virtuellen Appliance verbunden ist. Eine Cloud VPN- oder Cloud Interconnect-Verbindung wird in diesem VPC-Netzwerk beendet.
  • Eine hohe Verfügbarkeit wird auf den benutzerdefinierten Systemdiagnosen für den internen Load-Balancer erreicht. Sie können Appliances als aktiv/passiv konfigurieren, indem Sie Failover für das interne TCP/UDP-Load-Balancing verwenden. Dadurch wird sichergestellt, dass der Traffic immer über eine einzige virtuelle Appliance fließt.

Sie können diese Beispielarchitektur verwenden, wenn die Kommunikation zwischen den verschiedenen VPC-Netzwerken nur TCP/UDP ist. Es kann bis zu dem Limit von VPC-Netzwerk-Peering-Verbindungen pro VPC-Netzwerk skaliert werden.

Ein Beispiel für die Implementierung dieser Architektur mit einem NAT-Gateway als virtuelle Appliance finden Sie unter Zentralisierte VM-basierte Appliances mit internem TCP/UDP-Load-Balancer als nächsten Hop bereitstellen. Zum Bereitstellen anderer virtueller Appliances können Sie dasselbe Muster verwenden, wie im vorherigen Abschnitt Anwendungsfälle beschrieben.

Besonderer Anwendungsfall mit einem freigegebenen VPC-Netzwerk in Google Cloud

In einer besonderen Verwendung muss kein Traffic zwischen verschiedenen VPC-Netzwerken über die virtuellen Appliances geleitet werden. Stattdessen wird nur Traffic von einem einzelnen freigegebenen VPC-Netzwerk an eine lokale Umgebung und zum Internet weitergeleitet. Sie können diesen Anwendungsfall implementieren, indem Sie eine der zuvor beschriebenen Hochverfügbarkeitsoptionen verwenden, die weiter oben in diesem Dokument beschrieben sind, sowie jeweils eine Netzwerkschnittstelle, um eine Verbindung zum freigegebenen VPC-Netzwerk, lokal und in Google Cloud herzustellen. Wenn Sie möchten, dass Traffic zwischen Subnetzen ohne die zentralisierten Appliances sichtbar ist, können Sie die Paketspiegelung nutzen.

Diese Topologie ist im folgenden Diagramm dargestellt.

Topologie eines besonderen Anwendungsfalls mit einem freigegebenen VPC-Netzwerk in Google Cloud.

Das obige Diagramm zeigt den Traffic von einem einzelnen freigegebenen VPC-Netzwerk, der über ein Pool virtueller Appliances an das lokale Netzwerk und zum Internet weitergeleitet wird.

Implementieren einer Architektur mit virtuellen Appliances

Wählen Sie zur Implementierung einer Architektur, die virtuelle Appliances verwendet, eine Option für Hochverfügbarkeit aus und kombinieren Sie sie mit einer Option zum Anhängen von Netzwerksegmenten.

Für die folgenden Optionskombinationen sind Implementierungsanleitungen verfügbar:

In den vorherigen Anleitungen werden NAT-Gateways als Anwendungsfall für die Appliance verwendet, Sie können das Gateway jedoch mithilfe eines der anderen Anwendungsfälle anpassen.

Wenn Sie eine Appliance von einem Google Cloud-Partner bereitstellen möchten, z. B. über den Cloud Marketplace, wenden Sie sich an Ihren Appliance-Anbieter oder suchen Sie auf der Website des Anbieters nach Richtlinien zur Bereitstellung derer Appliances in Google Cloud.

Nächste Schritte