Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Private Service Connect-Architektur und -Leistung
Auf dieser Seite wird erläutert, wie Private Service Connect funktioniert.
Private Service Connect wird mithilfe eines softwarebasierten Netzwerks (SDN) von Google Cloud namens Andromeda (PDF) implementiert. Andromeda ist die verteilte Steuerungsebene und Datenebene für das Google Cloud-Netzwerk, die die VPC-Netzwerke (Virtual Private Cloud) ermöglicht. Die Andromeda-Netzwerkstruktur verarbeitet Pakete auf den physischen Servern, auf denen VMs gehostet werden. Infolgedessen ist die Datenebene vollständig verteilt und hat keine zentralisierten Engpässe bei zwischengeschalteten Proxys oder Appliances.
Dass Private Service Connect-Traffic vollständig auf den physischen Hosts verarbeitet wird, bietet erhebliche Leistungsvorteile gegenüber einem proxyorientierten Modell:
Für Private Service Connect gelten keine zusätzlichen Bandbreitenlimits. Die kombinierte Bandbreite der Quell- und Ziel-VM-Schnittstellen ist quasi das Bandbreitenlimit von Private Service Connect.
Private Service Connect erhöht die Latenz des Traffics minimal.
Der Traffic-Pfad ist mit des VM-zu-VM-Traffics in einem einzelnen VPC-Netzwerk identisch. Die Netzwerkadressübersetzung für Traffic ist der einzige zusätzliche Schritt zur Traffic-Verarbeitung, der vollständig auf dem Zielhost ausgeführt wird.
Das folgende Diagramm zeigt einen typischen Traffic-Pfad für Private Service Connect-Traffic zwischen einem VPC-Nutzernetzwerk und einem VPC-Erstellernetzwerk.
Physische Hosts führen ein Client-Load-Balancing durch, um zu bestimmen, an welchen Zielhost der Traffic gesendet werden soll (zum Vergrößern klicken).
Aus logischer Sicht gibt es Private Service Connect-Nutzerendpunkte und Ersteller-Load-Balancer.
Aus physischer Sicht wird der Traffic jedoch direkt vom physischen Server, auf dem die Client-VM gehostet wird, zum physischen Server gesendet, auf dem die Ersteller-Load-Balancer-VM gehostet wird.
Andromeda wendet Funktionen auf Private Service Connect-Traffic an, wie im folgenden Diagramm dargestellt:
Das clientseitige Load Balancing wird auf den Quellhost (Host 1) angewendet, der entscheidet, an welchen Zielhost der Traffic gesendet werden soll. Diese Entscheidung basiert auf Standort, Last und Zustand.
Das innere Paket aus VPC1 ist in einem Andromeda-Header mit dem Zielnetzwerk VPC2 gekapselt.
Der Zielhost (Host 2) wendet SNAT und DNAT auf das Paket an. Dabei wird das NAT-Subnetz als Quell-IP-Adressbereich des Pakets und die IP-Adresse des Ersteller-Load-Balancers als Ziel-IP-Adresse verwendet.
Es gibt Ausnahmen, bei denen der Traffic von zwischengeschalteten Routinghosts verarbeitet wird, z. B. interregionaler Traffic oder sehr kleine oder nur gelegentlich vorkommende Traffic-Flüsse.
Andromeda überträgt die Traffic-Flüsse jedoch nach Möglichkeit dynamisch für direkte Host-zu-Host-Netzwerke, um eine möglichst optimale Werte für Latenz und Durchsatz zu erreichen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-12-06 (UTC)."],[],[],null,["# Private Service Connect architecture and performance\n====================================================\n\nThis page explains how Private Service Connect works.\n\nPrivate Service Connect is implemented by using software-defined\nnetworking (SDN) from Google Cloud called\n[Andromeda](https://www.usenix.org/system/files/conference/nsdi18/nsdi18-dalton.pdf)\n(PDF). Andromeda is the distributed control plane and data plane for\nGoogle Cloud networking that enables networking for\nVirtual Private Cloud (VPC) networks. The Andromeda networking fabric processes\npackets on the physical servers that host VMs. As a result, the data plane is\nfully distributed and has no centralized bottlenecks on intermediate proxies or\nappliances.\n\nBecause Private Service Connect traffic is processed fully on the\nphysical hosts, it has significant performance benefits over a proxy-oriented\nmodel:\n\n- **There are no additional bandwidth limits imposed by\n Private Service Connect.** The combined bandwidth of the source and destination VM interfaces is effectively the bandwidth limit of Private Service Connect.\n- **Private Service Connect adds minimal latency to traffic.** The traffic path is the same as VM-to-VM traffic within a single VPC network. Network address translation of traffic is the only additional traffic processing step which is done entirely on the destination host.\n\nThe following diagram shows a typical traffic path for\nPrivate Service Connect traffic between a consumer\nVPC network and a producer VPC network.\n[](/static/vpc/images/psc-architecture.svg) Physical hosts perform client load balancing to determine which target host to send the traffic to (click to enlarge).\n\nFrom a logical perspective, there are consumer\nPrivate Service Connect endpoints and producer load balancers.\nHowever, from a physical perspective traffic goes directly from the physical\nserver that hosts the client VM to the physical server that hosts the producer\nload balancer VM.\n\nAndromeda applies functions to Private Service Connect traffic as\nshown in the following diagram:\n\n- Client-side load balancing is applied on the source host (`Host 1`) which decides which target host to send the traffic to. This decision is based on location, load and health.\n- The inner packet from `VPC1` is encapsulated in an Andromeda header with the destination network of `VPC2`.\n- The destination host (`Host 2`) applies SNAT and DNAT to the packet, using the [NAT subnet](/vpc/docs/about-vpc-hosted-services#psc-subnets) as the source IP address range of the packet and the producer load balancer IP address as the destination IP address.\n\nThere are exceptions where traffic is processed by intermediate routing hosts,\nsuch as inter-regional traffic or very small or intermittent traffic flows.\nHowever, Andromeda dynamically offloads traffic flows for direct, host-to-host\nnetworking whenever possible to optimize for best latency and throughput.\n\nWhat's next\n-----------\n\n- Learn more about [Private Service Connect](/vpc/docs/private-service-connect).\n- View [Private Service Connect compatibility\n information](/vpc/docs/private-service-connect-compatibility)."]]
