Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Architecture et performances de Private Service Connect
Cette page explique comment fonctionne Private Service Connect.
Private Service Connect est implémenté à l'aide du réseau défini par logiciel (SDN) de Google Cloud appelé Andromeda (PDF). Andromeda est le plan de contrôle et le plan de données distribués pour la gestion des réseaux Google Cloud qui permet la mise en réseau des réseaux de cloud privé virtuel (VPC). La structure de mise en réseau Andromeda traite les paquets sur les serveurs physiques qui hébergent des VM. Par conséquent, le plan de données est entièrement distribué et ne présente pas de goulots d'étranglement centralisés sur les proxys ou les appareils intermédiaires.
Par rapport à un modèle orienté proxy, le trafic Private Service Connect est entièrement traité sur les hôtes physiques et présente des avantages significatifs en termes de performances :
Aucune limite de bande passante supplémentaire n'est imposée par Private Service Connect. La bande passante combinée des interfaces de VM source et de destination correspond en fait à la limite de bande passante de Private Service Connect.
Private Service Connect ajoute une latence minimale au trafic.
Le chemin du trafic est identique au trafic entre plusieurs VM au sein d'un même réseau VPC. La traduction d'adresse réseau du trafic est la seule autre étape de traitement du trafic réalisée entièrement sur l'hôte de destination.
Le schéma suivant illustre un chemin de trafic type pour le trafic Private Service Connect entre un réseau VPC consommateur et un réseau VPC producteur.
Les hôtes physiques effectuent l'équilibrage de charge client pour déterminer l'hôte cible auquel envoyer le trafic (cliquez pour agrandir)
D'un point de vue logique, il existe des points de terminaison Private Service Connect clients et des équilibreurs de charge du producteur.
Cependant, du point de vue physique, le trafic passe directement du serveur physique qui héberge la VM cliente au serveur physique qui héberge la VM de l'équilibreur de charge du producteur.
Andromeda applique des fonctions au trafic Private Service Connect, comme illustré dans le schéma suivant :
L'équilibrage de charge côté client est appliqué sur l'hôte source (Host 1), qui détermine l'hôte cible auquel envoyer le trafic. Cette décision est basée sur l'emplacement, la charge et l'état.
Le paquet interne de VPC1 est encapsulé dans un en-tête Andromeda avec le réseau de destination de VPC2.
L'hôte de destination (Host 2) applique la traduction SNAT et DNAT au paquet, en utilisant le sous-réseau NAT comme plage d'adresses IP source du paquet et l'adresse IP de l'équilibreur de charge du producteur comme adresse IP de destination.
Il existe des exceptions où le trafic est traité par des hôtes de routage intermédiaires, comme le trafic interrégional ou des flux de trafic très petits ou intermittents.
Cependant, dans la mesure du possible, Andromeda décharge de manière dynamique les flux de trafic pour une mise en réseau directe d'hôte à hôte afin d'optimiser la latence et le débit.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/12/06 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]