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, FSx for Lustre, per FSx OpenZFS, EFS) come Persistent Volumes () utilizzando i rispettivi driver CSI. PVs 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.

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 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, è possibile configurare sia la capacità di archiviazione che la capacità di throughput (per TiB) richiesta.

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. Monitora le metriche 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:

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

Per scenari che coinvolgono più istanze di calcolo EC2 GPU 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 per OpenZFS. FSx Alcuni esempi di carichi di lavoro includono inferenza in tempo reale, apprendimento per rinforzo e addestramento di reti antagoniste generative. FSx per 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 per OpenZFS offre la flessibilità necessaria per scalare le prestazioni indipendentemente dalla capacità di archiviazione, aiutando a raggiungere un'efficienza ottimale in termini di costi adattando le dimensioni dello storage alle esigenze effettive e mantenendo i livelli di prestazioni richiesti

Il driver CSI nativo FSx per OpenZFS consente la creazione di più PVCs file system in un unico file 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 di applicazioni 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 distribuzione al momento della creazione:

  • Single-AZ: opzione dal costo più basso con latenze inferiori al millisecondo, ma non offre un'elevata disponibilità a livello di file system o di zona di disponibilità. Consigliato per carichi di lavoro di sviluppo e test o per carichi di lavoro con elevata disponibilità a livello di applicazione.

  • Single-AZ (HA): offre un'elevata disponibilità a livello di file system con latenze inferiori al millisecondo. Consigliato per carichi di lavoro dalle prestazioni più elevate che richiedono un'elevata disponibilità.

  • Multi-AZ: offre un'elevata disponibilità a livello di file system e tra le zone di disponibilità. Consigliato per carichi di lavoro ad alte prestazioni che richiedono una disponibilità aggiuntiva tra le zone di disponibilità.

Considerazioni sulle prestazioni:

  • Tipo di implementazione: se la disponibilità aggiuntiva tra le zone di disponibilità non è un requisito, prendi in considerazione l'utilizzo del tipo di implementazione Single-AZ (HA). Questo tipo di implementazione fornisce fino al 100% del throughput per le scritture, mantiene latenze inferiori al millisecondo e i file system Gen2 dispongono di una NVMe cache aggiuntiva per archiviare fino a terabyte di dati a cui si accede di frequente. I file system Multi-AZ forniscono fino al 75% del throughput per le scritture con una latenza maggiore per adattarsi al traffico Cross-AZ.

  • Throughput e IOPS: sia il throughput che l'IOPS configurati per il file system possono essere aumentati o ridotti dopo l'implementazione. È possibile fornire fino al 10% dell'accesso ai dati memorizzati nella cacheGB/s of disk throughput providing up to 21GB/s. Gli IOPS possono essere scalati fino a 400.000 dal disco e la cache può fornire oltre 1 milione di IOPS. Si noti che la scalabilità del throughput di un file system Single-AZ causa una breve interruzione del file system in quanto non esiste un'elevata disponibilità. La scalabilità della velocità effettiva di un file system Single-AZ (HA) o Multi-AZ può essere eseguita senza interruzioni. Gli IOPS SSD possono essere scalati una volta ogni sei ore.

  • Classe di archiviazione: FSx per OpenZFS supporta sia la classe di archiviazione SSD che la classe di archiviazione Intelligent-Tiering. Per i AI/ML carichi di lavoro si consiglia di utilizzare la classe di archiviazione SSD che fornisce prestazioni costanti al carico di lavoro mantenendo le CPU/GPU il più occupate possibile.

  • Compressione: abilita l'algoritmo di LZ4 compressione se hai un carico di lavoro che può essere compresso. Ciò riduce la quantità di dati che ogni file consuma nella cache, permettendo di fornire più dati direttamente dalla cache come throughput di rete e IOPS per ridurre il carico sul disco SSD.

  • Dimensione del record: la maggior parte dei AI/ML carichi di lavoro trarrà vantaggio dal mantenimento della dimensione di record predefinita di 128 KiB. Questo valore deve essere ridotto solo se il set di dati è costituito da file di grandi dimensioni (superiori a 10 GiB) con accesso costante a piccoli blocchi inferiore a 128 KiB dall'applicazione.

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 fsxz-vol-sc Volume Claim (PVC) creato dinamicamente rispetto a quello creato sopra. Nota, la capacità di archiviazione allocata è di 1Gi, necessaria FSx per i volumi 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 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 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 flussi di lavoro orientati agli oggetti e sensibili alla latenza

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 esempio, conformi a POSIX), puoi preferire Amazon for Lustre o OpenZFS. FSx Amazon S3 Express One Zone archivia i dati in un'unica zona di disponibilità (AZ) utilizzando bucket di directory e offre una latenza inferiore rispetto ai bucket S3 standard, che distribuiscono i dati su più bucket. AZs 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

  • Fornisce un accesso ai dati fino a 10 volte più veloce rispetto a S3 Standard, con una latenza costante di un millisecondo e costi di richiesta inferiori fino all'80%.

  • È scalabile per gestire da centinaia a milioni di richieste al secondo per bucket di directory, evitando i throttling o i brownout tipici di S3 standard durante carichi estremi (ad esempio, in cluster con decine o centinaia di migliaia di reti saturate). GPUs/CPUs

  • Utilizza un meccanismo di autenticazione basato sulla sessione. Effettua l'autenticazione una volta per ottenere un token di sessione, quindi esegui operazioni ripetute ad alta velocità senza sovraccarico di autenticazione per richiesta. È ottimizzato per carichi di lavoro come checkpoint frequenti o caricamento di dati.

Casi d'uso consigliati

  • Memorizzazione nella cache: uno dei principali casi d'uso dell'utilizzo del driver CSI Mountpoint S3 con S3 Express One Zone è la memorizzazione nella cache. La prima istanza legge i dati da S3 Standard (uso generico), memorizzandoli nella cache in Express One Zone a bassa latenza. Le letture successive da parte di altri client accedono più rapidamente ai dati memorizzati nella cache, il che è ideale per scenari a più nodi in cui più nodi EKS leggono gli stessi dati (ad esempio, set di dati di addestramento condivisi). Ciò può migliorare le prestazioni fino a 7 volte per accessi ripetuti e ridurre i costi di elaborazione. Per i carichi di lavoro che richiedono la piena conformità POSIX (ad esempio, blocco dei file e modifiche sul posto), considera Amazon FSx for Lustre o OpenZFS come alternative.

  • AI/ML Addestramento e inferenza su larga scala: ideale per carichi di lavoro con centinaia o migliaia di nodi di elaborazione (ad esempio, nei cluster EKS) GPUs in cui la limitazione generica di S3 potrebbe causare ritardi e sprecare costose risorse di elaborazione. Ad esempio, i ricercatori LLM o le organizzazioni che utilizzano modelli quotidiani traggono vantaggio da un accesso rapido e affidabile senza interrompere S3 regionale. tests/checkpoints Per carichi di lavoro su scala ridotta (ad esempio, decine di nodi), possono essere sufficienti S3 Standard o altre classi di storage.

  • Pipeline di dati: Load/prepare modelli, dati di addestramento di archivio o checkpoint di flusso. Se il tuo team preferisce lo storage di oggetti rispetto ai file system tradizionali (ad esempio, grazie alla familiarità con S3), usalo invece di apportare modifiche ingegneristiche per opzioni conformi a POSIX come Lustre. FSx

Considerazioni

  • Resilienza: il design Single-AZ offre una durabilità del 99,449% (come lo standard S3, tramite ridondanza all'interno della AZ) ma una disponibilità inferiore (progettazione al 99,95%, SLA del 99,9%) rispetto alle classi Multi-AZ (disponibilità del 99,99%). È meno resistente ai guasti AZ. Utilizzalo per dati ricreabili o memorizzati nella cache. Prendi in considerazione la replica o i backup Multi-AZ per carichi di lavoro critici.

  • Supporto per API e funzionalità: supporta un sottoinsieme di S3 APIs (ad esempio, nessuna policy o replica del ciclo di vita); potrebbe richiedere modifiche minori all'app per l'autenticazione della sessione o la gestione degli oggetti.

  • Integrazione EKS: colloca EKS nella stessa AZ del pods/nodes bucket di directory per ridurre al minimo la latenza di rete. Usa i driver Mountpoint per Amazon S3 o CSI per l'accesso nativo a Kubernetes.

  • Test: verifica la latenza di recupero in un ambiente non di produzione per convalidare i miglioramenti delle prestazioni. Monitora il throttling negli scenari S3 standard (ad esempio, elevata saturazione della GPU) e confrontalo.

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