Stockage - Amazon EKS
Gestion et stockage des données

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Stockage

Gestion et stockage des données

Déployez des modèles d'IA sur des pods à l'aide d'un pilote CSI

Les charges de travail IA/ML nécessitent souvent l'accès à de grands artefacts de modèles (par exemple, poids entraînés, configurations), et les pods ont besoin d'un moyen fiable et évolutif pour y accéder sans les intégrer dans des images de conteneur, ce qui peut augmenter la taille des images et les temps d'extraction du registre des conteneurs. Pour réduire les frais opérationnels liés à la gestion des montages de volumes, nous recommandons de déployer des modèles d'IA sur des pods en installant les services de stockage Amazon (par exemple, S3, FSx pour Lustre, EFS) en tant que volumes persistants (PVs) à l'aide de leurs pilotes CSI respectifs. Pour plus de détails sur la mise en œuvre, consultez les rubriques suivantes de cette section.

Optimisation du stockage pour les caches de modèles ML sur EKS

Il est essentiel de tirer parti d'une solution de stockage optimale pour minimiser la latence de démarrage des pods et des applications, réduire l'utilisation de la mémoire, obtenir les niveaux de performance souhaités pour accélérer les charges de travail et garantir l'évolutivité des charges de travail de machine learning. Les charges de travail ML reposent souvent sur des fichiers modèles (poids), qui peuvent être volumineux et nécessiter un accès partagé aux données entre les pods ou les nœuds. Le choix de la solution de stockage optimale dépend des caractéristiques de votre charge de travail, telles que l'efficacité d'un nœud unique, l'accès à plusieurs nœuds, les exigences de latence, les contraintes de coûts ainsi que les exigences en matière d'intégration des données (comme dans le cas d'un référentiel de données Amazon S3). Nous vous recommandons d'évaluer les différentes solutions de stockage en fonction de vos charges de travail afin de déterminer laquelle répond à vos exigences. Nous vous proposons les options suivantes pour vous aider à évaluer en fonction de vos exigences en matière de charge de travail.

Le pilote EKS CSI prend en charge les services de stockage AWS suivants. Chacun possède son propre pilote CSI et possède ses propres atouts pour les flux de travail d'IA et de ML :

Le choix du service de stockage AWS dépend de votre architecture de déploiement, de votre échelle, de vos exigences en matière de performances et de votre stratégie en matière de coûts. Les pilotes CSI de stockage doivent être installés sur votre cluster EKS, ce qui permet au pilote CSI de créer et de gérer des volumes persistants (PV) en dehors du cycle de vie d'un pod. À l'aide du pilote CSI, vous pouvez créer des définitions PV des services de stockage AWS pris en charge en tant que ressources de cluster EKS. Les pods peuvent ensuite accéder à ces volumes de stockage pour leurs volumes de données en créant une réclamation de volume persistante (PVC) pour le PV. En fonction du service de stockage AWS et de votre scénario de déploiement, un seul PVC (et le PV associé) peut être attaché à plusieurs pods pour une charge de travail. Par exemple, pour la formation ML, les données d'entraînement partagées sont stockées sur un PV et accessibles par plusieurs Pods ; pour une inférence en ligne en temps réel, les modèles LLM sont mis en cache sur un PV et accessibles par plusieurs Pods. Des exemples de fichiers YAML PV et PVC pour les services de stockage AWS sont fournis ci-dessous pour vous aider à démarrer.

Scénario : charge de travail de plusieurs instances GPU

Amazon FSx for Lustre : dans les scénarios où vous disposez d'un environnement d'instances de calcul à plusieurs EC2 GPU avec des charges de travail dynamiques sensibles à la latence et à haut débit de bande passante, tels que la formation distribuée et le service de modèles, et que vous avez besoin d'une intégration native au référentiel de données Amazon S3, nous recommandons Amazon for Lustre. FSx FSx for Lustre fournit un système de fichiers parallèle hautes performances entièrement géré, conçu pour les charges de travail intensives telles que le calcul haute performance (HPC) et le Machine Learning.

Vous pouvez installer le pilote CSI FSx for Lustre pour monter des FSx systèmes de fichiers sur EKS en tant que volume persistant (PV), puis le déployer FSx pour le système de fichiers Lustre en tant que cache haute performance autonome ou en tant que système de fichiers lié au S3 pour faire office de cache haute performance pour les données S3, fournissant ainsi un débit rapide I/O et élevé pour l'accès aux données entre vos instances de calcul GPU. FSx for Lustre peut être déployé avec les options de stockage Scratch-SSD ou Persistent-SSD :

  • Stockage sur SSD Scratch : recommandé pour les charges de travail éphémères ou de courte durée (heures), avec une capacité de débit fixe par To allouée.

  • Stockage SSD permanent : recommandé pour les charges de travail critiques de longue durée nécessitant le plus haut niveau de disponibilité, par exemple les simulations HPC, l'analyse de mégadonnées ou la formation au Machine Learning. Avec le stockage SSD persistant, vous pouvez configurer à la fois la capacité de stockage et la capacité de débit (par To) requises.

Considérations relatives aux performances :

  • Module d'administration FSx pour gérer le système de fichiers Lustre : configurez un module « administratif » sur lequel le client Lustre est installé et le système de FSx fichiers est monté. Cela permettra d'activer un point d'accès pour affiner le système de FSx fichiers, et également dans les situations où vous devez préchauffer le système de FSx fichiers avec vos données d'entraînement ML ou vos modèles LLM avant de démarrer vos instances de calcul GPU. Cela est particulièrement important si votre architecture utilise des instances GPU/Compute EC2 Amazon basées sur Spot, dans lesquelles vous pouvez utiliser le module d'administration pour « réchauffer » ou « précharger » les données souhaitées dans FSx le système de fichiers, afin que les données soient prêtes à être traitées lorsque vous exécutez vos instances Amazon basées sur Spot. EC2

  • Elastic Fabric Adapter (EFA) : les types de déploiement de stockage SSD persistants prennent en charge Elastic Fabric Adapter (EFA), où l'utilisation d'EFA est idéale pour les charges de travail basées sur des GPU à hautes performances et basées sur le débit. Notez que FSx for Lustre prend en charge le GPUDirect stockage NVIDIA (GDS), technologie qui crée un chemin de données direct entre le stockage local ou distant et la mémoire du GPU, afin de permettre un accès plus rapide aux données.

  • Compression : activez la compression des données sur le système de fichiers si certains types de fichiers peuvent être compressés. Cela peut contribuer à améliorer les performances, car la compression des données réduit la quantité de données transférées entre les serveurs FSx de fichiers Lustre et le stockage.

  • Configuration du découpage du système de fichiers Lustre :

    • Bandage des données : permet à Luster de distribuer FSx les données d'un fichier sur plusieurs cibles de stockage d'objets (OSTs) au sein d'un système de fichiers Lustre, ce qui maximise l'accès parallèle et le débit, en particulier pour les tâches de formation ML à grande échelle.

    • Système de fichiers autonome : par défaut, une configuration de découpage Lustre à 4 composants est créée pour vous via la fonctionnalité PFL (Progressive File Layouts) de for Lustre. FSx Dans la plupart des scénarios, il n'est pas nécessaire de mettre à jour le comptage et la taille des bandes PFL Lustre par défaut. Si vous devez ajuster le découpage des données Lustre, vous pouvez le régler manuellement en vous référant aux paramètres de découpage d'un système de fichiers FSx pour Lustre.

    • Système de fichiers lié au S3 : les fichiers importés dans le système de FSx fichiers à l'aide de l'intégration native Amazon S3 (Data Repository Association ou DRA) n'utilisent pas la mise en page PFL par défaut, mais utilisent plutôt la mise en page dans les paramètres du système de fichiers. ImportedFileChunkSize Les fichiers importés au format S3 dont la taille est supérieure à la taille ImportedFileChunkSize seront stockés sur plusieurs OSTs avec un nombre de bandes basé sur la valeur ImportedFileChunkSize définie (1 Go par défaut). Si vous avez des fichiers volumineux, nous vous recommandons de régler ce paramètre sur une valeur supérieure.

    • Emplacement : déployez un système de fichiers FSx pour Lustre dans la même zone de disponibilité que vos nœuds de calcul ou de GPU afin de permettre un accès aux données avec le plus faible temps de latence et d'éviter les modèles d'accès entre zones de disponibilité. Si vous avez plusieurs nœuds GPU situés dans différentes zones de disponibilité, nous vous recommandons de déployer un système de FSx fichiers dans chaque zone de disponibilité pour un accès aux données à faible latence.

Exemple

Définition du volume persistant (PV) pour un système de fichiers FSx pour Lustre, à l'aide du provisionnement statique (lorsque l' FSx instance a déjà été provisionnée).

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]

Exemple

Définition de la demande de volume persistant pour le PV appelée fsx-pv :

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

Exemple

Configurez un pod pour utiliser une réclamation de volume persistante de fsx-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

Pour des exemples complets, consultez les exemples FSx de pilotes Lustre dans GitHub.

Scénario : charge de travail d'une instance de GPU unique

Mountpoint pour Amazon S3 avec pilote CSI : vous pouvez monter un compartiment S3 sous forme de volume dans vos pods à l'aide du pilote CSI Mountpoint pour Amazon S3. Cette méthode permet un contrôle d'accès précis sur les pods autorisés à accéder à des compartiments S3 spécifiques. Chaque pod possède sa propre instance de point de montage et son propre cache local (5 à 10 Go), ce qui permet d'isoler les performances de chargement et de lecture des modèles entre les pods. Cette configuration prend en charge l'authentification au niveau du pod avec les rôles IAM pour les comptes de service (IRSA) et le versionnement indépendant des modèles pour différents modèles ou clients. Le compromis est une augmentation de l'utilisation de la mémoire et du trafic d'API, car chaque pod émet des appels d'API S3 et gère son propre cache.

Exemple partiel de déploiement d'un Pod YAML avec pilote 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

Considérations relatives aux performances :

  • Mise en cache des données : Mountpoint for S3 peut mettre en cache le contenu afin de réduire les coûts et d'améliorer les performances lors de lectures répétées d'un même fichier. Reportez-vous à la section Configuration de la mise en cache pour connaître les options et les paramètres de mise en cache.

  • Taille partielle de l'objet : lorsque vous stockez et accédez à des fichiers d'une taille supérieure à 72 Go, reportez-vous à la section Configuration des performances de Mountpoint pour comprendre comment configurer les paramètres et les paramètres de --write-part-size ligne de commande en fonction de votre profil de données --read-part-size et de vos exigences en matière de charge de travail.

  • Le cache partagé est conçu pour les objets d'une taille maximale de 1 Mo. Il ne supporte pas les objets de grande taille. Utilisez l'option de cache local pour mettre en cache des objets NVMe ou des volumes EBS sur le nœud EKS.

  • Frais de demande d'API : lorsque vous effectuez un grand nombre d'opérations sur les fichiers avec le Mountpoint pour S3, les frais de demande d'API peuvent devenir une partie des coûts de stockage. Pour atténuer ce problème, si une forte cohérence n'est pas requise, activez toujours la mise en cache des métadonnées et définissez la metadata-ttl période pour réduire le nombre d'opérations d'API à S3.

Pour plus de détails, consultez le pilote CSI Mountpoint pour Amazon S3 dans la documentation officielle Amazon EKS. Nous vous recommandons de surveiller les indicateurs de performance d'Amazon S3 à l'aide des CloudWatch indicateurs Amazon en cas de goulots d'étranglement et d'ajuster votre configuration si nécessaire.

Amazon EFS pour les caches de modèles partagés

Dans les scénarios où vous disposez d'un environnement d'instances de calcul à plusieurs EC2 GPU et que vous avez des charges de travail dynamiques nécessitant un accès partagé aux modèles sur plusieurs nœuds et zones de disponibilité (par exemple, inférence en ligne en temps réel avec Karpenter) avec des besoins modérés en termes de performances et d'évolutivité, nous vous recommandons d'utiliser un système de fichiers Amazon Elastic File System (EFS) en tant que volume persistant via le pilote EFS CSI. Amazon EFS est un système de fichiers NFS basé sur le cloud entièrement géré, hautement disponible et évolutif qui permet aux EC2 instances et aux conteneurs de bénéficier d'un stockage de fichiers partagé, avec des performances constantes et pour lesquels aucun provisionnement initial du stockage n'est requis. Utilisez EFS comme volume modèle et montez le volume en tant que système de fichiers partagé en définissant un volume persistant sur le cluster EKS. Chaque demande de volume persistant (PVC) soutenue par un système de fichiers EFS est créée en tant que point d'accès EFS au système de fichiers EFS. EFS permet à plusieurs nœuds et pods d'accéder aux mêmes fichiers de modèle, éliminant ainsi le besoin de synchroniser les données avec le système de fichiers de chaque nœud. Installez le pilote EFS CSI pour intégrer EFS à EKS.

Vous pouvez déployer un système de fichiers Amazon EFS avec les modes de débit suivants :

  • Débit en rafale : adapte le débit à la taille du système de fichiers, adapté à des charges de travail variées avec des rafales occasionnelles.

  • Débit provisionné : débit dédié, idéal pour les tâches de formation au machine learning cohérentes avec des besoins de performance prévisibles dans des limites limites.

  • Débit élastique (recommandé pour le ML) : s'adapte automatiquement en fonction de la charge de travail, rentabilité pour différentes charges de travail ML.

Pour consulter les spécifications de performances, consultez les spécifications de performance d'Amazon EFS.

Considérations relatives aux performances :

  • Utilisez Elastic Throughput pour différentes charges de travail.

  • Utilisez la classe de stockage standard pour les charges de travail ML actives.

Pour des exemples complets d'utilisation du système de fichiers Amazon EFS en tant que volume persistant au sein de votre cluster EKS et de vos pods, reportez-vous aux exemples de pilotes EFS CSI dans GitHub.

Surveillance des performances Les performances médiocres du disque peuvent retarder la lecture des images des conteneurs, augmenter le temps de latence au démarrage du pod et dégrader le débit d'inférence ou de formation. Nous recommandons les méthodes suivantes pour surveiller les indicateurs de performance du service de stockage AWS concerné en cas de problème et pour ajuster votre configuration si nécessaire.