Consideraciones de rendimiento

En esta página, se proporcionan instrucciones para configurar tu entorno de Google Cloud Managed Lustre para obtener el mejor rendimiento.

Para ver los números de rendimiento específicos de cada nivel de rendimiento, consulta Niveles de rendimiento.

Rendimiento después de aumentar la capacidad

Si aumentas la capacidad de almacenamiento de una instancia existente, también aumentarán su capacidad de procesamiento y sus IOPS máximas, y es posible que mejore el rendimiento de sus metadatos.

El rendimiento de la capacidad de procesamiento de lectura mejora de forma gradual a medida que se escriben y redistribuyen datos nuevos en el almacenamiento adicional. El rendimiento de la capacidad de procesamiento de escritura aumenta de inmediato.

Uso de alta capacidad

Una vez que el uso de la capacidad de almacenamiento de una instancia alcanza el 90%, es posible que se reduzca el rendimiento de la instancia. Considera aumentar la capacidad de tu instancia de Managed Lustre. Es posible que debas solicitar una cuota adicional antes de la expansión.

Si ves errores de No space left on device, pero tu instancia muestra la capacidad restante, consulta Errores de No space left on device.

Unidad de transmisión máxima (MTU) de la red de VPC

Cuando creas tu red de VPC, si configuras el valor de mtu (unidad de transmisión máxima o el tamaño del paquete IP más grande que se puede transmitir en esta red) en el valor máximo permitido de 8896, se mejora el rendimiento hasta en un 10% en comparación con el valor predeterminado de 1460 bytes.

Puedes ver el valor de MTU actual de tu red con el siguiente comando:

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

El valor de MTU de una red se puede actualizar después de que se crea la red, pero hay consideraciones importantes. Consulta Cambia la MTU de una red para obtener más detalles.

Tipos de máquina de Compute Engine

La capacidad de procesamiento de la red puede verse afectada por el tipo de máquina que elijas. En general, para obtener la mejor capacidad de procesamiento, haz lo siguiente:

  • Aumentar el número de CPU virtuales Por lo general, el ancho de banda de salida por instancia es de 2 Gbps por CPU virtual, hasta el máximo del tipo de máquina.
  • Selecciona una serie de máquinas que admita límites de entrada y salida más altos. Por ejemplo, las instancias C2 con redes Tier_1 admiten hasta 100 Gbps de ancho de banda de salida. Las instancias C3 con redes Tier_1 admiten hasta 200 Gbps.
  • Habilita el rendimiento de redes Tier_1 de VM con tipos de máquinas más grandes.
  • Usa la NIC virtual (gVNIC) de Google. gVNIC es la única opción para los tipos de máquinas de generación 3 y posteriores. gVNIC es obligatorio cuando se usan redes Tier_1.

Para obtener información detallada, consulta Ancho de banda de red.

Configuración de varias NIC

Con la capacidad integrada de varias rutas de Lustre, los clientes pueden segmentar el tráfico de red en varias tarjetas de interfaz de red (varias NIC). Esto agrega ancho de banda para saturar instancias de Managed Lustre de alta capacidad.

Para configurar varias NIC, debes hacer lo siguiente:

  • Selecciona un tipo de máquina con varias NIC físicas.
  • Crea una subred para cada NIC y asigna cada NIC a su subred.
  • Sigue los pasos de varias NIC cuando te conectes desde Compute Engine o GKE.

Verifica el balanceo de tráfico

Una vez que hayas configurado varias NIC, verifica que los datos se balanceen correctamente.

Compute Engine

Para verificar el balanceo de datos directamente en la VM, supervisa las interfaces de red configuradas (por ejemplo, eth0 y eth1) con nload mientras generas tráfico al backend de Managed Lustre:

nload -m eth0 eth1

En una configuración de varias NIC correcta, las tasas de bits salientes deben ser aproximadamente equivalentes en todas las interfaces configuradas.

GKE

Para confirmar que el tráfico de red de tu carga de trabajo esté balanceado en varias NIC, implementa un Pod de depurador de red temporal en el nodo en el que está programada tu carga de trabajo:

  1. Identifica el nodo en el que está programada tu carga de trabajo:

    kubectl get pod POD_NAME -o wide

    Reemplaza POD_NAME por el nombre del Pod. En el resultado del comando, anota el nombre en la columna NODE.

  2. Inicia el depurador de red en ese nodo:

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    Reemplaza NODE_NAME por el nombre del nodo del paso anterior.

  3. En el resultado, analiza las tasas de bits de la columna Outgoing para eth0 y eth1. Si la configuración es correcta, las tasas de bits son aproximadamente equivalentes. El resultado es similar a lo siguiente:

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. Para salir del depurador, presiona Ctrl+C.

Soluciona cuellos de botella comunes

Si el rendimiento de tu carga de trabajo es mucho más bajo de lo esperado para tu nivel de rendimiento de Managed Lustre, verifica los siguientes problemas comunes:

  • Cantidad insuficiente de máquinas cliente: Una sola máquina cliente se ve limitada por su propia CPU virtual (vCPU) y los límites de procesamiento de red de un solo vínculo. Para saturar los niveles de alta capacidad de procesamiento, debes distribuir la carga. Por ejemplo, para saturar un sistema de archivos de Managed Lustre de 100,000 MBps, por lo general, necesitas al menos 60 máquinas cliente estándar (o 12 máquinas cliente configuradas para usar redes de alta capacidad de procesamiento de nivel 1) que escriban en paralelo. Para el tamaño máximo de instancia de cualquier nivel de rendimiento, es posible que necesites más de 2,500 máquinas cliente configuradas para usar redes de alta capacidad de procesamiento de nivel 1.

  • MTU de nube privada virtual (VPC) no ideal: De forma predeterminada, las redes de VPC usan una MTU de 1460 (tramas Ethernet estándar). Para el almacenamiento de alto rendimiento, como Managed Lustre, debes configurar tramas jumbo con una MTU de 8896. Si se ejecuta con una MTU 1460 estándar, la CPU se ve obligada a procesar más del doble de la cantidad de paquetes de red, lo que agrega sobrecarga de CPU y limita el ancho de banda máximo.

  • Falta la configuración del ancho de banda de red de nivel 1: Muchos tipos de máquinas de alto rendimiento requieren que habilites de forma explícita el ancho de banda de red de nivel 1.

    • En Compute Engine y los grupos de nodos estándar de GKE, usa la marca --network-performance-configs=total-egress-bandwidth-tier=TIER_1 durante la creación. Sin esta marca, una VM o un nodo pueden estar limitados a un límite de salida predeterminado más bajo.
    • En GKE Autopilot, no especificas esta marca directamente. En su lugar, selecciona una serie de máquinas que admita un ancho de banda más alto (como c3) con selectores de nodos en las especificaciones de tu Pod.

    Para obtener más información, consulta Tipos de máquinas de Compute Engine.

  • Uso desequilibrado del destino de almacenamiento de objetos (OST) de Lustre: Managed Lustre divide los datos de archivos en varios destinos de almacenamiento de objetos (OSTs). Si tu prueba o carga de trabajo escribe en un solo archivo sin segmentar, o si las tareas del cliente escriben patrones que sobrecargan un solo OST, ese OST se convierte en un cuello de botella mientras el resto del sistema de archivos permanece inactivo. Para evitar esto, asegúrate de balancear la carga útil de escritura de manera uniforme en todos los OST disponibles (por ejemplo, usando el modo de archivo por proceso en las comparativas).

  • Contención del ancho de banda de red compartido: El ancho de banda de salida en las máquinas cliente (VMs de Compute Engine o nodos de GKE) se comparte en todas las operaciones de red de la máquina. Si tus máquinas cliente o Pods descargan paquetes grandes de forma simultánea, ejecutan barridos de registro pesados o se comunican en gran medida con otros nodos del clúster, el rendimiento del almacenamiento se limitará al ancho de banda de red restante.