Storage - Amazon EKS
Gestione e archiviazione dei dati

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Storage

Gestione e archiviazione dei dati

Implementa i modelli AI sui pod utilizzando un driver CSI

I carichi di lavoro AI/ML richiedono spesso l'accesso ad artefatti di modelli di grandi dimensioni (ad esempio pesi addestrati, configurazioni) e i pod necessitano di un modo affidabile e scalabile per accedervi senza incorporarli nelle immagini dei container, il che può aumentare le dimensioni delle immagini e i tempi di recupero del registro dei container. Per ridurre il sovraccarico operativo legato alla gestione dei montaggi di volume, consigliamo di implementare modelli AI sui pod montando i servizi di storage Amazon (ad esempio, S3, for FSx Lustre, EFS) come Persistent Volumes (PVs) utilizzando i rispettivi driver CSI. Per i dettagli sull'implementazione, consulta gli argomenti successivi in questa sezione.

Ottimizza lo storage per le cache dei modelli ML su EKS

L'utilizzo di una soluzione di archiviazione ottimale è fondamentale per ridurre al minimo la latenza di avvio dei pod e delle applicazioni, ridurre l'utilizzo della memoria, ottenere i livelli di prestazioni desiderati per accelerare i carichi di lavoro e garantire la scalabilità dei carichi di lavoro ML. I carichi di lavoro ML si basano spesso su file modello (pesi), che possono essere di grandi dimensioni e richiedere l'accesso condiviso ai dati tra pod o nodi. La scelta della soluzione di storage ottimale dipende dalle caratteristiche del carico di lavoro, come l'efficienza a nodo singolo, l'accesso a più nodi, i requisiti di latenza, i vincoli di costo e anche i requisiti di integrazione dei dati (ad esempio con un repository di dati Amazon S3). Ti consigliamo di confrontare diverse soluzioni di storage con i tuoi carichi di lavoro per capire quale soddisfa i tuoi requisiti e abbiamo fornito le seguenti opzioni per aiutarti a valutare in base ai requisiti del tuo carico di lavoro.

Il driver EKS CSI supporta i seguenti servizi di storage AWS, ognuno con il proprio driver CSI e presenta i propri punti di forza per i flussi di lavoro AI e ML:

La scelta del servizio di storage AWS dipende dall'architettura di distribuzione, dalla scalabilità, dai requisiti di prestazioni e dalla strategia di costo. I driver Storage CSI devono essere installati sul cluster EKS, il che consente al driver CSI di creare e gestire volumi persistenti (PV) al di fuori del ciclo di vita di un Pod. Utilizzando il driver CSI, puoi creare definizioni PV dei servizi di storage AWS supportati come risorse del cluster EKS. I pod possono quindi accedere a questi volumi di storage per i rispettivi volumi di dati creando un Persistent Volume Claim (PVC) per il PV. A seconda del servizio di storage AWS e dello scenario di implementazione, un singolo PVC (e il relativo PV associato) può essere collegato a più Pod per un carico di lavoro. Ad esempio, per l'allenamento ML, i dati di allenamento condivisi vengono archiviati su un PV e vi si accede da più Pod; per l'inferenza online in tempo reale, i modelli LLM vengono memorizzati nella cache su un PV e vi si accede da più Pod. Di seguito sono riportati esempi di file YAML PV e PVC per i servizi di storage AWS per aiutarti a iniziare.

Scenario: carico di lavoro su più istanze GPU

Amazon FSx for Lustre: negli scenari in cui disponi di un ambiente di calcolo con più istanze di calcolo EC2 GPU con carichi di lavoro dinamici sensibili alla latenza e con throughput di banda elevato, come formazione distribuita e gestione di modelli, e richiedi l'integrazione nativa del repository di dati Amazon S3, ti consigliamo Amazon for Lustre. FSx FSx for Lustre fornisce un file system parallelo ad alte prestazioni completamente gestito, progettato per carichi di lavoro ad alta intensità di calcolo come HPC (High Performance Computing) e Machine Learning.

È possibile installare il driver CSI FSx for Lustre per montare i FSx filesystem su EKS come volume persistente (PV), quindi implementarlo FSx per il file system Lustre come cache autonoma ad alte prestazioni o come file system collegato a S3 per fungere da cache ad alte prestazioni per i dati S3, fornendo un throughput rapido I/O e elevato per l'accesso ai dati tra le istanze di calcolo della GPU. FSx for Lustre può essere distribuito con opzioni di archiviazione Scratch-SSD o Persistent-SSD:

  • Storage Scratch-SSD: consigliato per carichi di lavoro temporanei o di breve durata (ore), con capacità di throughput fissa per TiB fornita.

  • Storage SSD persistente: consigliato per carichi di lavoro critici e di lunga durata che richiedono il massimo livello di disponibilità, ad esempio simulazioni HPC, analisi dei big data o formazione sul Machine Learning. Con lo storage SSD persistente, puoi configurare sia la capacità di archiviazione che la capacità di throughput (per TiB) richieste.

Considerazioni sulle prestazioni:

  • Pod amministrativo da gestire FSx per il file system Lustre: configura un pod «amministrativo» su cui sia installato il client lustre e che abbia il FSx file system montato. Ciò consentirà un punto di accesso per consentire la regolazione fine del FSx file system e anche in situazioni in cui è necessario preriscaldare il FSx file system con i dati di addestramento ML o i modelli LLM prima di avviare le istanze di calcolo GPU. Ciò è particolarmente importante se la tua architettura utilizza istanze Amazon EC2 GPU/Compute basate su Spot, in cui puoi utilizzare il Pod amministrativo per «riscaldare» o «precaricare» i dati desiderati nel FSx file system, in modo che siano pronti per essere elaborati quando esegui le istanze Amazon basate su Spot. EC2

  • Elastic Fabric Adapter (EFA): i tipi di implementazione dello storage SSD persistente supportano Elastic Fabric Adapter (EFA), dove l'utilizzo di EFA è ideale per carichi di lavoro basati su GPU ad alte prestazioni e velocità effettiva. Tieni presente che FSx for Lustre supporta NVIDIA GPUDirect Storage (GDS), dove GDS è una tecnologia che crea un percorso dati diretto tra lo storage locale o remoto e la memoria GPU, per consentire un accesso più rapido ai dati.

  • Compressione: abilita la compressione dei dati sul file system se hai tipi di file che possono essere compressi. Ciò può contribuire ad aumentare le prestazioni in quanto la compressione dei dati riduce la quantità di dati trasferiti tra FSx i file server Lustre e lo storage.

  • Configurazione dello striping del file system Lustre:

Esempio

Definizione del volume persistente (PV) per un file system FSx for Lustre, utilizzando il provisioning statico (laddove l' FSx istanza è già stato fornito).

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]

Esempio

Definizione di Persistent Volume Claim per PV denominata: fsx-pv

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

Esempio

Configura un pod per utilizzare un Persistent Volume Claim difsx-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

Per esempi completi, vedere gli esempi FSx di Lustre Driver in GitHub.

Scenario: carico di lavoro a singola istanza GPU

Mountpoint per Amazon S3 con driver CSI: puoi montare un bucket S3 come volume nei tuoi pod utilizzando il driver CSI Mountpoint per Amazon S3. Questo metodo consente un controllo granulare degli accessi su quali Pod possono accedere a bucket S3 specifici. Ogni pod dispone di una propria istanza di mountpoint e di una cache locale (5-10 GB), che isolano le prestazioni di caricamento e lettura del modello tra i pod. Questa configurazione supporta l'autenticazione a livello di pod con IAM Roles for Service Accounts (IRSA) e il controllo delle versioni dei modelli indipendenti per diversi modelli o clienti. Il compromesso è l'aumento dell'utilizzo della memoria e del traffico API, poiché ogni pod invia chiamate API S3 e mantiene la propria cache.

Esempio: esempio parziale di implementazione di un Pod (YAML) con driver 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

Considerazioni sulle prestazioni:

  • Memorizzazione nella cache dei dati: Mountpoint per S3 può memorizzare nella cache i contenuti per ridurre i costi e migliorare le prestazioni in caso di letture ripetute sullo stesso file. Fai riferimento alla configurazione della memorizzazione nella cache per le opzioni e i parametri di memorizzazione nella cache.

  • Dimensione parziale dell'oggetto: quando memorizzi e accedi a file di dimensioni superiori a 72 GB, consulta Configurazione delle prestazioni di Mountpoint per capire come configurare i parametri della --write-part-size riga di comando --read-part-size e il profilo dei dati per soddisfare i requisiti del profilo dei dati e del carico di lavoro.

  • La cache condivisa è progettata per oggetti di dimensioni fino a 1 MB. Non supporta oggetti di grandi dimensioni. Utilizzate l'opzione Cache locale per memorizzare nella cache gli oggetti nei volumi EBS NVMe o EBS sul nodo EKS.

  • Costi per le richieste API: quando si eseguono un numero elevato di operazioni sui file con Mountpoint for S3, i costi delle richieste API possono diventare una parte dei costi di archiviazione. Per mitigare questo problema, se non è richiesta una forte coerenza, abilita sempre la memorizzazione nella cache dei metadati e imposta il metadata-ttl periodo per ridurre il numero di operazioni API su S3.

Per ulteriori dettagli, consulta il driver CSI Mountpoint for Amazon S3 nella documentazione ufficiale di Amazon EKS. Ti consigliamo di monitorare i parametri prestazionali di Amazon S3 con i parametri di CloudWatch Amazon in caso di colli di bottiglia e di modificare la configurazione dove necessario.

Amazon EFS per cache di modelli condivisi

In scenari in cui disponi di un ambiente di elaborazione con più EC2 GPU e carichi di lavoro dinamici che richiedono l'accesso condiviso al modello su più nodi e zone di disponibilità (ad esempio, inferenza online in tempo reale con Karpenter) con esigenze di prestazioni e scalabilità moderate, consigliamo di utilizzare un file system Amazon Elastic File System (EFS) come volume persistente tramite il driver CSI EFS. Amazon EFS è un file system NFS basato sul cloud completamente gestito, altamente disponibile e scalabile che abilita EC2 istanze e contenitori con storage di file condiviso, con prestazioni costanti e in cui non è richiesto il provisioning anticipato dello storage. Usa EFS come volume modello e monta il volume come file system condiviso definendo un volume persistente sul cluster EKS. Ogni Persistent Volume Claim (PVC) supportato da un file system EFS viene creato come punto di accesso EFS al file system EFS. EFS consente a più nodi e pod di accedere agli stessi file di modello, eliminando la necessità di sincronizzare i dati con il file system di ciascun nodo. Installa il driver EFS CSI per integrare EFS con EKS.

Puoi implementare un file system Amazon EFS con le seguenti modalità di throughput:

  • Bursting Throughput: ridimensiona la velocità effettiva in base alle dimensioni del file system, adatta a carichi di lavoro diversi con picchi occasionali.

  • Provisioned Throughput: throughput dedicato, ideale per lavori di formazione ML coerenti con esigenze prestazionali prevedibili entro limiti.

  • Throughput elastico (consigliato per il machine learning): scalabilità automatica in base al carico di lavoro, conveniente per diversi carichi di lavoro ML.

Per visualizzare le specifiche prestazionali, consulta le specifiche prestazionali di Amazon EFS.

Considerazioni sulle prestazioni:

  • Usa Elastic Throughput per diversi carichi di lavoro.

  • Usa la classe di storage Standard per carichi di lavoro ML attivi.

Per esempi completi di utilizzo del file system Amazon EFS come volume persistente all'interno del cluster EKS e dei pod, consulta gli esempi di driver CSI EFS in. GitHub

Monitoraggio delle prestazioni Le scarse prestazioni del disco possono ritardare la lettura delle immagini dei container, aumentare la latenza di avvio dei pod e ridurre la velocità di inferenza o di addestramento. Consigliamo i seguenti metodi per monitorare i parametri prestazionali del rispettivo servizio di storage AWS in caso di colli di bottiglia e modificare la configurazione dove necessario.