Larghezza di banda della rete

Google Cloud tiene conto della larghezza di banda per istanza di calcolo, non per interfaccia di rete virtuale (vNIC) o indirizzo IP. Il tipo di macchina di un'istanza definisce la percentuale massima di traffico in uscita possibile. Tuttavia, puoi raggiungerla solo in situazioni specifiche.

Questa pagina descrive le aspettative, utili per pianificare i deployment. Classifica la larghezza di banda utilizzando due dimensioni:

  • In uscita o in entrata: come vengono utilizzati in questa pagina, i dati in uscita e in entrata vengono sempre dal punto di vista di un'istanza Google Cloud:
    • I pacchetti inviati da un'istanza Google Cloud compongono il proprio traffico in uscita (in uscita).
    • I pacchetti inviati a un'istanza Google Cloud compongono il suo traffico in entrata (in entrata).
  • Modalità di routing del pacchetto: un pacchetto può essere instradato da un'istanza di invio o a un'istanza ricevente utilizzando route i cui hop successivi si trovano all'interno di una rete VPC o route all'esterno di una rete VPC.

Né le interfacce di rete virtuali (vNIC) aggiuntive né gli indirizzi IP aggiuntivi per vNIC aumentano la larghezza di banda in entrata o in uscita per un'istanza di computing. Ad esempio, una VM C3 con 22 vCPU è limitata a una larghezza di banda totale in uscita di 23 Gbps. Se configuri la VM C3 con due vNIC, la VM è comunque limitata a una larghezza di banda totale in uscita di 23 Gbps, non di 23 Gbps per vNIC.

Tutte le informazioni riportate in questa pagina sono applicabili alle istanze di calcolo di Compute Engine, nonché ai prodotti che dipendono da queste istanze. Ad esempio, un nodo di Google Kubernetes Engine è un'istanza di Compute Engine.

Riepilogo larghezza di banda

La tabella seguente illustra le aspettative di larghezza di banda in base al fatto che un pacchetto venga inviato da un'istanza di computing o ricevuto (in uscita) da un'istanza di computing e dal metodo di routing dei pacchetti.

In uscita

Aspettative di larghezza di banda
Routing all'interno di una rete VPC
  • Definita principalmente da una larghezza di banda in uscita massima per istanza in base al tipo di macchina dell'istanza di invio e all'abilitazione o meno del networking Tier_1.

    • Le VM N2, N2D, C2 e C2D con supporto di rete Tier_1 supportano limiti di larghezza di banda in uscita fino a 100 Gbit/s.
    • Le VM H3 supportano limiti di larghezza di banda in uscita da VM a VM fino a 200 Gbit/s.
    • Le istanze X4, A2 e G2 supportano limiti di larghezza di banda in uscita fino a 100 Gbit/s.
    • Le istanze A3 supportano limiti di larghezza di banda in uscita fino a 1800 Gbit/s.
    • Le istanze C3, C3D e Z3 supportano fino a 200 Gbit/s di larghezza di banda in uscita con il networking Tier_1.
  • Per altri fattori, definizioni e scenari, consulta la sezione In uscita verso destinazioni con routing all'interno di una rete VPC.
Routing all'esterno di una rete VPC
  • Definita principalmente da una larghezza di banda in uscita massima per istanza in base al tipo di macchina dell'istanza di invio e all'abilitazione o meno del networking Tier_1. Ad eccezione delle VM H3, il traffico in uscita massimo possibile per un'istanza di invio verso una destinazione al di fuori della rete VPC non può superare i valori seguenti:

    • 7 Gbps in totale quando il networking Tier_1 non è abilitato
    • 25 Gbps totali quando il networking Tier_1 è abilitato
    • 3 Gbps per flusso
  • Per altri fattori, definizioni e avvertenze, consulta In uscita verso destinazioni al di fuori di una rete VPC.

In entrata

Aspettative di larghezza di banda
Routing all'interno di una rete VPC
  • In genere, le tariffe in entrata sono simili a quelle in uscita per un tipo di macchina.
  • Le dimensioni dell'istanza Compute, la capacità del NIC del server, il traffico in entrata in altre VM guest in esecuzione sullo stesso hardware host, la configurazione di rete del sistema operativo guest e il numero di letture su disco eseguite dall'istanza possono influire sulla velocità in entrata.
  • Google Cloud non impone ulteriori limitazioni alle tariffe in entrata all'interno di una rete VPC.
  • Per altri fattori, definizioni e scenari, consulta la sezione In entrata nelle destinazioni instradabili all'interno di una rete VPC.
Routing all'esterno di una rete VPC
  • Google Cloud protegge ogni istanza di computing limitando il traffico in entrata instradato al di fuori di una rete VPC. Il limite è il primo dei seguenti tassi riscontrati:

    • 1.800.000 pps (pacchetti al secondo)
    • 30 Gbit/s
  • Per una serie di macchine che supporta più NIC fisiche come A3, il limite è la prima delle seguenti tariffe rilevate:

    • 1.800.000 pps (pacchetti al secondo) per NIC fisico
    • 30 Gbit/s per NIC fisico
  • Per altri fattori, definizioni e scenari, consulta la sezione In entrata in destinazioni al di fuori di una rete VPC.

Larghezza di banda in uscita

Google Cloud limita la larghezza di banda in uscita utilizzando le tariffe massime di traffico in uscita per istanza. Queste tariffe dipendono dal tipo di macchina dell'istanza di computing che invia il pacchetto e dall'eventuale accesso alla destinazione del pacchetto tramite route all'interno di una rete VPC o route all'esterno di una rete VPC. La larghezza di banda in uscita include i pacchetti emessi da tutte le NIC dell'istanza e i dati trasferiti a tutti i volumi Hyperdisk e Persistent Disk connessi all'istanza.

Larghezza di banda in uscita massima per istanza

La larghezza di banda in uscita massima per istanza è generalmente di 2 Gbps per vCPU, ma esistono alcune differenze ed eccezioni a seconda della serie di macchine. La tabella seguente mostra l'intervallo di limiti massimi per la larghezza di banda in uscita per il traffico instradato all'interno di una rete VPC solo per il livello di rete standard, non per le prestazioni di rete Tier_1 per VM.

Serie di macchine Limite massimo in uscita più basso per istanza senza networking Tier_1 Limite massimo di traffico in uscita più alto per istanza senza networking Tier_1
E2 1 Gbit/s 16 Gbps
C3 23 Gbit/s 100 Gbit/s
C3D 20 Gbit/s 100 Gbit/s
C2 e C2D 10 Gbps 32 Gbit/s
E2 1 Gbit/s 16 Gbps
H3 N/A 200 Gbit/s
N4 10 Gbps 50 Gbit/s
N2 e N2D 10 Gbps 32 Gbit/s
N1 (escluse le VM con 1 vCPU) 10 Gbps 32 Gbps sulla piattaforma CPU Intel Skylake
16 Gbps su piattaforme CPU precedenti a Intel Skylake
Tipi di macchina N1 con 1 vCPU, f1-micro e g1-small 2 Gbit/s 2 Gbit/s
T2D 10 Gbps 32 Gbit/s
X4 N/A 100 Gbit/s
Z3 23 Gbit/s 100 Gbit/s

Puoi trovare la larghezza di banda in uscita massima per istanza per ogni tipo di macchina elencato nella pagina della famiglia di macchine specifica:

La larghezza di banda massima in uscita per istanza non è una garanzia. L'effettiva larghezza di banda in uscita può essere ridotta in base a fattori quali il seguente elenco non esaustivo:

  • Usare VirtIO invece di gVNIC con istanze di calcolo che supportano
  • Dimensione pacchetto
  • Overhead del protocollo
  • Il numero di flussi
  • Impostazioni del driver Ethernet del sistema operativo guest dell'istanza Compute, come offload per checksum e segmentazione TCP (TSO).
  • Congestione della rete
  • In una situazione in cui gli I/O di dischi permanenti competono con altro traffico di rete in uscita, il 60% della larghezza di banda massima della rete viene assegnato alle operazioni di scrittura su Persistent Disk, lasciando il 40% per l'altro traffico di rete in uscita. Per ulteriori dettagli, consulta Fattori che influiscono sulle prestazioni del disco.

Per ottenere la larghezza di banda in uscita massima per istanza:

  • Abilita le prestazioni di rete Tier_1 per VM con tipi di macchine più grandi.
  • Utilizza l'unità massima di trasmissione (MTU) della rete VPC più grande supportata dalla topologia di rete. MTU più grandi possono ridurre l'overhead delle intestazioni dei pacchetti e aumentare la velocità effettiva dei dati del payload.
  • Utilizza la versione più recente del driver gVNIC.
  • Usa serie di macchine di terza generazione o successive che usano Titanium per trasferire l'elaborazione di rete dalla CPU host.

In uscita verso destinazioni instradabili all'interno di una rete VPC

Dal punto di vista di un'istanza di invio e per gli indirizzi IP di destinazione accessibili tramite route all'interno di una rete VPC, Google Cloud limita il traffico in uscita utilizzando queste regole:

  • Larghezza di banda in uscita massima per VM: la larghezza di banda in uscita massima per istanza descritta nella sezione Larghezza di banda in uscita massima per istanza.
  • Larghezza di banda in uscita tra regioni per progetto: se un'istanza di invio e una destinazione interna o il suo hop successivo si trovano in regioni diverse, Google Cloud applica un limite massimo di larghezza di banda in uscita tra regioni. È improbabile che la maggior parte dei clienti raggiunga questo limite. Per domande su questo limite, invia una richiesta di assistenza.
  • Limiti di Cloud VPN e Cloud Interconnect: quando invii traffico da un'istanza a un indirizzo IP interno instradabile tramite un tunnel Cloud VPN dell'hop successivo o un collegamento VLAN di Cloud Interconnect, la larghezza di banda in uscita è limitata da:

Le destinazioni instradabili all'interno di una rete VPC includono tutte le seguenti destinazioni, ognuna delle quali è accessibile dal punto di vista dell'istanza di invio tramite una route il cui hop successivo non è il gateway internet predefinito:

  • Indirizzi IPv4 interni regionali negli intervalli di indirizzi IPv4 principali e di subnet della subnet, inclusi intervalli di indirizzi IPv4 privati e intervalli di indirizzi IPv4 pubblici utilizzati privatamente, utilizzati da queste risorse di destinazione:
    • L'indirizzo IPv4 interno principale dell'interfaccia di rete (vNIC) di un'istanza ricevente. Quando un'istanza di invio si connette all'indirizzo IPv4 esterno di un'altra istanza, i pacchetti vengono instradati utilizzando un gateway internet predefinito dell'hop successivo, quindi si applica invece il traffico in uscita verso destinazioni esterne a una rete VPC.
    • Un indirizzo IPv4 interno in un intervallo IP alias della vNIC di un'istanza ricevente.
    • Un indirizzo IPv4 interno di una regola di forwarding interno per l'inoltro del protocollo o per un bilanciatore del carico di rete passthrough interno.
  • Indirizzi IPv4 interni globali per queste risorse di destinazione:
  • Intervalli di indirizzi di subnet IPv6 interni utilizzati da queste risorse di destinazione:
    • Un indirizzo IPv6 nell'intervallo di indirizzi IPv6 /96 assegnato al vNIC di un'istanza a doppio stack che riceve.
    • Un indirizzo IPv6 nell'intervallo di indirizzi IPv6 /96 di una regola di forwarding interno per l'inoltro del protocollo o per un bilanciatore del carico di rete passthrough interno.
  • Intervalli di indirizzi di subnet IPv6 esterni utilizzati da queste risorse di destinazione quando i pacchetti vengono instradati tramite route di subnet o route di subnet di peering all'interno della rete VPC o da route personalizzate all'interno della rete VPC che non utilizzano l'hop successivo del gateway internet predefinito:
    • Un indirizzo IPv6 nell'intervallo di indirizzi IPv6 /96 assegnato al vNIC di un'istanza a doppio stack che riceve.
    • Un indirizzo IPv6 nell'intervallo di indirizzi IPv6 /96 di una regola di forwarding esterno per il forwarding del protocollo o per un bilanciatore del carico di rete passthrough esterno.
  • Altre destinazioni accessibili tramite le seguenti route di rete VPC:

Il seguente elenco classifica il traffico dall'invio delle istanze alle destinazioni interne, dalla larghezza di banda massima alla più bassa:

In uscita verso destinazioni esterne a una rete VPC

Dal punto di vista di un'istanza di invio e per gli indirizzi IP di destinazione all'esterno di una rete VPC, Google Cloud limita il traffico in uscita a qualsiasi tra le seguenti tariffe venga raggiunta per prima:

  • Larghezza di banda in uscita per istanza: la larghezza di banda massima per tutte le connessioni da un'istanza Compute verso destinazioni all'esterno di una rete VPC è la minore tra la larghezza di banda in uscita massima per istanza e una delle seguenti tariffe:

    • 25 Gbps, se il networking Tier_1 è abilitato
    • 7 Gbps, se il networking Tier_1 non è abilitato
    • 1 Gbps per istanze H3
    • 7 Gbit/s per NIC fisico per le serie di macchine che supportano più NIC fisiche, ad esempio A3.

    Ad esempio, anche se un'istanza c3-standard-44 ha una larghezza di banda in uscita massima per VM di 32 Gbps, la larghezza di banda in uscita per VM da una VM c3-standard-44` verso destinazioni esterne è di 25 Gbps o 7 Gbps, a seconda che il networking Tier_1 sia abilitato.

  • Frequenza massima in uscita per flusso: la larghezza di banda massima per ogni connessione a 5 tuple univoca da un'istanza di computing a una destinazione esterna a una rete VPC è di 3 Gbps, tranne su H3, dove è di 1 Gbps.

  • Larghezza di banda in uscita da internet per progetto: la larghezza di banda massima per tutte le connessioni dalle istanze di calcolo in ogni regione di un progetto verso destinazioni al di fuori di una rete VPC è definita dalle quote della larghezza di banda in uscita da internet del progetto.

Le destinazioni all'esterno di una rete VPC includono tutte le seguenti destinazioni, ognuna delle quali è accessibile da una route nella rete VPC dell'istanza di invio, il cui hop successivo è il gateway internet predefinito:

  • Indirizzi IPv4 e IPv6 esterni globali per bilanciatori del carico di rete proxy esterni e bilanciatori del carico delle applicazioni esterni
  • Indirizzi IPv4 esterni regionali per le risorse Google Cloud, inclusi indirizzi IPv4 esterni vNIC delle VM, indirizzi IPv4 esterni per l'inoltro del protocollo esterno, bilanciatori del carico di rete passthrough esterni e pacchetti di risposta ai gateway Cloud NAT.
  • Indirizzi IPv6 esterni regionali in subnet a doppio stack con intervalli di indirizzi IPv6 esterni utilizzati da indirizzi IPv6 esterni di istanze a doppio stack, forwarding del protocollo esterno e bilanciatori del carico di rete passthrough esterni. La subnet deve trovarsi in una rete VPC separata non in peering. L'intervallo di indirizzi IPv6 di destinazione deve essere accessibile tramite una route nella rete VPC dell'istanza di invio il cui hop successivo è il gateway internet predefinito. Se una subnet a doppio stack con un intervallo di indirizzi IPv6 esterno si trova nella stessa rete VPC o in una rete VPC in peering, consulta invece In uscita verso destinazioni con routing all'interno di una rete VPC.
  • Altre destinazioni esterne accessibili tramite una route statica nella rete VPC dell'istanza di invio, a condizione che l'hop successivo per la route sia il gateway internet predefinito.

Per maggiori dettagli su quali risorse Google Cloud utilizzano quali tipi di indirizzi IP esterni, vedi Indirizzi IP esterni.

Larghezza di banda in entrata

Google Cloud gestisce la larghezza di banda in entrata (in entrata) a seconda di come il pacchetto in arrivo viene instradato a un'istanza di computing ricevente.

Ingress verso destinazioni instradabili all'interno di una rete VPC

Un'istanza ricevente è in grado di gestire tutti i pacchetti in entrata consentiti dal tipo di macchina, dal sistema operativo e da altre condizioni di rete. Google Cloud non implementa alcuna restrizione mirata della larghezza di banda sui pacchetti in entrata consegnati a un'istanza se il pacchetto in entrata viene consegnato utilizzando route all'interno di una rete VPC:

  • Route di subnet nella rete VPC dell'istanza ricevente
  • Route di subnet di peering in una rete VPC in peering
  • Route in un'altra rete i cui hop successivi sono tunnel Cloud VPN, collegamenti Cloud Interconnect (VLAN) o istanze di appliance router situate nella rete VPC dell'istanza ricevente

Le destinazioni dei pacchetti instradati all'interno di una rete VPC includono:

  • L'indirizzo IPv4 interno principale dell'interfaccia di rete (NIC) dell'istanza ricevente. Gli indirizzi IPv4 interni principali sono indirizzi IPv4 interni a livello di regione che provengono dall'intervallo di indirizzi IPv4 principali di una subnet.
  • Un indirizzo IPv4 interno da un intervallo IP alias del NIC dell'istanza ricevente. Gli intervalli IP alias possono provenire da un intervallo di indirizzi IPv4 principali di una subnet o da uno dei suoi intervalli di indirizzi IPv4 secondari.
  • Un indirizzo IPv6 nell'intervallo di indirizzi IPv6 /96 assegnato al NIC di un'istanza a doppio stack che riceve. Gli intervalli IPv6 delle istanze Compute possono provenire da questi intervalli IPv6 di subnet:
  • Un indirizzo IPv4 interno di una regola di forwarding utilizzata dall'inoltro del protocollo interno all'istanza ricevente o dal bilanciatore del carico di rete passthrough interno in cui l'istanza ricevente è un backend del bilanciatore del carico. Gli indirizzi IPv4 della regola di forwarding interno provengono dall'intervallo di indirizzi IPv4 principale di una subnet.
  • Un indirizzo IPv6 interno compreso nell'intervallo IPv6 /96 di una regola di forwarding utilizzata dall'inoltro del protocollo interno all'istanza ricevente o dal bilanciatore del carico di rete passthrough interno, in cui l'istanza ricevente è un backend del bilanciatore del carico. Gli indirizzi IPv6 della regola di forwarding interno provengono da un intervallo di indirizzi IPv6 interni di una subnet.
  • Un indirizzo IPv6 esterno compreso nell'intervallo IPv6 /96 di una regola di forwarding utilizzata dal protocollo esterno che esegue l'inoltro all'istanza ricevente o al bilanciatore del carico di rete passthrough esterno. L'istanza ricevente è un backend del bilanciatore del carico quando il pacchetto in arrivo viene instradato all'interno della rete VPC utilizzando una delle route elencate in precedenza in questa sezione. Gli indirizzi IPv6 della regola di forwarding esterno provengono dall'intervallo di indirizzi IPv6 esterni di una subnet.
  • Un indirizzo IP nell'intervallo di destinazione di una route statica personalizzata che utilizza l'istanza ricevente come istanza dell'hop successivo (next-hop-instance o next-hop-address).
  • Un indirizzo IP nell'intervallo di destinazione di una route statica personalizzata che utilizza l'hop successivo di un bilanciatore del carico di rete passthrough interno (next-hop-ilb), se l'istanza ricevente è un backend per il bilanciatore del carico.

In entrata verso destinazioni esterne a una rete VPC

Google Cloud implementa i seguenti limiti di larghezza di banda per i pacchetti in entrata consegnati a un'istanza di ricezione utilizzando route all'esterno di una rete VPC. Quando è necessario il bilanciamento del carico, i limiti della larghezza di banda vengono applicati singolarmente a ciascuna istanza ricevente.

Per le serie di macchine che non supportano più NIC fisiche, la limitazione della larghezza di banda in entrata applicabile si applica collettivamente a tutte le interfacce di rete virtuale (vNIC). Il limite è il primo dei seguenti tassi riscontrati:

  • 1.800.000 pacchetti al secondo
  • 30 Gbit/s

Per le serie di macchine che supportano più NIC fisiche, ad esempio A3, la limitazione della larghezza di banda in entrata applicabile si applica singolarmente a ogni NIC fisico. Il limite è il primo dei seguenti tassi riscontrati:

  • 1.800.000 pacchetti al secondo per NIC fisico
  • 30 Gbit/s per NIC fisico

Le destinazioni dei pacchetti instradati tramite route al di fuori di una rete VPC includono:

  • Un indirizzo IPv4 esterno assegnato in una configurazione di accesso NAT one-to-one su una delle interfacce di rete (NIC) dell'istanza ricevente.
  • Un indirizzo IPv6 esterno dall'intervallo di indirizzi IPv6 /96 assegnato a una vNIC di un'istanza di ricezione a doppio stack quando il pacchetto in entrata viene instradato tramite una route esterna alla rete VPC dell'istanza di ricezione.
  • Un indirizzo IPv4 esterno di una regola di forwarding utilizzata dal protocollo esterno che esegue l'inoltro all'istanza ricevente o al bilanciatore del carico di rete passthrough esterno in cui l'istanza ricevente è un backend del bilanciatore del carico.
  • Un indirizzo IPv6 esterno compreso nell'intervallo IPv6 /96 di una regola di forwarding utilizzata dal protocollo esterno che esegue l'inoltro all'istanza ricevente o al bilanciatore del carico di rete passthrough esterno. L'istanza ricevente deve essere un backend del bilanciatore del carico quando il pacchetto in arrivo viene instradato utilizzando una route esterna a una rete VPC.
  • Risposte in entrata stabilite elaborate da Cloud NAT.

Fotogrammi Jumbo

Per ricevere e inviare jumbo frame, configura la rete VPC utilizzata dalle istanze di calcolo; imposta l'unità massima di trasmissione (MTU) su un valore più alto, fino a 8896.

Valori di MTU più elevati aumentano la dimensione del pacchetto e riducono l'overhead dell'intestazione dei pacchetti, che aumenta la velocità effettiva dei dati del payload.

Puoi utilizzare i jumbo frame con il driver gVNIC versione 1.3 o successiva nelle istanze VM o con il driver IDPF nelle istanze bare metal. Non tutte le immagini pubbliche di Google Cloud includono questi driver. Per ulteriori informazioni sul supporto dei sistemi operativi per i jumbo frame, consulta la scheda Funzionalità di networking nella pagina Dettagli del sistema operativo.

Se utilizzi un'immagine sistema operativo che non supporta completamente i jumbo frame, puoi installare manualmente il driver gVNIC versione 1.3.0 o successiva. Google consiglia di installare la versione del driver gVNIC contrassegnata come Latest per poter usufruire di funzionalità aggiuntive e correzioni di bug. Puoi scaricare i driver gVNIC da GitHub.

Per aggiornare manualmente la versione del driver gVNIC nel sistema operativo guest, vedi Utilizzare su sistemi operativi non supportati.

Ricezione e trasmissione di code

A ogni NIC o vNIC per un'istanza Compute viene assegnato un numero di code di ricezione e trasmissione per l'elaborazione dei pacchetti dalla rete.

  • Coda di ricezione (RX): in coda per la ricezione dei pacchetti. Quando il NIC riceve un pacchetto dalla rete, seleziona il descrittore per un pacchetto in entrata dalla coda, lo elabora e lo passa al sistema operativo guest tramite una coda di pacchetti collegata a un core vCPU tramite un interruzione. Se la coda RX è piena e non è disponibile alcun buffer per posizionare un pacchetto, il pacchetto viene eliminato. Questo può accadere in genere se un'applicazione sta utilizzando un core vCPU che è anch'esso collegato alla coda di pacchetti selezionata.
  • Coda di trasmissione (TX): coda per la trasmissione dei pacchetti. Quando il sistema operativo guest invia un pacchetto, viene allocato un descrittore che viene inserito nella coda TX. Il NIC quindi elabora il descrittore e trasmette il pacchetto.

Allocazione predefinita della coda

A meno che non assegni esplicitamente il conteggio delle code per le NIC, puoi modellare l'algoritmo utilizzato da Google Cloud per assegnare un numero fisso di code RX e TX per NIC nel seguente modo:

  1. Per le istanze bare metal, esiste un solo NIC, quindi il conteggio delle code è sempre 16.

  2. Per le istanze VM, utilizza uno dei seguenti metodi, a seconda del tipo di interfaccia di rete:

    • VirtIO: dividi il numero di vCPU per il numero di vNIC e ignora tutto il resto: [number of vCPUs/number of vNICs].
    • gVNIC: dividi il numero di vCPU per il numero di vNIC, quindi dividi il risultato per 2 e ignora l'eventuale resto ([number of vCPUs/number of vNICs/2]).

    Questo calcolo restituisce sempre un numero intero (non una frazione).

  3. Se il numero calcolato è inferiore a 1, assegna invece una coda a ogni vNIC.

  4. Determina se il numero calcolato è maggiore del numero massimo di code per vNIC. Per le istanze VM, il numero massimo di code per vNIC dipende dal tipo di driver:

    • Se utilizzi virtIO o un driver personalizzato, il numero massimo di code per vNIC è 32. Se il numero calcolato è maggiore di 32, ignoralo e assegna invece ogni coda vNIC 32.
    • Utilizzando gVNIC, il numero massimo di code per vNIC è 16. Se il numero calcolato è maggiore di 16, ignora il numero calcolato e assegna invece ogni coda vNIC 16.

Gli esempi seguenti mostrano come calcolare il numero predefinito di code per un'istanza VM:

  • Se un'istanza VM utilizza VirtIO e ha 16 vCPU e 4 vNIC, il numero calcolato è [16/4] = 4. Google Cloud assegna quattro code a ogni vNIC.

  • Se un'istanza VM utilizza gVNIC e ha 128 vCPU e due vNIC, il numero calcolato è [128/2/2] = 32. Google Cloud assegna a ogni vNIC il numero massimo possibile di code per vNIC. Google Cloud assegna 16 code per vNIC.

Sui sistemi Linux, puoi utilizzare ethtool per configurare una vNIC con meno code rispetto al numero di code assegnate da Google Cloud per vNIC.

Allocazione personalizzata della coda

Invece dell'allocazione predefinita delle code, puoi assegnare un conteggio personalizzato delle code (totale sia di RX che di TX) a ogni vNIC quando crei una nuova istanza di computing utilizzando l'API Compute Engine.

Il numero di code personalizzate specificato deve rispettare le seguenti regole:

  • Il numero minimo di code che puoi assegnare per ogni vNIC è uno.

  • Il numero massimo di code che puoi assegnare a ogni vNIC di un'istanza VM è il più basso tra il numero di vCPU o il numero massimo di code per vNIC, in base al tipo di driver:

    • Se utilizzi virtIO o un driver personalizzato, il numero massimo di code è 32.
    • Utilizzando gVNIC, il numero massimo di code è 16.
  • Se assegni conteggi personalizzati di code a tutte le NIC dell'istanza di computing, la somma delle assegnazioni del conteggio code deve essere inferiore o uguale al numero di vCPU assegnate all'istanza.

Puoi sottoscrivere un abbonamento eccessivo del conteggio delle code personalizzate per le tue vNIC. In altre parole, si può avere una somma dei conteggi delle code assegnati a tutte le NIC per l'istanza VM, maggiore del numero di vCPU per l'istanza. Per sottoscrivere un abbonamento in eccesso rispetto al conteggio delle code personalizzate, l'istanza VM deve soddisfare le seguenti condizioni:

  • Utilizza gVNIC come tipo di vNIC per tutte le NIC configurate per l'istanza.
  • Utilizza un tipo di macchina che supporta il networking Tier_1.
  • Ha il networking Tier_1 abilitato.
  • Specificato un conteggio code personalizzato per tutte le NIC configurate per l'istanza.

Con l'oversubscription della coda, il numero massimo di code per l'istanza VM è 16 volte superiore al numero di NIC. Pertanto, se disponi di 6 NIC configurate per un'istanza con 30 vCPU, puoi configurare un massimo di (16 * 6) o 96 code personalizzate per l'istanza.

Esempi

  • Se un'istanza VM ha 8 vCPU e 3 NIC, il numero massimo di code per l'istanza è il numero di vCPU, ovvero 8. Puoi assegnare 1 coda a nic0, 4 code a nic1 e 3 code a nic2. In questo esempio, non puoi successivamente assegnare 4 code a nic2 conservando le altre due assegnazioni code vNIC, poiché la somma delle code assegnate non può superare il numero di vCPU (8).

  • Se un'istanza VM ha 96 vCPU e 2 NIC, è possibile assegnare a entrambe le NIC fino a 32 code ciascuna quando si utilizza il driver virtIO o fino a 16 code ciascuna quando si utilizza il driver gVNIC. In questo esempio, la somma delle code assegnate è sempre inferiore al numero di vCPU.

È anche possibile assegnare un conteggio personalizzato delle code solo per alcune NIC, consentendo a Google Cloud di assegnare le code alle NIC rimanenti. Il numero di code che puoi assegnare per vNIC è comunque soggetto alle regole menzionate in precedenza. Puoi modellare la fattibilità della configurazione e, se la configurazione è possibile, il numero di code che Google Cloud assegna alle NIC rimanenti con questo processo:

  1. Calcola la somma delle code per le NIC utilizzando l'assegnazione di code personalizzate. Per un'istanza VM con 20 vCPU e 6 NIC, supponi di assegnare nic0 5 code, nic1 6 code, nic2 4 code e lasciare che Google Cloud assegni code per nic3, nic4 e nic5. In questo esempio, la somma delle code assegnate personalmente è 5+6+4 = 15.

  2. Sottrai la somma delle code assegnate in modo personalizzato dal numero di vCPU. Se la differenza non è almeno uguale al numero di NIC rimanenti per cui Google Cloud deve assegnare code, Google Cloud restituisce un errore. Continuando con l'istanza di esempio di 20 vCPU e una somma di 15 code assegnate personalizzate, Google Cloud ha ancora 20-15 = 5 code da assegnare alle NIC rimanenti (nic3, nic4, nic5).

  3. Dividi la differenza rispetto al passaggio precedente per il numero di NIC rimanenti e ignora tutto il resto (⌊(number of vCPUs - sum of assigned queues)/(number of remaining NICs)⌋). Questo calcolo genera sempre un numero intero (non una frazione) maggiore di zero a causa del vincolo spiegato nel passaggio precedente. Google Cloud assegna a ogni NIC rimanente un conteggio di code corrispondente al numero calcolato, purché il numero calcolato non sia superiore al numero massimo di code per vNIC. Il numero massimo di code per vNIC dipende dal tipo di driver:

    • Tramite virtIO o un driver personalizzato, se il numero calcolato di code per ogni vNIC rimanente è maggiore di 32, Google Cloud assegna ogni coda 32 di vNIC rimanente.
    • Utilizzando gVNIC, se il numero calcolato di code per ogni vNIC rimanente è maggiore di 16, Google Cloud assegna ogni coda 16 di vNIC rimanente.

Configura conteggi personalizzati delle code

Per creare un'istanza Compute che utilizza un conteggio code personalizzato per una o più NIC o vNIC, completa i passaggi riportati di seguito.

gcloud

  1. Se non hai già una rete VPC con una subnet per ogni interfaccia vNIC che prevedi di configurare, creale.
  2. Utilizza il comando gcloud compute instances create per creare l'istanza Compute. Ripeti il flag --network-interface per ogni vNIC che vuoi configurare per l'istanza e includi l'opzione queue-count.
    gcloud compute instances create INSTANCE_NAME \
        --zone=ZONE \
        --machine-type=MACHINE_TYPE \
        --network-performance-configs=total-egress-bandwidth-tier=TIER_1  \
        --network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
        --network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2

Sostituisci quanto segue:

  • INSTANCE_NAME: un nome per la nuova istanza di computing
  • ZONE: la zona in cui creare l'istanza
  • MACHINE_TYPE: il tipo di macchina dell'istanza. Per sottoscrivere un abbonamento superiore al conteggio delle code, il tipo di macchina specificato deve supportare il networking gVNIC e Tier_1.
  • NETWORK_NAME: il nome della rete creata in precedenza
  • SUBNET_*: il nome di una delle subnet create in precedenza
  • QUEUE_SIZE: il numero di code per il vNIC, in base alle regole descritte in Allocazione delle code personalizzate.

Terraform

  1. Se non hai già una rete VPC con una subnet per ogni interfaccia vNIC che prevedi di configurare, creale.
  2. Crea un'istanza Compute con conteggi di code specifici per vNIC utilizzando la risorsa google_compute_instance. Ripeti il parametro --network-interface per ogni vNIC che vuoi configurare per l'istanza di computing e includi il parametro queue-count.

    # Queue oversubscription instance
    resource "google_compute_instance" "VM_NAME" {
    project      = "PROJECT_ID"
    boot_disk {
      auto_delete = true
      device_name = "DEVICE_NAME"
      initialize_params {
         image="IMAGE_NAME"
         size = DISK_SIZE
         type = "DISK_TYPE"
      }
    }
    machine_type = "MACHINE_TYPE"
    name         = "VM_NAME"
    zone = "ZONE"
    
    network_performance_config {
        total_egress_bandwidth_tier = "TIER_1"
    }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_1
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_1"
     }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_2
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_2"
    }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_3
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_3""
    }
    
    network_interface {
        nic_type = "GVNIC"
        queue_count = QUEUE_COUNT_4
        subnetwork_project = "PROJECT_ID"
        subnetwork = "SUBNET_4""
    }
    
    }
    
    

Sostituisci quanto segue:

  • VM_NAME: un nome per la nuova istanza di computing
  • PROJECT_ID: ID del progetto in cui creare l'istanza. A meno che tu non stia utilizzando una rete VPC condiviso, il progetto specificato deve essere lo stesso in cui sono state create tutte le subnet e le reti.
  • DEVICE_NAME: il nome da associare al disco di avvio nel sistema operativo guest
  • IMAGE_NAME: il nome di un'immagine, ad esempio "projects/debian-cloud/global/images/debian-11-bullseye-v20231010".
  • DISK_SIZE: le dimensioni del disco di avvio in GiB
  • DISK_TYPE: tipo di disco da utilizzare per il disco di avvio, ad esempio pd-standard
  • MACHINE_TYPE: il tipo di macchina dell'istanza. Per sottoscrivere un abbonamento superiore al conteggio delle code, il tipo di macchina specificato deve supportare il networking gVNIC e Tier_1.
  • ZONE: la zona in cui creare l'istanza
  • QUEUE_COUNT: il numero di code per il vNIC, in base alle regole descritte in Allocazione delle code personalizzate.
  • SUBNET_*: il nome della subnet a cui si collega l'interfaccia di rete

REST

  1. Se non hai già una rete VPC con una subnet per ogni interfaccia vNIC che prevedi di configurare, creale.
  2. Crea un'istanza Compute con conteggi di code specifici per le NIC utilizzando il metodo instances.insert. Ripeti la proprietà networkInterfaces per configurare più interfacce di rete.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
    {
    "name": "VM_NAME",
    "machineType": "machineTypes/MACHINE_TYPE",
    "networkPerformanceConfig": {
        "totalEgressBandwidthTier": TIER_1
    },
    "networkInterfaces": [
        {
          "nicType": gVNIC,
          "subnetwork":"regions/region/subnetworks/SUBNET_1",
          "queueCount": "QUEUE_COUNT_1"
        } ],
    "networkInterfaces": [
        {
          "nicType": gVNIC,
          "subnetwork":"regions/region/subnetworks/SUBNET_2",
          "queueCount": "QUEUE_COUNT_2"
        } ],
    }
    

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del progetto in cui creare l'istanza Compute
    • ZONE: zona in cui creare l'istanza Compute
    • VM_NAME: nome della nuova istanza di computing
    • MACHINE_TYPE: tipo di macchina, predefinita o personalizzata, per la nuova istanza di computing. Per sottoscrivere un numero eccessivo di code, il tipo di macchina deve supportare il networking gVNIC e Tier_1.
    • SUBNET_*: il nome della subnet a cui si connette l'interfaccia di rete
    • QUEUE_COUNT: numero di code per vNIC, in base alle regole descritte nella sezione Allocazione delle code personalizzate.

Allocazioni delle code e modifica del tipo di macchina

Le istanze di computing vengono create con un'allocazione predefinita delle code oppure puoi assegnare un conteggio delle code personalizzato a ogni scheda di interfaccia di rete virtuale (vNIC) quando crei una nuova istanza di computing utilizzando l'API Compute Engine. Le assegnazioni di code vNIC predefinite o personalizzate vengono impostate solo quando si crea un'istanza di computing. Se l'istanza ha vNIC che utilizzano i conteggi predefiniti delle code, puoi modificare il tipo di macchina. Se il tipo di macchina che stai passando ha un numero diverso di vCPU, i conteggi predefiniti delle code per la tua istanza vengono ricalcolati in base al nuovo tipo di macchina.

Se l'istanza Compute ha vNIC che utilizzano conteggi di code personalizzati non predefiniti, puoi modificare il tipo di macchina utilizzando Google Cloud CLI o l'API Compute Engine per aggiornare le proprietà dell'istanza. La conversione va a buon fine se l'istanza di computing risultante supporta lo stesso conteggio della coda per vNIC dell'istanza originale. Per le istanze di calcolo che utilizzano l'interfaccia VirtIO-Net e hanno un conteggio code personalizzato superiore a 16 per vNIC, non puoi modificare il tipo di macchina in una terza generazione o successiva, perché utilizzano solo gVNIC. Puoi invece eseguire la migrazione dell'istanza di computing a un tipo di macchina di terza generazione o successivo seguendo le istruzioni in Spostare il carico di lavoro in una nuova istanza di computing.

Passaggi successivi