Ancho de banda de red

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Google Cloud incluye el ancho de banda por instancia de máquina virtual (VM), no por interfaz de red (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:

  • La dirección del tráfico: como se usa en esta página, la dirección del tráfico siempre es 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).
  • El tipo de dirección IP de destino: Google Cloud clasifica las direcciones IP como internas o externas:

    • Una dirección IP dentro de una red de VPC se denomina dirección IP interna. Por ejemplo, la NIC de cada VM tiene una dirección IP interna principal ubicada en una red de VPC. Las direcciones IP internas pueden ser cualquier rango de direcciones IP válidas privadas o privadas reutilizadas como públicas.
    • Una dirección IP a la que se puede acceder desde Internet es una dirección IP externa. Las direcciones IP externas se pueden ubicar en Google Cloud, como la dirección IP externa asignada a una NIC de una VM. Las direcciones IP externas siempre son direcciones IP públicas, incluidas las direcciones IP públicas en Internet fuera de Google Cloud.

    Consulta Direcciones IP en la documentación de VPC para obtener definiciones precisas. Por ejemplo, si reutilizas una dirección IP pública en tu red de VPC de forma privada, esta es una dirección IP interna y ya no se puede acceder a la dirección IP externa correspondiente.

Toda la información de esta página se aplica a las VM 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.

Ni las interfaces de red adicionales (NIC), ni las direcciones IP adicionales por NIC aumentan el ancho de banda de entrada o salida de una VM. Por ejemplo, una VM n1-standard-8 con dos NIC está limitada a un ancho de banda de salida total de 16 Gbps, no a un ancho de banda de salida de 16 Gbps por NIC.

Tabla de resumen del ancho de banda

En la siguiente tabla, se resumen las expectativas de ancho de banda:

Dirección de destino del paquete
Dirección del tráfico Destino de la dirección IP interna Destino de la dirección IP externa
Salida
desde una VM de Google Cloud
  • La salida máxima posible se define según el tipo de máquina de la VM que envía. Las configuraciones de rendimiento de red Tier_1 por VM admiten límites de ancho de banda de salida de hasta 100 Gbps. Las herramientas de redes Tier_1 son una opción para algunas VMs creadas en las series de máquinas N2, N2D, C2 y C2D. Para obtener más información, consulta Configura el rendimiento de red Tier_1 por VM.
  • Para alcanzar la tasa de salida máxima posible, envía tráfico a una dirección IP interna asociada con otra VM de Google Cloud en la misma zona que la VM de envío, en la misma red de VPC o una red de VPC conectada mediante intercambio de tráfico entre redes de VPC.
La salida máxima posible de una sola VM no puede exceder los siguientes valores:
  • Para todos los flujos de salida a direcciones IP externas, 7 Gbps en total o 25 Gbps en total con redes Tier_1
  • 3 Gbps por flujo de salida individual a una dirección IP externa
Entrada
a una VM de Google Cloud
  • Limitado por el tipo de máquina, el sistema operativo y las condiciones de la red.
  • Google Cloud no impone ninguna limitación adicional en la entrada a una dirección IP interna.
Google Cloud protege cada VM mediante la limitación del tráfico de entrada entregado a una dirección IP externa asociada a la VM. El límite es la primera de las siguientes tasas que se alcance:
  • 1,800,000 pps (paquetes por segundo)
  • 30 Gbps

Ancho de banda de salida

Google Cloud limita el ancho de banda saliente (salida) por VM y por proyecto. El ancho de banda saliente incluye el tráfico enviado desde todas las NIC de la VM y los datos transferidos a todos los discos persistentes conectados a la VM.

El ancho de banda máximo de salida estándar depende del tipo de máquina de la 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 muestran los límites mínimos y máximos del ancho de banda de salida solo para el nivel de red estándar, no por el rendimiento de red de Tier_1 de VM.

Series de máquinas Límite de salida mínimo estándar Límite de salida máximo estándar
E2 1 Gbps 16 Gbps
T2D 10 Gbps 32 Gbps
N2, C2, N2D y C2D 10 Gbps 32 Gbps
N1 (excluye VMs con 1 CPU virtual) 10 Gbps 32 Gbps en la plataforma de CPU Skylake
16 Gbps en plataformas de CPU anteriores a Skylake
Tipos de máquina N1 con 1 CPU virtual, f1-micro y g1-small 2 Gbps 2 Gbps
A2 Basado en GPU Basado en GPU

Por ejemplo, una VM basada en el tipo de máquina t2d-standard-6 tiene un ancho de banda de salida máximo estándar de 12 Gbps. Este valor se basa en 6 CPU virtuales, con 2 Gbps para cada CPU virtual. El resultado, 12 Gbps, es mayor que el valor mínimo para la serie de máquinas y no supera el límite máximo de 32.

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

El ancho de banda máximo de salida posible no está garantizado. Además del tipo de máquina, el ancho de banda de salida se ve afectado por factores como los que se encuentran en 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
  • El destino del paquete; Google Cloud controla el tráfico de salida de una VM de manera diferente según si la dirección de destino del paquete saliente es una dirección IP interna o externa.
  • 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 otros factores que afectan el rendimiento en la documentación de Persistent Disk.

Puedes habilitar el rendimiento de las redes de Tier_1 por VM con tipos de máquinas optimizados para procesamiento y de uso general más grandes, que ofrecen anchos de banda de red más altos.

Salida a destinos de direcciones IP internas

Desde la perspectiva de una VM de envío, Google Cloud restringe la salida máxima posible a destinos de direcciones IP internas según el tipo de máquina de la VM de envío. Las direcciones IP internas son las que están en una red de VPC, una red de VPC diferente conectada mediante el intercambio de tráfico entre redes de VPC o una red conectada a tu red de VPC con Cloud VPN o Cloud Interconnect.

En la siguiente lista, se clasifica el tráfico de VM a VM mediante fuentes y destinos de direcciones IP internas, desde el ancho de banda más alto posible hasta el más bajo:

  • Entre VM en la misma zona
  • Entre VM en diferentes zonas de la misma región
  • Entre VM en diferentes zonas de distintas regiones
  • De una VM a las APIs y los servicios de Google mediante Private Service Connect

Cuando se envía tráfico desde una VM a una dirección IP interna ubicada en una red de VPC diferente conectada mediante túneles de Cloud VPN, el ancho de banda de salida se limita a la tasa máxima de datos de un túnel de Cloud VPN.

Para usar por completo el ancho de banda de varios túneles y el enrutamiento de ECMP, debes usar varias conexiones de TCP (tuplas de 5 únicas). Una tupla de cinco se compone de un protocolo, una dirección IP de origen, un puerto de origen, una dirección IP de destino y un puerto de destino.

Salida a destinos de direcciones IP externas

Desde la perspectiva de una VM de envío, Google Cloud limita el tráfico saliente enviado a un destino público o de dirección IP externa a cualquiera de las siguientes tasas que se alcance primero. Una dirección IP externa se puede enrutar de forma pública, ya sea una dirección IP externa de un recurso de Google Cloud o una dirección en Internet.

  • 25 Gbps en total para todos los flujos de paquetes y conexiones en VMs con las redes Tier_1 habilitadas
  • 7 Gbps en total para todos los flujos de paquetes y conexiones en las VMs sin las redes Tier_1 habilitadas
  • 3 Gbps por flujo (hash de cinco tuplas único)

Puedes asociar una dirección IP externa con una VM de Google Cloud en una de las siguientes capacidades:

  • Puedes asignar una dirección IP externa a la interfaz de red de una VM.
  • Una regla de reenvío externa usada para el reenvío de protocolos requiere una dirección IP externa.
  • La dirección IP de la regla de reenvío del balanceador de cargas de TCP/UDP de red requiere una dirección IP externa.
  • Las direcciones IP externas están asociadas con una puerta de enlace de Cloud NAT.

Por ejemplo, aunque una instancia n2-standard-16 tiene un límite de ancho de banda de salida de 32 Gbps, el ancho de banda total de salida a Internet se limita a 7 Gbps.

Cuotas y límites de salida agregada por proyecto

Google Cloud también aplica lo siguiente para los proyectos:

  • Ancho de banda de salida de Internet máximo de todas las VM de cada región a direcciones IP externasfuera de Google Cloud: Este máximo se define por cada cuota de Ancho de banda de salida de Internet de la región.

  • Ancho de banda de salida máximo de todas las VM en una región determinada a todas las demás regiones de Google Cloud: se aplica al tráfico enviado a ambos destinos de direcciones IP internas y a destinos de direcciones IP externas. Este límite se calcula mediante telemetría interna y es poco probable que restrinja el ancho de banda interregional para la mayoría de los proyectos. Comunícate con el equipo de ventas si tienes preguntas sobre cómo alcanzar el ancho de banda necesario entre regiones.

Ancho de banda de entrada

Google Cloud controla el tráfico entrante de una VM de forma diferente en función de si el destino del paquete es una dirección IP interna o una externa.

Entrada a destinos de direcciones IP internas

Google Cloud no implementa ninguna restricción con un propósito en el tráfico entrante a una dirección IP interna asociada. Una VM puede recibir todo el tráfico interno que su tipo de máquina, su sistema operativo y otras condiciones y recursos de red permitan. Se considera una dirección IP interna asociada a las siguientes:

  • La dirección IP interna principal de la interfaz de red de una VM
  • Un alias de dirección IP de un rango de alias de IP que se asignó a la interfaz de red de una VM
  • La dirección IP de una regla de reenvío interna que se usa para el reenvío de protocolos internos
  • La dirección IP de una regla de reenvío de un balanceador de cargas de TCP/UDP interno

Entrada a destinos de direcciones IP externas

Google Cloud limita el tráfico entrante enviado a la dirección IP externa asociada de una VM a cualquiera de las siguientes tasas que se alcance primero:

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

Para los fines de este límite, se considera una dirección IP externa asociada a lo siguiente:

  • Una dirección IP externa asignada a la interfaz de red de una VM
  • La dirección IP de una regla de reenvío externa usada para el reenvío de protocolos externos
  • La dirección IP de la regla de reenvío del balanceador de cargas de TCP/UDP de una red
  • Las respuestas entrantes establecidas que procesa Cloud NAT

Para las dos últimas definiciones de una dirección IP externa asociada: si se comparte una dirección IP externa entre varias VM, Google Cloud limita el tráfico entrante de forma individual por cada VM de backend.

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 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 seleccionada.
  • Cola de transmisión (TX): Cola para transmitir paquetes. Cuando el SO invitado envía un paquete, se asigna un descriptor y se coloca en la cola de transmisión. 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:

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

    • VirtIO: Divide la cantidad de CPU virtuales por la cantidad de NIC y descarta el resto: [number of vCPUs/number of NICs].
    • GVNIC: Divide la cantidad de CPU virtuales por la cantidad de NIC 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 NIC 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 NIC es 32. Si el número calculado es mayor que 32, ignóralo y asigna a cada NIC 32 colas en su lugar
    • 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 su lugar.

En los ejemplos siguientes, 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 NIC.

  • Si una VM usa GVNIC y tiene 128 CPU virtuales y dos NIC, el número calculado es [128/2/2] = 32. Google Cloud asigna a cada NIC la cantidad máxima de colas por NIC posible. Google Cloud asigna 16 colas por NIC.

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 es el menor entre el recuento de CPU virtuales o el recuento máximo de colas por NIC, 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 NIC de la VM, la suma de las asignaciones de recuento de colas debe ser menor o igual que la cantidad de CPU virtuales asignada a la instancia de VM.

A modo de ejemplo:

  • Si una VM tiene 8 CPU virtuales y 3 NIC, el recuento máximo de colas para la VM es la cantidad de CPU 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 NIC sigue sujeta a las reglas anteriores. 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.

API

Crea una VM con recuentos de colas específicos para NIC mediante el método instances.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
{
  "name": "VM_NAME",
  "machineType": "machineTypes/MACHINE_TYPE"
  "networkInterfaces": [
      {
        "network": string,
        "subnetwork": string,
        "networkIP": string,
        "name": string,
        "queueCount": "QUEUE_SIZE",
        ....
      ],
      } ],
 }
 

Reemplaza lo siguiente:

  • PROJECT_ID: ID del proyecto en el que se creará la VM
  • ZONE: Zona en la que se creará la VM
  • MACHINE_TYPE: es el tipo de máquina, predefinido o personalizado, de la VM nueva
  • VM_NAME: Nombre de la VM nueva
  • QUEUE_SIZE: cantidad de colas para la NIC, sujeta a las reglas que se analizan en esta sección.

Asignaciones de cola y cambio del tipo de máquina

Si detienes una instancia de VM y cambias su tipo de máquina, y el tipo nuevo tiene una cantidad diferente de CPU virtuales, Google Cloud no altera las asignaciones de colas por NIC. Las asignaciones de colas de NIC predeterminadas o personalizadas solo se establecen cuando creas una VM.

¿Qué sigue?