Ancho de banda de red

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

En esta página, se describen los límites de ancho de banda de la red, 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 su tráfico de salida (saliente).
    • Los paquetes enviados a una instancia de 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 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.

Toda la información de esta página se aplica a las instancias de procesamiento de Compute Engine y 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 el 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 para tu instancia de procesamiento.

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.

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

Las NIC dinámicas no son compatibles con las instancias de Compute Engine que ejecutan un SO Windows.

Resumen del ancho de banda

En la siguiente tabla, se ilustra el ancho de banda máximo posible 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.

Límites de ancho de banda de salida

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 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 2,000 Gbps.
    • Las instancias A4 y A3 admiten límites de ancho de banda de salida de hasta 3,600 Gbps.
    • Las instancias M4, C4, C4D, 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.

Límites de ancho de banda de entrada

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.
  • Para obtener el mayor ancho de banda de entrada posible, habilita las redes de nivel 1.
  • 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 limitando el 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 NICs físicas, como A3, 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
  • 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 (de salida) con tasas de salida máximas por instancia. Estas tarifas se basan en el tipo de máquina de la instancia de procesamiento que envía el paquete y en si se puede acceder al destino del paquete a través de rutas dentro de una red de VPC o rutas fuera de una 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.

En la siguiente tabla, se resume el ancho de banda de salida máximo para cada serie de máquinas. 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 (con los vínculos de cada serie de máquinas en la tabla).

Límite máximo de salida por instancia
Series de máquinas Estándar Redes Tier_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 Gbps N/A
Núcleo compartido E2 2 Gbps N/A
H3 200 Gbps N/A
M4 100 Gbps 200 Gbps
M3 32 Gbps 100 Gbps
M2 32 Gbps en CPU Intel Cascade Lake o posterior
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 (excluye VMs con 1 CPU virtual) 32 Gbps en CPU Intel Skylake y posteriores
16 Gbps en plataformas de CPU anteriores		 N/A
Tipos de máquinas N1 con 1 CPU virtual 2 Gbps 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 red de las series de máquinas optimizadas para aceleradores, consulta Máquinas de GPU y redes.

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:

  • Usa VirtIO en lugar de gVNIC con instancias de procesamiento que admiten 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 posterior que usen Titanium para transferir 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:

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 emisora se conecta a la NIC de otra instancia)externa Dirección IPv4, 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 la NIC de una instancia receptora de pila doble o solo IPv6.
    • 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 la NIC de una instancia receptora de pila doble o solo IPv6.
    • 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 hacia 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 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 recursos de Google Cloud , incluidas las direcciones IPv4 externas de la NIC virtual de la VM, las direcciones IPv4 externas para el reenvío de protocolos externos, los balanceadores de cargas de red de transferencia externos y los paquetes de respuesta a las puertas de enlace de Cloud NAT.
  • Direcciones IPv6 externas regionales en subredes de pila doble o solo IPv6 con rangos de direcciones IPv6 externas que utilizan las direcciones IPv6 externas de instancias de pila doble o solo IPv6, el reenvío de protocolos externos y los balanceadores de cargas de red de paso externos. La subred debe estar ubicada en una red de VPC separada y sin intercambio de tráfico. Se debe poder acceder al rango de direcciones IPv6 de destino a través de 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 o solo IPv6 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 a través de 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 una instancia receptora de pila doble o solo IPv6. 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 el reenvío de protocolos externo usa a la instancia de destino 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 a través de 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 los siguientes límites de ancho de banda para los paquetes entrantes que se entregan a una instancia receptora a través de 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 NICs físicas, la restricción de ancho de banda entrante aplicable se aplica de forma colectiva a todas las interfaces de red virtuales (vNICs). 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 o solo IPv6 cuando el paquete entrante se enruta a través de 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

Usa marcos jumbo para maximizar el ancho de banda de la red

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 el controlador gVNIC versión 1.3 o posterior en instancias de VM, o con el controlador IDPF en instancias de Bare Metal. No todas las Google Cloud imágenes públicas 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.

Marcos jumbo y máquinas con GPU

Para los tipos de máquinas con GPU, usa la configuración de MTU recomendada para los Jumbo frames. Para obtener más información, consulta Configuración de MTU recomendada para marcos jumbo.

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 para 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 equipos físicos, solo hay una NIC, por lo que el recuento máximo de colas es 16.
Crea instancias de VM que usen la interfaz de red gVNIC.

En el caso de las instancias C4, para mejorar el rendimiento, los siguientes parámetros de configuración usan una cantidad fija de filas:

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

Para las otras series de máquinas, el recuento de la cola depende de si la serie de máquinas usa Titanium.

  • Para las instancias de tercera generación (excepto M3) y posteriores que usan Titanium, haz lo siguiente:

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

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

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

Para finalizar el cálculo predeterminado del recuento de la fila, 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 NIC, 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 CPU virtuales por la cantidad de vNICs 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 NIC, 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 vNIC. Google Cloudasigna 16 colas por vNIC.

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

Recuentos de filas cuando se usa la interfaz de red dinámica

Si usas interfaces de red dinámicas con tus interfaces de red, los recuentos de filas 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 personalizada 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 redes Tier_1 habilitadas

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

      • AMD SEV en los 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 cumplir con 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 redes Tier_1.
  • Tiene habilitadas las redes Tier_1.
  • Haber especificado 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 CPU virtuales, 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 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 a cada una 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 CPU virtuales.

También es posible asignar un recuento de colas personalizado para solo algunas NIC, lo que permite queGoogle 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 con 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 Cloudasigne 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 queGoogle Cloud debe asignar colas, Google Cloud devuelve 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, nic5).

  3. Divide la diferencia del paso anterior por la cantidad de NIC virtuales 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 NIC virtual 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 NIC virtual. 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 cada NIC restante 32 colas.
  • 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 una 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 establecido 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 sobreinscripción de colas que están disponibles para los tipos de máquinas compatibles.

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 para 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: 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 sobreasignar el recuento de filas, el tipo de máquina que especifiques debe admitir gVNIC y redes 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 para 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: un nombre para la nueva instancia de procesamiento
  • PROJECT_ID: 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 sobreasignar el recuento de filas, el tipo de máquina que especifiques debe admitir gVNIC y redes 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 a través del 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 nueva instancia de procesamiento
    • MACHINE_TYPE: Es el tipo de máquina, predefinido o personalizado, de la instancia de procesamiento nueva. Para exceder la suscripción del recuento de filas, el tipo de máquina debe admitir gVNIC y redes 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 con la API de Compute Engine. Las asignaciones de colas de vNIC predeterminadas o personalizadas solo se establecen cuando creas 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 con Google Cloud CLI 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 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?