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, FSx para OpenZFS, 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:

• Mountpoint para Amazon S3

• Amazon FSx para Lustre

• Amazon FSx para OpenZFS

• Amazon EFS

• Amazon EBS

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.

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. Utilice Amazon CloudWatch para supervisar las métricas de rendimiento de sus servicios de almacenamiento de AWS. Cuando identifique los cuellos de botella en el rendimiento, modifique los parámetros de configuración del almacenamiento para optimizarlo.

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 sobre el 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 entre 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. Supervisa las métricas FSx de rendimiento de Amazon Lustre con Amazon CloudWatch. Cuando se identifiquen cuellos de botella en el rendimiento, ajuste los parámetros de configuración según sea necesario.

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: cuando almacene archivos de más de 72 GB y acceda 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.

Almacenamiento compartido persistente de Amazon FSx para OpenZFS

Para escenarios que implican varias instancias de procesamiento de EC2 GPU con cargas de trabajo sensibles a la latencia que requieren alta disponibilidad, alto rendimiento, sensibilidad a los costes e implementaciones de varios pods para diferentes aplicaciones, recomendamos Amazon para OpenZFS. FSx Algunos ejemplos de cargas de trabajo incluyen la inferencia en tiempo real, el aprendizaje por refuerzo y el entrenamiento de redes generativas antagónicas. FSx para OpenZFS es particularmente beneficioso para las cargas de trabajo que necesitan un acceso de alto rendimiento a una estructura de directorios específica con archivos pequeños que utilizan patrones de acceso a datos de E/S pequeños. Además, OpenZFS proporciona la flexibilidad necesaria FSx para escalar el rendimiento de forma independiente de la capacidad de almacenamiento, lo que le ayuda a lograr una rentabilidad óptima al adaptar el tamaño del almacenamiento a las necesidades reales y, al mismo tiempo, mantener los niveles de rendimiento requeridos

El controlador CSI nativo FSx de OpenZFS permite la creación de varios sistemas de archivos o uno solo PVCs mediante la creación de varios volúmenes. Esto reduce la sobrecarga de administración y maximiza la utilización del rendimiento y las IOPS del sistema de archivos mediante la implementación consolidada de los módulos de aplicaciones en un solo sistema de archivos. Además, incluye funciones empresariales, como las instantáneas sin copias, los clones sin copias y las cuotas de usuarios y grupos, que se pueden aprovisionar de forma dinámica mediante el controlador CSI.

FSx para OpenZFS, admite tres tipos de implementación diferentes en el momento de su creación:

• Single-AZ: la opción más económica con latencias inferiores a un milisegundo, pero no proporciona alta disponibilidad a nivel del sistema de archivos o de la zona de disponibilidad. Se recomienda para cargas de trabajo de desarrollo y prueba o para aquellas que tienen una alta disponibilidad en la capa de aplicación.

• Single-AZ (HA): proporciona alta disponibilidad a nivel de sistema de archivos con latencias inferiores a un milisegundo. Se recomienda para cargas de trabajo de alto rendimiento que requieren alta disponibilidad.

• Multi-AZ: proporciona alta disponibilidad a nivel de sistema de archivos y en todas las zonas de disponibilidad. Se recomienda para cargas de trabajo de alto rendimiento que requieren disponibilidad adicional en todas las zonas de disponibilidad.

Consideraciones sobre el rendimiento:

• Tipo de implementación: si la disponibilidad adicional en todas las zonas de disponibilidad no es un requisito, considere usar el tipo de implementación Single-AZ (HA). Este tipo de implementación proporciona hasta el 100% del rendimiento de las escrituras, mantiene latencias inferiores a un milisegundo y los sistemas de archivos Gen2 tienen una NVMe memoria caché adicional para almacenar hasta terabytes de datos a los que se accede con frecuencia. Los sistemas de archivos Multi-AZ proporcionan hasta un 75% del rendimiento de las escrituras con una latencia mayor para adaptarse al tráfico entre zonas de disponibilidad.

• Rendimiento e IOPS: tanto el rendimiento como las IOPS configuradas para el sistema de archivos se pueden ampliar o reducir después de la implementación. Puede aprovisionar hasta un 10% del acceso a los datos en cachéGB/s of disk throughput providing up to 21GB/s. Las IOPS se pueden escalar hasta 400 000 desde el disco y la memoria caché puede proporcionar más de 1 millón de IOPS. Tenga en cuenta que la ampliación del rendimiento de un sistema de archivos Single-AZ provoca una breve interrupción del sistema de archivos, ya que no existe una alta disponibilidad. El escalado del rendimiento de un sistema de archivos Single-AZ (HA) o Multi-AZ se puede realizar de forma no disruptiva. Las IOPS del SSD se pueden escalar una vez cada seis horas.

• Clase de almacenamiento: FSx para OpenZFS, admite tanto la clase de almacenamiento SSD como la clase de almacenamiento Intelligent-Tiering. Para AI/ML las cargas de trabajo, se recomienda utilizar la clase de almacenamiento SSD, que proporciona un rendimiento uniforme a la carga de trabajo y mantiene las CPU/GPU lo más ocupadas posible.

• Compresión: habilite el algoritmo LZ4 de compresión si tiene una carga de trabajo que se pueda comprimir. Esto reduce la cantidad de datos que cada archivo consume en la memoria caché, lo que permite almacenar más datos directamente desde la memoria caché, ya que el rendimiento de la red y las IOPS reducen la carga en el disco SSD.

• Tamaño del registro: la mayoría de las AI/ML cargas de trabajo se beneficiarán de mantener el tamaño de registro predeterminado de 128 KB. Este valor solo debe reducirse si el conjunto de datos consta de archivos grandes (de más de 10 GiB) con acceso constante a bloques pequeños por debajo de los 128 KB desde la aplicación.

Una vez creado el sistema de archivos, el servicio crea automáticamente un volumen raíz asociado. Se recomienda almacenar los datos dentro de los volúmenes secundarios del volumen raíz del sistema de archivos. Con el FSx controlador CSI de OpenZFS, se crea una notificación de volumen persistente asociada para crear de forma dinámica el volumen secundario.

Ejemplos:

Definición de clase de almacenamiento (SC) FSx para un volumen de OpenZFS, que se utiliza para crear un volumen secundario del volumen raíz ($ROOT_VOL_ID) en un sistema de archivos existente y exportar el volumen al CIDR de VPC ($VPC_CIDR) mediante el protocolo NFS v4.2.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fsxz-vol-sc
provisioner: fsx.openzfs.csi.aws.com
parameters:
  ResourceType: "volume"
  ParentVolumeId: '"$ROOT_VOL_ID"'
  CopyTagsToSnapshots: 'false'
  DataCompressionType: '"LZ4"'
  NfsExports: '[{"ClientConfigurations": [{"Clients": "$VPC_CIDR", "Options": ["rw","crossmnt","no_root_squash"]}]}]'
  ReadOnly: 'false'
  RecordSizeKiB: '128'
  Tags: '[{"Key": "Name", "Value": "AI-ML"}]'
  OptionsOnDeletion: '["DELETE_CHILD_VOLUMES_AND_SNAPSHOTS"]'
reclaimPolicy: Delete
allowVolumeExpansion: false
mountOptions:
  - nfsvers=4.2
  - rsize=1048576
  - wsize=1048576
  - timeo=600
  - nconnect=16
  - async

Una reclamación de fsxz-vol-sc volumen persistente (PVC) creada de forma dinámica en función de la anterior. Tenga en cuenta que la capacidad de almacenamiento asignada es de 1 GB, algo obligatorio FSx para los volúmenes de OpenZFS, tal y como se indica en las preguntas frecuentes sobre los controladores CSI. El volumen dispondrá de toda la capacidad aprovisionada al sistema de archivos con esta configuración. Si es necesario restringir la capacidad del volumen, puede hacerlo mediante cuotas de usuarios o grupos.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-vol-pvc
  namespace: example
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: fsxz-vol-sc
  resources:
    requests:
      storage: 1Gi

Configure un pod para montar un volumen mediante la declaración de volumen persistente (PVC) de dynamic-vol-pvc:

kind: Pod
apiVersion: v1
metadata:
  name: fsx-app
  namespace: example
spec:
  volumes:
    - name: dynamic-vol-pv
      persistentVolumeClaim:
        claimName: dynamic-vol-pvc
  containers:
    - name: app
      image: amazonlinux:2023
      command: ["/bin/sh"]
      volumeMounts:
        - mountPath: "/mnt/fsxz"
          name: dynamic-vol-pv

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. Supervise las métricas de rendimiento de Amazon EFS con Amazon CloudWatch. Cuando se identifiquen cuellos de botella en el rendimiento, ajuste los parámetros de configuración según sea necesario.

Utilice S3 Express One Zone para flujos de trabajo orientados a objetos y sensibles a la latencia

Para AI/ML las cargas de trabajo sensibles a la latencia en Amazon EKS, como el entrenamiento de modelos a gran escala, la inferencia o el análisis de alto rendimiento, recomendamos usar S3 Express One Zone para almacenar y recuperar modelos de alto rendimiento. S3 Express One Zone ofrece un espacio de nombres jerárquico, similar a un sistema de archivos, en el que basta con subirlos a un depósito de directorios, lo que permite «guardar todo» y, al mismo tiempo, mantener una alta velocidad. Esto resulta especialmente útil si está acostumbrado a los flujos de trabajo orientados a objetos. Como alternativa, si está más acostumbrado a los sistemas de archivos (por ejemplo, compatibles con POSIX), puede preferir Amazon FSx for Lustre u OpenZFS. Amazon S3 Express One Zone almacena los datos en una única zona de disponibilidad (AZ) mediante buckets de directorio y ofrece una latencia más baja que los buckets S3 estándar, que distribuyen los datos entre varias. AZs Para obtener los mejores resultados, asegúrese de ubicar su equipo de EKS en la misma zona de disponibilidad que su depósito de Express One Zone. Para obtener más información sobre las diferencias de S3 Express One Zone, consulte Diferencias entre los depósitos de directorio.

Para acceder a S3 Express One Zone con la semántica del sistema de archivos, recomendamos utilizar el controlador CSI Mountpoint S3, que monta los depósitos de S3 (incluido Express One Zone) como un sistema de archivos local. Esto traduce las operaciones de archivos (por ejemplo, abrir, leer o escribir) en llamadas a la API de S3, lo que proporciona un acceso de alto rendimiento optimizado para cargas de trabajo de lectura intensivas desde varios clientes y escrituras secuenciales en nuevos objetos. Para obtener más información sobre las operaciones y limitaciones admitidas (p. ej., no cumplen totalmente con POSIX, pero Express One Zone admite la incorporación y el cambio de nombre), consulte la documentación de semántica de Mountpoint.

Ventajas de rendimiento

• Proporciona un acceso a los datos hasta 10 veces más rápido que el estándar S3, con una latencia uniforme de milisegundos de un solo dígito y una reducción de los costes de solicitud de hasta un 80%.

• Se amplía para gestionar de cientos de miles a millones de solicitudes por segundo por segmento de directorio, lo que evita las limitaciones o las interrupciones que se producen en el S3 estándar durante las cargas extremas (por ejemplo, en clústeres con decenas o cientos de miles de redes saturadas). GPUs/CPUs

• Utiliza un mecanismo de autenticación basado en sesiones. Autentíquese una vez para obtener un token de sesión y, a continuación, realice operaciones repetidas a alta velocidad sin sobrecargar la autenticación por solicitud. Esto está optimizado para cargas de trabajo como los puntos de control frecuentes o la carga de datos.

Casos de uso recomendados

• Almacenamiento en caché: uno de los principales casos de uso del controlador CSI Mountpoint S3 con S3 Express One Zone es el almacenamiento en caché. La primera instancia lee los datos de S3 Standard (uso general) y los almacena en caché en Express One Zone, de baja latencia. Las lecturas posteriores realizadas por otros clientes acceden más rápido a los datos almacenados en caché, lo que resulta ideal para situaciones con varios nodos de EKS en las que varios nodos de EKS leen los mismos datos (por ejemplo, conjuntos de datos de entrenamiento compartidos). Esto puede mejorar el rendimiento hasta 7 veces en el caso de los accesos repetidos y reducir los costes informáticos. Para las cargas de trabajo que requieren una conformidad total con POSIX (por ejemplo, bloqueo de archivos y modificaciones in situ), considere Amazon FSx for Lustre u OpenZFS como alternativas.

• AI/ML Capacitación e inferencia a gran escala: ideal para cargas de trabajo con cientos o miles de nodos de cómputo (por ejemplo, GPUs en clústeres de EKS) en los que la limitación del S3 de uso general podría provocar demoras y desperdiciar costosos recursos de cómputo. Por ejemplo, los investigadores de LLM o las organizaciones que utilizan un modelo diario se tests/checkpoints benefician de un acceso rápido y fiable sin interrumpir el S3 regional. Para cargas de trabajo de menor escala (p. ej., decenas de nodos), puede ser suficiente el S3 Standard u otras clases de almacenamiento.

• Canalizaciones de datos: Load/prepare modelos, archivos de datos de entrenamiento o puntos de control de transmisiones. Si su equipo prefiere el almacenamiento de objetos en lugar de los sistemas de archivos tradicionales (por ejemplo, debido a que está familiarizado con S3), utilícelo en lugar de introducir cambios de diseño para opciones compatibles con POSIX, como Lustre. FSx

Consideraciones

• Resiliencia: el diseño con una sola zona de disponibilidad ofrece una durabilidad del 99,19% (igual que el S3 estándar, mediante la redundancia dentro de la zona de disponibilidad), pero una disponibilidad inferior (diseño del 99,95% y SLA del 99,9%) en comparación con las clases con zonas de disponibilidad múltiples (disponibilidad del 99,99%). Es menos resistente a los fallos en las zonas de disponibilidad. Úselo para datos recreables o en caché. Considere la posibilidad de realizar copias de seguridad o replicaciones en zonas de disponibilidad múltiples (Multi-AZ) para cargas

• Soporte de API y funciones: admite un subconjunto de S3 APIs (por ejemplo, sin políticas de ciclo de vida ni replicación); puede requerir cambios menores en la aplicación para la autenticación de la sesión o el manejo de objetos.

• Integración con EKS: coloque su EKS pods/nodes en la misma zona de disponibilidad que el depósito del directorio para minimizar la latencia de la red. Utilice Mountpoint para Amazon S3 o los controladores CSI para el acceso nativo de Kubernetes.

• Pruebas: pruebe la latencia de recuperación en un entorno que no sea de producción para validar las mejoras de rendimiento. Supervisa la presencia de estrangulamientos en escenarios S3 estándar (p. ej., alta saturación de la GPU) y compara.

La clase de almacenamiento S3 Express One Zone está disponible en varias regiones y se integra con EKS para las cargas de trabajo que necesitan acceder a objetos sin tener que esperar a ser almacenadas. Para obtener más información, consulte Cómo empezar a usar S3 Express One Zone.