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à.

Archiviazione

Gestione e archiviazione dei dati

Implementa i modelli AI sui pod utilizzando un driver CSI

AI/ML i carichi di lavoro richiedono spesso l'accesso a 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, FSx for Lustre, FSx for OpenZFS, EFS) come Persistent Volumes (PV) 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 prestazionali 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.

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. Usa Amazon CloudWatch per monitorare i parametri prestazionali per i tuoi servizi di storage AWS. Quando identifichi problemi di prestazioni, modifica i parametri di configurazione dello storage per ottimizzare le prestazioni.

Scenario: carico di lavoro di più istanze GPU

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

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

Considerazioni sulle prestazioni:

Esempio

Definizione del volume persistente (PV) per un file system FSx for Lustre, utilizzando il provisioning statico (in cui è già stato effettuato il provisioning dell'istanza FSx).

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 di driver FSx for Lustre in. GitHub Monitora i parametri prestazionali di Amazon FSx for Lustre utilizzando Amazon. CloudWatch Quando vengono identificati problemi di prestazioni, modifica i parametri di configurazione in base alle esigenze.

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:

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 FSx per lo storage condiviso persistente OpenZFS

Per scenari che coinvolgono più istanze di calcolo GPU EC2 con carichi di lavoro sensibili alla latenza che richiedono alta disponibilità, alte prestazioni, sensibilità ai costi e implementazioni di più pod per diverse applicazioni, consigliamo Amazon FSx per OpenZFS. Alcuni esempi di carichi di lavoro includono inferenza in tempo reale, reinforcement learning e addestramento di reti generative antagoniste. FSx for OpenZFS è particolarmente utile per i carichi di lavoro che richiedono un accesso ad alte prestazioni a una struttura di directory mirata con file di piccole dimensioni che utilizzano modelli di accesso ai dati IO di piccole dimensioni. Inoltre, FSx for OpenZFS offre la flessibilità necessaria per scalare le prestazioni indipendentemente dalla capacità di storage, aiutandovi a raggiungere un'efficienza ottimale in termini di costi adattando le dimensioni dello storage alle esigenze effettive e mantenendo al contempo i livelli di prestazioni richiesti

Il driver CSI nativo FSx for OpenZFS consente la creazione di più PVC su un singolo file system creando più volumi. Ciò riduce il sovraccarico di gestione e massimizza l'utilizzo del throughput e degli IOPS del file system attraverso implementazioni consolidate di pod applicativi su un singolo file system. Inoltre, include funzionalità aziendali come istantanee a copia zero, cloni a copia zero e quote di utenti e gruppi, che possono essere fornite dinamicamente tramite il driver CSI.

FSx for OpenZFS supporta tre diversi tipi di implementazione al momento della creazione:

Considerazioni sulle prestazioni:

Una volta creato il file system, il servizio crea automaticamente un volume root associato. È consigliabile archiviare i dati all'interno di volumi secondari del volume root del file system. Utilizzando il driver CSI FSx for OpenZFS si crea un Persistent Volume Claim associato per creare dinamicamente il volume figlio.

Esempi:

Una definizione di Storage Class (SC) per un volume FSx for OpenZFS, utilizzata per creare un volume figlio del volume root ($ROOT_VOL_ID) su un file system esistente ed esportare il volume nel VPC CIDR ($VPC_CIDR) utilizzando il protocollo 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

Un Persistent Volume Claim (PVC) creato dinamicamente rispetto al fsxz-vol-sc creato sopra. Nota, la capacità di storage allocata è 1Gi, necessaria per i volumi FSx for OpenZFS, come indicato nelle domande frequenti sui driver CSI. Al volume verrà fornita la piena capacità fornita al file system con questa configurazione. Se è necessario limitare la capacità del volume, è possibile farlo utilizzando quote per utenti o gruppi.

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

Configura un pod per montare un volume utilizzando il Persistent Volume Claim (PVC) di 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 per cache di modelli condivisi

In scenari in cui disponi di un ambiente di calcolo con più istanze di calcolo GPU EC2 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 istanze e contenitori EC2 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 EFS Access-point per il 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:

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

Considerazioni sulle prestazioni:

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 Monitora i parametri prestazionali di Amazon EFS utilizzando Amazon CloudWatch. Quando vengono identificati problemi di prestazioni, modifica i parametri di configurazione in base alle esigenze.

Usa S3 Express One Zone per Latency-Sensitive flussi di lavoro orientati agli oggetti

Per i AI/ML carichi di lavoro sensibili alla latenza su Amazon EKS, come la formazione su modelli su larga scala, l'inferenza o l'analisi ad alte prestazioni, consigliamo di utilizzare S3 Express One Zone per lo storage e il recupero di modelli ad alte prestazioni. S3 Express One Zone offre uno spazio dei nomi gerarchico, simile a un file system, in cui è sufficiente caricare in un bucket di directory, adatto per «inserire tutto», mantenendo al contempo un'alta velocità. Ciò è particolarmente utile se siete abituati a flussi di lavoro orientati agli oggetti. In alternativa, se sei più abituato ai file system (ad es. POSIX-compliant), puoi preferire Amazon FSx for Lustre o OpenZFS. Amazon S3 Express One Zone archivia i dati in un'unica zona di disponibilità (AZ) utilizzando bucket di directory e offrendo una latenza inferiore rispetto ai bucket S3 standard, che distribuiscono i dati su più AZ. Per ottenere i migliori risultati, assicurati di collocare le tue risorse di calcolo EKS nella stessa zona del bucket Express One Zone. Per saperne di più sulle differenze di S3 Express One Zone, consulta Differenze per i bucket di directory.

Per accedere a S3 Express One Zone con la semantica del filesystem, consigliamo di utilizzare il driver CSI Mountpoint S3, che monta i bucket S3 (incluso Express One Zone) come file system locale. Questo traduce le operazioni sui file (ad esempio, apertura, lettura, scrittura) in chiamate API S3, fornendo un accesso ad alta velocità ottimizzato per carichi di lavoro impegnativi in lettura da più client e scritture sequenziali su nuovi oggetti. Per i dettagli sulle operazioni e le limitazioni supportate (ad esempio, nessuna conformità POSIX completa, ma aggiunte e ridenominazioni supportate in Express One Zone), consulta la documentazione semantica di Mountpoint.

Vantaggi prestazionali

Casi d'uso consigliati

Considerazioni

La classe di storage S3 Express One Zone è disponibile in più regioni e si integra con EKS per i carichi di lavoro che richiedono l'accesso agli oggetti senza attendere lo storage. Per ulteriori informazioni, consulta Guida introduttiva a S3 Express One Zone.