Reti VPC

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

Una rete VPC svolge 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 i bilanciatori del carico delle applicazioni interni.
  • Si connette alle reti on-premise utilizzando i tunnel Cloud VPN e i collegamenti VLAN per Cloud Interconnect.
  • Distribuisce il traffico dai bilanciatori del carico esterni Google Cloud ai backend.

I progetti possono contenere più reti VPC. A meno che tu non crei una policy 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.

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 saperne di più, 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 consoleGoogle Cloud , nel riferimento Google Cloud CLI e nella documentazione dell'API.

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

Per saperne di più, consulta Istanze di macchine virtuali nella documentazione di Compute Engine.

Specifiche

Le reti VPC hanno le seguenti proprietà:

  • Le reti VPC, incluse le route e le regole firewall associate, sono risorse globali. Non sono associate a nessuna regione o zona particolare.

  • Le subnet sono risorse regionali.

  • Ogni subnet definisce i seguenti intervalli di indirizzi IP:

    • Le subnet solo IPv4 e a doppio stack definiscono entrambe un intervallo di indirizzi IPv4, mentre le subnet a doppio stack definiscono anche un intervallo di indirizzi IPv6.
    • Le subnet solo IPv6 (anteprima) definiscono un intervallo di indirizzi IPv6.

    Per saperne di più, consulta Tipi di subnet.

  • Il traffico da e verso le istanze può essere controllato con le regole firewall di rete. Le regole vengono implementate sulle VM stesse, quindi il traffico può essere controllato e registrato solo quando esce da una VM 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, in base alle regole firewall di rete applicabili. Per saperne di più, vedi Comunicazione all'interno della rete.

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

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

  • Un'organizzazione può utilizzare VPC condivisa 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, incluso il traffico su Cloud VPN e Cloud Interconnect. Le reti VPC non supportano GRE per Cloud NAT o per regole di forwarding per il bilanciamento del carico e il forwarding dei protocolli. Il supporto di 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 ti consente di utilizzare servizi come Secure Access Service Edge (SASE) e SD-WAN.

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

    Per saperne di più sugli intervalli di subnet IPv6, vedi Subnet.

Esempio di rete VPC

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

Esempio di rete VPC.
Esempio di rete VPC (fai clic per ingrandire).
  • Subnet1 è definita come 10.240.0.0/24 nella regione us-west1.
    • In questa subnet si trovano due istanze VM nella zona us-west1-a. I loro indirizzi IP provengono entrambi dall'intervallo di indirizzi disponibile in subnet1.
  • Subnet2 è definita come 192.168.1.0/24 nella regione us-east1.
    • In questa subnet si trovano due istanze VM nella zona us-east1-b. I loro indirizzi IP provengono entrambi dall'intervallo di indirizzi disponibile in subnet2.
  • Subnet3 è definita come 10.2.0.0/16, anch'essa nella regione us-east1.
    • Una VM nella zona us-east1-b e una seconda istanza nella zona us-east1-c si trovano in subnet3 e ognuna riceve un indirizzo IP dal proprio intervallo disponibile. Poiché le subnet sono risorse regionali, le istanze possono avere le interfacce di rete associate a qualsiasi subnet nella stessa regione che contiene le zone.

Vincoli dei criteri dell'organizzazione

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

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

    • Disabilita l'utilizzo di IPv6 all'esterno di VPC: se impostato su true, il vincolo constraints/compute.disableVpcExternalIpv6 impedisce la configurazione di subnet con intervalli IPv6 esterni.

    • Disattiva uso di IPv6 all'interno di VPC: se impostato su true, il vincolo constraints/compute.disableVpcInternalIpv6 impedisce la configurazione di subnet con intervalli IPv6 interni.

    • Disattiva tutti gli utilizzi di IPv6: se impostato su true, il vincolo constraints/compute.disableAllIpv6 disattiva la creazione o l'aggiornamento di qualsiasi subnet o altra risorsa di rete coinvolta nell'utilizzo di IPv6.

Per saperne di più sui vincoli, consulta la pagina Vincoli delle policy dell'organizzazione.

Modalità di creazione subnet

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

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

  • Quando viene creata una rete VPC in modalità personalizzata, non vengono create automaticamente subnet. Questo tipo di rete ti offre il controllo completo sulle subnet e sugli intervalli IP corrispondenti. Puoi decidere tu quali subnet creare nelle regioni di tua scelta utilizzando gli intervalli IP da te specificati.

Puoi passare dalla modalità automatica alla modalità personalizzata per una rete VPC. Si tratta di una conversione unidirezionale: le reti VPC in modalità personalizzata non possono essere convertite in reti VPC in modalità automatica. Per decidere quale tipo di rete soddisfa le tue esigenze, consulta le considerazioni per le 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 per le reti VPC in modalità automatica

Le reti VPC in modalità automatica sono facili da configurare e utilizzare e sono adatte a 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 utilizzeresti per scopi diversi (ad esempio, connessioni Cloud VPN alle 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 sono consigliate o richieste reti VPC in modalità personalizzata:

  • Non è necessario che venga creata automaticamente una subnet in ogni regione.

  • La creazione automatica di nuove subnet man mano che diventano disponibili nuove regioni potrebbe sovrapporsi agli indirizzi IP utilizzati da subnet create manualmente o da route statiche oppure potrebbe interferire con la pianificazione di rete generale.

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

  • 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 tra loro utilizzando il peering di rete VPC o Cloud VPN.

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

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

Intervalli di subnet IPv4

Ogni subnet ha un intervallo di indirizzi IPv4 primario. Gli indirizzi interni principali per le seguenti risorse provengono dall'intervallo principale della subnet: istanze VM, bilanciatori del carico interni e forwarding del protocollo interno. Se vuoi, puoi aggiungere intervalli di indirizzi IP secondari a una subnet, che vengono utilizzati solo dagli intervalli IP alias. Tuttavia, puoi configurare intervalli IP alias per le istanze dall'intervallo primario 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. Consulta i limiti per rete per il numero di intervalli IP secondari che puoi definire.

Non è necessario che le subnet IPv4 formino un blocco CIDR contiguo predefinito, ma puoi farlo se vuoi. Ad esempio, le reti VPC in modalità automatica creano subnet che rientrano in un intervallo IP in modalità automatica predefinito.

Quando crei una subnet in una rete VPC in modalità personalizzata, scegli l'intervallo IPv4 da utilizzare. Per saperne di più, vedi intervalli validi, intervalli di subnet vietati e limitazioni per gli intervalli di subnet IPv4.

In ogni intervallo di subnet IPv4 primario sono presenti quattro indirizzi IP inutilizzabili. 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 nelle 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 non utilizzate di 10.128.0.0/9 sono riservate per un futuro Google Cloud utilizzo. Per informazioni sull'intervallo IPv4 utilizzato in ciascuna regione, vedi Intervalli di subnet IPv4 in modalità automatica.

Intervalli di subnet IPv6

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

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

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

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

    • Gli indirizzi GUA possono essere utilizzati per la comunicazione da VM a VM all'interno delle reti VPC e sono anche instradabili su internet.

Per saperne di più sugli intervalli di subnet IPv6, vedi Subnet.

Reti che supportano subnet con intervalli di indirizzi IPv6

Puoi creare subnet con intervalli di indirizzi IPv6 in una rete VPC in modalità personalizzata. Per ulteriori informazioni, consulta la sezione Utilizzare le subnet.

Le subnet con intervalli di indirizzi IPv6 non sono supportate in:

  • Reti VPC in modalità automatica, inclusa la rete predefinita
  • Reti precedenti

Se hai una rete VPC in modalità automatica a cui vuoi aggiungere subnet con intervalli di indirizzi IPv6, puoi procedere nel seguente modo:

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

  2. Crea nuove subnet a doppio stack o solo IPv6(anteprima). Puoi anche convertire le subnet solo IPv4 esistenti in dual-stack.

Route e regole firewall

Route

Le route definiscono i percorsi per i pacchetti che escono dalle istanze (traffico in uscita). Per maggiori dettagli sui tipi di Google Cloud itinerari, vedi Itinerari.

Modalità di routing dinamico

Ogni rete VPC ha una modalità di routing dinamico associata che controlla il comportamento di tutti i suoi router Cloud. I router Cloud gestiscono le sessioni BGP per i Google Cloud prodotti che utilizzano router Cloud�.

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

Annunci di route e indirizzi IP interni

All'interno di una rete VPC vengono pubblicizzati i seguenti indirizzi IP:

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 gli intervalli di subnet che utilizzano indirizzi IPv4 pubblici utilizzati privatamente vengono scambiati e se vengono scambiati gli intervalli di subnet IPv6 interni ed esterni. Gli indirizzi IPv4 interni globali non vengono mai scambiati utilizzando il 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 di connettività Google Cloud come Cloud VPN, Cloud Interconnect o Router Appliance:

  • Puoi annunciare gli indirizzi IP interni della rete VPC a un'altra rete (ad esempio una rete on-premise).
  • Sebbene la connettività tra una rete VPC e un'altra rete (ad esempio una rete on-premise) possa utilizzare il routing privato fornito da un prodotto di connettivitàGoogle Cloud , gli indirizzi IP dell'altra rete potrebbero essere anche instradabili pubblicamente. Tieni presente questo aspetto se una rete on-premise utilizza 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 quando 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 le risorse che dipendono dalle VM, come i nodi Google Kubernetes Engine). Entrambi i tipi di firewall controllano il traffico anche se si verifica tra 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, devono essere configurate anche regole firewall appropriate, poiché ogni rete ha una regola firewall implicita per negare tutto 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 tra istanze all'interno della rete. La rete predefinita include anche regole in entrata che consentono protocolli come RDP e SSH.

Le regole fornite con la rete predefinita vengono presentate anche come opzioni da applicare alle nuove reti VPC in modalità automatica che crei utilizzando la console Google Cloud .

Requisiti di 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 valida o una route personalizzata il cui intervallo IP di destinazione sia il più generale (0.0.0.0/0 per IPv4, ::/0 per IPv6). Questa route definisce il percorso verso internet. Per ulteriori informazioni, consulta Tipi di route.

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

  • Deve essere vera una delle seguenti condizioni:

    • L'istanza deve avere un indirizzo IP esterno. Un indirizzo IP esterno può essere assegnato a un'istanza al momento della creazione o dopo la creazione.

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

Comunicazioni e accesso per App Engine

Le regole firewall VPC si applicano alle risorse in esecuzione nella rete VPC, ad esempio le VM di Compute Engine. Per le istanze App Engine, le regole firewall funzionano nel seguente modo:

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

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

Per saperne di più su come controllare l'accesso alle istanze App Engine, consulta Sicurezza delle app.

Traceroute agli indirizzi IP esterni

Per motivi interni, Google Cloud aumenta il contatore TTL dei pacchetti che attraversano gli hop successivi nella rete di 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 alle destinazioni su internet.

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

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

Limiti di velocità effettiva in uscita

Le informazioni sul throughput di rete sono disponibili nella pagina Larghezza di banda della rete nella documentazione di Compute Engine.

Dimensione pacchetto

Puoi trovare informazioni sulla dimensione dei pacchetti 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 estensione:

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

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

Profili di rete per casi d'uso specifici

Google Cloud utilizza la risorsa del profilo di rete per preconfigurare determinate proprietà in una rete VPC per un caso d'uso specifico. Puoi specificare facoltativamente un profilo di rete fornito da Google Cloud quando crei la rete.

Il caso d'uso supportato dai profili di rete è l'esecuzione di carichi di lavoro AI su macchine con interfacce di rete (NIC) che supportano l'accesso diretto alla memoria remota (RDMA). Google Cloud fornisce un profilo di rete RDMA che consente di creare una rete Virtual Private Cloud (VPC) che supporta la connettività RDMA.

Per saperne di più, consulta la panoramica dei profili di rete.

Per saperne di più sull'esecuzione di workload AI in Google Cloud, consulta la documentazione di AI Hypercomputer.

Prestazioni di rete

Latenza

La latenza interregionale misurata per le reti Google Cloud è disponibile nella nostra dashboard live. La dashboard mostra la latenza interregionale mediana e le metriche sul rendimento del throughput di Google Cloud, nonché la metodologia per riprodurre questi risultati utilizzando PerfKit Benchmarker.

Google Cloud misura in genere 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.

Google Cloud misura in genere 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 assicurando che le VM si trovino fisicamente all'interno della stessa rete a bassa latenza.

Metodologia: la latenza intra-zona viene monitorata tramite un probe black box che esegue costantemente il benchmark netperf TCP_RR tra una coppia di VM di tipo c2 in ogni zona in cui sono disponibili istanze c2. Raccoglie i risultati P50 e P99 per la configurazione con e senza la policy di posizionamento compatto. Il benchmark TCP_RR misura le prestazioni di richiesta/risposta misurando la velocità delle transazioni. Se le tue applicazioni richiedono la migliore latenza possibile, ti consigliamo 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: un probe VM-to-VM blackbox monitora la perdita di pacchetti per ogni coppia di zone utilizzando i ping e aggrega i risultati in una metrica di perdita globale. Questa metrica viene monitorata con una finestra di un giorno.

Passaggi successivi

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni di VPC in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti senza addebiti per l'esecuzione, il test e il deployment dei workload.

Prova VPC gratuitamente