Larghezza di banda della rete

Trusted Cloud tiene conto della larghezza di banda per istanza di computing, non per interfaccia di rete virtuale (vNIC) o indirizzo IP. Il tipo di macchina di un'istanza ne determina il tasso in uscita massimo possibile. Tuttavia, puoi raggiungere questo tasso in uscita massimo solo in situazioni specifiche.

Questa pagina illustra i limiti di larghezza di banda della rete, utili per pianificare i deployment. Classifica la larghezza di banda tramite due dimensioni:

  • Traffico in uscita o in entrata: in riferimento all'uso in questa pagina, i concetti di traffico "in entrata" e "in uscita" rimandano sempre a un'istanza Trusted Cloud :
    • I pacchetti inviati da un'istanza Trusted Cloud costituiscono il traffico in uscita (outbound).
    • I pacchetti inviati a un'istanza Trusted Cloud costituiscono il suo traffico in entrata (inbound).
  • Come viene instradato il pacchetto: un pacchetto può essere instradato da un'istanza di invio o a un'istanza di ricezione utilizzando route i cui hop successivi si trovano all'interno di una rete VPC o route esterne a una rete VPC.

Né le interfacce di rete virtuali (vNIC) aggiuntive né gli indirizzi IP aggiuntivi tramite 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 in uscita totale di 23 Gbps. Se configuri la VM C3 con due vNIC, la VM è comunque limitata a una larghezza di banda in uscita totale di 23 Gbps, non a 23 Gbps per vNIC.

Per ottenere la larghezza di banda in entrata e in uscita più elevata possibile, configura le prestazioni di rete Tier_1 per VM per la tua istanza di computing.

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

Riepilogo della larghezza di banda

La tabella seguente illustra la larghezza di banda massima possibile in base al fatto che un pacchetto venga inviato da (in uscita) o ricevuto da (in entrata) un'istanza di computing e al metodo di instradamento dei pacchetti.

Limiti di larghezza di banda in uscita

Routing all'interno di
una rete VPC

  • Definite principalmente da una larghezza di banda in uscita massima per istanza in base al tipo di macchina dell'istanza di invio e all'eventuale attivazione della rete Tier_1.

    • Le VM N2, N2D, C2, C2D e C4A con rete Tier_1 supportano limiti di larghezza di banda in uscita fino a 100 Gbps.
    • Le VM H3 supportano limiti di larghezza di banda in uscita da VM a VM fino a 200 Gbps.
    • Le istanze X4, A2 e G2 supportano limiti di larghezza di banda in uscita fino a 100 Gbps.
    • Le istanze A4 e A3 supportano limiti di larghezza di banda in uscita fino a 3.600 Gbps.
    • Le istanze M4, C4, C4D, C3, C3D e Z3 supportano fino a 200 Gbps di limiti di larghezza di banda in uscita con la rete Tier_1.
  • Per altri fattori, definizioni e scenari, consulta Traffico in uscita verso destinazioni instradabili all'interno di una rete VPC.
Routing al di fuori
di una rete VPC

  • Definite principalmente da una larghezza di banda in uscita massima per istanza in base al tipo di macchina dell'istanza di invio e all'eventuale attivazione della rete Tier_1. Ad eccezione delle VM H3, il traffico in uscita massimo possibile di un'istanza di invio a una destinazione esternamente alla rete VPC non può superare quanto segue:

    • 7 Gbps totali quando la rete Tier_1 non è attivata
    • 25 Gbps totali quando la gestione della rete Tier_1 è attivata
    • 3 Gbps per flusso
  • Per altri fattori, definizioni e avvertenze, consulta Traffico in uscita verso destinazioni esterne a una rete VPC.

Limiti di larghezza di banda in entrata

Routing all'interno di
una rete VPC
  • In genere, le frequenze in ingresso sono simili a quelle in uscita per un tipo di macchina.
  • Per ottenere la larghezza di banda in ingresso più elevata possibile, abilita la rete Tier_1.
  • Le dimensioni dell'istanza di computing, la capacità della 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 del disco eseguite dall'istanza possono influire sulla frequenza in entrata.
  • Trusted Cloud by S3NS non impone limitazioni aggiuntive alle frequenze in ingresso all'interno di una rete VPC.
  • Per altri fattori, definizioni e scenari, consulta Traffico in ingresso alle destinazioni instradabili all'interno di una rete VPC.
Routing al di fuori
di una rete VPC

  • Trusted Cloud protegge ogni istanza di computing limitando il traffico in entrata indirizzato all'esterno di una rete VPC. Il limite è la prima delle seguenti frequenze rilevate:

    • 1.800.000 pps (pacchetti al secondo)
    • 30 Gbps

  • Per una serie di macchine che supporta più NIC fisiche, come A4 e A3, il limite è la prima delle seguenti frequenze rilevate:

    • 1.800.000 pps (pacchetti al secondo) per NIC fisica
    • 30 Gbps per NIC fisica
  • Per altri fattori, definizioni e scenari, consulta Traffico in ingresso a destinazioni esterne a una rete VPC.

Larghezza di banda in uscita

Trusted Cloud limita la larghezza di banda in uscita (outbound) utilizzando le frequenze in uscita massime per istanza. Queste frequenze si basano sul tipo di macchina dell'istanza di computing che invia il pacchetto e sul fatto che la destinazione del pacchetto sia accessibile 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 tutte le NIC dell'istanza e i dati trasferiti a tutti i volumi Hyperdisk e Persistent Disk collegati 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 indirizzato all'interno di una rete VPC solo per il tier di rete standard, non in base alle prestazioni di rete Tier_1 per VM.

Serie di macchine Limite massimo in uscita per istanza più basso per lo standard Limite massimo in uscita per istanza più elevato per lo standard
C4, C4A e C4D 10 Gbps 100 Gbps
C3 23 Gbps 100 Gbps
C3D 20 Gbps 100 Gbps
C2 e C2D 10 Gbps 32 Gbps
E2 1 Gbps 16 Gbps
H3 N/A 200 Gbps
M4 32 Gbps 100 Gbps
M3 e M1 32 Gbps 32 Gbps
M2 32 Gbps 32 Gbps sulla piattaforma CPU Intel Cascade Lake
16 Gbps su altre piattaforme CPU
N4 10 Gbps 50 Gbps
N2 e N2D 10 Gbps 32 Gbps
N1 (escluse le VM con 1 vCPU) 10 Gbps 32 Gbps sulla piattaforma CPU Intel Skylake
16 Gbps sulle piattaforme CPU precedenti a Intel Skylake
Tipi di macchine N1 con 1 vCPU, f1-micro e g1-small 2 Gbps 2 Gbps
T2D 10 Gbps 32 Gbps
X4 N/A 100 Gbps
Z3 23 Gbps 100 Gbps

Puoi trovare la larghezza di banda in uscita massima per istanza per ogni tipo di macchina elencato nella pagina delle famiglie di macchine specifiche:

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

  • Utilizzo di VirtIO anziché gVNIC con istanze di computing che supportano entrambe le tecnologie
  • Dimensione del pacchetto
  • Overhead del protocollo
  • Numero di flussi
  • Impostazioni del driver Ethernet del sistema operativo guest dell'istanza di computing, ad esempio il trasferimento del checksum e il trasferimento della segmentazione TCP (TSO)
  • Congestione della rete
  • In una situazione in cui gli I/O del Persistent Disk competono con altro traffico di rete in uscita, il 60% della larghezza di banda di rete massima viene assegnato alle scritture del 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 per istanza più grande possibile:

  • Attiva 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 della rete. MTU più grandi possono ridurre l'overhead delle intestazioni dei pacchetti e aumentare il throughput dei dati del payload.
  • Utilizza la versione più recente del driver gVNIC.
  • Utilizza una serie di macchine di terza generazione o successive che impiegano Titanium per trasferire l'elaborazione di rete dalla CPU host.

Traffico 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, Trusted Cloud limita il traffico in uscita utilizzando queste regole:

Le destinazioni instradabili all'interno di una rete VPC includono tutte le seguenti destinazioni, ciascuna 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 secondari della subnet, inclusi gli intervalli di indirizzi IPv4 privati e gli intervalli di indirizzi IPv4 pubblici utilizzati privatamente, utilizzati da queste risorse di destinazione:
    • L'indirizzo IPv4 interno principale di un'interfaccia di rete (vNIC) dell'istanza di ricezione. (Quando un'istanza di invio si connette all'indirizzo IPv4 esterno della vNIC di un'altra istanza, i pacchetti vengono instradati utilizzando un gateway internet predefinito di hop successivo, quindi si applica Traffico in uscita verso destinazioni esterne a una rete VPC.)
    • Un indirizzo IPv4 interno in un intervallo IP alias della vNIC di un'istanza di ricezione.
    • Un indirizzo IPv4 interno di una regola di forwarding interna per il forwarding 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 dall'intervallo di indirizzi IPv6 /96 assegnato alla vNIC di un'istanza di ricezione a doppio stack o solo IPv6 (anteprima).
    • Un indirizzo IPv6 dell'intervallo di indirizzi IPv6 /96 di una regola di forwarding interna per il forwarding 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 alla vNIC di un'istanza di ricezione a doppio stack o solo IPv6 (anteprima).
    • Un indirizzo IPv6 dell'intervallo di indirizzi IPv6 /96 di una regola di forwarding esterna 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 dalle istanze di invio alle destinazioni interne, dalla larghezza di banda massima a quella minima:

Traffico 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 al di fuori di una rete VPC, Trusted Cloud limita il traffico in uscita alla prima frequenza raggiunta tra le seguenti:

  • Larghezza di banda in uscita per istanza: la larghezza di banda massima per tutte le connessioni da un'istanza di computing a destinazioni esterne a una rete VPC è la più piccola tra la larghezza di banda in uscita massima per istanza e una di queste frequenze:

    • 25 Gbps, se la rete Tier_1 è abilitata
    • 7 Gbps, se la rete Tier_1 non è abilitata
    • 1 Gbps per le istanze H3
    • 7 Gbps per NIC fisica per le serie di macchine che supportano più NIC fisiche, ad esempio A4 e 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 a destinazioni esterne è di 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 quintupla 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 computing in ogni regione di un progetto alle destinazioni esterne a una rete VPC è definita dalle quote di larghezza di banda in uscita da internet del progetto.

Le destinazioni esterne a una rete VPC includono tutte le seguenti destinazioni, ciascuna accessibile tramite 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 a livello regionale per le risorse Trusted Cloud , inclusi gli indirizzi IPv4 esterni delle vNIC della VM, gli indirizzi IPv4 esterni per il forwarding del protocollo esterno, i bilanciatori del carico di rete passthrough esterni e i pacchetti di risposta ai gateway Cloud NAT.
  • Indirizzi IPv6 esterni a livello di regione in subnet a doppio stack o solo IPv6 (anteprima) con intervalli di indirizzi IPv6 esterni utilizzati da indirizzi IPv6 esterni di istanze a doppio stack o solo IPv6 (anteprima), inoltro di protocolli esterni e bilanciatori del carico di rete passthrough esterni. La subnet deve trovarsi in una rete VPC separata e non in peering. L'intervallo di indirizzi IPv6 di destinazione deve essere accessibile utilizzando una route nella rete VPC dell'istanza di invio il cui hop successivo è il gateway internet predefinito. Se una subnet a doppio stack o solo IPv6 con un intervallo di indirizzi IPv6 esterno si trova nella stessa rete VPC o in una rete VPC in peering, consulta Traffico in uscita verso destinazioni instradabili all'interno di una rete VPC.
  • Altre destinazioni esterne accessibili utilizzando 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 informazioni dettagliate sulle risorse Trusted Cloud che utilizzano i tipi di indirizzi IP esterni, consulta Indirizzi IP esterni.

Larghezza di banda in entrata

Trusted Cloud gestisce la larghezza di banda in entrata (inbound) a seconda di come il pacchetto in entrata viene indirizzato a un'istanza di computing di ricezione.

Traffico in ingresso alle destinazioni instradabili all'interno di una rete VPC

Un'istanza di ricezione può gestire tutti i pacchetti in entrata consentiti dal tipo di macchina, dal sistema operativo e da altre condizioni di rete. Trusted Cloud non implementa alcuna limitazione intenzionale della larghezza di banda per i pacchetti in entrata inviati a un'istanza se il pacchetto in entrata viene inviato utilizzando route all'interno di una rete VPC:

  • Route di subnet nella rete VPC dell'istanza di ricezione
  • Route delle 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 di ricezione

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

  • L'indirizzo IPv4 interno principale dell'interfaccia di rete (NIC) dell'istanza di ricezione. Gli indirizzi IPv4 interni principali sono indirizzi IPv4 interni regionali provenienti da un intervallo di indirizzi IPv4 principale di una subnet.
  • Un indirizzo IPv4 interno da un intervallo IP dell'alias della NIC dell'istanza di ricezione. Gli intervalli IP alias possono provenire dall'intervallo di indirizzi IPv4 primario di una subnet o da uno dei suoi intervalli di indirizzi IPv4 secondari.
  • Un indirizzo IPv6 dall'intervallo di indirizzi IPv6 /96 assegnato alla NIC di un'istanza di ricezione a doppio stack o solo IPv6 (anteprima). Gli intervalli IPv6 delle istanze di computing possono provenire da questi intervalli IPv6 di subnet:
  • Un indirizzo IPv4 interno di una regola di forwarding utilizzata dal forwarding del protocollo interno all'istanza di ricezione o al bilanciatore del carico di rete passthrough interno, dove l'istanza di ricezione è un backend del bilanciatore del carico. Gli indirizzi IPv4 della regola di forwarding interna provengono dall'intervallo di indirizzi IPv4 principale di una subnet.
  • Un indirizzo IPv6 interno dell'intervallo IPv6 /96 di una regola di forwarding utilizzata dal forwarding del protocollo interno all'istanza di ricezione o al bilanciatore del carico di rete passthrough interno, dove l'istanza di ricezione è un backend del bilanciatore del carico. Gli indirizzi IPv6 delle regole di forwarding interno provengono dall'intervallo di indirizzi IPv6 interno di una subnet.
  • Un indirizzo IPv6 esterno dall'intervallo IPv6 /96 di una regola di forwarding utilizzata dal forwarding del protocollo esterno all'istanza di ricezione o al bilanciatore del carico di rete passthrough esterno. L'istanza di ricezione è 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 della regola di forwarding esterno provengono dall'intervallo di indirizzi IPv6 esterno di una subnet.
  • Un indirizzo IP all'interno dell'intervallo di destinazione di una route statica personalizzata che utilizza l'istanza di ricezione come istanza di hop successivo (next-hop-instance o next-hop-address).
  • Un indirizzo IP compreso nell'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 l'istanza di ricezione è un backend per quel bilanciatore del carico.

Traffico in ingresso a destinazioni esterne a una rete VPC

Trusted Cloud implementa i seguenti limiti di larghezza di banda per i pacchetti in entrata inviati a un'istanza di ricezione utilizzando route all'esterno di una rete VPC. Quando è coinvolto il bilanciamento del carico, i limiti di larghezza di banda vengono applicati singolarmente a ogni istanza di ricezione.

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 virtuali (vNIC). Il limite è la prima delle seguenti frequenze rilevate:

  • 1.800.000 pacchetti al secondo
  • 30 Gbps

Per le serie di macchine che supportano più NIC fisiche, come A4 e A3, la limitazione della larghezza di banda in entrata applicabile si applica singolarmente a ogni NIC fisica. Il limite è la prima delle seguenti frequenze rilevate:

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

Le destinazioni per i pacchetti instradati 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) dell'istanza di ricezione.
  • Un indirizzo IPv6 esterno dell'intervallo di indirizzi IPv6 /96 assegnato a una vNIC di un'istanza di ricezione a doppio stack o solo IPv6 (anteprima) quando il pacchetto in arrivo viene instradato utilizzando una route esterna alla rete VPC dell'istanza di ricezione.
  • Un indirizzo IPv4 esterno di una regola di forwarding utilizzata dal forwarding del protocollo esterno all'istanza di destinazione o al bilanciatore del carico di rete passthrough esterno in cui l'istanza di ricezione è un backend del bilanciatore del carico.
  • Un indirizzo IPv6 esterno dall'intervallo IPv6 /96 di una regola di forwarding utilizzata dal forwarding del protocollo esterno all'istanza di ricezione o al bilanciatore del carico di rete passthrough esterno. L'istanza di ricezione deve essere 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.

Frame jumbo

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

Valori MTU più elevati aumentano le dimensioni dei pacchetti e riducono l'overhead delle intestazioni dei pacchetti, il che aumenta il throughput dei dati del payload.

Puoi utilizzare i frame jumbo con il driver gVNIC versione 1.3 o successive sulle istanze VM o con il driver IDPF sulle istanze bare metal. Non tutte le immagini pubbliche Trusted Cloud by S3NS includono questi driver. Per maggiori informazioni sul supporto del sistema operativo per i frame jumbo, consulta la scheda Funzionalità di rete nella pagina Dettagli sistema operativo.

Se utilizzi un'immagine sistema operativo che non supporta completamente 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 da Latest per 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, consulta Utilizzo su sistemi operativi non supportati.

Ricezione e trasmissione di code

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

  • Coda di ricezione (RX): coda per ricevere i pacchetti. Quando la NIC riceve un pacchetto dalla rete, seleziona il descrittore di un pacchetto in arrivo dalla coda, lo elabora e lo consegna al sistema operativo guest tramite una coda di pacchetti collegata a un core vCPU utilizzando un'interruzione. Se la coda RX è piena e non è disponibile alcun buffer per inserire un pacchetto, il pacchetto viene perso. In genere, questo può accadere se un'applicazione sfrutta in modo eccessivo un core vCPU collegato anche alla coda dei pacchetti selezionata.
  • Coda di trasmissione (TX): coda per la trasmissione dei pacchetti. Quando il sistema operativo guest invia un pacchetto, viene allocato un descrittore e inserito nella coda TX. La NIC quindi elabora il descrittore e trasmette il pacchetto.

Allocazione della coda predefinita

A meno che non assegni esplicitamente i numeri delle code per le NIC, puoi simulare l'algoritmo che Trusted Cloud utilizza per assegnare un numero fisso di code RX e TX per NIC in questo modo:

Istanze bare metal
Per le istanze bare metal è presente una sola NIC, pertanto il numero massimo di code è 16.
Istanze VM che utilizzano l'interfaccia di rete gVNIC

Per le istanze C4, per migliorare le prestazioni, le seguenti configurazioni utilizzano un numero fisso di code:

  • Per le istanze Linux con 2 vCPU, il numero di code è 1.
  • Per le istanze Linux con 4 vCPU, il numero di code è 2.

Per le altre serie di macchine, il numero di code dipende dal fatto che la serie di macchine utilizzi o meno Titanium.

  • Per le istanze di terza generazione (esclusa M3) e successive che utilizzano Titanium:

    Dividi il numero di vCPU per il numero di vNIC (num_vcpus/num_vnics) e ignora il resto.

  • Per le VM di prima e seconda generazione che non utilizzano Titanium:

    Dividi il numero di vCPU per il numero di vNIC, quindi dividi il risultato per 2 (num_vcpus/num_vnics/2). Ignora il resto.

Per completare il calcolo del numero di code predefinito:

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

  2. Determina se il numero calcolato è maggiore del numero massimo di code per vNIC, ovvero 16. Se il numero calcolato è maggiore di 16, ignoralo e assegna 16 code a ogni vNIC.

Istanze VM che utilizzano l'interfaccia di rete VirtIO o un driver personalizzato

Dividi il numero di vCPU per il numero di vNIC e ignora il resto -[number of vCPUs/number of vNICs].

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

  2. Determina se il numero calcolato è maggiore del numero massimo di code per vNIC, ovvero 32. Se il numero calcolato è maggiore di 32, ignoralo e assegna 32 code a ogni vNIC.

Esempi

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

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

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

Sui sistemi Linux, puoi utilizzare ethtool per configurare una vNIC con meno code rispetto al numero di code che Trusted Cloud assegna per ciascuna vNIC.

Allocazione di code personalizzate per le istanze VM

Anziché l'allocazione delle code predefinite, puoi assegnare un numero delle code personalizzato (totale di RX e TX) a ciascuna vNIC quando crei una nuova istanza di computing utilizzando l'API Compute Engine.

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

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

  • Il numero massimo di code che puoi assegnare a ciascuna vNIC di un'istanza VM è il minore 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.
    • Se utilizzi gVNIC, il numero massimo di code è 16, tranne nei casi seguenti, in cui il numero massimo di code è 32:
      • Istanze A2 o G2
      • Istanze TPU
      • Istanze C2, C2D, N2 o N2D con la rete Tier_1 abilitata

    • Per le seguenti configurazioni di Confidential VM, il numero massimo di code è 8:

      • AMD SEV sui tipi di macchine C2D e N2D
      • AMD SEV-SNP sui tipi di macchine N2D

  • Se assegni numeri di code personalizzati a tutte le NIC dell'istanza di computing, la somma delle assegnazioni del numero di code deve essere inferiore o uguale al numero di vCPU assegnate all'istanza.

Puoi eseguire una sottoscrizione in eccesso del numero di code personalizzati per le vNIC. In altre parole, puoi avere una somma dei numeri di code assegnate a tutte le NIC per la tua istanza VM superiore al numero di vCPU per l'istanza. Per eseguire una sottoscrizione in eccesso del numero di code personalizzato, l'istanza VM deve soddisfare le seguenti condizioni:

  • Utilizzare gVNIC come tipo di vNIC per tutte le NIC configurate per l'istanza.
  • Utilizzare un tipo di macchina che supporta la rete Tier_1.
  • Avere la rete Tier_1 abilitata.
  • Avere un numero di code personalizzato specificato per tutte le NIC configurate per l'istanza.

Con la sottoscrizione in eccesso delle code, il numero massimo di code per l'istanza VM è 16 volte il numero di NIC. Pertanto, se hai configurato 6 NIC 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 vNIC, 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 assegnare in seguito 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.

  • Se hai una VM N2 con 96 vCPU e 2 vNIC, puoi assegnare a entrambe le vNIC fino a 32 code ciascuna se utilizzi il driver virtIO o fino a 16 code ciascuna se utilizzi il driver gVNIC. Se attivi la rete Tier_1 per la VM N2, puoi assegnare fino a 32 code a ogni vNIC. In questo esempio, la somma delle code assegnate è sempre inferiore o uguale al numero di vCPU.

È anche possibile assegnare un numero di code personalizzato per solo alcune NIC, lasciando a Trusted Cloud l'assegnazione delle 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 tua configurazione è possibile, il numero di code che Trusted Cloud assegna alle vNIC rimanenti con questa procedura:

  1. Calcola la somma delle code per le vNIC utilizzando l'assegnazione delle code personalizzata. Per una VM di esempio con 20 vCPU e 6 vNIC, supponiamo di assegnare 5 code a nic0, 6 code a nic1, 4 code a nic2 e di lasciare che Trusted Cloud assegni 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 è inferiore al numero di vNIC rimanenti per le quali Trusted Cloud deve assegnare code, Trusted Cloud restituisce un errore perché ogni vNIC deve avere almeno una coda.

    Continuando con l'esempio di una VM con 20 vCPU e una somma di 15 code assegnate in modo personalizzato, Trusted Cloud ha 20-15 = 5 code rimanenti da assegnare alle vNIC restanti (nic3, nic4, nic5).

  3. Dividi la differenza del passaggio precedente per il numero di vNIC rimanenti e ignora il resto - ⌊(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)⌋. Questo calcolo restituisce sempre un numero intero (non una frazione) che è almeno uguale a uno a causa del vincolo spiegato nel passaggio precedente. Trusted Cloud assegna a ogni vNIC rimanente un conteggio delle code corrispondente al numero calcolato, a condizione che 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:

  • Se utilizzi virtIO o un driver personalizzato, se il numero calcolato di code per ogni vNIC rimanente è superiore a 32, Trusted Cloud assegna a ogni vNIC rimanente 32 code.
  • Se utilizzi gVNIC, se il numero calcolato di code per ogni vNIC rimanente è superiore al limite di 16 o 32 (a seconda della configurazione della VM), Trusted Cloud assegna a ogni vNIC rimanente 16 code.

Configurazione dei numeri di code personalizzati

Per creare un'istanza di computing che utilizzi un numero di code personalizzato per una o più NIC o vNIC, completa i seguenti passaggi.

Nei seguenti esempi di codice, la VM viene creata con il tipo di interfaccia di rete impostato su GVNIC e le prestazioni di rete Tier_1 per VM abilitate. Puoi utilizzare questi esempi di codice per specificare il numero massimo di code e la sottoscrizione in eccesso delle code disponibili per i tipi di macchine supportati.

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 di computing. 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 eseguire una sottoscrizione in eccesso del numero di code, il tipo di macchina specificato deve supportare gVNIC e la rete 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 descritte in Allocazione di 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 di computing con numeri di code specifici per le vNIC utilizzando la risorsa google_compute_instance. Ripeti il parametro --network-interface per ogni vNIC da 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: l'ID del progetto in cui creare l'istanza. A meno che non utilizzi una rete VPC condivisa, 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: il tipo di disco da utilizzare per il disco di avvio, ad esempio pd-standard
  • MACHINE_TYPE: il tipo di macchina dell' istanza. Per eseguire una sottoscrizione in eccesso del numero di code, il tipo di macchina specificato deve supportare gVNIC e la rete Tier_1.
  • ZONE: la zona in cui creare l'istanza
  • QUEUE_COUNT: il numero di code per la vNIC, in base alle regole descritte in Allocazione di code personalizzate.
  • SUBNET_*: il nome della subnet a cui si connette 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 di computing con numeri 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 di computing
    • ZONE: la zona in cui creare l'istanza di computing
    • VM_NAME: nome della nuova istanza di computing
    • MACHINE_TYPE: tipo di macchina, predefinito o personalizzato, per la nuova istanza di computing. Per eseguire una sottoscrizione in eccesso del numero di code, il tipo di macchina deve supportare gVNIC e la rete Tier_1.
    • SUBNET_*: il nome della subnet a cui si connette l'interfaccia di rete
    • QUEUE_COUNT: numero di code per la vNIC, soggette alle regole descritte in Allocazione di code personalizzate.

Allocazioni di code e modifica del tipo di macchina

Le istanze di computing vengono create con un'allocazione della coda predefinita oppure puoi assegnare un numero di 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 alla coda vNIC predefinite o personalizzate vengono impostate solo durante la creazione di un'istanza di computing. Se la tua istanza dispone di vNIC che utilizzano conteggi di coda predefiniti, puoi modificarne il tipo di macchina. Se il tipo di macchina a cui stai passando ha un numero diverso di vCPU, i numeri di coda predefinite per l'istanza vengono ricalcolati in base al nuovo tipo di macchina.

Se la VM ha vNIC che utilizzano numeri 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 la VM risultante supporta lo stesso numero di code per vNIC dell'istanza originale. Per le VM che utilizzano l'interfaccia VirtIO-Net e hanno un numero di code personalizzato superiore a 16 per vNIC, non puoi modificare il tipo di macchina in un tipo di macchina di terza generazione o successiva, perché utilizzano solo gVNIC. In alternativa, puoi eseguire la migrazione della VM a un tipo di macchina di terza generazione o successiva seguendo le istruzioni riportate in Spostamento del carico di lavoro in una nuova istanza di computing.

Passaggi successivi