Ancho de banda de red

Google Cloud incluye el ancho de banda por instancia de procesamiento, no por interfaz de red virtual (vNIC) ni dirección IP. El tipo de máquina de una VM define su tasa de salida máxima posible; sin embargo, solo puedes alcanzarla en situaciones específicas.

En esta página, se describen las expectativas que son útiles para planificar las implementaciones. Se clasifica el ancho de banda con dos dimensiones:

  • Salida o entrada: Como se usa en esta página, la salida y la entrada siempre se generan desde la perspectiva de una instancia de Google Cloud:
    • Los paquetes enviados desde una instancia de Google Cloud componen el tráfico de salida (saliente).
    • Los paquetes enviados a una instancia de Google Cloud componen el tráfico de entrada (entrante).
  • Cómo se enruta el paquete: un paquete se puede enrutar desde una instancia de envío o hacia una instancia de recepción a través de rutas cuyos próximos saltos se encuentren dentro de una red de VPC o de rutas fuera de una red de VPC.

Ni las interfaces de red virtuales (vNIC) adicionales ni las direcciones IP adicionales por vNIC aumentan el ancho de banda de entrada o salida de una instancia de procesamiento. Por ejemplo, una VM C3 con 22 CPU virtuales está limitada a un ancho de banda de salida total de 23 Gbps. Si configuras la VM C3 con dos vNIC, la VM aún está limitada a un ancho de banda de salida total de 23 Gbps, no a un ancho de banda de 23 Gbps por NIC.

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

Resumen del ancho de banda

En la siguiente tabla, se ilustran las expectativas de ancho de banda según si un paquete se envía desde (salida) o si lo recibe una (entrada) instancia de procesamiento, y el método de enrutamiento de paquetes.

Egress

Expectativas del ancho de banda
Enrutamiento dentro de una red de VPC

  • Principalmente definido por un ancho de banda de salida máximo por instancia según el tipo de máquina de la instancia de envío y si las herramientas de redes de Tier_1 están habilitadas.

    • Las VMs N2, N2D, C2, C2D y C4A con herramientas de redes de nivel 1 admiten límites de ancho de banda de salida de hasta 100 Gbps.
    • Las VMs H3 admiten límites de ancho de banda de salida de VM a VM 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 A3 admiten límites de ancho de banda de salida de hasta 1,800 Gbps.
    • Las instancias de C4, C3, C3D y Z3 admiten límites de ancho de banda de salida de hasta 200 Gbps con las herramientas de redes de nivel 1.
  • Para otros factores, definiciones y situaciones, consulta Salida a destinos enrutables dentro de una red de VPC.
Enrutamiento fuera de una red de VPC

  • Principalmente definido por un ancho de banda de salida máximo por instancia según el tipo de máquina de la instancia de envío y si las herramientas de redes de Tier_1 están habilitadas. Excepto por las VMs H3, la salida máxima posible de una instancia emisora a un destino fuera de su red de VPC no puede exceder lo siguiente:

    • 7 Gbps en total cuando las redes de Tier_1 no están habilitadas
    • 25 Gbps en total cuando las Herramientas de redes de Tier_1 están habilitadas
    • 3 Gbps por flujo
  • Para otros factores, definiciones y advertencias, consulta Salida a destinos fuera de una red de VPC.

Entrada

Expectativas del ancho de banda
Enrutamiento dentro de una red de VPC
  • Por lo general, las tarifas de entrada son similares a las tarifas de salida para un tipo de máquina.
  • El tamaño de tu instancia de procesamiento, la capacidad de la NIC del servidor, el tráfico que entra a otras VMs invitadas que se ejecutan en el mismo hardware host, la configuración de red de tu SO invitado y la cantidad de lecturas del disco que realiza tu instancia pueden afectar la tasa de entrada.
  • Google Cloud no impone ninguna limitación adicional en las tarifas de entrada dentro de una red de VPC.
  • Para otros factores, definiciones y situaciones, consulta Entrada a destinos enrutables dentro de una red de VPC.
Enrutamiento fuera de una red de VPC

  • Google Cloud protege cada instancia de procesamiento mediante la limitación del tráfico de entrada enrutado fuera de una red de VPC. El límite es la primera de las siguientes tasas que se alcance:

    • 1,800,000 pps (paquetes por segundo)
    • 30 Gbps

  • Para una serie de máquinas que admite varias NIC físicas, como la A3, el límite es la primera de las siguientes tasas encontradas:

    • 1,800,000 pps (paquetes por segundo) por NIC físico
    • 30 Gbps por NIC físico
  • Para 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 saliente (salida) mediante tarifas máximas de salida por instancia. Estas tarifas se basan en el tipo de máquina de la instancia de procesamiento que envía el paquete y si se puede acceder al destino del paquete mediante rutas dentro de una red de VPC o rutas externas por cada red de VPC. El ancho de banda saliente incluye los paquetes que emiten todas las NIC de la instancia y los datos transferidos a todos los volúmenes de Hyperdisk y Persistent Disk conectados a la instancia.

Ancho de banda de salida máximo por instancia

Por lo general, el ancho de banda de salida por instancia es de 2 Gbps por CPU virtual, pero existen algunas diferencias y excepciones, según la serie de máquinas. En la siguiente tabla, se muestra el rango de límites máximos para el ancho de banda de salida en el tráfico enrutado dentro de una red de VPC solo para el nivel de red estándar, no para el rendimiento de herramientas de redes de nivel de VM 1.

Series de máquinas El límite máximo de salida por instancia más bajo para la versión estándar Límite máximo de salida por instancia más alto para la versión estándar
C4 y C4A 10 Gbps 100 Gbps
C3 23 Gbps 100 Gbps
C3D 20 Gbps 100 Gbps
C2 y C2D 10 Gbps 32 Gbps
E2 1 Gbps 16 Gbps
H3 N/A 200 Gbps
M3 y M1 32 Gbps 32 Gbps
M2 32 Gbps 32 Gbps en la plataforma de CPU Intel Cascade Lake
16 Gbps en otras plataformas de CPU
N4 10 Gbps 50 Gbps
N2 y N2D 10 Gbps 32 Gbps
N1 (excluye VMs con 1 CPU virtual) 10 Gbps 32 Gbps en la plataforma de CPU Intel Skylake
16 Gbps en plataformas de CPU anteriores a Intel Skylake
Tipos de máquina N1 con 1 CPU virtual, f1-micro y g1-small 2 Gbps 2 Gbps
T2D 10 Gbps 32 Gbps
X4 N/A 100 Gbps
Z3 23 Gbps 100 Gbps

Puedes encontrar el ancho de banda de salida máximo por instancia para cada tipo de máquina que aparece en su página específica de la familia de máquinas:

El ancho de banda de salida máximo por instancia no es una garantía. El ancho de banda de salida real puede reducirse según factores como los de la siguiente lista no exhaustiva:

  • Usar VirtIO en lugar de gVNIC con instancias de Compute Engine que admitan ambos
  • Tamaño del paquete
  • Sobrecarga del protocolo
  • La cantidad de flujos
  • la configuración del controlador de Ethernet del SO invitado de la instancia de procesamiento, como la descarga de la suma de comprobación y la descarga de segmentación de TCP (TSO)
  • Congestión en la red
  • En una situación en la que las I/Os de Persistent Disk compiten con otro tráfico de salida de red, el 60% del ancho de banda máximo de la red se otorga a las operaciones de escritura de discos persistentes, lo que deja un 40% para otro tráfico de salida de red. Para obtener más detalles, consulta Factores que afectan el rendimiento del disco.

Para obtener el mayor ancho de banda de salida máximo posible por instancia, sigue estos pasos:

  • Habilita el rendimiento de redes Tier_1 de 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. Las MTU más grandes pueden reducir la sobrecarga del encabezado del paquete y aumentar la capacidad de procesamiento de datos de la carga útil.
  • Usa la versión más reciente del controlador de gVNIC.
  • Usa series de máquinas de tercera generación o posteriores que usen Titanium para descargar el procesamiento de red de la CPU host.

Salida a destinos enrutables dentro de una red de 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 con estas reglas:

  • Ancho de banda de salida máximo por VM: Es el ancho de banda de salida máximo por instancia que se describe en la sección Ancho de banda de salida máximo por instancia.
  • Ancho de banda de salida interregional por proyecto: Si una instancia emisora y un destino interno o su próximo salto están en regiones diferentes, Google Cloud aplica un límite de ancho de banda de salida interregional máximo. Es poco probable que la mayoría de los clientes alcancen este límite. Para responder preguntas sobre este límite, presenta un caso de asistencia.
  • Límites de Cloud VPN y Cloud Interconnect: Cuando se envía tráfico desde una instancia a un destino de dirección IP interna enrutable por un túnel de Cloud VPN de próximo salto o un adjunto de VLAN de Cloud Interconnect, el ancho de banda de salida es limitado por:

Los destinos que se pueden enrutar dentro de una red de VPC incluyen todos los destinos siguientes, cada uno de los cuales es accesible desde la perspectiva de la instancia de envío mediante una ruta cuyo próximo salto no es la puerta de enlace de Internet predeterminada:

  • Direcciones IPv4 internas regionales en rangos de direcciones principales de IPv4 y subredes secundarias de subred, incluidos los rangos de direcciones IPv4 privadas y públicas de uso privado, que usan estos recursos de destino:
    • La dirección IPv4 interna principal de la interfaz de red (NIC) de una instancia receptora. (Cuando una instancia de envío se conecta a la dirección IPv4 externa de la vNIC de otra instancia, los paquetes se enrutan mediante una puerta de enlace de Internet predeterminada de próximo salto, por lo que la salida a destinos fuera de una red de VPC se aplica en su lugar).
    • Una dirección IPv4 interna en un rango de alias de IP de la NIC de una instancia receptora.
    • Una dirección IPv4 interna de una regla de reenvío interna para el reenvío de protocolos o un balanceador de cargas de red de transferencia interno.
  • Direcciones IPv4 internas globales para estos recursos de destino:
  • Rangos de direcciones IPv6 internos de subred que usan estos recursos de destino:
    • Una dirección IPv6 del rango de direcciones IPv6 /96 asignado a una NIC de pila doble que recibe la instancia.
    • Una dirección IPv6 del rango de direcciones IPv6 /96 de una regla de reenvío interno para el reenvío de protocolos o un balanceador de cargas de red de paso interno.
  • Rangos de direcciones IPv6 externos que usan estos recursos de destino cuando los paquetes se enrutan a través de rutas de subred o rutas de subred de intercambio de tráfico dentro de la red de VPC o mediante rutas personalizadas dentro de rutas Red de VPC que no usa el próximo salto de puerta de enlace de Internet predeterminado:
    • Una dirección IPv6 del rango de direcciones IPv6 /96 asignado a una NIC de pila doble que recibe la instancia.
    • Una dirección IPv6 del rango de direcciones IPv6 /96 de una regla de reenvío externa para un reenvío de protocolos o un balanceador de cargas de red de paso externo.
  • Otros destinos a los que se puede acceder a través de las siguientes rutas de red de VPC:

En la siguiente lista, se clasifica el tráfico desde el envío de instancia hacia destinos internos, desde el ancho de banda más alto posible hasta el más bajo:

Salida a destinos fuera de una red de VPC

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

  • Ancho de banda de salida por instancia: El ancho de banda máximo de todas las conexiones desde una instancia de procesamiento a destinos fuera de una red de VPC es el ancho de banda de salida máximo por instancia menor y una de estas tasas:

    • 25 Gbps, si las herramientas de redes de Tier_1 están habilitadas
    • 7 Gbps, si las redes de Tier_1 no están habilitadas
    • 1 Gbps para instancias de H3
    • 7 Gbps por NIC físico para las series de máquinas que admiten varias NIC físicas, como la 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 7 Gbps, según si las Herramientas de redes de Tier_1 están habilitadas.

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

  • Ancho de banda de salida de Internet por proyecto: se define el ancho de banda máximo de todas las conexiones desde las instancias de procesamiento en cada región de un proyecto a destinos fuera de una red de VPC según las cuotas de ancho de banda de salida de Internet del proyecto.

Los destinos fuera de una red de VPC incluyen todos los siguientes destinos, cada uno de los cuales es accesible por una ruta en la red de VPC de la instancia emisora, cuyo próximo salto es la puerta de enlace de Internet predeterminada:

  • Direcciones IPv4 e IPv6 externas globales para balanceadores de cargas de red de proxy y de aplicaciones externos
  • Direcciones IPv4 externas regionales para los recursos de Google Cloud, incluidas las direcciones IPv4 externas de la NIC de la VM, las direcciones IPv4 externas para el reenvío de protocolos externos, los balanceadores de cargas de red de traspaso externos y los paquetes de respuesta a las puertas de enlace de Cloud NAT.
  • Direcciones IPv6 externas regionales en subredes de pila doble con rangos de direcciones IPv6 externos que usan direcciones IPv6 externas de instancias de pila doble, reenvío de protocolos externos y balanceadores de cargas de red de transferencia externos. La subred debe estar ubicada en una red de VPC independiente que no tenga intercambio de tráfico. Se debe poder acceder al rango de direcciones IPv6 de destino mediante una ruta en la red de VPC de la instancia de envío cuyo próximo salto sea la puerta de enlace de Internet predeterminada. Si una subred de doble pila con un rango de direcciones IPv6 externo se encuentra en la misma red de VPC o en una red de VPC con intercambio de tráfico, consulta Salida a destinos enrutables dentro de una red de VPC.
  • Otros destinos externos a los que se puede acceder mediante una ruta estática en la red de VPC de la instancia de envío siempre que el próximo salto para la ruta sea la puerta de enlace de Internet predeterminada.

Para obtener más detalles sobre qué recursos de Google Cloud usan qué tipos de direcciones IP externas, consulta Direcciones IP externas.

Ancho de banda de entrada

Google Cloud controla el ancho de banda entrante (de entrada) según la forma en que el paquete entrante se enruta a una instancia de procesamiento receptora.

Entrada a destinos enrutables dentro de una red de VPC

Una instancia receptora puede manejar todos los paquetes entrantes que su tipo de máquina, sistema operativo y otras condiciones de red permiten. Google Cloud no implementa ninguna restricción de ancho de banda intencional en los paquetes entrantes entregados a una instancia si el paquete entrante se entrega mediante rutas dentro de una red de VPC:

  • Rutas de subred en la red de VPC de la instancia receptora
  • Rutas de subred de intercambio de tráfico en una red de VPC con intercambio de tráfico
  • Rutas en otra red cuyos próximos saltos son túneles de Cloud VPN, adjuntos de Cloud Interconnect (VLAN) o instancias de dispositivo de router ubicados en la red de VPC de la instancia de recepción

Los destinos de los paquetes enrutados dentro de una red de VPC incluyen lo siguiente:

  • La dirección IPv4 interna principal de la interfaz de red (NIC) de la interfaz receptora. Las direcciones IPv4 internas principales son direcciones IPv4 internas regionales que provienen de un rango de direcciones IPv4 principal de una subred.
  • Una dirección IPv4 interna de un rango de alias de IP de la NIC de la instancia receptora. Los rangos de IP de alias pueden provenir de un rango de direcciones IPv4 principal de una subred o de uno de los rangos de direcciones IPv4 secundarios.
  • Una dirección IPv6 del rango de direcciones IPv6 /96 asignado a una NIC de pila doble que recibe la instancia. Los rangos de IPv6 de las instancias de procesamiento pueden provenir de estos rangos de IPv6 de subredes:
  • Una dirección IPv4 interna de una regla de reenvío que se usa en el reenvío de protocolos internos a la instancia de recepción o en el balanceador de cargas de red interno en el que la instancia de recepción es un backend del balanceador de cargas. Las direcciones IPv4 de la regla de reenvío interno provienen del rango de direcciones IPv4 principal de una subred.
  • Una dirección IPv6 interna del rango /96 IPv6 de una regla de reenvío que el reenvío de protocolos interno usa a la instancia de destino o el balanceador de cargas de red de transferencia interno en el que la instancia de recepción es un backend del balanceador de cargas. Las direcciones IPv6 de la regla de reenvío interno provienen del rango de direcciones IPv6 interno de una subred.
  • Una dirección IPv6 externa del rango /96 IPv6 de una regla de reenvío que usa el reenvío de protocolos externos a la instancia de recepción o el balanceador de cargas de red de transferencia externo. La instancia receptora es un backend del balanceador de cargas cuando el paquete entrante se enruta dentro de la red de VPC con una de las rutas que se mencionaron antes en esta sección. Las direcciones IPv6 de las regla de reenvío externas provienen del rango de direcciones IPv6 externo de una subred.
  • Una dirección IP dentro del rango de destino de una ruta estática personalizada que usa la instancia receptora como una instancia de próximo salto (next-hop-instance o next-hop-address)
  • Una dirección IP dentro del rango de destino de una ruta estática personalizada mediante un próximo salto de balanceador de cargas de red de transferencia interno (next-hop-ilb), si la instancia es un backend para ese balanceador de cargas

Entrada a destinos fuera de una red de VPC

Google Cloud implementa las siguientes restricciones de ancho de banda para los paquetes entrantes que se entregaron a una instancia receptora mediante rutas fuera de una red de VPC. Cuando se involucra el balanceo de cargas, los límites del ancho de banda se aplican de forma individual a cada instancia receptora.

Para las series de máquinas que no admiten varias NIC físicas, la restricción de ancho de banda entrante aplicable se aplica de forma colectiva a todas las interfaces de red virtual (vNIC). El límite es la primera de las siguientes tasas que se alcance:

  • 1,800,000 paquetes por segundo
  • 30 Gbps

Para las series de máquinas que admiten varias NICs físicas, como A3, la restricción de ancho de banda entrante aplicable se aplica de forma individual a cada NIC física. El límite es la primera de las siguientes tasas que se alcance:

  • 1,800,000 pps (paquetes por segundo) por NIC físico
  • 30 Gbps por NIC físico

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

  • Una dirección IPv4 externa asignada en una configuración de acceso de NAT uno a uno en una de las interfaces de red (NIC) de instancias receptoras.
  • Una dirección IPv6 externa del rango de direcciones IPv6 /96 asignado a una NIC de una instancia receptora de pila doble cuando el paquete entrante se enruta mediante una ruta fuera de la red de VPC de la instancia receptora.
  • Una dirección IPv4 externa de una regla de reenvío que usa el reenvío de protocolos externos a la instancia de recepción o el balanceador de cargas de red de transferencia externo en el que la instancia receptora es un backend del balanceador de cargas.
  • Una dirección IPv6 externa del rango IPv6 /96 de una regla de reenvío que el reenvío de protocolos externo usa con la instancia receptora o el balanceador de cargas de red de transferencia externo, en el que la VM receptora es un backend del balanceador de cargas de red cuando el paquete entrante se enruta a través de una ruta fuera de una red de VPC.
  • Las respuestas entrantes establecidas que procesa Cloud NAT

Marcos jumbo

Para recibir y enviar marcos jumbo, configura la red de VPC que usan tus instancias de procesamiento. Establece la unidad de transmisión máxima (MTU) en un valor mayor, hasta 8896.

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

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

Si usas una imagen de SO que no tiene compatibilidad total con los marcos jumbo, puedes instalar de forma manual la versión del controlador de gVNIC v1.3.0 o una posterior. Google recomienda instalar la versión del controlador gVNIC marcada como Latest para beneficiarse de funciones adicionales y correcciones de errores. Puedes descargar los controladores de gVNIC desde GitHub.

Para actualizar de forma manual la versión del controlador gVNIC en tu SO invitado, consulta Uso en sistemas operativos no compatibles.

Recibe y transmite colas

A cada NIC o vNIC de una instancia de procesamiento se le asigna una cantidad 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 adjunta a un núcleo de CPU virtual mediante la interrupción. Si la cola de RX está llena y no hay un búfer disponible para colocar un paquete, el paquete se descarta. Por lo general, esto puede suceder si una aplicación usa en exceso un núcleo de CPU virtual que también está conectado a la cola de paquetes elegida.
  • 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. Luego, la NIC procesa el descriptor y transmite el paquete.

Asignación de colas predeterminada

A menos que asignes recuentos de colas para NIC de forma explícita, puedes modelar el algoritmo que usa Google Cloud a fin de asignar una cantidad fija de colas de RX y TX por NIC de esta manera:

Instancias de equipos físicos
En el caso de las instancias de Bare Metal, solo hay una NIC, por lo que el recuento máximo de colas es de 16.
Crea instancias de VM que usen la interfaz de red gVNIC.

Para las instancias de C4, para mejorar el rendimiento, las siguientes configuraciones usan una cantidad fija de colas:

  • Para instancias de Linux con 2 CPU virtuales, el recuento de colas es 1.
  • Para instancias de Linux con 4 CPU virtuales, el recuento de colas es 2.

En el caso de las otras series de máquinas, el recuento de colas depende de si la serie de máquinas usa Titanium o no.

  • Para instancias de tercera generación (excepto M3) y versiones posteriores que usan Titanium:

    Divide la cantidad de CPU virtuales por la cantidad de vNIC (num_vcpus/num_vnics) y descarta el resto.

  • Para las VMs de primera y segunda generación que no usan Titanium:

    Divide la cantidad de CPUs virtuales por la cantidad de vNICs y, luego, divide el resultado por 2 (num_vcpus/num_vnics/2). Descarta el resto.

Para finalizar el cálculo del recuento de colas predeterminado, haz lo siguiente:

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

  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 mayor que 16, ignóralo y asigna a cada NIC 16 colas.

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

Divide la cantidad de CPUs virtuales por la cantidad de vNIC y descarta el resto: [number of vCPUs/number of vNICs].

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

  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 mayor que 32, ignóralo y asigna a cada NIC 32 colas.

Ejemplos

En los siguientes ejemplos, se muestra cómo calcular la cantidad predeterminada de colas para una instancia de VM:

  • Si una instancia de VM usa VirtIO y tiene 16 CPU virtuales y 4 vNIC, 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 CPU virtuales y dos vNIC, el número calculado es [128/2/2] = 32. Google Cloud asigna a cada vNIC la cantidad máxima de colas posible por NIC. Google Cloud asigna 16 colas por vNIC.

En los sistemas Linux, puedes usar ethtool para configurar una NIC con menos colas que la cantidad de colas que asigna Google Cloud por NIC.

Asignación de colas personalizadas para instancias de VM

En lugar de la asignación de cola predeterminada, puedes asignar un recuento de colas personalizado (total de RX y TX) a cada NIC cuando crees una instancia de procesamiento nueva mediante la API de Compute Engine.

La cantidad de colas personalizadas que especifiques debe cumplir con las siguientes reglas:

  • El recuento mínimo de colas que puedes asignar por NIC es de uno.

  • El recuento máximo de colas que puedes asignar a cada vNIC de una instancia de VM es el menor entre el recuento de CPU virtuales o el recuento máximo de colas por vNIC, según el tipo de controlador:

    • Si usas virtIO o un controlador personalizado, el recuento máximo de colas es de 32.
    • Con gVNIC, el recuento máximo de colas es de 16, excepto en los siguientes casos, en los que el recuento máximo de colas es de 32:
      • Instancias A2 o G2
      • Instancias de TPU
      • Instancias C2, C2D, N2 o N2D con las redes Tier_1 habilitadas

    • Para las siguientes configuraciones de Confidential VM, el recuento máximo de colas es 8:

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

  • Si asignas recuentos de colas personalizadas a todas las NICs de la instancia de procesamiento, la suma de las asignaciones de recuento de colas debe ser menor o igual que la cantidad de CPUs virtuales asignada a la instancia de instancia.

Puedes exceder la suscripción del recuento de colas personalizadas para tus NIC. En otras palabras, puedes tener una suma de recuentos de colas asignados a todas las NIC de tu instancia de VM, que sea mayor que la cantidad de CPU virtuales para tu instancia. Para exceder la suscripción del recuento de colas personalizadas, la instancia de VM debe satisfacer las siguientes condiciones:

  • Usar gVNIC como el tipo de vNIC para todas las NIC configuradas para la instancia
  • Usa un tipo de máquina que admita las redes Tier_1.
  • Tiene habilitadas las redes de Tier_1.
  • Especificaste un recuento de colas personalizado para todas las NIC configuradas para la instancia.

Con el exceso de suscripciones a una cola, el recuento máximo de colas para la instancia de VM es 16 veces la cantidad de NIC. Por lo tanto, si tienes 6 NIC configuradas para una instancia con 30 CPU virtuales, puedes configurar un máximo de (16 * 6) o 96 colas personalizadas para tu instancia.

Ejemplos

  • Si una instancia de VM tiene 8 CPU virtuales y 3 vNIC, el recuento máximo de colas para la instancia es la cantidad de CPUs virtuales u 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 mientras se mantienen las otras dos asignaciones de cola de NIC porque la suma de colas asignadas no puede exceder la cantidad de CPU virtuales.

  • Si tienes una VM N2 con 96 CPU virtuales y 2 vNIC, puedes asignar a cada vNIC hasta 32 colas si usas el controlador virtIO, o hasta 16 colas si usas el controlador gVNIC. Si habilitas las redes Tier_1 para la VM N2, puedes asignar hasta 32 colas a cada vNIC. En este ejemplo, la suma de colas asignadas siempre es menor o igual que la cantidad de CPUs virtuales.

También es posible asignar un recuento de colas personalizado para solo algunas NIC, lo que permite que Google Cloud asigne colas a las NIC restantes. La cantidad de colas que puedes asignar por vNIC sigue sujeta a las reglas que se mencionaron antes. Puedes modelar la viabilidad de tu configuración y, si la configuración es posible, la cantidad de colas que Google Cloud asigna a las vNIC restantes mediante este proceso:

  1. Calcula la suma de colas de las vNIC mediante la asignación de colas personalizadas. Para una VM de ejemplo con 20 CPU virtuales y 6 vNIC, supongamos que asignas 5 colas nic0, 6 colas nic1, 4 colas nic2 y dejas que Google Cloud asigne colas para nic3, nic4 y nic5. En este ejemplo, la suma de colas asignadas de forma personalizada es 5+6+4 = 15.

  2. Resta la suma de colas asignadas de forma personalizada de la cantidad de CPU virtuales. Si la diferencia es menor que la cantidad de vNIC restantes para las que Google Cloud debe asignar colas, Google Cloud mostrará un error porque cada vNIC debe tener al menos una cola.

    Continuando con el ejemplo de una VM que tiene 20 CPU virtuales y una suma de 15 colas asignadas de forma personalizada, Google Cloud tiene 20-15 = 5 colas para asignar a las vNIC restantes (nic3, nic4 y nic5).

  3. Divide la diferencia del paso anterior por la cantidad de vNIC 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 recuento de colas que coincide con el número calculado, siempre que el número calculado no sea mayor que el número máximo de colas por vNIC. El número máximo de colas por cada NIC depende del tipo de controlador:

  • Usando virtIO o un controlador personalizado, si la cantidad calculada de colas para cada NIC restante es mayor que 32, Google Cloud asigna las colas 32 de NIC restantes a cada una.
  • En gVNIC, si la cantidad calculada de colas para cada NIC restante es mayor que el límite de 16 o 32 (según la configuración de la VM), Google Cloud asigna cada cola 16 de NIC restante.

Configura recuentos de colas personalizados

Para crear una instancia de procesamiento que use un recuento de colas personalizado para uno o más NIC o vNIC, completa los siguientes pasos.

En los siguientes ejemplos de código, la VM se crea con el tipo de interfaz de red configurado en GVNIC y el rendimiento de red Tier_1 por VM habilitado. Puedes usar estos ejemplos de código para especificar los recuentos máximos de colas y la sobresuscripción de colas que están 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 vNIC que planeas configurar, créalas.
  2. Usa el comando gcloud compute instances create para crear la instancia de procesamiento. Repite la marca --network-interface en cada vNIC que desees configurar para la instancia y, luego, 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

Reemplaza lo siguiente:

  • INSTANCE_NAME: Es un nombre para la nueva instancia de procesamiento.
  • ZONE: la zona en la cual se creará la instancia.
  • MACHINE_TYPE: Es el tipo de máquina de la instancia. Para realizar una suscripción superior al recuento de colas, el tipo de máquina que especifiques debe ser compatible con las redes gVNIC y Tier_1.
  • NETWORK_NAME: el nombre de la red que se creó antes.
  • SUBNET_*: el nombre de una de las subredes creadas antes
  • QUEUE_SIZE: la cantidad de colas para vNIC, sujeta a las reglas que se analizan en Asignación de colas personalizada.

Terraform

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

  2. Crea una instancia de procesamiento con recuentos de colas específicos para las vNIC a través del recurso google_compute_instance. Repite el parámetro --network-interface en cada vNIC que desees configurar para la instancia de procesamiento y, luego, 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""
}

}

Reemplaza lo siguiente:

  • VM_NAME: Es un nombre para la nueva instancia de procesamiento.
  • PROJECT_ID: Es el ID del proyecto en el que se creará la instancia. A menos que uses una red de VPC compartida, el proyecto que especifiques debe ser el mismo en el que se crearon todas las subredes y las redes.
  • DEVICE_NAME: el 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: el tamaño del disco de arranque, expresado en GiB
  • DISK_TYPE: el tipo de disco que se usará para el disco de arranque, por ejemplo, pd-standard
  • MACHINE_TYPE: Es el tipo de máquina de la instancia. Para realizar una suscripción superior al recuento de colas, el tipo de máquina que especifiques debe ser compatible con las redes gVNIC y Tier_1.
  • ZONE: la zona en la cual se creará la instancia.
  • QUEUE_COUNT: la cantidad de colas para vNIC, sujeta a las reglas que se analizan en Asignación de colas personalizada.
  • 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 vNIC que planeas configurar, créalas.

  2. Crea una instancia de procesamiento con recuentos de colas específicos para las NIC 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"
    } ],
}

    Reemplaza lo siguiente:

    • PROJECT_ID: ID del proyecto en el que se creará la instancia de procesamiento
    • ZONE: Es la zona en la que se creará la instancia de procesamiento.
    • VM_NAME: Nombre de la instancia de procesamiento nueva
    • MACHINE_TYPE: Es el tipo de máquina, predefinido o personalizado, de la nueva instancia de procesamiento. Para aumentar la suscripción del recuento de colas, el tipo de máquina debe ser compatible con las redes gVNIC y de nivel 1.
    • SUBNET_*: el nombre de la subred a la que se conecta la interfaz de red
    • QUEUE_COUNT: la cantidad de colas para vNIC, sujeta a las reglas que se analizan en Asignación de colas personalizada.

Asignaciones de cola y cambio del tipo de máquina

Las instancias de procesamiento se crean con una asignación de cola predeterminada, o puedes asignar un recuento de colas personalizado a cada tarjeta de interfaz de red virtual (vNIC) cuando creas una instancia de procesamiento nueva mediante la API de Compute Engine. Las asignaciones de colas de vNIC predeterminadas o personalizadas solo se establecen cuando se crea una instancia de procesamiento. 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 deseas cambiar tiene una cantidad diferente de CPU virtuales, los recuentos de colas predeterminados de la instancia se vuelven a calcular en función del tipo de máquina nuevo.

Si tu VM tiene vNICs que usan recuentos de colas personalizados y no predeterminados, puedes cambiar el tipo de máquina mediante Google Cloud CLI o la API de Compute Engine para actualizar las propiedades de la instancia. La conversión se realiza de forma correcta si la VM resultante admite el mismo recuento de colas por vNIC que la instancia original. Para las VMs que usan la interfaz de 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 si sigues las instrucciones en Mueve tu carga de trabajo a una instancia de procesamiento nueva.

¿Qué sigue?