Reti VPC

Una rete Virtual Private Cloud (VPC) è una versione virtuale di una rete fisica implementata all'interno della rete di produzione di Google tramite Andromeda.

Una rete VPC esegue le seguenti operazioni:

• Fornisce connettività per le tue istanze di macchine virtuali (VM) Compute Engine.
• Offre bilanciatori del carico di rete passthrough interni nativi e sistemi proxy per Application Load Balancer interni.
• Si connette alle reti on-premise utilizzando tunnel Cloud VPN e collegamenti VLAN per Cloud Interconnect.
• Distribuisce il traffico dai bilanciatori del carico esterni di Google Cloud ai backend.

I progetti possono contenere più reti VPC. A meno che non crei un criterio dell'organizzazione che lo vieti, i nuovi progetti iniziano con una rete predefinita (una rete VPC in modalità automatica) che ha una subnet in ogni regione.

Importante: questa pagina descrive le reti VPC, che sono diverse dalle reti legacy. Le reti legacy non possono più essere create e non sono consigliate per la produzione perché non supportano funzionalità di networking avanzate. Puoi convertire una rete legacy in una rete VPC. Per visualizzare il tipo di rete esistente, vedi Visualizzare le reti.

Reti e subnet

I termini subnet e subnetwork sono sinonimi. Vengono utilizzati in modo intercambiabile nella console Google Cloud, nei comandi gcloud e nella documentazione dell'API.

Una subnet non è la stessa cosa di una rete (VPC). Le reti e le subnet sono tipi di risorse diversi in Google Cloud.

Per ulteriori informazioni, vedi Subnet.

Istanze di macchine virtuali

Un'istanza di macchina virtuale (VM) Compute Engine è una macchina virtuale ospitata sull'infrastruttura di Google. I termini istanza Compute Engine, istanza VM e VM sono sinonimi. Vengono utilizzati in modo intercambiabile nella console Google Cloud, nel riferimento di Google Cloud CLI e nella documentazione delle API.

Le istanze VM includono cluster Google Kubernetes Engine (GKE), istanze dell'ambiente flessibile App Engine e altri prodotti Google Cloud basati su VM di Compute Engine.

Per ulteriori informazioni, consulta Istanze di macchine virtuali nella documentazione di Compute Engine.

Specifiche

Le reti VPC hanno le seguenti proprietà:

• Le reti VPC, comprese le route e le regole firewall associate, sono risorse globali. Non sono associati a una determinata regione o zona.

• Le subnet sono risorse a livello di regione.

• Ogni subnet definisce un intervallo di indirizzi IPv4. Anche le subnet in modalità personalizzata possono avere un intervallo di indirizzi IPv6.

• Il traffico da e verso le istanze può essere controllato con regole firewall di rete. Le regole vengono implementate sulle VM stesse, quindi il traffico può essere controllato e registrato solo quando esce o arriva a una VM.

• Le risorse all'interno di una rete VPC possono comunicare tra loro utilizzando indirizzi IPv4 interni, indirizzi IPv6 interni o indirizzi IPv6 esterni, soggetti alle regole firewall di rete applicabili. Per ulteriori informazioni, consulta la pagina relativa alla comunicazione all'interno della rete.

• Le istanze con indirizzi IPv4 o IPv6 interni possono comunicare con le API e i servizi Google. Per ulteriori informazioni, vedi Opzioni di accesso privato per i servizi.

• L'amministrazione della rete può essere protetta utilizzando i ruoli di Identity and Access Management (IAM).

• Un'organizzazione può utilizzare un VPC condiviso per mantenere una rete VPC in un progetto host comune. Le entità IAM autorizzate di altri progetti nella stessa organizzazione possono creare risorse che utilizzano subnet della rete VPC condiviso.

• Le reti VPC possono essere connesse ad altre reti VPC in progetti o organizzazioni diversi utilizzando il peering di rete VPC.

• Le reti VPC possono essere connesse in modo sicuro in ambienti ibridi utilizzando Cloud VPN o Cloud Interconnect.

• Le reti VPC supportano il traffico GRE, compreso il traffico su Cloud VPN e Cloud Interconnect. Le reti VPC non supportano GRE per Cloud NAT o per le regole di forwarding per il bilanciamento del carico e l'inoltro del protocollo. Il supporto per GRE consente di terminare il traffico GRE su una VM da internet (indirizzo IP esterno) e Cloud VPN o Cloud Interconnect (indirizzo IP interno). Il traffico decapsulato può quindi essere inoltrato a una destinazione raggiungibile. GRE consente di utilizzare servizi come SASE (Secure Access ServiceEdge) e SD-WAN.

  Nota: il supporto GRE per VPN e Interconnect è stato testato solo con GRE versione 0. Inoltre, il supporto per il traffico GRE non include l'assistenza da parte di Google Cloud per risolvere i problemi della rete in overlay.

• Le reti VPC supportano gli indirizzi unicast IPv4 e IPv6. Le reti VPC non supportano indirizzi di trasmissione o multicast all'interno della rete.

  Per ulteriori informazioni sugli intervalli di subnet IPv6, consulta Subnet.

Esempio di rete VPC

L'esempio seguente illustra una rete VPC in modalità personalizzata con tre subnet in due regioni:

Esempio di rete VPC (fai clic per ingrandire)

• La Subnet1 è definita come 10.240.0.0/24 nella regione us-west1.
  • Due istanze VM nella zona us-west1-a si trovano in questa subnet. Entrambi gli indirizzi IP provengono dall'intervallo di indirizzi disponibile in subnet1.
• La Subnet2 è definita come 192.168.1.0/24 nella regione us-east1.
  • Due istanze VM nella zona us-east1-b si trovano in questa subnet. Entrambi gli indirizzi IP provengono dall'intervallo di indirizzi disponibile in subnet2.
• Subnet3 è definita come 10.2.0.0/16, anch'essa nella regione us-east1.
  • Un'istanza VM nella zona us-east1-b e una seconda istanza nella zona us-east1-c si trovano in subnet3 e ciascuna riceve un indirizzo IP dal proprio intervallo disponibile. Poiché le subnet sono risorse a livello di regione, le istanze delle istanze possono avere le relative interfacce di rete associate a qualsiasi subnet nella stessa regione che contiene le rispettive zone.

Vincoli dei criteri dell'organizzazione

• Ogni nuovo progetto viene avviato con una rete VPC predefinita. Puoi disabilitare la creazione di reti predefinite creando un criterio dell'organizzazione con il vincolo compute.skipDefaultNetworkCreation. I progetti che ereditano questo criterio non avranno una rete predefinita.

• Puoi controllare le seguenti configurazioni IPv6 utilizzando i criteri dell'organizzazione:

  • Disabilita l'utilizzo di IPv6 esterno del VPC: se impostato su true, il vincolo constraints/compute.disableVpcExternalIpv6 ti impedisce di configurare subnet a doppio stack con intervalli IPv6 esterni.

  • Disabilita l'utilizzo di IPv6 interno di VPC: se impostato su true, il vincolo constraints/compute.disableVpcInternalIpv6 ti impedisce di configurare subnet a doppio stack con intervalli IPv6 interni.

  • Disabilita l'utilizzo di tutti gli indirizzi IPv6: se impostato su true, il vincolo constraints/compute.disableAllIpv6 disattiva la creazione o l'aggiornamento delle risorse coinvolte nell'utilizzo di IPv6.

Per ulteriori informazioni sui vincoli, consulta Vincoli dei criteri dell'organizzazione.

Modalità di creazione subnet

Google Cloud offre due tipi di reti VPC, determinati dalla loro modalità di creazione subnet:

• Quando si crea una rete VPC in modalità automatica, viene creata automaticamente una subnet per ogni regione al suo interno. Queste subnet create automaticamente utilizzano un insieme di intervalli IPv4 predefiniti che rientrano nel blocco CIDR 10.128.0.0/9. Man mano che nuove regioni Google Cloud diventano disponibili, le nuove subnet al loro interno vengono aggiunte automaticamente alle reti VPC in modalità automatica utilizzando un intervallo IP di quel blocco. Oltre alle subnet create automaticamente, puoi aggiungere manualmente altre subnet per le reti VPC in modalità automatica nelle regioni che scegli utilizzando intervalli IP esterni a 10.128.0.0/9.

• Quando si crea una rete VPC in modalità personalizzata, non viene creata automaticamente nessuna subnet. Questo tipo di rete offre il controllo completo sulle subnet e sui relativi intervalli IP. Puoi decidere quali subnet creare nelle regioni che scegli usando gli intervalli IP da te specificati.

Puoi passare dalla modalità automatica alla modalità personalizzata di una rete VPC. Questa è una conversione unidirezionale; le reti VPC in modalità personalizzata non possono essere cambiate in reti VPC in modalità automatica. Per aiutarti a decidere quale tipo di rete soddisfa le tue esigenze, consulta le considerazioni relative alle reti VPC in modalità automatica.

Rete predefinita

A meno che tu non scelga di disattivarla, ogni nuovo progetto viene avviato con una rete predefinita. La rete predefinita è una rete VPC in modalità automatica con regole firewall IPv4 precompilate. La rete predefinita non ha regole firewall IPv6 precompilate.

Considerazioni sulle reti VPC in modalità automatica

Le reti VPC in modalità automatica sono facili da configurare e da utilizzare e sono particolarmente adatte per i casi d'uso con questi attributi:

• La creazione automatica di subnet in ogni regione è utile.

• Gli intervalli IP predefiniti delle subnet non si sovrappongono agli intervalli IP che useresti per scopi diversi (ad esempio, connessioni Cloud VPN a risorse on-premise).

Tuttavia, le reti VPC in modalità personalizzata sono più flessibili e più adatte alla produzione. I seguenti attributi evidenziano i casi d'uso in cui le reti VPC in modalità personalizzata sono consigliate o obbligatorie:

• Non è necessario creare automaticamente una subnet in ogni regione.

• La creazione automatica di nuove subnet quando diventano disponibili nuove regioni potrebbe sovrapporsi agli indirizzi IP utilizzati da subnet create manualmente o da route statiche, oppure potrebbe interferire con la tua pianificazione di rete complessiva.

• Devi avere il controllo completo sulle subnet create nella tua rete VPC, inclusi gli intervalli di indirizzi IP e le regioni utilizzati.

• Prevedi di connettere la tua rete VPC a un'altra rete:

  • Poiché le subnet di ogni rete VPC in modalità automatica utilizzano lo stesso intervallo predefinito di indirizzi IP, non puoi connettere le reti VPC in modalità automatica utilizzando il peering di rete VPC o Cloud VPN.

  • Poiché l'intervallo CIDR 10.128.0.0/9 in modalità automatica fa parte dello spazio di indirizzi RFC 1918 comunemente utilizzato, le reti esterne a Google Cloud potrebbero utilizzare, attualmente o in futuro, un intervallo CIDR sovrapposto.

• Vuoi creare subnet con intervalli IPv6. Le reti VPC in modalità automatica non supportano le subnet a doppio stack.

Importante: le reti di produzione devono essere pianificate in anticipo. Ti consigliamo di utilizzare le reti VPC in modalità personalizzata in produzione.

Intervalli di subnet IPv4

Ogni subnet ha un intervallo di indirizzi IPv4 principale. Gli indirizzi interni principali per le risorse seguenti provengono dall'intervallo principale della subnet: istanze VM, bilanciatori del carico interni e forwarding del protocollo interno. Facoltativamente, puoi aggiungere intervalli di indirizzi IP secondari a una subnet, utilizzati solo dagli intervalli IP alias. Puoi però configurare intervalli IP alias per le istanze dell'intervallo principale o secondario di una subnet.

Ogni intervallo IPv4 primario o secondario per tutte le subnet in una rete VPC deve essere un blocco CIDR valido univoco. Fai riferimento ai limiti per rete per conoscere il numero di intervalli IP secondari che puoi definire.

Le subnet IPv4 non devono necessariamente formare un blocco CIDR contiguo predefinito, ma puoi farlo se vuoi. Le reti VPC in modalità automatica creano subnet che rientrano in un intervallo IP predefinito.

Quando crei una subnet in una rete VPC in modalità personalizzata, scegli l'intervallo IPv4 da utilizzare. Per ulteriori informazioni, consulta Intervalli di subnet validi, intervalli di subnet vietati e utilizzo con le subnet.

Esistono quattro indirizzi IP inutilizzabili in ogni intervallo di subnet IPv4 principale. Per maggiori informazioni, vedi Indirizzi inutilizzabili negli intervalli di subnet IPv4.

Le reti VPC in modalità automatica vengono create con una subnet per regione al momento della creazione e ricevono automaticamente nuove subnet in nuove regioni. Le subnet hanno solo intervalli IPv4 e tutti gli intervalli di subnet rientrano nel blocco CIDR 10.128.0.0/9. Le parti inutilizzate di 10.128.0.0/9 vengono riservate per uso futuro di Google Cloud. Per informazioni sull'intervallo IPv4 utilizzato in ogni regione, consulta Intervalli di subnet IPv4 in modalità automatica.

Intervalli di subnet IPv6

Quando crei una subnet a doppio stack in una rete VPC in modalità personalizzata, scegli se la subnet è configurata con un intervallo di subnet IPv6 interno o con un intervallo di subnet IPv6 esterne.

• Gli intervalli di subnet IPv6 interni utilizzano indirizzi locali univoci (ULA).

  • Gli ULA sono utilizzati per le comunicazioni da VM a VM all'interno delle reti VPC. Gli ULA per IPv6 sono analoghi agli indirizzi RFC 1918 per IPv4. Gli UA non sono raggiungibili da internet e non sono instradabili pubblicamente.

• Gli intervalli di subnet IPv6 esterne utilizzano indirizzi unicast globali (GUA).

  • Le GUA possono essere utilizzate per la comunicazione da VM a VM all'interno di reti VPC, oltre a essere instradabili su internet.

Per ulteriori informazioni sugli intervalli di subnet IPv6, consulta Subnet.

Reti che supportano subnet a doppio stack

Puoi creare subnet a doppio stack in una rete VPC in modalità personalizzata.

Le subnet a doppio stack non sono supportate sulle reti VPC in modalità automatica, inclusa la rete predefinita. Le subnet a doppio stack non sono supportate sulle reti legacy.

Se hai una rete VPC in modalità automatica a cui vuoi aggiungere subnet a doppio stack, segui questi passaggi:

1. Converti la rete in modalità automatica in modalità personalizzata.

2. Crea nuove subnet a doppio stack o converti le subnet esistenti in subnet a doppio stack.

Route e regole firewall

Route

Le route definiscono i percorsi dei pacchetti che escono dalle istanze (traffico in uscita). Per maggiori dettagli sui tipi di route Google Cloud, consulta Route.

Modalità di routing dinamico

A ogni rete VPC è associata una modalità di routing dinamico che controlla il comportamento di tutti i suoi router Cloud. I router Cloud gestiscono le sessioni BGP per i prodotti per la connettività Google Cloud.

Per una descrizione delle opzioni della modalità di routing dinamico, consulta Effetti della modalità di routing dinamico nella documentazione del router Cloud.

Annunci di routing e indirizzi IP interni

I seguenti indirizzi IP sono pubblicizzati all'interno di una rete VPC:

• Indirizzi IPv4 interni a livello di regione

  Utilizzato per gli intervalli di indirizzi di subnet IPv4 primari e secondari

• Indirizzi IPv6 interni ed esterni a livello di regione

  Utilizzato per gli intervalli di indirizzi di subnet IPv6 interni ed esterni

• Indirizzi IPv4 interni globali

  Utilizzata per gli endpoint di Private Service Connect per le API di Google

Se connetti le reti VPC utilizzando il peering di rete VPC, gli intervalli di subnet che utilizzano indirizzi IPv4 privati vengono sempre scambiati. Puoi controllare se vengono scambiati intervalli di subnet utilizzando indirizzi IPv4 pubblici utilizzati privatamente. Gli indirizzi IPv4 interni globali non vengono mai scambiati tramite peering. Per ulteriori dettagli, consulta la documentazione sul peering di rete VPC.

Quando connetti una rete VPC a un'altra rete, ad esempio una rete on-premise, utilizzando un prodotto per la connettività Google Cloud come Cloud VPN, Cloud Interconnect o appliance router:

• Puoi pubblicizzare gli indirizzi IP interni della rete VPC a un'altra rete (ad esempio una rete on-premise).
• Anche se la connettività tra una rete VPC e un'altra rete (ad esempio una rete on-premise) può utilizzare il routing privato fornito da un prodotto di connettività Google Cloud, anche gli indirizzi IP dell'altra rete potrebbero essere instradabili pubblicamente. Tieni presente questo aspetto se una rete on-premise usa indirizzi IP instradabili pubblicamente.
• Le istanze VM in una rete VPC contenente intervalli di subnet con indirizzi IP pubblici utilizzati privatamente non sono in grado di connettersi a risorse esterne che utilizzano gli stessi indirizzi IP pubblici.
• Presta particolare attenzione quando pubblicizzi indirizzi IP pubblici utilizzati privatamente su un'altra rete (ad esempio una rete on-premise), soprattutto se l'altra rete può pubblicizzare questi indirizzi IP pubblici su internet.

Regole firewall

Sia i criteri firewall gerarchici sia le regole firewall VPC si applicano ai pacchetti inviati da e verso le istanze VM (e alle risorse che dipendono dalle VM, come i nodi di Google Kubernetes Engine). Entrambi i tipi di firewall controllano il traffico anche se si trova tra le VM nella stessa rete VPC.

Per monitorare quale regola firewall ha consentito o negato una determinata connessione, consulta Logging delle regole firewall.

Comunicazioni e accesso

Comunicazione all'interno della rete

Le route di subnet generate dal sistema definiscono i percorsi per l'invio del traffico tra le istanze all'interno della rete utilizzando indirizzi IP interni. Affinché un'istanza possa comunicare con un'altra, è necessario configurare anche regole firewall appropriate perché ogni rete ha una regola firewall implicita di negazione per il traffico in entrata.

Ad eccezione della rete predefinita, devi creare esplicitamente regole firewall in entrata con priorità più elevata per consentire alle istanze di comunicare tra loro. La rete predefinita include diverse regole firewall oltre a quelle implicite, inclusa la regola default-allow-internal, che consente la comunicazione da istanza a istanza all'interno della rete. La rete predefinita è dotata anche di regole in entrata che consentono protocolli come RDP e SSH.

Anche le regole incluse nella rete predefinita vengono presentate come opzioni da applicare alle nuove reti VPC in modalità automatica che crei utilizzando la console Google Cloud.

Requisiti per l'accesso a internet

Affinché un'istanza abbia accesso a internet in uscita, devono essere soddisfatti i seguenti criteri:

• La rete deve avere una route gateway internet predefinito valido o una route personalizzata il cui intervallo IP di destinazione è il più generale (0.0.0.0/0). Questa route definisce il percorso a internet. Per ulteriori informazioni, consulta Route.

• Le regole firewall devono consentire il traffico in uscita dall'istanza. A meno che non venga sostituito da una regola con priorità più elevata, la regola di autorizzazione implicita per il traffico in uscita consente il traffico in uscita da tutte le istanze.

• Una delle seguenti condizioni deve essere vera:

  • L'istanza deve avere un indirizzo IP esterno. Un indirizzo IP esterno può essere assegnato a un'istanza quando viene creata o dopo che è stata creata.

  • L'istanza deve essere in grado di utilizzare Cloud NAT o un proxy basato su istanza che sia la destinazione di una route 0.0.0.0/0 statica.

Comunicazioni e accesso per App Engine

Le regole firewall VPC si applicano alle risorse in esecuzione nella rete VPC, come le VM Per le istanze di App Engine, le regole firewall funzionano come segue:

• Ambiente standard di App Engine: al traffico in entrata si applicano solo le regole firewall di App Engine. Poiché le istanze dell'ambiente standard di App Engine non vengono eseguite all'interno della rete VPC, le regole firewall VPC non vengono applicate.

• Ambiente flessibile di App Engine: le regole firewall di App Engine e VPC si applicano al traffico in entrata. Il traffico in entrata è consentito solo se consentito da entrambi i tipi di regole firewall. Per il traffico in uscita, si applicano le regole del firewall VPC.

Per ulteriori informazioni su come controllare l'accesso alle istanze di App Engine, consulta Sicurezza delle app.

Traceroute a indirizzi IP esterni

Per motivi interni, Google Cloud aumenta il contatore TTL dei pacchetti che attraversano gli hop successivi nella rete Google. Strumenti come traceroute e mtr potrebbero fornire risultati incompleti perché il TTL non scade su alcuni hop. Gli hop all'interno della rete di Google potrebbero essere nascosti quando invii pacchetti dalle istanze di Compute Engine a destinazioni su internet.

Il numero di hop nascosti varia in base a Network Service Tiers dell'istanza, alla regione e ad altri fattori. Se sono presenti pochi hop, è possibile che vengano nascosti tutti. Hop mancanti da un risultato traceroute o mtr non significano che il traffico in uscita è stato eliminato.

Non esiste una soluzione alternativa per questo comportamento. Devi tenerne conto se configuri un monitoraggio di terze parti che si connette a un indirizzo IP esterno associato a una VM.

Importante: le statistiche sulla perdita di probe sono un componente dei test traceroute, ma occorre prestare attenzione quando si analizzano i risultati dei test. traceroute e mtr per impostazione predefinita utilizzano il probe basato su ICMP. La generazione della risposta del probe ICMP è in genere limitata di frequenza (o disabilitata) nei router che risiedono nel percorso di rete del probing e può causare risposte del probe mancanti. Quando si verifica questo comportamento, potresti notare una perdita del probe negli hop di routing intermedi, ma questo non dovrebbe riflettere le prestazioni end-to-end. Se cerchi la perdita di pacchetti, l'unico hop che generalmente conta è l'hop di destinazione.

Limiti di velocità effettiva in uscita

Le informazioni sulla velocità effettiva di rete sono disponibili nella pagina Larghezza di banda di rete nella documentazione di Compute Engine.

Dimensione pacchetto

Puoi trovare informazioni sulle dimensioni del pacchetto in Unità massima di trasmissione.

Unità massima di trasmissione

Per ulteriori informazioni sull'impostazione dell'unità massima di trasmissione (MTU) per una rete VPC e le relative VM connesse, consulta Unità massima di trasmissione.

Per informazioni sulla modifica della MTU di una rete VPC o sulla migrazione di VM tra reti VPC con impostazioni MTU diverse, consulta Modificare l'impostazione MTU di una rete VPC.

Protocolli supportati

Google Cloud supporta solo i seguenti protocolli e intestazioni di estensioni:

• Pacchetti di dati IPv4 tra le VM: tutti i protocolli IPv4.
• Pacchetti di dati IPv4 tra VM e internet: i protocolli ICMP, IPIP, TCP, UDP, GRE, ESP, AH e SCTP.
• Pacchetti di dati IPv6 tra le VM e tra le VM e internet: i protocolli AH, ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP e UDP e le intestazioni dell'estensione Opzioni di destinazione e Fragments. Tuttavia, non è supportato il posizionamento dell'intestazione Opzioni di destinazione dopo l'intestazione Frammento in un pacchetto di dati IPv6.
• Inoltro del protocollo:i protocolli AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP e UDP

Per consentire i pacchetti di dati dei protocolli supportati, devi configurare le regole firewall o le regole di forwarding del protocollo in base ai tuoi requisiti.

Rendimento della rete

Latenza

La latenza misurata tra regioni per le reti Google Cloud è disponibile nella nostra dashboard dal vivo. La dashboard mostra le metriche e la metodologia delle prestazioni mediane di latenza e velocità effettiva tra regioni di Google Cloud per riprodurre questi risultati utilizzando il Benchmarker PerfKit.

In genere, Google Cloud misura latenze di andata e ritorno inferiori a 55 μs al 50° percentile e latenze di coda inferiori a 80 μs al 99° percentile tra le istanze VM c2-standard-4 nella stessa zona.

In genere Google Cloud misura latenze di andata e ritorno inferiori a 45 μs al 50° percentile e latenze di coda inferiori a 60 μs al 99° percentile tra le istanze VM c2-standard-4 nella stessa rete a bassa latenza (criterio di posizionamento "compatto"). Un criterio di posizionamento compatto riduce la latenza di rete garantendo che le VM si trovino fisicamente all'interno della stessa rete a bassa latenza.

Metodologia: la latenza intrazona è monitorata tramite un prober blackbox che esegue costantemente netperf TCP_RR benchmark tra una coppia di VM di tipo c2 in ogni zona c2 sono disponibili. Raccoglie i risultati P50 e P99 per la configurazione con e senza criterio di posizionamento compatto. Il benchmark TCP_RR misura le prestazioni di richiesta/risposta misurando il tasso di transazione. Se le tue applicazioni richiedono la migliore latenza possibile, si consiglia di utilizzare le istanze c2.

Perdita pacchetti

Google Cloud monitora la perdita di pacchetti tra regioni misurando regolarmente la perdita di round trip tra tutte le regioni. Il nostro obiettivo è che la media globale di queste misurazioni sia inferiore allo 0,01% .

Metodologia: una blackbox vm-to-vm prober monitora la perdita di pacchetti per ogni coppia di zone tramite ping e aggrega i risultati in un'unica metrica di perdita globale. Questa metrica viene monitorata con una finestra di un giorno.

Passaggi successivi

• Crea, modifica o elimina reti e subnet VPC.

Provalo

Se non hai mai utilizzato Google Cloud, crea un account per valutare le prestazioni del VPC in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Prova VPC gratuitamente