Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Architettura e prestazioni di Private Service Connect
Questa pagina spiega come funziona Private Service Connect.
Private Service Connect viene implementato utilizzando la rete virtuale software (SDN) di Google Cloud chiamata
Andromeda
(PDF). Andromeda è il piano di controllo e il piano dati distribuiti per laGoogle Cloud networking che abilita la networking per le reti Virtual Private Cloud (VPC). La rete Andromeda elabora i pacchetti sui server fisici che ospitano le VM. Di conseguenza, il piano dati è completamente distribuito e non presenta colli di bottiglia centralizzati su proxy o appliance intermedi.
Poiché il traffico di Private Service Connect viene elaborato completamente sugli host fisici, offre vantaggi significativi in termini di prestazioni rispetto a un modello basato su proxy:
Private Service Connect non impone limiti di larghezza di banda aggiuntivi. La larghezza di banda combinata delle interfacce VM di origine e di destinazione è in pratica il limite di larghezza di banda di Private Service Connect.
Private Service Connect aggiunge una latenza minima al traffico.
Il percorso del traffico è lo stesso del traffico da VM a VM all'interno di una singola rete VPC. La Network Address Translation del traffico è l'unico ulteriore passaggio di elaborazione del traffico che viene eseguito interamente sull'host di destinazione.
Il seguente diagramma mostra un percorso di traffico tipico per il traffico Private Service Connect tra una rete VPC consumer e una rete VPC producer.
Gli host fisici eseguono il bilanciamento del carico dei client per determinare a quale host di destinazione inviare il traffico (fai clic per ingrandire).
Dal punto di vista logico, esistono endpoint consumer Private Service Connect e bilanciatori del carico dei producer.
Tuttavia, dal punto di vista fisico, il traffico passa direttamente dal server fisico che ospita la VM client al server fisico che ospita la VM bilanciatore del carico del produttore.
Andromeda applica le funzioni al traffico di Private Service Connect come mostrato nel seguente diagramma:
Il bilanciamento del carico lato client viene applicato all'host di origine (Host 1), che decide a quale host di destinazione inviare il traffico. Questa decisione si basa su posizione, carico e stato.
Il pacchetto interno di VPC1 è incapsulato in un'intestazione Andromeda con la rete di destinazione di VPC2.
L'host di destinazione (Host 2) applica SNAT e DNAT al pacchetto, utilizzando la subnet NAT come intervallo di indirizzi IP di origine del pacchetto e l'indirizzo IP del bilanciatore del carico del produttore come indirizzo IP di destinazione.
Esistono eccezioni in cui il traffico viene elaborato da host di routing intermedi, come il traffico interregionale o i flussi di traffico molto piccoli o intermittenti.
Tuttavia, Andromeda esegue il offload dinamico dei flussi di traffico per la rete diretta da host a host, se possibile, per ottimizzare la latenza e il throughput.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-10 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)."]]