Larghezza di banda della rete

Google Cloud tiene conto della larghezza di banda per istanza di macchina virtuale (VM), non per interfaccia di rete virtuale (vNIC) o indirizzo IP. Il tipo di macchina di una VM definisce la velocità massima di uscita possibile; tuttavia, puoi raggiungere quella massima velocità in uscita possibile solo in situazioni specifiche.

Questa pagina descrive le aspettative, che sono utili quando pianifichi le implementazioni. Categorizza la larghezza di banda in base a due dimensioni:

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

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

Tutte le informazioni in questa pagina sono applicabili alle VM di Compute Engine e ai prodotti che dipendono dalle VM di Compute Engine. Ad esempio, un nodo Google Kubernetes Engine è una VM Compute Engine.

Riepilogo larghezza di banda

La seguente tabella illustra le aspettative di larghezza di banda a seconda che un pacchetto venga inviato (in uscita) o ricevuto (in entrata) da una VM e al metodo di routing dei pacchetti.

In uscita

Aspettative relative alla larghezza di banda
Routing all'interno di una rete VPC

  • Definito principalmente da una larghezza di banda in uscita massima per VM in base al tipo di macchina della VM di invio e all'abilitazione del networking Tier_1.

    • Le VM N2, N2D, C2 e C2D con networking 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 VM A2 e G2 supportano limiti di larghezza di banda in uscita fino a 100 Gbit/s.
    • Le VM A3 supportano limiti di larghezza di banda in uscita fino a 1000 Gbit/s.
    • Le VM C3, C3D e Z3 supportano limiti di larghezza di banda in uscita fino a 200 Gbps con il networking Tier_1.
  • Per altri fattori, definizioni e scenari, consulta la pagina In uscita verso destinazioni instradabili all'interno di una rete VPC.
Routing all'esterno di una rete VPC

  • Definito principalmente da una larghezza di banda in uscita massima per VM in base al tipo di macchina della VM di invio e all'abilitazione del networking Tier_1. Ad eccezione delle VM H3, il traffico in uscita massimo possibile di una VM di invio verso una destinazione esterna alla sua rete VPC non può superare quanto segue:

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

In entrata

Aspettative relative alla larghezza di banda
Routing all'interno di una rete VPC
  • In genere, le velocità in entrata sono simili a quelle in uscita per un tipo di macchina.
  • Le dimensioni della VM, la capacità del NIC del server, il traffico in entrata in altre VM guest in esecuzione sullo stesso hardware host, la configurazione della rete del sistema operativo guest e il numero di letture del disco eseguite dalla VM possono influire sulla velocità in entrata.
  • Google Cloud non impone ulteriori limitazioni alle velocità in entrata all'interno di una rete VPC.
  • Per altri fattori, definizioni e scenari, consulta la pagina In entrata verso destinazioni instradabili all'interno di una rete VPC.
Routing all'esterno di una rete VPC

  • Google Cloud protegge ogni VM limitando il traffico in entrata instradato all'esterno di una rete VPC. Il limite corrisponde alla prima delle seguenti tariffe rilevate:

    • 1.800.000 pps (pacchetti al secondo)
    • 30 Gbit/s
  • Per le serie di macchine che supportano più NIC fisiche come A3, il limite corrisponde alla prima delle seguenti tariffe riscontrate:
    • 1.800.000 pps (pacchetti al secondo) per NIC fisico
    • 30 Gbps per NIC fisico
  • Per altri fattori, definizioni e scenari, consulta la pagina relativa all'ingresso verso destinazioni al di fuori di una rete VPC.

Larghezza di banda in uscita

Google Cloud limita la larghezza di banda in uscita utilizzando le velocità di uscita massime per VM in base al tipo di macchina della VM che invia il pacchetto e all'accessibilità della destinazione del pacchetto utilizzando 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 tutti i NIC della VM e i dati trasferiti su tutti i dischi permanenti connessi alla VM.

Larghezza di banda in uscita massima per VM

La larghezza di banda in uscita massima per VM è in genere di 2 Gbps per vCPU, ma esistono alcune differenze ed eccezioni a seconda della serie di macchine. La seguente tabella 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 networking standard, non per le prestazioni di rete Tier_1 per VM.

Serie di macchine Limite massimo in uscita per VM più basso senza networking Tier_1 Limite massimo in uscita per VM senza networking Tier_1
E2 1 Gbit/s 16 Gbps
C3 23 Gbit/s 100 Gbit/s
C3D 20 Gbit/s 100 Gbit/s
T2D 10 Gbps 32 Gbit/s
N2, C2, N2D e C2D 10 Gbps 32 Gbit/s
N4 10 Gbps 50 Gbit/s
H3 N/D 200 Gbit/s
Z3 23 Gbit/s 100 Gbit/s
N1 (VM escluse con 1 vCPU) 10 Gbps 32 Gbps sulla piattaforma CPU Intel Skylake
16 Gbit/s 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
A3, A2 e G2 N/D In base al tipo di GPU

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

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

  • Driver Ethernet guest: gVNIC offre prestazioni migliori rispetto all'interfaccia di rete VirtIO
  • Dimensioni pacchetto
  • Overhead del protocollo
  • Il numero di flussi
  • Impostazioni del driver Ethernet del sistema operativo guest della VM, come l'offload del checksum e l'offload della segmentazione TCP (TSO)
  • Congestione della rete
  • In una situazione in cui i dischi permanenti competono con altro traffico di rete in uscita, il 60% della larghezza di banda massima di rete viene assegnato alle scritture di Persistent Disk, lasciando il 40% per il resto del traffico di rete in uscita. Per ulteriori dettagli, consulta Fattori che influiscono sulle prestazioni del disco nella documentazione di Persistent Disk.

Per ottenere la larghezza di banda in uscita massima possibile per VM:

  • Abilita le prestazioni di rete Tier_1 per VM con tipi di macchine per uso generico e ottimizzate per il calcolo più grandi.
  • Utilizza la più grande unità di trasmissione massima (MTU) della rete VPC più grande supportata dalla tua topologia di rete. MTU più grandi possono ridurre l'overhead dell'intestazione dei pacchetti e aumentare la velocità effettiva dei dati del payload.

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

Dal punto di vista di una VM 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 VM descritta nella sezione Larghezza di banda in uscita massima per VM.
  • Larghezza di banda in uscita tra regioni diverse per progetto: se una VM di invio e una destinazione interna o l'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 il traffico da una VM a una destinazione di indirizzo IP interno instradabile da un tunnel Cloud VPN o un collegamento VLAN di Cloud Interconnect successivo, 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 della VM di invio tramite una route il cui hop successivo non sia il gateway internet predefinito:

  • Indirizzi IPv4 interni a livello di regione negli intervalli di indirizzi IPv4 principali della subnet e degli intervalli di indirizzi IPv4 secondari 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 una VM ricevente. (quando una VM di invio si connette all'indirizzo IPv4 esterno vNIC di un'altra VM, i pacchetti vengono instradati utilizzando un gateway internet predefinito dell'hop successivo, quindi viene applicato il valore In uscita verso destinazioni al di fuori di una rete VPC).
    • Un indirizzo IPv4 interno in un intervallo IP alias del vNIC della VM ricevente.
    • Un indirizzo IPv4 interno di una regola di forwarding interno per l'inoltro di 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 dall'intervallo di indirizzi IPv6 /96 assegnato a una vNIC della VM a doppio stack.
    • Un indirizzo IPv6 dall'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 utilizzando 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 dall'intervallo di indirizzi IPv6 /96 assegnato a una vNIC della VM a doppio stack.
    • Un indirizzo IPv6 dell'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 utilizzando le seguenti route di rete VPC:

Il seguente elenco classifica il traffico dall'invio di VM alle destinazioni interne, dalla larghezza di banda massima possibile a quella più bassa:

In uscita verso destinazioni al di fuori di una rete VPC

Dal punto di vista di una VM di invio e per gli indirizzi IP di destinazione all'esterno di una rete VPC, Google Cloud limita il traffico in uscita a quale delle seguenti tariffe viene raggiunta per prima:

  • Larghezza di banda in uscita per VM: la larghezza di banda massima per tutte le connessioni da una VM a destinazioni al di fuori di una rete VPC è la minore tra la larghezza di banda in uscita massima per VM e una di queste tariffe:

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

    Ad esempio, anche se un'istanza n2-standard-16 ha una larghezza di banda in uscita massima per VM di 32 Gbit/s, la larghezza di banda in uscita per VM da un'istanza n2-standard-16 a destinazioni esterne è 25 Gbps o 7 Gbps, a seconda che la rete Tier_1 sia abilitata.

  • Velocità in uscita massima per flusso: la larghezza di banda massima per ogni connessione univoca a 5 tuple da una VM a una destinazione al di fuori di una rete VPC è di 3 Gbit/s, tranne H3, dove è pari a 1 Gbit/s.

  • Larghezza di banda in uscita da internet per progetto: la larghezza di banda massima per tutte le connessioni dalle VM in ciascuna regione di un progetto a destinazioni esterne a una rete VPC viene definita dalle quote di larghezza di banda in uscita da internet del progetto.

Le destinazioni al di fuori di una rete VPC includono tutte le seguenti destinazioni, ciascuna delle quali è accessibile da una route nella rete VPC della VM di invio il cui hop successivo è il gateway internet predefinito:

  • Indirizzi IPv4 e IPv6 esterni globali per bilanciatori del carico di rete con proxy esterno e Application Load Balancer esterni
  • Indirizzi IPv4 esterni regionali per le risorse Google Cloud, inclusi indirizzi IPv4 esterni vNIC delle VM, indirizzi IPv4 esterni per l'inoltro di protocolli esterni, 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 VM a due stack, forwarding del protocollo esterno e bilanciatori del carico di rete passthrough esterni, a condizione che la subnet si trovi in una rete VPC separata non in peering e l'intervallo di indirizzi IPv6 di destinazione sia accessibile utilizzando una route nella rete VPC della VM di invio, il cui hop successivo è il gateway 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 instradabili all'interno di una rete VPC.
  • Altre destinazioni esterne accessibili utilizzando una route statica nella rete VPC della VM 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 i tipi di indirizzi IP esterni, consulta 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 entrata viene instradato a una VM ricevente.

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

Una VM ricevente può gestire un numero di pacchetti in entrata illimitato a seconda del tipo di macchina, del sistema operativo e di altre condizioni di rete. Google Cloud non implementa alcuna restrizione mirata della larghezza di banda sui pacchetti in entrata consegnati a una VM se vengono consegnati utilizzando route all'interno di una rete VPC:

  • Route di subnet nella rete VPC della VM 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 VM dell'appliance router situate nella rete VPC della VM ricevente

Le destinazioni per i pacchetti che vengono instradati all'interno di una rete VPC includono:

  • L'indirizzo IPv4 interno principale dell'interfaccia di rete (vNIC) della VM 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 vNIC della VM ricevente. Gli intervalli IP alias possono provenire dall'intervallo di indirizzi IPv4 principali di una subnet o da uno degli intervalli di indirizzi IPv4 secondari.
  • Un indirizzo IPv6 dall'intervallo di indirizzi IPv6 /96 assegnato a una vNIC della VM a doppio stack. Gli intervalli IPv6 delle VM possono provenire da questi intervalli IPv6 di subnet:
  • Un indirizzo IPv4 interno di una regola di forwarding utilizzato dal protocollo interno che inoltra alla VM ricevente o al bilanciatore del carico di rete passthrough interno, dove la VM ricevente è un backend del bilanciatore del carico. Gli indirizzi IPv4 regola di forwarding interno provengono dall'intervallo di indirizzi IPv4 principali di una subnet.
  • Un indirizzo IPv6 interno dall'intervallo IPv6 /96 di una regola di forwarding utilizzato dall'inoltro del protocollo interno alla VM ricevente o al bilanciatore del carico di rete passthrough interno in cui la VM ricevente è un backend del bilanciatore del carico. Gli indirizzi IPv6 della regola di forwarding interno provengono dall'intervallo di indirizzi IPv6 interni di una subnet.
  • Un indirizzo IPv6 esterno dall'intervallo IPv6 /96 di una regola di forwarding utilizzata dal protocollo esterno di inoltro alla VM ricevente o al bilanciatore del carico di rete passthrough esterno in cui la VM ricevente è un backend del bilanciatore del carico quando il pacchetto in entrata viene instradato all'interno della rete VPC utilizzando una delle route elencate in precedenza in questa sezione. Gli indirizzi IPv6 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 la VM ricevente come VM dell'hop successivo (next-hop-instance o next-hop-address).
  • Un indirizzo IP all'interno dell'intervallo di destinazione di una route statica personalizzata che utilizza un hop successivo del bilanciatore del carico di rete passthrough interno (next-hop-ilb), se la VM 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 una VM ricevente utilizzando route all'esterno di una rete VPC. Quando è richiesto il bilanciamento del carico, i limiti di larghezza di banda vengono applicati singolarmente a ogni VM 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 NIC virtuali. Il limite corrisponde alla prima delle seguenti tariffe riscontrate:

  • 1.800.000 pacchetti al secondo
  • 30 Gbit/s

Per le serie di macchine che supportano più NIC fisiche, ad esempio A3, la limitazione applicabile della larghezza di banda in entrata si applica singolarmente a ciascuna NIC fisica. Il limite corrisponde alla prima delle seguenti tariffe riscontrati:

  • 1.800.000 pacchetti al secondo per NIC fisico
  • 30 Gbps per NIC fisico

Le destinazioni dei pacchetti il cui routing viene eseguito utilizzando route esterne a 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) della VM ricevente.
  • Un indirizzo IPv6 esterno dall'intervallo di indirizzi IPv6 /96 assegnato a un vNIC di una VM ricevente a doppio stack quando il pacchetto in entrata viene instradato utilizzando una route esterna alla rete VPC della VM ricevente.
  • Un indirizzo IPv4 esterno di una regola di forwarding utilizzato dal protocollo esterno che inoltra alla VM ricevente o al bilanciatore del carico di rete passthrough esterno, dove la VM ricevente è un backend del bilanciatore del carico.
  • Un indirizzo IPv6 esterno nell'intervallo IPv6 /96 di una regola di forwarding utilizzata dal protocollo esterno di inoltro alla VM ricevente o al bilanciatore del carico di rete passthrough esterno in cui la VM ricevente è un backend del bilanciatore del carico quando il pacchetto in entrata viene instradato utilizzando una route esterna a una rete VPC.
  • Risposte in entrata stabilite elaborate da Cloud NAT

Jumbo frame

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

Valori MTU più elevati aumentano le dimensioni del pacchetto e riducono l'overhead dell'intestazione dei pacchetti, con un conseguente aumento della velocità effettiva dei dati del payload.

Per utilizzare frame jumbo con il driver gVNIC, è necessario utilizzare la versione 1.3 o successiva del driver. Non tutte le immagini pubbliche di Google Cloud includono questa versione del driver. Per ulteriori informazioni sul supporto del sistema operativo per i jumbo frame, consulta la scheda Funzionalità di networking nella pagina Dettagli del sistema operativo. Le versioni immagine che indicano il supporto completo per i frame jumbo includono il driver gVNIC aggiornato, anche se il sistema operativo guest mostra la versione del driver gve come 1.0.0.

Se utilizzi un'immagine del sistema operativo che non ha il supporto completo per i frame jumbo, 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à e correzioni di bug aggiuntive. 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.

Code di ricezione e trasmissione

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

  • Ricevi coda (RX): coda per ricevere pacchetti. Quando il vNIC riceve un pacchetto dalla rete, vNIC seleziona il descrittore di un pacchetto in entrata dalla coda, lo elabora e passa il pacchetto al sistema operativo guest su una coda di pacchetti collegata al core di una vCPU utilizzando un'interruzione. Se la coda RX è piena e non è disponibile alcun buffer per inserire un pacchetto, il pacchetto viene eliminato. In genere questo può accadere se un'applicazione utilizza in modo eccessivo un core vCPU collegato anche alla coda di pacchetti selezionata.
  • Transmit Queue (TX): coda per la trasmissione dei pacchetti. Quando il sistema operativo guest invia un pacchetto, viene allocato un descrittore nella coda TX. vNIC elabora quindi il descrittore e trasmette il pacchetto.

Allocazione coda predefinita

A meno che tu non assegni esplicitamente i conteggi delle code per le NIC, puoi modellare l'algoritmo che Google Cloud utilizza per assegnare un numero fisso di code RX e TX per vNIC nel seguente modo:

  1. Utilizza uno dei seguenti metodi, a seconda del tipo di interfaccia di rete:

    • VirtIO: dividi il numero di vCPU per il numero di NIC ed elimina tutti i restanti, [number of vCPUs/number of NICs].
    • gVNIC: dividi il numero di vCPU per il numero di NIC, quindi dividi il risultato per 2 e ignora qualsiasi resto: [number of vCPUs/number of NICs/2].

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

  2. Se il numero calcolato è inferiore a 1, assegna ogni coda vNIC una sola coda.

  3. Determina se il numero calcolato è maggiore del numero massimo di code per vNIC. Il numero massimo di code per vNIC dipende dal tipo di driver:

    • Utilizzando 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, ignoralo e assegna invece ogni coda vNIC 16.

I seguenti esempi mostrano come calcolare il numero predefinito di code:

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

  • Se una VM che utilizza gVNIC e ha 128 vCPU e due NIC, 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 che Google Cloud assegna per vNIC.

Allocazione personalizzata della coda

Al posto dell'allocazione predefinita delle code, puoi assegnare un conteggio delle code personalizzato (totale sia di RX che di TX) a ogni vNIC quando crei una nuova VM 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 vNIC è uno.

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

    • Utilizzando 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 tutti i NIC della VM, la somma delle assegnazioni del conteggio delle code deve essere inferiore o uguale al numero di vCPU assegnate all'istanza VM.

Puoi sovrascrivere il numero di code personalizzate per le tue NIC. In altre parole, puoi avere una somma dei conteggi delle code assegnati a tutte le NIC della tua VM, maggiore del numero di vCPU per la tua VM. Per sottoscrivere un numero eccessivo di sottoscrizioni per il conteggio delle code personalizzate, devi soddisfare le seguenti condizioni:

  • Utilizzi gVNIC come tipo vNIC per tutte le NIC configurate per la VM.
  • La VM utilizza un tipo di macchina delle serie N2, N2D, C2 e C2D.
  • Hai abilitato il networking Tier_1 per la VM.
  • Hai specificato un conteggio di code personalizzato per tutte le NIC configurate per la VM.

Con la sottoscrizione di code in eccesso, il numero massimo di code per la VM è pari a 16 volte il numero di NIC. Quindi, se hai 6 NIC configurate per una VM con 30 vCPU, puoi configurare un massimo di (16 * 6) o 96 code personalizzate per la tua VM.

Esempi

  • Se una VM ha 8 vCPU e 3 NIC, il numero massimo di code per la VM è il numero di vCPU o 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 mantenendo le altre due assegnazioni di code vNIC perché la somma delle code assegnate non può superare il numero di vCPU (8).

  • Se una VM ha 96 vCPU e 2 NIC, puoi assegnare entrambe le NIC fino a 32 code quando utilizzi il driver VitIO o fino a 16 code ciascuna quando utilizzi il driver gVNIC. In questo esempio, la somma delle code assegnate è sempre inferiore al numero di vCPU.

Puoi anche assegnare un conteggio di code personalizzato solo per alcune NIC, in modo che Google Cloud possa assegnare code alle NIC rimanenti. Il numero di code che puoi assegnare per vNIC è ancora soggetto alle regole menzionate in precedenza. Puoi modellare la fattibilità della tua configurazione e, se la configurazione è possibile, il numero di code che Google Cloud assegna alle NIC rimanenti con questa procedura:

  1. Calcola la somma delle code per le NIC utilizzando l'assegnazione di code personalizzate. Per una VM di esempio con 20 vCPU e 6 NIC, supponi di assegnare nic0 5 code, nic1 6 code, nic2 4 code e consentire a Google Cloud di assegnare code per nic3, nic4 e nic5. In questo esempio, la somma delle code assegnate in modo personalizzato è 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. Proseguendo con la VM 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 del passaggio precedente per il numero di NIC rimanenti e ignora gli eventuali restanti: ⌊(number of vCPUs - sum of assigned queues)/(number of remaining NICs)⌋. Questo calcolo genera sempre un numero intero (non una frazione) che sia almeno uguale a uno a causa del vincolo spiegato nel passaggio precedente. Google Cloud assegna a ogni NIC rimanente un conteggio code corrispondente al numero calcolato, purché il numero calcolato non sia maggiore del numero massimo di code per vNIC. Il numero massimo di code per vNIC dipende dal tipo di driver:

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

Configurare conteggi di code personalizzati

Per creare una VM che utilizza un conteggio di code personalizzato per una o più vNIC, completa i passaggi seguenti.

gcloud

  1. Se non disponi già di una rete VPC con una subnet per ogni interfaccia vNIC che intendi configurare, creala.
  2. Utilizza il comando gcloud compute instances create per creare la VM. Ripeti il flag --network-interface per ogni vNIC che vuoi configurare per la VM e includi l'opzione queue-count.
    gcloud compute instances create VM_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:

  • VM_NAME: un nome per la nuova VM
  • ZONE: la zona in cui creare la VM
  • MACHINE_TYPE: il tipo di macchina della VM. 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 la vNIC, in base alle regole discusse in Allocazione di code personalizzata.

Terraform

  1. Se non disponi già di una rete VPC con una subnet per ogni interfaccia vNIC che intendi configurare, creala.

  2. Crea una VM con conteggi specifici di code per le vNIC utilizzando la risorsa google_compute_instance. Ripeti il parametro --network-interface per ogni vNIC che vuoi configurare per la VM 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 VM
  • PROJECT_ID: ID del progetto in cui creare la VM. A meno che non utilizzi 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: la dimensione del disco di avvio, in GiB
  • DISK_TYPE: il tipo di disco da utilizzare per il disco di avvio, ad esempio pd-standard
  • MACHINE_TYPE: il tipo di macchina della VM. Il tipo di macchina specificato deve supportare il networking gVNIC e Tier_1.
  • ZONE: la zona in cui creare la VM
  • QUEUE_COUNT: il numero di code per la vNIC, in base alle regole discusse in Allocazione di code personalizzata.
  • SUBNET_*: nome della subnet a cui si connette l'interfaccia di rete

REST

  1. Se non disponi già di una rete VPC con una subnet per ogni interfaccia vNIC che intendi configurare, creala.

  2. Crea una VM 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: ID del progetto in cui creare la VM
    • ZONE: zona in cui creare la VM
    • VM_NAME: nome della nuova VM
    • MACHINE_TYPE: tipo di macchina, predefinita o personalizzata, per la nuova VM
    • SUBNET_*: nome della subnet a cui si collega l'interfaccia di rete
    • QUEUE_COUNT: numero di code per la vNIC, soggette alle regole discusse in Allocazione di code personalizzata.

Allocazioni delle code e modifica del tipo di macchina

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

Se la tua VM ha vNIC che utilizzano conteggi di code personalizzati e 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 ha esito positivo se la VM risultante supporta lo stesso numero di code per vNIC della VM originale. Per le VM che utilizzano l'interfaccia VirtIO-Net e hanno un numero di code personalizzato superiore a 16 per vNIC, non puoi cambiare il tipo di macchina in un tipo di macchina di terza generazione, che utilizza solo gVNIC. Puoi invece eseguire la migrazione della VM a un tipo di macchina di terza generazione seguendo le istruzioni in Eseguire la migrazione del carico di lavoro da una VM esistente a una nuova VM.

Passaggi successivi