Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Speicher

Datenmanagement und Speicherung

Stellen Sie mithilfe eines CSI-Treibers KI-Modelle auf Pods bereit

KI/ML-Workloads erfordern häufig Zugriff auf große Modellartefakte (z. B. trainierte Gewichte, Konfigurationen), und Pods benötigen eine zuverlässige, skalierbare Methode, um auf diese zuzugreifen, ohne sie in Container-Images einzubetten, was die Bildgröße und die Abrufzeiten der Container-Registry erhöhen kann. Um den betrieblichen Aufwand bei der Verwaltung von Volume-Mounts zu reduzieren, empfehlen wir die Bereitstellung von KI-Modellen auf Pods, indem Amazon-Speicherdienste (z. B. S3, FSx für Lustre, FSx für OpenZFS, EFS) als persistente Volumes (PVs) mithilfe ihrer jeweiligen CSI-Treiber bereitgestellt werden. Einzelheiten zur Implementierung finden Sie in den nachfolgenden Themen in diesem Abschnitt.

Optimieren Sie den Speicher für ML-Modell-Caches auf EKS

Die Nutzung einer optimalen Speicherlösung ist entscheidend, um die Latenz beim Starten von Pods und Anwendungen zu minimieren, den Speicherverbrauch zu reduzieren, das gewünschte Leistungsniveau zur Beschleunigung von Workloads zu erreichen und die Skalierbarkeit von ML-Workloads sicherzustellen. ML-Workloads basieren häufig auf Modelldateien (Gewichtungen), die groß sein können und gemeinsamen Zugriff auf Daten über Pods oder Knoten hinweg erfordern. Die Auswahl der optimalen Speicherlösung hängt von den Merkmalen Ihres Workloads ab, wie z. B. der Effizienz eines einzelnen Knotens, dem Zugriff auf mehrere Knoten, den Latenzanforderungen, den Kostenbeschränkungen und auch den Anforderungen an die Datenintegration (z. B. mit einem Amazon S3 S3-Datenrepository). Wir empfehlen, verschiedene Speicherlösungen mit Ihren Workloads zu vergleichen, um herauszufinden, welche Ihren Anforderungen entspricht. Wir haben die folgenden Optionen bereitgestellt, um Ihnen bei der Bewertung anhand Ihrer Workload-Anforderungen zu helfen.

Der EKS-CSI-Treiber unterstützt die folgenden AWS-Speicherservices, von denen jeder seinen eigenen CSI-Treiber hat und seine eigenen Stärken für KI- und ML-Workflows hat:

Die Wahl des AWS-Speicherservices hängt von Ihrer Bereitstellungsarchitektur, Ihrem Umfang, Ihren Leistungsanforderungen und Ihrer Kostenstrategie ab. Speicher-CSI-Treiber müssen auf Ihrem EKS-Cluster installiert werden, sodass der CSI-Treiber persistente Volumes (PV) außerhalb des Lebenszyklus eines Pods erstellen und verwalten kann. Mithilfe des CSI-Treibers können Sie PV-Definitionen unterstützter AWS-Speicherservices als EKS-Clusterressourcen erstellen. Pods können dann auf diese Speichervolumes für ihre Datenvolumen zugreifen, indem sie einen Persistent Volume Claim (PVC) für den PV erstellen. Abhängig vom AWS-Speicherservice und Ihrem Bereitstellungsszenario kann ein einzelnes PVC (und das zugehörige PV) für einen Workload an mehrere Pods angehängt werden. Bei ML-Trainings werden gemeinsame Trainingsdaten beispielsweise auf einem PV gespeichert und von mehreren Pods abgerufen. Für Online-Inferenzen in Echtzeit werden LLM-Modelle auf einem PV zwischengespeichert und von mehreren Pods abgerufen. Nachfolgend finden Sie Beispiele für PV- und PVC-YAML-Dateien für AWS-Speicherservices, um Ihnen den Einstieg zu erleichtern.

Leistungsüberwachung Eine schlechte Festplattenleistung kann das Lesen von Container-Images verzögern, die Latenz beim Pod-Start erhöhen und den Inferenz- oder Trainingsdurchsatz verringern. Verwenden Sie Amazon CloudWatch, um die Leistungskennzahlen für Ihre AWS-Speicherservices zu überwachen. Wenn Sie Leistungsengpässe feststellen, ändern Sie Ihre Speicherkonfigurationsparameter, um die Leistung zu optimieren.

Szenario: Arbeitslast mehrerer GPU-Instanzen

Amazon FSx for Lustre: In Szenarien, in denen Sie eine Umgebung mit mehreren EC2 GPU-Recheninstanzen mit latenzsensitiven dynamischen Workloads und hohem Bandbreitendurchsatz haben, wie z. B. verteiltes Training und Model Serving, und Sie eine native Amazon S3 S3-Datenrepository-Integration benötigen, empfehlen wir Amazon for Lustre. FSx FSx for Lustre bietet ein vollständig verwaltetes paralleles Hochleistungsdateisystem, das für rechenintensive Workloads wie Hochleistungsrechnen (HPC) und Machine Learning konzipiert ist.

Sie können den FSx for Lustre CSI-Treiber installieren, um FSx Dateisysteme auf EKS als persistentes Volume (PV) zu mounten, und dann das Lustre-Dateisystem als eigenständigen Hochleistungs-Cache oder als S3-verknüpftes Dateisystem bereitstellen FSx , das als Hochleistungs-Cache für S3-Daten fungiert und einen schnellen I/O und hohen Durchsatz für den Datenzugriff über Ihre GPU-Recheninstanzen hinweg bietet. FSx for Lustre kann entweder mit Scratch-SSD- oder Persistent-SSD-Speicheroptionen bereitgestellt werden:

Überlegungen zur Leistung:

Beispiel

Definition eines persistenten Volumes (PV) FSx für ein For Lustre-Dateisystem unter Verwendung von Static Provisioning (wobei die FSx Instanz bereits bereitgestellt wurde).

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]

Beispiel

Die Definition von Persistent Volume Claim für PV lautet: fsx-pv

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

Beispiel

Konfigurieren Sie einen Pod für die Verwendung eines persistenten Volumenanspruchs vonfsx-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

Vollständige Beispiele finden Sie unter Beispiele FSx für Lustre-Treiber unter GitHub. Überwachen Sie die Leistungskennzahlen von Amazon FSx for Lustre mithilfe von Amazon CloudWatch. Wenn Leistungsengpässe festgestellt werden, passen Sie Ihre Konfigurationsparameter nach Bedarf an.

Szenario: Arbeitslast einer einzelnen GPU-Instanz

Mountpoint für Amazon S3 mit CSI-Treiber: Mit dem Mountpoint for Amazon S3 CSI-Treiber können Sie einen S3-Bucket als Volume in Ihren Pods mounten. Diese Methode ermöglicht eine detaillierte Zugriffskontrolle darüber, welche Pods auf bestimmte S3-Buckets zugreifen können. Jeder Pod verfügt über eine eigene Mountpoint-Instanz und einen eigenen lokalen Cache (5-10 GB), wodurch die Lade- und Leseleistung des Modells zwischen den Pods isoliert wird. Dieses Setup unterstützt die Authentifizierung auf Pod-Ebene mit IAM Roles for Service Accounts (IRSA) und die unabhängige Modellversionierung für verschiedene Modelle oder Kunden. Der Kompromiss besteht in einer erhöhten Speichernutzung und einem erhöhten API-Verkehr, da jeder Pod S3-API-Aufrufe ausgibt und seinen eigenen Cache verwaltet.

Beispiel für ein teilweises Beispiel für eine Pod-Implementierung mit YAML und CSI-Treiber:

# 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

Überlegungen zur Leistung:

Weitere Informationen finden Sie im Mountpoint for Amazon S3 CSI-Treiber in der offiziellen Amazon EKS-Dokumentation. Wir empfehlen, die Leistungskennzahlen von Amazon S3 mit CloudWatch Amazon-Metriken zu überwachen, falls Engpässe auftreten, und Ihre Konfiguration gegebenenfalls anzupassen.

Amazon FSx für OpenZFS — persistenter gemeinsam genutzter Speicher

Für Szenarien mit mehreren EC2 GPU-Recheninstanzen mit latenzempfindlichen Workloads, die hohe Verfügbarkeit, hohe Leistung, Kostensensitivität und mehrere Pod-Bereitstellungen für verschiedene Anwendungen erfordern, empfehlen wir Amazon for OpenZFS. FSx Einige Beispiele für Workloads umfassen Inferenz in Echtzeit, Reinforcement-Learning und Training generativer gegnerischer Netzwerke. FSx für OpenZFS ist besonders vorteilhaft für Workloads, die einen leistungsstarken Zugriff auf eine fokussierte Verzeichnisstruktur mit kleinen Dateien und kleinen I/O-Datenzugriffsmustern benötigen. Außerdem bietet OpenZFS die Flexibilität, FSx die Leistung unabhängig von der Speicherkapazität zu skalieren. So können Sie optimale Kosteneffizienz erzielen, indem Sie die Speichergröße an die tatsächlichen Bedürfnisse anpassen und gleichzeitig das erforderliche Leistungsniveau beibehalten

Der native CSI-Treiber FSx für OpenZFS ermöglicht die Erstellung mehrerer Dateisysteme in einem einzigen PVCs , indem mehrere Volumes erstellt werden. Dies reduziert den Verwaltungsaufwand und maximiert die Nutzung des Durchsatzes und der IOPS des Dateisystems durch konsolidierte Anwendungs-Pod-Bereitstellungen auf einem einzigen Dateisystem. Darüber hinaus umfasst es Unternehmensfunktionen wie Zero-Copy-Snapshots, Zero-Copy-Clones sowie Benutzer- und Gruppenkontingente, die dynamisch über den CSI-Treiber bereitgestellt werden können.

FSx for OpenZFS unterstützt bei der Erstellung drei verschiedene Bereitstellungstypen:

Überlegungen zur Leistung:

Sobald das Dateisystem erstellt ist, wird vom Dienst automatisch ein zugehöriges Root-Volume erstellt. Es hat sich bewährt, Daten in untergeordneten Volumes des Root-Volumes im Dateisystem zu speichern. Mithilfe des CSI-Treibers FSx für OpenZFS erstellen Sie einen zugehörigen Persistent Volume Claim, um das untergeordnete Volume dynamisch zu erstellen.

Beispiele:

Eine Speicherklassendefinition (SC) für ein Volume FSx für OpenZFS, mit der ein untergeordnetes Volume des Root-Volumes ($ROOT_VOL_ID) in einem vorhandenen Dateisystem erstellt und das Volume mithilfe des NFS v4.2-Protokolls in das VPC CIDR ($VPC_CIDR) exportiert wird.

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

Ein dynamisch erstellter Persistent Volume Claim (PVC) für das oben erstellte Objekt. fsxz-vol-sc Beachten Sie, dass die zugewiesene Speicherkapazität 1 Gi beträgt. Dies ist FSx für OpenZFS-Volumes erforderlich, wie in den häufig gestellten Fragen zu CSI-Treibern angegeben. Dem Volume wird die volle Kapazität zur Verfügung gestellt, die mit dieser Konfiguration für das Dateisystem bereitgestellt wird. Wenn die Volumenkapazität eingeschränkt werden muss, können Sie dies mithilfe von Benutzer- oder Gruppenkontingenten tun.

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

Konfigurieren Sie einen Pod so, dass er ein Volume mithilfe des Persistent Volume Claim (PVC) bereitstellt 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 für gemeinsam genutzte Modell-Caches

In Szenarien, in denen Sie über eine Umgebung mit mehreren EC2 GPU-Recheninstanzen verfügen und dynamische Workloads haben, die gemeinsamen Modellzugriff über mehrere Knoten und Availability Zones (z. B. Online-Inferenz in Echtzeit mit Karpenter) mit moderaten Leistungs- und Skalierbarkeitsanforderungen erfordern, empfehlen wir die Verwendung eines Amazon Elastic File System (EFS) -Dateisystems als persistentes Volume über den EFS CSI-Treiber. Amazon EFS ist ein vollständig verwaltetes, hochverfügbares und skalierbares Cloud-basiertes NFS-Dateisystem, das EC2 Instances und Container mit gemeinsam genutztem Dateispeicher mit gleichbleibender Leistung ermöglicht, bei denen keine vorherige Bereitstellung von Speicher erforderlich ist. Verwenden Sie EFS als Modellvolume und mounten Sie das Volume als gemeinsam genutztes Dateisystem, indem Sie ein persistentes Volume auf dem EKS-Cluster definieren. Jeder Persistent Volume Claim (PVC), der von einem EFS-Dateisystem unterstützt wird, wird als EFS-Zugriffspunkt zum EFS-Dateisystem erstellt. EFS ermöglicht mehreren Knoten und Pods den Zugriff auf dieselben Modelldateien, sodass keine Daten mit dem Dateisystem jedes Knotens synchronisiert werden müssen. Installieren Sie den EFS-CSI-Treiber, um EFS mit EKS zu integrieren.

Sie können ein Amazon EFS-Dateisystem mit den folgenden Durchsatzmodi bereitstellen:

Leistungsspezifikationen finden Sie unter Amazon EFS-Leistungsspezifikationen.

Überlegungen zur Leistung:

Vollständige Beispiele für die Verwendung des Amazon EFS-Dateisystems als persistentes Volume innerhalb Ihres EKS-Clusters und Ihrer Pods finden Sie in den EFS-CSI-Treiberbeispielen unter GitHub. Überwachen Sie Amazon EFS-Leistungskennzahlen mithilfe von Amazon CloudWatch. Wenn Leistungsengpässe festgestellt werden, passen Sie Ihre Konfigurationsparameter nach Bedarf an.

Verwenden Sie S3 Express One Zone für latenzempfindliche, objektorientierte Workflows

Für latenzempfindliche AI/ML Workloads auf Amazon EKS, wie z. B. umfangreiches Modelltraining, Inferenz oder Hochleistungsanalysen, empfehlen wir die Verwendung von S3 Express One Zone für das Speichern und Abrufen von Modellen mit hoher Leistung. S3 Express One Zone bietet einen hierarchischen Namespace, ähnlich einem Dateisystem, in den Sie einfach in einen Verzeichnis-Bucket hochladen, der sich dafür eignet, „alles hineinzuwerfen“ und gleichzeitig die hohe Geschwindigkeit aufrechtzuerhalten. Dies ist besonders nützlich, wenn Sie an objektorientierte Workflows gewöhnt sind. Wenn Sie eher an Dateisysteme gewöhnt sind (z. B. POSIX-konform), bevorzugen Sie möglicherweise Amazon FSx for Lustre oder OpenZFS. Amazon S3 Express One Zone speichert Daten in einer einzigen Availability Zone (AZ) mithilfe von Verzeichnis-Buckets und bietet eine geringere Latenz als Standard-S3-Buckets, die Daten auf mehrere verteilen. AZs Um optimale Ergebnisse zu erzielen, stellen Sie sicher, dass sich Ihre EKS-Rechenleistung in derselben AZ wie Ihr Express One Zone-Bucket befindet. Weitere Informationen zu den Unterschieden von S3 Express One Zone finden Sie unter Unterschiede bei Directory-Buckets.

Für den Zugriff auf S3 Express One Zone mit Dateisystemsemantik empfehlen wir die Verwendung des Mountpoint S3 CSI-Treibers, der S3-Buckets (einschließlich Express One Zone) als lokales Dateisystem mountet. Auf diese Weise werden Dateioperationen (z. B. Öffnen, Lesen, Schreiben) in S3-API-Aufrufe umgewandelt. Dadurch wird ein Zugriff mit hohem Durchsatz ermöglicht, der für leseintensive Workloads von mehreren Clients und sequentielle Schreibvorgänge auf neue Objekte optimiert ist. Einzelheiten zu den unterstützten Vorgängen und Einschränkungen (z. B. keine vollständige POSIX-Konformität, aber Anhängen und Umbenennen werden in Express One Zone unterstützt) finden Sie in der Dokumentation zur Mountpoint-Semantik.

Vorteile bei der Leistung

Empfohlene Anwendungsfälle

Überlegungen

Die Speicherklasse S3 Express One Zone ist in mehreren Regionen verfügbar und lässt sich in EKS für Workloads integrieren, die Objektzugriff benötigen, ohne auf Speicherplatz warten zu müssen. Weitere Informationen finden Sie unter Erste Schritte mit S3 Express One Zone.