Ancho de banda de red

Google Cloud tiene en cuenta el ancho de banda por instancia de proceso, no por interfaz de red virtual (vNIC) ni por dirección IP. El tipo de máquina de una instancia define su tasa de salida máxima posible. Sin embargo, solo puedes alcanzar esa tasa de salida máxima posible en situaciones específicas.

En esta página se describen los límites de ancho de banda de red, que son útiles para planificar las implementaciones. Categoriza el ancho de banda mediante dos dimensiones:

  • Salida o entrada: en esta página, los términos "salida" y "entrada" siempre se refieren a la perspectiva de una Google Cloud instancia:
    • Los paquetes enviados desde una instancia Google Cloud componen su tráfico de salida.
    • Los paquetes enviados a una instancia Google Cloud componen su tráfico de entrada (entrante).
  • Cómo se enruta el paquete: un paquete se puede enrutar desde una instancia de envío o a una instancia de recepción mediante rutas cuyos siguientes saltos se encuentren dentro de una red de VPC o fuera de ella.

Toda la información de esta página se aplica a las instancias de cálculo de Compute Engine, así como a los productos que dependen de las instancias de Compute Engine. Por ejemplo, un nodo de Google Kubernetes Engine es una instancia de Compute Engine.

Configuraciones que afectan al ancho de banda de la red

Para obtener el mayor ancho de banda de entrada y salida posible, configura el rendimiento de red Tier_1 por VM en tu instancia de proceso.

Ni las interfaces de red virtuales (vNICs) adicionales ni las direcciones IP adicionales por vNIC aumentan el ancho de banda de entrada o salida de una instancia de proceso. Por ejemplo, una VM C3 con 22 vCPUs está limitada a 23 Gbps de ancho de banda de salida total. Si configuras la VM C3 con dos vNICs, la VM seguirá teniendo un límite de 23 Gbps de ancho de banda de salida total, no de 23 Gbps por vNIC.

Las interfaces de red dinámicas (vista previa) usan el ancho de banda de su vNIC principal. No hay aislamiento del tráfico en una vNIC principal. El tráfico de red de una NIC dinámica puede privar de recursos a las otras NICs dinámicas asociadas a la misma NIC virtual principal. Para evitar este conflicto, puedes usar el control de tráfico (TC) de Linux para crear políticas de limitación de tráfico específicas de cada aplicación. Estas políticas ayudan a implementar la equidad o determinados tipos de prioridad. Para priorizar, asigna el tráfico (por ejemplo, para NICs dinámicas) a una clase de tráfico y, a continuación, asigna esa clase de tráfico a una calidad del servicio. Para ver un ejemplo de este enfoque, consulta Traffic shaping with Red Hat (Limitación del tráfico con Red Hat).

No se admiten las NICs dinámicas en las instancias de Compute Engine que ejecutan un SO Windows.

Resumen del ancho de banda

En la siguiente tabla se muestra el ancho de banda máximo posible en función de si un paquete se envía desde una instancia de proceso (salida) o se recibe en ella (entrada), así como del método de enrutamiento de paquetes.

Límites de ancho de banda de salida

Enrutamiento en una red VPC

  • Se define principalmente por un ancho de banda de salida máximo por instancia en función del tipo de máquina de la instancia de envío y de si la red de nivel 1 está habilitada.

    • Las máquinas virtuales N2, N2D, C2, C2D y C4A con compatibilidad con la red Tier_1 tienen límites de ancho de banda de salida de hasta 100 Gbps.
    • Las máquinas virtuales H3 admiten límites de ancho de banda de salida de máquina virtual a máquina virtual de hasta 200 Gbps.
    • Las instancias X4, A2 y G2 admiten límites de ancho de banda de salida de hasta 100 Gbps.
    • Las instancias G4 admiten límites de ancho de banda de salida de hasta 400 Gbps.
    • Las instancias A4X admiten límites de ancho de banda de salida de hasta 2000 Gbps.
    • Las instancias A4 y A3 admiten límites de ancho de banda de salida de hasta 3600 Gbps.
    • Las instancias M4, C4, C4D, C3, C3D y Z3 admiten límites de ancho de banda de salida de hasta 200 Gbps con la red Tier_1.
  • Para ver otros factores, definiciones y situaciones, consulta Salida a destinos enrutables en una red de VPC.
Enrutamiento fuera de
una red VPC

  • Se define principalmente por un ancho de banda de salida máximo por instancia en función del tipo de máquina de la instancia de envío y de si la red de nivel 1 está habilitada. A excepción de las VMs H3, la salida máxima posible de una instancia de envío a un destino fuera de su red de VPC no puede superar lo siguiente:

    • 7 Gbps en total cuando la red Tier_1 no está habilitada
    • 25 Gbps en total cuando la red de nivel 1 está habilitada
    • 3 Gbps por flujo
  • Para obtener más información sobre otros factores, definiciones y advertencias, consulta Salida a destinos fuera de una red de VPC.

Límites de ancho de banda de entrada

Enrutamiento en una red VPC
  • Por lo general, las tarifas de entrada son similares a las de salida de un tipo de máquina.
  • Para obtener el mayor ancho de banda de entrada posible, habilita la red Tier_1.
  • El tamaño de tu instancia de computación, la capacidad de la NIC del servidor, el tráfico que llega a otras VMs invitadas que se ejecutan en el mismo hardware host, la configuración de red de tu SO invitado y el número de lecturas de disco que realiza tu instancia pueden influir en la tasa de entrada.
  • Google Cloud no impone ninguna limitación adicional a las tasas de entrada en una red VPC.
  • Para obtener información sobre otros factores, definiciones y situaciones, consulta Entrada a destinos enrutables en una red de VPC.
Enrutamiento fuera de
una red VPC

  • Google Cloud Protege cada instancia de proceso limitando el tráfico de entrada que se enruta fuera de una red de VPC. El límite es el primero de los siguientes tipos que se encuentre:

    • 1.800.000 pps (paquetes por segundo)
    • 30 Gbps

  • En el caso de una serie de máquinas que admita varias NICs físicas, como A3, el límite es la primera de las siguientes tasas que se encuentre:

    • 1.800.000 pps (paquetes por segundo) por NIC física
    • 30 Gbps por NIC física
  • Para obtener información sobre otros factores, definiciones y situaciones, consulta Entrada a destinos fuera de una red de VPC.

Ancho de banda de salida

Google Cloud limita el ancho de banda de salida (egreso) mediante las tasas máximas de egreso por instancia. Estas tarifas se basan en el tipo de máquina de la instancia de computación que envía el paquete y en si se puede acceder al destino del paquete mediante rutas dentro de una red VPC o rutas fuera de una red VPC. El ancho de banda de salida incluye los paquetes emitidos por todas las NICs de la instancia y los datos transferidos a todos los volúmenes de Hyperdisk y de disco persistente conectados a la instancia.

Ancho de banda de salida máximo por instancia

El ancho de banda de salida máximo por instancia suele ser de 2 Gbps por vCPU, pero hay algunas diferencias y excepciones en función de la serie de la máquina. En la siguiente tabla se muestra el intervalo de límites máximos de ancho de banda de salida del tráfico enrutado en una red de VPC.

En la siguiente tabla se resume el ancho de banda de salida máximo de cada serie de máquinas. Puedes consultar el ancho de banda de salida máximo por instancia de cada tipo de máquina en la página de su familia de máquinas específica (usa los enlaces de cada serie de máquinas de la tabla).

Límite de salida por instancia
Serie de máquinas Estándar Redes de nivel 1
C4 y C4D 100 Gbps 200 Gbps
C4A 50 Gbps 100 Gbps
C3 y C3D 100 Gbps 200 Gbps
C2 y C2D 32 Gbps 100 Gbps
E2 16 Gb/s N/A
E2 con núcleo compartido 2 Gb/s N/A
H3 200 Gbps N/A
M4 100 Gbps 200 Gbps
M3 32 Gbps 100 Gbps
M2 32 Gbps en CPUs Intel Cascade Lake o posteriores
16 Gbps en otras plataformas de CPU		 N/A
M1 32 Gbps N/A
N4 50 Gbps N/A
N2 y N2D 32 Gbps 100 Gbps
N1 (excepto las VMs con 1 vCPU) 32 Gbps en Intel Skylake y CPUs posteriores
16 Gbps en plataformas de CPUs anteriores		 N/A
Tipos de máquinas N1 con 1 vCPU 2 Gb/s N/A
N1 con núcleo compartido (f1-micro y g1-small) 1 Gbps N/A
T2A y T2D 32 Gbps N/A
X4 100 Gbps N/A
Z3 100 Gbps 200 Gbps

Para obtener información sobre el ancho de banda de la red de las series de máquinas optimizadas para aceleradores, consulta Máquinas de redes y GPUs.

El ancho de banda de salida máximo por instancia no es una garantía. El ancho de banda de salida real puede reducirse en función de factores como los que se indican en la siguiente lista no exhaustiva:

  • Usar VirtIO en lugar de gVNIC con instancias de proceso que admitan ambos
  • Tamaño del paquete
  • Sobrecarga del protocolo
  • El número de flujos
  • Ajustes del controlador Ethernet del SO invitado de la instancia de cálculo, como la descarga de la suma de comprobación y la descarga de la segmentación TCP (TSO)
  • Congestión de red
  • En una situación en la que las operaciones de entrada/salida de disco persistente compiten con otro tráfico de salida de red, se asigna el 60% del ancho de banda de red máximo a las escrituras de disco persistente, lo que deja un 40% para otro tráfico de salida de red. Consulta más información en la sección Factores que afectan al rendimiento del disco.

Para obtener el ancho de banda de salida máximo por instancia más grande posible, haz lo siguiente:

  • Habilita el rendimiento de red Tier_1 por VM con tipos de máquinas más grandes.
  • Usa la unidad de transmisión máxima (MTU) de la red de VPC más grande que admita tu topología de red. Los MTUs más grandes pueden reducir la sobrecarga de los encabezados de los paquetes y aumentar el rendimiento de los datos de la carga útil.
  • Usa la versión más reciente del controlador gVNIC.
  • Usa series de máquinas de tercera generación o posteriores que usen Titanium para descargar el procesamiento de la red de la CPU del host.

Salida a destinos a los que se puede enrutar dentro de una red VPC

Desde la perspectiva de una instancia de envío y para las direcciones IP de destino a las que se puede acceder mediante rutas dentro de una red de VPC,Google Cloud limita el tráfico saliente mediante estas reglas:

  • Ancho de banda de salida máximo por VM: ancho de banda de salida máximo por instancia descrito en la sección Ancho de banda de salida máximo por instancia.
  • Ancho de banda de salida entre regiones por proyecto: si una instancia de envío y un destino interno o su siguiente salto están en regiones diferentes,Google Cloud aplica una cuota basada en la región y el proyecto de la instancia de envío, así como en la región del destino interno o del siguiente salto. Para obtener más información sobre esta cuota, consulta Ancho de banda de salida de red entre regiones (Mbps) de instancias de Compute en la documentación sobre cuotas y límites de VPC.
  • Límites de Cloud VPN y Cloud Interconnect: al enviar tráfico desde una instancia a una dirección IP interna de destino a la que se puede enrutar mediante un túnel de Cloud VPN de salto siguiente o una vinculación de VLAN de Cloud Interconnect, el ancho de banda de salida está limitado por lo siguiente:

Entre los destinos a los que se puede enrutar dentro de una red de VPC se incluyen los siguientes, a los que se puede acceder desde la instancia de envío mediante una ruta cuyo siguiente salto no es la puerta de enlace de Internet predeterminada:

  • Direcciones IPv4 internas regionales en intervalos de direcciones IPv4 principales y secundarias de subred, incluidos los intervalos de direcciones IPv4 privadas y los intervalos de direcciones IPv4 públicas usadas de forma privada, que utilizan estos recursos de destino:
    • La dirección IPv4 interna principal de la interfaz de red (vNIC) de una instancia receptora. Cuando una instancia de envío se conecta a la dirección IPv4 externa de la interfaz de red virtual de otra instancia, los paquetes se enrutan mediante una pasarela de Internet predeterminada de salto siguiente, por lo que se aplica la salida a destinos fuera de una red de VPC.
    • Una dirección IPv4 interna de un intervalo de IP de alias de la interfaz de red virtual de una instancia receptora.
    • Una dirección IPv4 interna de una regla de reenvío interna para el reenvío de protocolos o para un balanceador de carga de red de paso a través interno.
  • Direcciones IPv4 internas globales de estos recursos de destino:
  • Intervalos de direcciones de subred IPv6 internas que usan estos recursos de destino:
    • Una dirección IPv6 del /96 intervalo de direcciones IPv6 asignado a la interfaz de red virtual de una instancia de recepción de doble pila o solo IPv6.
    • Una dirección IPv6 del /96 intervalo de direcciones IPv6 de una regla de reenvío interna para el reenvío de protocolos o para un balanceador de carga de red interno de tipo pasarela.
  • Intervalos de direcciones de subred IPv6 externas que usan estos recursos de destino cuando los paquetes se enrutan mediante rutas de subred o rutas de subred de emparejamiento en la red de VPC, o bien mediante rutas personalizadas en la red de VPC que no usan el siguiente salto de la puerta de enlace de Internet predeterminada:
    • Una dirección IPv6 del /96 intervalo de direcciones IPv6 asignado a la interfaz de red virtual de una instancia de recepción de doble pila o solo IPv6.
    • Una dirección IPv6 del intervalo de direcciones IPv6 /96 de una regla de reenvío externa para el reenvío de protocolos o para un balanceador de carga de red passthrough externo.
  • Otros destinos accesibles mediante las siguientes rutas de red de VPC:

En la siguiente lista se clasifica el tráfico de las instancias de envío a los destinos internos, de mayor a menor ancho de banda posible:

Salida a destinos fuera de una red de VPC

Desde el punto de vista de una instancia de envío y para las direcciones IP de destino fuera de una red de VPC, Google Cloud se limita el tráfico saliente a la velocidad que se alcance primero de las siguientes:

  • Ancho de banda de salida por instancia: el ancho de banda máximo de todas las conexiones de una instancia de proceso a destinos fuera de una red VPC es el menor de los siguientes valores: Ancho de banda de salida máximo por instancia y una de estas velocidades:

    • 25 Gbps si la red de nivel 1 está habilitada
    • 7 Gbps si la red Tier_1 no está habilitada
    • 1 Gbps para las instancias H3
    • 7 Gbps por NIC física en las series de máquinas que admiten varias NICs físicas, como A3.

    Por ejemplo, aunque una instancia c3-standard-44 tiene un ancho de banda de salida máximo por VM de 32 Gbps, el ancho de banda de salida por VM de una VM c3-standard-44 a destinos externos es de 25 Gbps o de 7 Gbps, en función de si la red de nivel 1 está habilitada.

  • Velocidad de salida máxima por flujo: el ancho de banda máximo de cada conexión única de 5 tuplas, desde una instancia de proceso hasta un destino fuera de una red VPC, es de 3 Gbps, excepto en H3, donde es de 1 Gbps.

  • Ancho de banda saliente de Internet por proyecto: el ancho de banda máximo de todas las conexiones de las instancias de proceso de cada región de un proyecto a destinos fuera de una red de VPC se define mediante las cuotas de ancho de banda saliente de Internet del proyecto.

Los destinos que no están en una red de VPC incluyen todos los destinos siguientes, a los que se puede acceder mediante una ruta de la red de VPC de la instancia de envío cuyo siguiente salto es la pasarela de Internet predeterminada:

  • Direcciones IPv4 e IPv6 externas globales para balanceadores de carga de red con proxy externos y balanceadores de carga de aplicaciones externos
  • Direcciones IPv4 externas regionales para Google Cloud recursos, incluidas las direcciones IPv4 externas de las NIC virtuales de las VMs, las direcciones IPv4 externas para el reenvío de protocolos externos, los balanceadores de carga de red de tipo pasarela externos y los paquetes de respuesta a las pasarelas de Cloud NAT.
  • Direcciones IPv6 externas regionales en subredes de doble pila o solo IPv6 con intervalos de direcciones IPv6 externas usadas por direcciones IPv6 externas de instancias de doble pila o solo IPv6, reenvío de protocolos externos y balanceadores de carga de red de pases externos. La subred debe estar ubicada en una red de VPC independiente que no esté emparejada. Se debe poder acceder al intervalo de direcciones IPv6 de destino mediante una ruta de la red VPC de la instancia de envío cuyo siguiente salto sea la pasarela de Internet predeterminada. Si una subred de doble pila o solo IPv6 con un intervalo de direcciones IPv6 externas se encuentra en la misma red de VPC o en una red de VPC emparejada, consulta Salida a destinos enrutables en una red de VPC.
  • Otros destinos externos accesibles mediante una ruta estática en la red VPC de la instancia de envío, siempre que el siguiente salto de la ruta sea la pasarela de Internet predeterminada.

Para obtener información sobre qué recursos Google Cloud utilizan qué tipos de direcciones IP externas, consulta Direcciones IP externas.

Ancho de banda de entrada

Google Cloud gestiona el ancho de banda de entrada (ingreso) en función de cómo se enruta el paquete entrante a una instancia de computación receptora.

Entrada a destinos a los que se puede enrutar dentro de una red de VPC

Una instancia receptora puede gestionar tantos paquetes entrantes como le permitan su tipo de máquina, su sistema operativo y otras condiciones de la red. Google Cloud no implementa ninguna restricción de ancho de banda intencionada en los paquetes entrantes que se envían a una instancia si el paquete entrante se envía mediante rutas dentro de una red VPC:

  • Rutas de subred en la red de VPC de la instancia receptora
  • Rutas de subred de emparejamiento en una red VPC emparejada
  • Rutas de otra red cuyos siguientes saltos son túneles de Cloud VPN, vinculaciones de Cloud Interconnect (VLAN) o instancias de Router Appliance ubicadas en la red VPC de la instancia receptora

Los destinos de los paquetes que se enrutan en una red de VPC son los siguientes:

  • La dirección IPv4 interna principal de la interfaz de red (NIC) de la instancia receptora. Las direcciones IPv4 internas principales son direcciones IPv4 internas regionales que proceden del intervalo de direcciones IPv4 principal de una subred.
  • Una dirección IPv4 interna de un intervalo de IP de alias de la NIC de la instancia receptora. Los intervalos de IPs de alias pueden proceder del intervalo de direcciones IPv4 principal de una subred o de uno de sus intervalos de direcciones IPv4 secundarios.
  • Una dirección IPv6 del /96 intervalo de direcciones IPv6 asignado a la NIC de una instancia receptora de doble pila o solo IPv6. Los intervalos de IPv6 de las instancias de Compute pueden proceder de estos intervalos de IPv6 de subred:
  • Dirección IPv4 interna de una regla de reenvío utilizada por el reenvío de protocolo interno a la instancia receptora o al balanceador de carga de red de paso a través interno, donde la instancia receptora es un backend del balanceador de carga. Las direcciones IPv4 de las reglas de reenvío internas proceden del intervalo de direcciones IPv4 principal de una subred.
  • Una dirección IPv6 interna del /96 intervalo IPv6 de una regla de reenvío que usa el reenvío de protocolo interno a la instancia receptora o al balanceador de carga de red de paso a través interno en el que la instancia receptora es un backend del balanceador de carga. Las direcciones IPv6 de las reglas de reenvío internas proceden del intervalo de direcciones IPv6 internas de una subred.
  • Una dirección IPv6 externa del intervalo IPv6 /96 de una regla de reenvío que se usa para el reenvío de protocolos externos a la instancia receptora o al balanceador de carga de red de paso a través externo. La instancia receptora es un backend del balanceador de carga cuando el paquete entrante se enruta en la red de VPC mediante una de las rutas que se han indicado anteriormente en esta sección. Regla de reenvío externa Las direcciones IPv6 proceden del intervalo de direcciones IPv6 externas de una subred.
  • Una dirección IP dentro del intervalo de destino de una ruta estática personalizada que usa la instancia receptora como instancia de siguiente salto (next-hop-instance o next-hop-address).
  • Una dirección IP dentro del intervalo de destino de una ruta estática personalizada que use un siguiente salto de balanceador de carga de red de paso a través interno (next-hop-ilb), si la instancia receptora es un backend de ese balanceador de carga.

Entrada a destinos fuera de una red de VPC

Google Cloud implementa los siguientes límites de ancho de banda para los paquetes entrantes que se envían a una instancia receptora mediante rutas externas a una red de VPC. Cuando se utiliza el balanceo de carga, los límites de ancho de banda se aplican individualmente a cada instancia receptora.

En el caso de las series de máquinas que no admiten varias NICs físicas, la restricción de ancho de banda de entrada aplicable se aplica de forma colectiva a todas las interfaces de red virtual (vNICs). El límite es el primero de los siguientes tipos que se encuentre:

  • 1.800.000 paquetes por segundo
  • 30 Gbps

En el caso de las series de máquinas que admiten varias NICs físicas, como A3, la restricción de ancho de banda de entrada aplicable se aplica individualmente a cada NIC física. El límite es el primero de los siguientes tipos que se encuentre:

  • 1.800.000 paquetes por segundo por NIC física
  • 30 Gbps por NIC física

Los destinos de los paquetes que se enrutan mediante rutas fuera de una red VPC incluyen los siguientes:

  • Una dirección IPv4 externa asignada en una configuración de acceso NAT uno a uno en una de las interfaces de red (NICs) de la instancia receptora.
  • Una dirección IPv6 externa del intervalo de direcciones IPv6 /96 asignado a una interfaz de red virtual de una instancia de recepción de doble pila o solo IPv6 cuando el paquete entrante se enruta mediante una ruta fuera de la red de VPC de la instancia de recepción.
  • Una dirección IPv4 externa de una regla de reenvío usada por el reenvío de protocolo externo a la instancia receptora o al balanceador de carga de red de paso a través externo en el que la instancia receptora es un backend del balanceador de carga.
  • Una dirección IPv6 externa del intervalo IPv6 /96 de una regla de reenvío que se usa para el reenvío de protocolos externos a la instancia receptora o al balanceador de carga de red de paso a través externo. La instancia receptora debe ser un backend del balanceador de carga cuando el paquete entrante se enruta mediante una ruta fuera de una red VPC.
  • Respuestas entrantes establecidas procesadas por Cloud NAT.

Usar tramas gigantes para maximizar el ancho de banda de la red

Para recibir y enviar tramas jumbo, configura la red de VPC que usan tus instancias de proceso. Define la unidad de transmisión máxima (MTU) con un valor más alto, de hasta 8896.

Los valores de MTU más altos aumentan el tamaño de los paquetes y reducen la sobrecarga del encabezado de los paquetes, lo que incrementa el rendimiento de los datos de la carga útil.

Puedes usar tramas gigantes con la versión 1.3 o posterior del controlador gVNIC en instancias de VM o con el controlador IDPF en instancias de hardware desnudo. No todas las imágenes públicas de Google Cloud incluyen estos controladores. Para obtener más información sobre la compatibilidad de los sistemas operativos con los marcos jumbo, consulta la pestaña Funciones de red de la página Detalles del sistema operativo.

Si usas una imagen de SO que no es totalmente compatible con los jumbo frames, puedes instalar manualmente la versión 1.3.0 o posterior del controlador gVNIC. Google recomienda instalar la versión del controlador gVNIC marcada con Latest para disfrutar de funciones adicionales y correcciones de errores. Puedes descargar los controladores de gVNIC desde GitHub.

Para actualizar manualmente la versión del controlador gVNIC en tu SO invitado, consulta Usar en sistemas operativos no compatibles.

Tramas gigantes y máquinas con GPU

En el caso de los tipos de máquina con GPU, usa los ajustes de MTU recomendados para los Jumbo Frames. Para obtener más información, consulta Ajustes de MTU recomendados para tramas Jumbo.

Recibir y transmitir colas

A cada NIC o vNIC de una instancia de computación se le asigna un número de colas de recepción y transmisión para procesar paquetes de la red.

  • Cola de recepción (RX): cola para recibir paquetes. Cuando la NIC recibe un paquete de la red, selecciona el descriptor de un paquete entrante de la cola, lo procesa y entrega el paquete al SO invitado a través de una cola de paquetes conectada a un núcleo de vCPU mediante una interrupción. Si la cola RX está llena y no hay ningún búfer disponible para colocar un paquete, el paquete se descarta. Esto suele ocurrir si una aplicación está utilizando en exceso un núcleo de vCPU que también está asociado a la cola de paquetes seleccionada.
  • Cola de transmisión (TX): cola para transmitir paquetes. Cuando el SO invitado envía un paquete, se asigna un descriptor y se coloca en la cola de transmisión. A continuación, la NIC procesa el descriptor y transmite el paquete.

Asignación de colas predeterminada

A menos que asignes explícitamente recuentos de colas a las NICs, puedes modelar el algoritmo que usa Google Cloud para asignar un número fijo de colas RX y TX por NIC de esta forma:

Instancias Bare Metal
En las instancias de hardware desnudo, solo hay una NIC, por lo que el número máximo de colas es 16.
Instancias de máquina virtual que usan la interfaz de red gVNIC

En el caso de las instancias C4, para mejorar el rendimiento, las siguientes configuraciones usan un número fijo de colas:

  • En el caso de las instancias Linux con 2 vCPUs, el número de colas es 1.
  • En el caso de las instancias de Linux con 4 vCPUs, el número de colas es 2.

En el resto de las series de máquinas, el número de colas depende de si la serie de máquinas usa Titanium o no.

  • En el caso de las instancias de tercera generación (excepto M3) y posteriores que usan Titanium:

    Divide el número de vCPUs entre el número de vNICs (num_vcpus/num_vnics) y descarta el resto.

  • En el caso de las VMs de primera y segunda generación que no usan Titanium:

    Divide el número de vCPUs entre el número de vNICs y, a continuación, divide el resultado entre 2 (num_vcpus/num_vnics/2). Descarta el resto.

Para terminar de calcular el número de elementos de la cola predeterminada, sigue estos pasos:

  1. Si el número calculado es inferior a 1, asigna una cola a cada vNIC.

  2. Determina si el número calculado es mayor que el número máximo de colas por vNIC, que es 16. Si el número calculado es superior a 16, ignora el número calculado y asigna 16 colas a cada vNIC.

Instancias de VM que usen la interfaz de red VirtIO o un controlador personalizado

Divide el número de vCPUs entre el número de vNICs y descarta el resto: [number of vCPUs/number of vNICs].

  1. Si el número calculado es inferior a 1, asigna una cola a cada vNIC.

  2. Determina si el número calculado es mayor que el número máximo de colas por vNIC, que es 32. Si el número calculado es superior a 32, ignora el número calculado y asigna 32 colas a cada vNIC.

Ejemplos

En los siguientes ejemplos se muestra cómo calcular el número predeterminado de colas de una instancia de VM:

  • Si una instancia de VM usa VirtIO y tiene 16 vCPUs y 4 vNICs, el número calculado es [16/4] = 4. Google Cloud asigna cuatro colas a cada vNIC.

  • Si una instancia de VM usa gVNIC y tiene 128 vCPUs y dos vNICs, el número calculado es [128/2/2] = 32. Google Cloud asigna a cada vNIC el número máximo de colas por vNIC posible. Google Cloudasigna 16 colas por vNIC.

En los sistemas Linux, puedes usar ethtool para configurar una NIC virtual con menos colas que el número de colas que Google Cloud asigna por NIC virtual.

Recuentos de colas al usar la interfaz de red dinámica

Si usa interfaces de red dinámicas con sus interfaces de red, los recuentos de colas no cambian. Una NIC dinámica no tiene sus propias colas de recepción y transmisión, sino que usa las mismas colas que la vNIC principal.

Asignación de colas personalizadas para instancias de máquina virtual

En lugar de la asignación de colas predeterminada, puede asignar un número de colas personalizado (total de RX y TX) a cada vNIC cuando cree una instancia de Compute mediante la API de Compute Engine.

El número de colas personalizadas que especifiques debe cumplir las siguientes reglas:

  • El número mínimo de colas que puedes asignar por vNIC es uno.

  • El número máximo de colas que puedes asignar a cada vNIC de una instancia de VM es el menor entre el número de vCPUs y el número máximo de colas por vNIC, en función del tipo de controlador:

    • Si se usa virtIO o un controlador personalizado, el número máximo de colas es 32.
    • Con gVNIC, el número máximo de colas es 16, excepto en los siguientes casos, en los que el número máximo de colas es 32:
      • Instancias A2 o G2
      • Instancias de TPU
      • Instancias C2, C2D, N2 o N2D con la red Tier_1 habilitada

    • En las siguientes configuraciones de VM confidencial, el número máximo de colas es 8:

      • SEV de AMD en tipos de máquinas C2D y N2D
      • AMD SEV-SNP en tipos de máquinas N2D

  • Si asignas recuentos de colas personalizados a todas las NICs de la instancia de proceso, la suma de las asignaciones de recuento de colas debe ser menor o igual al número de vCPUs asignadas a la instancia.

Puedes suscribir en exceso el número de colas personalizadas de tus NICs virtuales. Es decir, puedes tener una suma de los recuentos de colas asignados a todas las NICs de tu instancia de VM que sea superior al número de vCPUs de tu instancia. Para sobreasignar el número de colas personalizadas, la instancia de VM debe cumplir las siguientes condiciones:

  • Usa gVNIC como tipo de vNIC para todas las NICs configuradas en la instancia.
  • Usa un tipo de máquina que admita redes de nivel 1.
  • Tiene habilitada la red de nivel 1.
  • Se ha especificado un recuento de colas personalizado para todas las NICs configuradas en la instancia.

Con la sobreasignación de colas, el número máximo de colas de la instancia de VM es 16 veces el número de NICs. Por lo tanto, si tienes 6 NICs configuradas para una instancia con 30 vCPUs, puedes configurar un máximo de (16 * 6) o 96 colas personalizadas para tu instancia.

Ejemplos

  • Si una instancia de VM tiene 8 vCPUs y 3 vNICs, el número máximo de colas de la instancia es el número de vCPUs, es decir, 8. Puedes asignar 1 cola a nic0, 4 colas a nic1 y 3 colas a nic2. En este ejemplo, no puedes asignar 4 colas a nic2 y mantener las otras dos asignaciones de colas de vNIC, ya que la suma de las colas asignadas no puede superar el número de vCPUs.

  • Si tienes una máquina virtual N2 con 96 vCPUs y 2 vNICs, puedes asignar a ambas vNICs hasta 32 colas cada una cuando uses el controlador virtIO, o hasta 16 colas cada una cuando uses el controlador gVNIC. Si habilitas la red de nivel 1 en la VM N2, puedes asignar hasta 32 colas a cada vNIC. En este ejemplo, la suma de las colas asignadas siempre es menor o igual que el número de vCPUs.

También es posible asignar un número de colas personalizado solo a algunas NICs, lo que permite aGoogle Cloud asignar colas a las NICs restantes. El número de colas que puedes asignar por vNIC sigue sujeto a las reglas mencionadas anteriormente. Puedes modelar la viabilidad de tu configuración y, si es posible, el número de colas que Google Cloud asigna a las vNICs restantes con este proceso:

  1. Calcula la suma de las colas de las vNICs mediante la asignación de colas personalizadas. Por ejemplo, en una VM con 20 vCPUs y 6 vNICs, supongamos que asignas nic0 5 colas, nic1 6 colas y nic2 4 colas, y que dejas que Google Cloudasigne colas a nic3, nic4 y nic5. En este ejemplo, la suma de las colas asignadas de forma personalizada es 5+6+4 = 15.

  2. Resta la suma de las colas asignadas de forma personalizada al número de vCPUs. Si la diferencia es inferior al número de vNICs restantes a los queGoogle Cloud debe asignar colas Google Cloud ,devuelve un error porque cada vNIC debe tener al menos una cola.

    Siguiendo con el ejemplo de una VM que tiene 20 vCPUs y un total de 15 colas asignadas de forma personalizada, Google Cloud quedan 20-15 = 5 colas para asignar a las vNICs restantes (nic3, nic4 y nic5).

  3. Divide la diferencia del paso anterior entre el número de vNICs restantes y descarta el resto: ⌊(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)⌋. Este cálculo siempre da como resultado un número entero (no una fracción) que es al menos igual a uno debido a la restricción explicada en el paso anterior. Google Cloud asigna a cada vNIC restante un número de colas que coincida con el número calculado, siempre que este no sea superior al número máximo de colas por vNIC. El número máximo de colas por vNIC depende del tipo de controlador:

  • Si se usa virtIO o un controlador personalizado, si el número calculado de colas de cada vNIC restante es mayor que 32, Google Cloud asigna 32 colas a cada vNIC restante.
  • Si se usa gVNIC y el número calculado de colas de cada vNIC restante es superior al límite de 16 o 32 (en función de la configuración de la VM), Google Cloud asigna 16 colas a cada vNIC restante.

Configurar recuentos de colas personalizados

Para crear una instancia de proceso que use un número de colas personalizado para una o varias NICs o vNICs, sigue estos pasos.

En los siguientes ejemplos de código, la VM se crea con el tipo de interfaz de red definido como GVNIC y el rendimiento de la red Tier_1 por VM habilitado. Puedes usar estos ejemplos de código para especificar el número máximo de colas y la sobreasignación de colas disponibles para los tipos de máquinas admitidos.

gcloud

  1. Si aún no tienes una red de VPC con una subred para cada interfaz de NIC virtual que quieras configurar, créalas.
  2. Usa el comando gcloud compute instances create para crear la instancia de proceso. Repite la marca --network-interface para cada vNIC que quieras configurar en la instancia e incluye la opción 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

Haz los cambios siguientes:

  • INSTANCE_NAME: un nombre para la nueva instancia de proceso
  • ZONE: la zona en la que se creará la instancia
  • MACHINE_TYPE: el tipo de máquina de la instancia. Para sobreasignar el número de colas, el tipo de máquina que especifiques debe admitir gVNIC y la red Tier_1.
  • NETWORK_NAME: el nombre de la red creada anteriormente
  • SUBNET_*: el nombre de una de las subredes creadas anteriormente
  • QUEUE_SIZE: número de colas de la vNIC, sujeto a las reglas descritas en la sección Asignación de colas personalizadas.

Terraform

  1. Si aún no tienes una red de VPC con una subred para cada interfaz de NIC virtual que quieras configurar, créalas.

  2. Crea una instancia de proceso con recuentos de colas específicos para las vNICs mediante el recurso google_compute_instance. Repite el parámetro --network-interface por cada vNIC que quieras configurar en la instancia de proceso e incluye el parámetro 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""
}

}

Haz los cambios siguientes:

  • VM_NAME: un nombre para la nueva instancia de proceso
  • PROJECT_ID: ID del proyecto en el que se va a crear la instancia. A menos que utilices una red de VPC compartida, el proyecto que especifiques debe ser el mismo en el que se crearon todas las subredes y redes.
  • DEVICE_NAME: nombre que se asociará al disco de arranque en el SO invitado
  • IMAGE_NAME: el nombre de una imagen,por ejemplo, "projects/debian-cloud/global/images/debian-11-bullseye-v20231010".
  • DISK_SIZE: tamaño del disco de arranque en GiB
  • DISK_TYPE: el tipo de disco que se va a usar para el disco de arranque. Por ejemplo, pd-standard.
  • MACHINE_TYPE: el tipo de máquina de la instancia. Para sobreasignar el número de colas, el tipo de máquina que especifiques debe admitir gVNIC y la red Tier_1.
  • ZONE: la zona en la que se creará la instancia
  • QUEUE_COUNT: número de colas de la vNIC, sujeto a las reglas descritas en la sección Asignación de colas personalizadas.
  • SUBNET_*: el nombre de la subred a la que se conecta la interfaz de red

REST

  1. Si aún no tienes una red de VPC con una subred para cada interfaz de NIC virtual que quieras configurar, créalas.

  2. Crea una instancia de Compute con recuentos de colas específicos para NICs mediante el método instances.insert. Repite la propiedad networkInterfaces para configurar varias interfaces de red.

    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"
    } ],
}

    Haz los cambios siguientes:

    • PROJECT_ID: ID del proyecto en el que se va a crear la instancia de proceso
    • ZONE: zona en la que se creará la instancia de computación
    • VM_NAME: nombre de la nueva instancia de proceso
    • MACHINE_TYPE: tipo de máquina, predefinido o personalizado, de la nueva instancia de proceso. Para sobreasignar el número de colas, el tipo de máquina debe admitir gVNIC y la red Tier_1.
    • SUBNET_*: el nombre de la subred a la que se conecta la interfaz de red
    • QUEUE_COUNT: número de colas de la vNIC, sujeto a las reglas descritas en Asignación de colas personalizadas.

Asignaciones de colas y cambio del tipo de máquina

Las instancias de proceso se crean con una asignación de colas predeterminada o puedes asignar un número de colas personalizado a cada tarjeta de interfaz de red virtual (vNIC) al crear una instancia de proceso con la API de Compute Engine. Las asignaciones de colas de vNIC predeterminadas o personalizadas solo se definen al crear una instancia de proceso. Si tu instancia tiene vNICs que usan recuentos de colas predeterminados, puedes cambiar su tipo de máquina. Si el tipo de máquina al que vas a cambiar tiene un número diferente de vCPUs, se volverán a calcular los recuentos de colas predeterminados de tu instancia en función del nuevo tipo de máquina.

Si tu VM tiene vNICs que usan recuentos de colas personalizados que no son los predeterminados, puedes cambiar el tipo de máquina mediante la CLI de Google Cloud o la API de Compute Engine para actualizar las propiedades de la instancia. La conversión se realiza correctamente si la VM resultante admite el mismo número de colas por NIC virtual que la instancia original. En las VMs que usan la interfaz VirtIO-Net y tienen un recuento de colas personalizado superior a 16 por vNIC, no puedes cambiar el tipo de máquina a un tipo de máquina de tercera generación o posterior, ya que solo usan gVNIC. En su lugar, puedes migrar tu VM a un tipo de máquina de tercera generación o posterior siguiendo las instrucciones que se indican en Trasladar una carga de trabajo a una nueva instancia de computación.

Siguientes pasos