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.

Abbildung 1. Physische Hosts führen clientseitiges Load Balancing durch, um zu bestimmen, an welchen Zielhost der Traffic gesendet werden soll.

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.

Nächste Schritte