Ancho de banda de red

Google Cloud incluye el ancho de banda por instancia de máquina virtual (VM), no por interfaz de red virtual (NIC) o 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 VM de Google Cloud:
    • Los paquetes enviados desde una VM de Google Cloud componen el tráfico de salida (saliente).
    • Los paquetes enviados a una VM de Google Cloud componen el tráfico de entrada (entrante).
  • Cómo se enruta el paquete: un paquete se puede enrutar desde una VM de envío o hacia una VM 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 VM. 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 VMs de Compute Engine y a los productos que dependen de estas. Por ejemplo, un nodo de Google Kubernetes Engine es una VM 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) VM, y el método de enrutamiento de paquetes.

salida

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

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

    • Las VMs N2, N2D, C2 y C2D con herramientas de redes de Tier_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 VMs A2 y G2 admiten límites de ancho de banda de salida de hasta 100 Gbps.
    • Las VMs A3 admiten límites de ancho de banda de salida de hasta 1,000 Gbps.
    • Las VMs C3, C3D y Z3 (vista previa) 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 VM según el tipo de máquina de la VM 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 VM 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 VM, 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 el número de lecturas del disco que hace tu VM puede 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 VM 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 las series de máquinas que admiten 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 VM según el tipo de máquina de la VM 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 VM y los datos transferidos a todos los discos persistentes conectados a la VM.

Ancho de banda de salida máximo por VM

Por lo general, el ancho de banda de salida 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 VM más bajo sin las herramientas de redes de Tier_1 Límite máximo de salida por VM sin redes de Tier_1
E2 1 Gbps 16 Gbps
C3 23 Gbps 100 Gbps
C3D 20 Gbps 100 Gbps
T2D 10 Gbps 32 Gbps
N2, C2, N2D y C2D 10 Gbps 32 Gbps
H3 No disponible 200 Gbps
Z3 (Vista previa) 23 Gbps 100 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
A3, A2 y G2 No disponible Según el tipo de GPU

Puedes encontrar el ancho de banda de salida máximo por VM 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 VM 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:

  • Controlador Ethernet invitado: gVNIC ofrece un mejor rendimiento que la interfaz de red de VirtIO
  • Tamaño del paquete
  • Sobrecarga del protocolo
  • La cantidad de flujos
  • la configuración del controlador de Ethernet del SO invitado de la VM, como la descarga de la suma de verificación y la descarga de segmentación de TCP (TSO)
  • Congestión en la red
  • En una situación en la que los discos persistentes 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 en la documentación de Persistent Disk.

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

Salida a destinos enrutables dentro de una red de VPC

Desde la perspectiva de una VM 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 VM que se describe en la sección Ancho de banda de salida máximo por VM.
  • Ancho de banda de salida interregional por proyecto: Si una VM emisora y un destino interno o su siguiente 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 VM a un destino de dirección IP interna enrutable por un túnel de Cloud VPN 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 VM de envío mediante una ruta cuyo siguiente 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 VM receptora. (Cuando una VM emisora se conecta a la NIC de otra VM)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 VM 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 VM.
    • 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 VM.
    • 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 VMs 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 VM 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 VM: El ancho de banda máximo de todas las conexiones desde una VM hacia destinos fuera de una red de VPC es el Ancho de banda de salida máximo por VM menor y una de estas tasas:

    • 25 Gbps, si las herramientas de redes de Tier_1 están habilitadas
    • 7 Gbps, si las herramientas de redes de Tier_1 no están habilitadas
    • 1 Gbps para VM 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 n2-standard-16 tiene un ancho de banda de salida máximo por VM de 32 Gbps, el ancho de banda de salida por VM de una instancia n2-standard-16 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 VM 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 VMs 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 VM 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 doble pila con Rangos de direcciones IPv6 externos que usan las direcciones IPv6 externas de VM de pila doble, el reenvío de protocolos externos y los balanceadores de cargas de red de traspaso externos, siempre y cuando la subred esté ubicada en una red de VPC independiente que no intercambia tráfico y la dirección IPv6 de destino sea accesible al rango a través de una ruta en la red de VPC de la VM emisora cuyo próximo saltosea 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 VM 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 VM receptora.

Entrada a destinos enrutables dentro de una red de VPC

Una VM 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 VM si el paquete entrante se entrega mediante rutas dentro de una red de VPC:

  • Rutas de subred en la red de VPC de la VM 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 VMs de dispositivo de router ubicados en la red de VPC de la VM 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 VM 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 VM 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 VM. Los rangos de IPv6 de las VMs 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 VM de recepción o en el balanceador de cargas de red interno en el que la VM 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 VM de destino o el balanceador de cargas de red de transferencia interno en el que la VM 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 IPv6 /96 de una regla de reenvío que el reenvío de protocolos externo usa con la VM receptora o el balanceador de cargas de red de transferencia externo, en el que la VM receptora es un backend del balanceador de cargas cuando el paquete entrante se enruta dentro de la red de VPC mediante 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 VM receptora como una VM 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 VM 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 VM 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 VM 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 NICs virtuales. 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 VM receptoras.
  • Una dirección IPv6 externa del rango de direcciones IPv6 /96 asignado a una NIC de una VM receptora de pila doble cuando el paquete entrante se enruta mediante una ruta fuera de la red de VPC de la VM receptora.
  • Una dirección IPv4 externa de una regla de reenvío que usa el reenvío de protocolos externos a la VM de recepción o el balanceador de cargas de red de transferencia externo en el que la VM 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 VM receptora o el balanceador de cargas de red de transferencia externo, en el que la VM receptora es un backend del balanceador de cargas 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 VMs. 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.

Para usar marcos jumbo con el controlador gVNIC, debes usar la versión 1.3 o posterior del controlador. No todas las imágenes públicas de Google Cloud incluyen esta versión del controlador. 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. Las versiones con imágenes que indican la compatibilidad total con los marcos jumbo, incluyen el controlador de gVNIC actualizado, incluso si el SO invitado muestra la versión de controlador gve como 1.0.0.

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 de VM 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 el vNIC recibe un paquete de la red, elige 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 una CPU virtual. central mediante una 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:

  1. Usa uno de los siguientes métodos, según el tipo de interfaz de red:

    • VirtIO: Divide la cantidad de CPUs virtuales por la cantidad de NICs y descarta el resto: [[number of vCPUs/number of NICs]].
    • gVNIC: Divide la cantidad de CPUs virtuales por la cantidad de NICs y, luego, divide el resultado por 2 y descarta el resto: [[number of vCPUs/number of NICs/2]].

    Este cálculo siempre da como resultado un número entero (no una fracción).

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

  3. Determina si el número calculado es mayor que el número máximo de colas por NIC. El número máximo de colas por cada NIC depende del tipo de controlador:

    • Con virtIO o un controlador personalizado, la cantidad máxima de colas por vNIC es 32. Si el número calculado es mayor que 32, ignóralo y asigna a cada NIC 32 colas.
    • Con gVNIC, la cantidad máxima de colas por NIC es 16. Si el número calculado es mayor que 16, ignóralo y asigna a cada NIC 16 colas.

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

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

  • Si una VM usa gVNIC y tiene 128 CPU virtuales y dos NICs, 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 personalizada

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 VM 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 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.

  • Si asignas recuentos de colas personalizadas a todas las NICs de la VM, 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 VM.

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 VM, que sea mayor que la cantidad de CPU virtuales para tu VM. Para exceder la suscripción del recuento de colas personalizadas, debes cumplir con las siguientes condiciones:

  • Usar gVNIC como el tipo de vNIC para todas las NIC configuradas para la VM.
  • Que tu VM use un tipo de máquina de las series de máquinas N2, N2D, C2 y C2D.
  • Haber habilitado las redes Tier_1 para la VM.
  • Haber especificado un recuento de colas personalizado para todas las NIC configuradas para la VM.

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

Ejemplos

  • Si una VM tiene 8 CPUs virtuales y 3 NICs, el recuento máximo de colas para la VM 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 (8).

  • Si una VM tiene 96 CPU virtuales y 2 NIC, puedes asignar a cada NIC hasta 32 colas si usas el controlador virtIO, o hasta 16 colas a cada una si usas el controlador gVNIC. En este ejemplo, la suma de colas asignadas siempre es menor que la cantidad de CPU 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 NIC restantes mediante este proceso:

  1. Calcula la suma de colas de las NIC mediante la asignación de colas personalizadas. Para una VM de ejemplo con 20 CPU virtuales y 6 NIC, 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 no es, al menos, igual a la cantidad de NIC restantes para las que Google Cloud debe asignar colas, Google Cloud mostrará un error. Continúa con la VM de ejemplo de 20 CPU virtuales y una suma de 15 colas asignadas de forma personalizada, Google Cloud tiene 20-15 = 5 colas para asignar a las NIC restantes (nic3, nic4 y nic5).

  3. Divide la diferencia del paso anterior por la cantidad de NIC restantes y descarta el resto: ⌊(number of vCPUs - sum of assigned queues)/(number of remaining NICs)⌋. 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 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. 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 16, Google Cloud asigna cada cola 16 de NIC restante.

Configura recuentos de colas personalizados

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

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 VM. Repite la marca --network-interface en cada vNIC que desees configurar para la VM y, luego, incluye la opción queue-count.
    gcloud compute instances create VM_NAME \
        --zone=ZONE \
        --machine-type=MACHINE_TYPE \
        --network-performance-configs=total-egress-bandwidth-tier=TIER_1  \
        --network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
        --network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2

Reemplaza lo siguiente:

  • VM_NAME: un nombre para la VM nueva
  • ZONE: Es la zona en la que se creará la VM.
  • MACHINE_TYPE: el tipo de máquina de la VM. 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 VM 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 VM 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 VM nueva
  • PROJECT_ID: ID del proyecto en el que se creará la VM 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: el tipo de máquina de la VM. El tipo de máquina que especifiques debe ser compatible con las redes gVNIC y Tier_1.
  • ZONE: Es la zona en la que se creará la VM.
  • QUEUE_COUNT: la cantidad de colas para la 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 VM 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 VM
    • ZONE: Zona en la que se creará la VM
    • VM_NAME: Nombre de la VM nueva
    • MACHINE_TYPE: Es el tipo de máquina, predefinido o personalizado de la VM nueva.
    • 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 VMs 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 VM nueva mediante la API de Compute Engine. Las asignaciones de colas de vNIC predeterminadas o personalizadas solo se establecen cuando creas una VM. Si la VM 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 VM 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 VM 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, que solo usa gVNIC. En su lugar, puedes migrar tu VM a un tipo de máquina de tercera generación si sigues las instrucciones en Migra tu carga de trabajo de una VM existente a una nueva.

¿Qué sigue?