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.
Architektur
Das folgende Diagramm zeigt einen typischen Anwendungsfall mit mehreren Designoptionen, die eine zentrale, virtualisierte Netzwerk-Appliance beinhalten.
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 Passthrough-Network-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:
Internen Passthrough-Network-Load-Balancer als nächsten Hop verwenden. Bei diesem Ansatz platzieren Sie mehrere virtuelle Appliances in einer verwalteten Instanzgruppe hinter einem internen Passthrough-Network-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 interne Passthrough-Network-Load-Balancer 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 Passthrough-Network-Load-Balancer als nächster Hop Back-Ends auf jeder Netzwerkschnittstelle haben.
Das folgende Diagramm zeigt die Topologie der Verwendung eines internen Passthrough-Network-Load-Balancers als nächster Hop.
Das vorherige Diagramm zeigt eine verwaltete Instanzgruppe in einem VPC-Netzwerk, einschließlich mehrerer virtueller Appliances hinter einem internen Passthrough-Network-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.
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.
Die Verwendung eines internen Passthrough-Network-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.
- Mit dem symmetrischen Hashing können Sie dafür sorgen, dass der Rücktraffic an dieselbe virtuelle Maschine wie der ausgehende Traffic geleitet wird.
Die Verwendung von Google Cloud-Routing hat die folgenden Vorteile:
- Konsistentes symmetrisches Hashing sorgt dafür, dass Pakete für eine bestimmte Verbindung für Anfragen und Antworten von derselben Back-End-VM verarbeitet werden, je nach Auswahl von Protokoll und Sitzungsaffinität. Die Auswahl von Protokoll und Sitzungsaffinität bestimmt, ob das Verbindungs-Tracking verwendet wird oder nicht. Beachten Sie, dass einige Anwendungsfälle von einer Quell-NAT-Konfiguration (SNAT) in den Back-End-Instanzen profitieren könnten, beispielsweise wenn eine Antwortverbindung von einem Netzwerk zu einem anderen mit einer separaten Anfrageverbindung in derselben Richtung zwischen denselben beiden Netzwerken übereinstimmen soll.
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.
Unabhängig davon, ob Sie einen internen Passthrough-Network-Load-Balancer als nächsten Hop oder das Google Cloud-Routing verwenden, wird der gesamte Protokoll-Traffic unterstützt. Ausführliche Informationen zu dieser Unterstützung finden Sie unter Verarbeitung von TCP-, UDP- und anderem Protokolltraffic.
Gleichzeitig unterstützen beide Lösungen die Beschränkung von Routen auf bestimmte Netzwerktags. Beispielsweise können VM-Instanzen nach Regionen segmentiert werden, um unterschiedliche Gruppen von Appliances zu verwenden.
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.
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 Passthrough-Network-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.
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.
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.
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:
- Sie können bis zum Limit für VPC-Netzwerk-Peering-Verbindungen aus einem einzelnen VPC-Netzwerk hochskalieren. Wenden Sie sich an das Google Cloud-Vertriebsteam, wenn Sie Fragen zur Erhöhung dieses Limits haben.
- VPC-Netzwerk-Peering lässt sich ganz einfach in diese Architektur einfügen oder daraus entfernen.
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 Passthrough-Network-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-Netzwerk-Peering und internen Passthrough-Network-Load-Balancer als nächsten Hop
Diese Architektur ist ein typischer Anwendungsfall für Unternehmensumgebungen. Er verwendet den internen Passthrough-Network-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.
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 Passthrough-Network-Load-Balancer. Eine statische Standardroute verweist auf den internen Passthrough-Network-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 interne Passthrough-Network-Load-Balancer 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 TCP/UDP oder ein anderer Protokolltraffic ist. Sie 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 Hub-and-Spoke-Netzwerk mit einem 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.
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
Informationen zur Verwendung von VPC-Netzwerk-Peering zwischen Segmenten und dem internen Passthrough-Network-Load-Balancer als Hochverfügbarkeitsoption finden Sie unter Hub-and-Spoke-Netzwerk mit einem Load Balancer als nächsten Hop bereitstellen.
Wenn Sie eine Appliance von einem Google Cloud-Partner über den Cloud Marketplace bereitstellen möchten, 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
- Best Practices und Referenzarchitekturen für das VPC-Design.
- Hybrid- und Multi-Cloud-Netzwerktopologien
- Best Practices für Netzwerkdesign im Google Cloud-Architektur-Framework
- Virtual Private Cloud-Dokumentation.
- Dokumentation zum internen Passthrough-Network-Load-Balancer.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center