Almacenamiento - Amazon EKS
Administración y almacenamiento de datos

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Almacenamiento

Administración y almacenamiento de datos

Implemente modelos de IA en los pods mediante un controlador CSI

Las cargas de trabajo de inteligencia artificial y aprendizaje automático suelen requerir el acceso a artefactos de modelos de gran tamaño (por ejemplo, pesos entrenados o configuraciones), y los pods necesitan una forma confiable y escalable de acceder a ellos sin necesidad de incorporarlos en imágenes de contenedores, lo que puede aumentar el tamaño de las imágenes y los tiempos de extracción del registro de contenedores. Para reducir la sobrecarga operativa que supone gestionar los montajes de volúmenes, recomendamos implementar modelos de IA en los pods montando los servicios de almacenamiento de Amazon (p. ej., S3, FSx para Lustre, EFS) como volúmenes persistentes (PVs) utilizando sus respectivos controladores CSI. Para obtener información detallada sobre la implementación, consulte los temas siguientes de esta sección.

Optimice el almacenamiento de las cachés de modelos ML en EKS

Aprovechar una solución de almacenamiento óptima es fundamental para minimizar la latencia de inicio de los módulos y las aplicaciones, reducir el uso de memoria, obtener los niveles de rendimiento deseados para acelerar las cargas de trabajo y garantizar la escalabilidad de las cargas de trabajo de aprendizaje automático. Las cargas de trabajo de aprendizaje automático suelen basarse en archivos modelo (pesos), que pueden ser de gran tamaño y requieren un acceso compartido a los datos entre los módulos o nodos. La selección de la solución de almacenamiento óptima depende de las características de la carga de trabajo, como la eficiencia de un solo nodo, el acceso a varios nodos, los requisitos de latencia, las restricciones de costes y también los requisitos de integración de datos (por ejemplo, con un repositorio de datos de Amazon S3). Recomendamos comparar diferentes soluciones de almacenamiento con sus cargas de trabajo para saber cuál cumple con sus requisitos, y le ofrecemos las siguientes opciones para ayudarlo a realizar una evaluación en función de sus requisitos de carga de trabajo.

El controlador CSI de EKS es compatible con los siguientes servicios de almacenamiento de AWS, cada uno con su propio controlador de CSI y tiene sus propias ventajas para los flujos de trabajo de IA y aprendizaje automático:

La elección del servicio de almacenamiento de AWS depende de la arquitectura de implementación, la escala, los requisitos de rendimiento y la estrategia de costes. Los controladores CSI de almacenamiento deben estar instalados en el clúster de EKS, lo que permite al controlador CSI crear y gestionar volúmenes persistentes (PV) fuera del ciclo de vida de un pod. Con el controlador CSI, puede crear definiciones de PV de los servicios de almacenamiento de AWS compatibles como recursos de clúster de EKS. Luego, los pods pueden acceder a estos volúmenes de almacenamiento para sus volúmenes de datos mediante la creación de una notificación de volumen persistente (PVC) para el PV. Según el servicio de almacenamiento de AWS y el escenario de implementación, se puede conectar un único PVC (y el PV asociado) a varios pods para una carga de trabajo. Por ejemplo, para el entrenamiento de aprendizaje automático, los datos de entrenamiento compartidos se almacenan en un PV y varios pods acceden a ellos; para realizar inferencias en línea en tiempo real, los modelos LLM se almacenan en caché en un PV y se accede a ellos desde varios pods. A continuación, se proporcionan ejemplos de archivos YAML de PVC y PVC para los servicios de almacenamiento de AWS para ayudarle a empezar.

Escenario: carga de trabajo de varias instancias de GPU

Amazon FSx for Lustre: en situaciones en las que tiene un entorno de instancias de procesamiento de varias EC2 GPU con cargas de trabajo dinámicas sensibles a la latencia y con un alto rendimiento de ancho de banda, como la formación distribuida y el servicio de modelos, y necesita una integración nativa del repositorio de datos de Amazon S3, le recomendamos Amazon for Lustre. FSx FSx for Lustre proporciona un sistema de archivos paralelo de alto rendimiento totalmente gestionado que está diseñado para cargas de trabajo con uso intensivo de cómputo, como la computación de alto rendimiento (HPC) y Machine Learning.

Puede instalar el controlador CSI de FSx for Lustre para montar FSx los sistemas de archivos en EKS como un volumen persistente (PV) y, a continuación, implementarlo FSx para el sistema de archivos Lustre como una caché de alto rendimiento independiente o como un sistema de archivos vinculado a S3 para que actúe como una caché de alto rendimiento para los datos de S3, lo que proporciona un rápido I/O y alto rendimiento para el acceso a los datos en todas las instancias de cómputo de la GPU. FSx for Lustre se puede implementar con las opciones de almacenamiento Scratch-SSD o Persistent-SSD:

  • Almacenamiento Scratch-SSD: se recomienda para cargas de trabajo efímeras o de corta duración (horas), con una capacidad de rendimiento fija por TIB aprovisionado.

  • Almacenamiento SSD persistente: recomendado para cargas de trabajo críticas y de larga duración que requieren el mayor nivel de disponibilidad, por ejemplo, simulaciones de HPC, análisis de macrodatos o formación en Machine Learning. Con el almacenamiento SSD persistente, puede configurar tanto la capacidad de almacenamiento como la capacidad de rendimiento (por TIB) que se requieren.

Consideraciones de rendimiento:

  • Módulo administrativo FSx para gestionar el sistema de archivos Lustre: configure un módulo «administrativo» que tenga el cliente lustre instalado y el sistema de FSx archivos montado. Esto habilitará un punto de acceso para ajustar el sistema de FSx archivos y también en situaciones en las que necesite precalentar el sistema de FSx archivos con sus datos de entrenamiento de aprendizaje automático o modelos LLM antes de iniciar las instancias de cómputo de la GPU. Esto es especialmente importante si su arquitectura utiliza instancias de GPU/Compute de EC2 Amazon basadas en Spot, donde puede utilizar el pod administrativo para «calentar» o «precargar» los datos deseados en FSx el sistema de archivos, de modo que estén listos para procesarse cuando ejecute sus instancias de Amazon basadas en Spot. EC2

  • Elastic Fabric Adapter (EFA): los tipos de implementación de almacenamiento SSD persistente admiten el Elastic Fabric Adapter (EFA), donde el uso del EFA es ideal para cargas de trabajo basadas en GPU de alto rendimiento y rendimiento. Tenga en cuenta que, FSx para Lustre, es compatible con el GPUDirect almacenamiento NVIDIA (GDS), donde el GDS es una tecnología que crea una ruta de datos directa entre el almacenamiento local o remoto y la memoria de la GPU, para permitir un acceso más rápido a los datos.

  • Compresión: habilite la compresión de datos en el sistema de archivos si tiene tipos de archivos que se puedan comprimir. Esto puede ayudar a aumentar el rendimiento, ya que la compresión de datos reduce la cantidad de datos que se transfieren entre FSx los servidores de archivos Lustre y el almacenamiento.

  • Configuración de división del sistema de archivos Lustre:

    • División de datos: permite FSx a Luster distribuir los datos de un archivo en varios destinos de almacenamiento de objetos (OSTs) dentro de un sistema de archivos Lustre, lo que maximiza el acceso paralelo y el rendimiento, especialmente para trabajos de formación de aprendizaje automático a gran escala.

    • Sistema de archivos independiente: de forma predeterminada, se crea automáticamente una configuración de división de Lustre de 4 componentes mediante la función de diseño progresivo de archivos (PFL) de for Lustre. FSx En la mayoría de los casos, no es necesario actualizar el número o tamaño predeterminados de las franjas de PFL Lustre. Si necesita ajustar la división de datos de Lustre, puede ajustarla manualmente consultando los parámetros de división de un sistema de archivos de Lustre. FSx

    • Sistema de archivos vinculado a S3: los archivos importados al sistema de FSx archivos mediante la integración nativa de Amazon S3 (Data Repository Association o DRA) no utilizan el diseño de PFL predeterminado, sino que utilizan el diseño del parámetro del sistema de archivos. ImportedFileChunkSize Los archivos importados en S3 con un tamaño superior al 1 se ImportedFileChunkSize almacenarán en varios archivos OSTs con un recuento de franjas basado en el valor ImportedFileChunkSize definido (por defecto, 1 GiB). Si tiene archivos de gran tamaño, le recomendamos ajustar este parámetro a un valor superior.

    • Ubicación: Implemente un sistema de archivos FSx for Lustre en la misma zona de disponibilidad que sus nodos de procesamiento o GPU para permitir el acceso a los datos con la latencia más baja y evitar los patrones de acceso entre zonas de disponibilidad. Si tiene varios nodos de GPU ubicados en distintas zonas de disponibilidad, le recomendamos implementar un sistema de FSx archivos en cada zona de disponibilidad para acceder a los datos con baja latencia.

Ejemplo

Definición de volumen persistente (PV) para un sistema de archivos FSx para Lustre, mediante aprovisionamiento estático (cuando la FSx instancia ya se ha aprovisionado).

apiVersion: v1
kind: PersistentVolume
metadata:
  name: fsx-pv
spec:
  capacity:
    storage: 1200Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  mountOptions:
    - flock
  persistentVolumeReclaimPolicy: Recycle
  csi:
    driver: fsx.csi.aws.com
    volumeHandle: [FileSystemId of FSx instance]
    volumeAttributes:
      dnsname: [DNSName of FSx instance]
      mountname: [MountName of FSx instance]

Ejemplo

Definición de reclamación de volumen persistente para PV denominada: fsx-pv

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fsx-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1200Gi
  volumeName: fsx-pv

Ejemplo

Configure un pod para que utilice una declaración de volumen persistente defsx-claim:

apiVersion: v1
kind: Pod
metadata:
  name: fsx-app
spec:
  containers:
  - name: app
    image: amazonlinux:2023
    command: ["/bin/sh"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: fsx-claim

Para ver ejemplos completos, consulte los ejemplos FSx de controladores Lustre en GitHub.

Escenario: carga de trabajo de una sola instancia de GPU

Mountpoint para Amazon S3 con controlador CSI: puede montar un bucket S3 como volumen en sus pods mediante el controlador CSI de Mountpoint para Amazon S3. Este método permite un control de acceso detallado sobre qué pods pueden acceder a buckets S3 específicos. Cada pod tiene su propia instancia de punto de montaje y caché local (de 5 a 10 GB), lo que aísla el rendimiento de carga y lectura de modelos entre los pods. Esta configuración admite la autenticación a nivel de pod con funciones de IAM para cuentas de servicio (IRSA) y el control de versiones de modelos independientes para diferentes modelos o clientes. La contrapartida es el aumento del uso de la memoria y del tráfico de la API, ya que cada módulo emite llamadas a la API de S3 y mantiene su propia caché.

Ejemplo parcial de implementación de un pod (YAML) con un controlador CSI:

# CSI driver dynamically mounts the S3 bucket for each pod

volumes:
  - name: s3-mount
    csi:
      driver: s3.csi.aws.com
      volumeAttributes:
        bucketName: your-s3-bucket-name
        mountOptions: "--allow-delete"  # Optional
        region: us-west-2

containers:
  - name: inference
    image: your-inference-image
    volumeMounts:
      - mountPath: /models
        name: s3-mount
volumeMounts:
  - name: model-cache
    mountPath: /models
volumes:
  - name: model-cache
    hostPath:
      path: /mnt/s3-model-cache

Consideraciones de rendimiento:

  • Almacenamiento en caché de datos: Mountpoint para S3 puede almacenar contenido en caché para reducir los costos y mejorar el rendimiento en caso de lecturas repetidas del mismo archivo. Consulte la configuración del almacenamiento en caché para conocer las opciones y los parámetros de almacenamiento en caché.

  • Tamaño parcial del objeto: al almacenar archivos de más de 72 GB y acceder a ellos, consulte Configuración del rendimiento de Mountpoint para saber cómo configurar los parámetros de la --write-part-size línea de comandos --read-part-size y de forma que se ajusten a sus requisitos de perfil de datos y carga de trabajo.

  • La caché compartida está diseñada para objetos de hasta 1 MB de tamaño. No admite objetos grandes. Utilice la opción de caché local para almacenar objetos en caché NVMe o volúmenes de EBS en el nodo EKS.

  • Cargos por solicitud de API: al realizar un gran número de operaciones de archivos con el Mountpoint para S3, los cargos por solicitud de API pueden convertirse en una parte de los costos de almacenamiento. Para mitigar esta situación, si no se requiere una coherencia sólida, habilite siempre el almacenamiento en caché de los metadatos y establezca un metadata-ttl período para reducir el número de operaciones de la API a S3.

Para obtener más información, consulte el controlador CSI de Mountpoint for Amazon S3 en la documentación oficial de Amazon EKS. Recomendamos monitorizar las métricas de rendimiento de Amazon S3 con las CloudWatch métricas de Amazon en caso de que se produzcan cuellos de botella y ajustar la configuración cuando sea necesario.

Amazon EFS para cachés de modelos compartidos

En los escenarios en los que tiene un entorno de instancias de procesamiento de varias EC2 GPU y cargas de trabajo dinámicas que requieren acceso a modelos compartidos en varios nodos y zonas de disponibilidad (por ejemplo, inferencia en línea en tiempo real con Karpenter) con necesidades moderadas de rendimiento y escalabilidad, le recomendamos utilizar un sistema de archivos Amazon Elastic File System (EFS) como volumen persistente a través del controlador CSI de EFS. Amazon EFS es un sistema de archivos NFS basado en la nube escalable, de alta disponibilidad y totalmente gestionado que permite que EC2 las instancias y los contenedores cuenten con almacenamiento de archivos compartido, con un rendimiento uniforme y en los que no es necesario aprovisionar el almacenamiento por adelantado. Utilice EFS como volumen modelo y monte el volumen como un sistema de archivos compartido mediante la definición de un volumen persistente en el clúster EKS. Cada notificación de volumen persistente (PVC) respaldada por un sistema de archivos EFS se crea como un punto de acceso de EFS al sistema de archivos EFS. EFS permite que varios nodos y pods accedan a los mismos archivos de modelo, lo que elimina la necesidad de sincronizar los datos con el sistema de archivos de cada nodo. Instale el controlador CSI de EFS para integrar EFS con EKS.

Puede implementar un sistema de archivos Amazon EFS con los siguientes modos de rendimiento:

  • Rendimiento en ráfaga: escala el rendimiento en función del tamaño del sistema de archivos, lo que resulta adecuado para cargas de trabajo variables con ráfagas ocasionales.

  • Rendimiento aprovisionado: rendimiento dedicado, ideal para trabajos de formación en aprendizaje automático consistentes con necesidades de rendimiento predecibles dentro de unos límites.

  • Rendimiento elástico (recomendado para el aprendizaje automático): se escala automáticamente en función de la carga de trabajo y es rentable para diferentes cargas de trabajo de aprendizaje automático.

Para ver las especificaciones de rendimiento, consulte las especificaciones de rendimiento de Amazon EFS.

Consideraciones sobre el rendimiento:

  • Usa Elastic Throughput para diferentes cargas de trabajo.

  • Utilice la clase de almacenamiento estándar para las cargas de trabajo de aprendizaje automático activas.

Para ver ejemplos completos del uso del sistema de archivos Amazon EFS como volumen persistente en el clúster y los pods de EKS, consulte los ejemplos de controladores CSI de EFS en GitHub.

Supervisión del rendimiento Un rendimiento deficiente del disco puede retrasar las lecturas de las imágenes del contenedor, aumentar la latencia de inicio del pod y reducir el rendimiento de las inferencias o el entrenamiento. Recomendamos los siguientes métodos para monitorear las métricas de rendimiento del servicio de almacenamiento de AWS correspondiente en caso de que se produzcan cuellos de botella y ajustar la configuración cuando sea necesario.