Ich teste verschiedene GCP-Funktionen und bin mit der Frage im Titel konfrontiert worden. Nach ein wenig Experimentieren habe ichdenkenes sollte folgendes gelten:
- 2 Peered VPC können nicht die gleichen Subnetzbereiche teilen, während VPC-SharingIstdie gleichen Subnetze teilen: Wenn wir möchten, dass Instanzen kommunizieren und wir Firewall-Regeln (FW) anpassen,macht das einen praktischen Unterschied?
- Shared VPC erstellt eine hierarchische Beziehung, bei der ein EndeIstder Manager der Netzwerk- und FW-Regeln und kann daher allen Serviceprojekten die Befugnisse vorgeben und Freigaben widerrufen. Dies bedeutet auch, dass der Hostteil Zugriff auf Serviceprojekte haben muss, um sie auswählen und ihnen die Verwendung der VPCs des Hostprojekts erlauben zu können. VPC-Peering erfordert jedenfalls eine bestimmte Zugriffsebene auf Projekte, wenn man sie peeren möchte, aber die beiden Projekte sind gleichberechtigt (beide Enden müssen das Peering zulassen):Dies ist ein Verwaltungs-/Authentifizierungsunterschied
- Shared VPC ermöglicht eine vereinfachte FW-Einrichtung, da Sie nur einen zentralen Punkt zum Einrichten Ihrer FW-Regeln haben: Sie haben denselben Satz gemeinsam genutzter Subnetze. Beim Peering hingegen müssen – wie bei VPNs – an beiden Enden Regeln eingerichtet werden:Dies ist eine Managementvereinfachung
- Gemeinsam genutztes VPCdürfenerschöpft seine Ressourcen (IPv4-Bereiche) schneller, aber das bedeutet, dass Sie eine Menge Instanzen verbunden haben ...
- VPC Peering kann Passthrou (Daisy Chain) bis zu einer Ebene durchführen: Ich habe eine Verbindung von VPC A zu VPC B und eine von VPC B zu VPC C. VPC A und C könnennichtkommunizieren, aber VPC B kann mit beiden kommunizieren. Im Gegensatz dazu kann in einem Share-Szenario ein Projekt nur gleichzeitig entweder ein Host oder ein Dienst sein, aber ich kann ein Szenario mit mehreren Projekten erstellen, die dasselbe Subnetz teilen und transitiv miteinander kommunizieren ...das ist wahrscheinlich der wichtigste Unterschied, den ich gesehen habe
Nehmen wir an, wir habenNverschiedene Projekte mitNverschiedene Administratoren,WennAlle Teile sind sich einig, dass zwischen den Instanzen eine Art Netzwerkverbindung bestehen muss. Gibt es noch weitere Vor-/Nachteile, wenn man sich für Peering statt Shared entscheidet?!
Bearbeiten
- vielleicht ist das der wirklich größte Unterschied: Wenn ein Serviceprojekt ein gemeinsam genutztes VPC verwendet und Sie es später entfernen möchten, müssen Sie zuerst ein neues VPC erstellen (oder die Standardeinstellung des Serviceprojekts verwenden), allen Instanzen, die derzeit das gemeinsam genutzte VPC verwenden, eine neue Netzwerkkarte zuweisen, diese neue Netzwerkkarte das eigene VPC des Projekts verwenden lassen, die FW-Regeln wiederholen und die korrekte Konnektivität aller Instanzen überprüfen, bevor Sie sie vom gemeinsam genutzten VPC trennen.
- zusätzlich kann VPC Peering genutzt werdeninnerhalb desselben Projektesum die Isolation zwischen Workloads zu erhöhen, aber die Kommunikation einiger ausgewählter VMs zu ermöglichen.
Bearbeiten 2
- Ab sofort (2021-01) kann Shared VPC auf einer zweiten Netzwerkkarte verwendet werden, es handelt sich jedoch um eine Betafunktion.
- außerdem kann man nicht mehr als 25 Peerings zu einem Netzwerk hinzufügen, daher ist es durchaus üblich, Projekte in sogenannten Hub-and-Spoke-Designs über ein gemeinsam genutztes VPC kommunizieren zu lassen.
- Ich habe gerade entdeckt, dass VPC Peering auch zwischen verschiedenenOrganisationen!
Bearbeiten 3
Obwohl es sich nicht um eine reine Netzwerkarchitektur handelt, bietet Google jetzt auch privaten Servicezugriff: eine Möglichkeit, externe Dienste (einschließlich derer in anderen Projekten/VPCs) über einenProxy in Ihrem VPC
Danke
Antwort1
Zu Ihren hervorragenden Feststellungen möchte ich noch etwas ergänzen:
Um denselben Subnetzbereich zu teilen, müssen wir berücksichtigen, dass beide VPCs zur selben Organisation gehören müssen. Außerdem wollte ich sagen, dass Shared VCP (XPVC) es ermöglicht, Ressourcen mit mehr als einem Projekt zu teilen. Im Gegensatz dazu erlaubt VPC-Peering nur das Teilen von Ressourcen zwischen zwei Projekten.
Ich stimme Ihrer Ansicht zu, dass sich die Ressourcen mit XVPC einfacher verwalten lassen als mit VPC, was bedeutet, dass jedes VPC über eigene Ressourcen verfügt.
Zusammenfassend lässt sich also sagen, dass der Hauptunterschied zwischen der Verwendung von XVPC und VPC-Peering von Ihren Anforderungen und Ihrer Erfahrung bei der Verwaltung von Ressourcen abhängt oder davon, wie praktisch Sie vorgehen möchten.
Antwort2
Peering: Peering ermöglicht die interne IP-Adresskonnektivität über zwei Virtual Private Cloud (VPC)-Netzwerke hinweg, unabhängig davon, ob sie zum selben Projekt oder zur selben Organisation gehören. Sie sind auf 25 pro Projekt beschränkt und die Transitivität ist nicht möglich.
VPC-Sharing: Shared VPC ermöglicht es einer Organisation, Ressourcen aus mehreren Projekten mit einem gemeinsamen Virtual Private Cloud (VPC)-Netzwerk zu verbinden, sodass sie über interne IPs aus diesem Netzwerk sicher und effizient miteinander kommunizieren können. Wenn Sie Shared VPC verwenden, legen Sie ein Projekt als Hostprojekt fest und fügen ein oder mehrere andere Serviceprojekte daran an. Die VPC-Netzwerke im Hostprojekt werden als Shared VPC-Netzwerke bezeichnet. Berechtigte Ressourcen aus Serviceprojekten können Subnetze im Shared VPC-Netzwerk verwenden.