Speicher - Amazon EKS
Datenmanagement und Speicherung

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, 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, die Ihnen den Einstieg erleichtern.

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:

  • Scratch-SSD-Speicher: Empfohlen für kurzlebige oder kurzlebige Workloads (Stunden), bei denen eine feste Durchsatzkapazität pro TIB bereitgestellt wird.

  • Persistenter SSD-Speicher: Empfohlen für unternehmenskritische, lang andauernde Workloads, die ein Höchstmaß an Verfügbarkeit erfordern, z. B. HPC-Simulationen, Big-Data-Analysen oder Machine-Learning-Schulungen. Mit persistentem SSD-Speicher können Sie sowohl die erforderliche Speicherkapazität als auch die Durchsatzkapazität (pro TIB) konfigurieren.

Überlegungen zur Leistung:

  • Administrativer Pod FSx zur Verwaltung des Lustre-Dateisystems: Konfigurieren Sie einen „administrativen“ Pod, auf dem der Lustre-Client installiert und das FSx Dateisystem gemountet ist. Auf diese Weise steht ein Access Point für die Feinabstimmung des FSx Dateisystems zur Verfügung. Dies gilt auch für Situationen, in denen Sie das FSx Dateisystem mit Ihren ML-Trainingsdaten oder LLM-Modellen vorwärmen müssen, bevor Sie Ihre GPU-Compute-Instances starten. Dies ist besonders wichtig, wenn Ihre Architektur Spot-basierte Amazon EC2 GPU/Compute-Instances verwendet, bei denen Sie den administrativen Pod verwenden können, um die gewünschten Daten „warm“ oder „vorab in das FSx Dateisystem zu laden“, sodass die Daten für die Verarbeitung bereit sind, wenn Sie Ihre Spot-basierten Amazon-Instances ausführen. EC2

  • Elastic Fabric Adapter (EFA): Persistent-SSD-Speicherbereitstellungstypen unterstützen den Elastic Fabric Adapter (EFA), wobei die Verwendung von EFA ideal für GPU-basierte Workloads mit hoher Leistung und Durchsatz ist. Beachten Sie, dass FSx For Lustre NVIDIA GPUDirect Storage (GDS) unterstützt. Dabei handelt es sich bei GDS um eine Technologie, die einen direkten Datenpfad zwischen lokalem oder Remote-Speicher und GPU-Speicher herstellt, um einen schnelleren Datenzugriff zu ermöglichen.

  • Komprimierung: Aktivieren Sie die Datenkomprimierung im Dateisystem, wenn Sie über Dateitypen verfügen, die komprimiert werden können. Dies kann zur Steigerung der Leistung beitragen, da die Datenkomprimierung die Datenmenge reduziert, die zwischen FSx For Lustre-Dateiservern und Speichern übertragen wird.

  • Striping-Konfiguration des Lustre-Dateisystems:

    • Data Striping: Ermöglicht es FSx Luster, die Daten einer Datei auf mehrere Object Storage Targets (OSTs) innerhalb eines Lustre-Dateisystems zu verteilen, wodurch der parallel Zugriff und der Durchsatz maximiert werden, insbesondere für umfangreiche ML-Trainingsaufgaben.

    • Eigenständiges Dateisystem-Striping: Standardmäßig wird mithilfe der PFL-Funktion (Progressive File Layouts) von for Lustre eine 4-Komponenten-Lustre-Striping-Konfiguration für Sie erstellt. FSx In den meisten Szenarien müssen Sie die standardmäßige Anzahl und Größe der PFL-Lustre-Stripes nicht aktualisieren. Wenn Sie das Lustre-Daten-Striping anpassen müssen, können Sie das Lustre-Striping manuell anpassen, indem Sie sich auf die Striping-Parameter eines for Lustre-Dateisystems beziehen. FSx

    • S3-verknüpftes Dateisystem: Dateien, die mit der nativen Amazon S3 S3-Integration (Data Repository Association oder DRA) in das FSx Dateisystem importiert wurden, verwenden nicht das standardmäßige PFL-Layout, sondern das Layout im Dateisystemparameter. ImportedFileChunkSize S3-importierte Dateien, die größer als die sind, ImportedFileChunkSize werden auf mehreren gespeichert, OSTs wobei die Anzahl der Stripes auf dem ImportedFileChunkSize definierten Wert basiert (Standard 1 GiB). Wenn Sie große Dateien haben, empfehlen wir, diesen Parameter auf einen höheren Wert einzustellen.

    • Platzierung: Stellen Sie ein FSx for Lustre-Dateisystem in derselben Availability Zone wie Ihre Rechen- oder GPU-Knoten bereit, um den Zugriff auf die Daten mit der geringsten Latenz zu ermöglichen und Zugriffsmuster zwischen Availability Zones zu vermeiden. Wenn Sie mehrere GPU-Knoten in verschiedenen Availability Zones haben, empfehlen wir die Bereitstellung eines FSx Dateisystems in jeder Availability Zone für den Datenzugriff mit niedriger Latenz.

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.

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:

  • Daten-Caching: Mountpoint for S3 kann Inhalte zwischenspeichern, um Kosten zu senken und die Leistung bei wiederholten Lesevorgängen derselben Datei zu verbessern. Informationen zu den Caching-Optionen und -Parametern finden Sie unter Caching-Konfiguration.

  • Objektgröße: Wenn Sie Dateien mit einer Größe von mehr als 72 GB speichern und darauf zugreifen, finden Sie unter Konfiguration der Mountpoint-Leistung Informationen darüber, wie Sie die Parameter --read-part-size und die --write-part-size Befehlszeilenparameter so konfigurieren, dass sie Ihr Datenprofil und Ihre Workload-Anforderungen erfüllen.

  • Shared-Cache ist für Objekte mit einer Größe von bis zu 1 MB konzipiert. Es unterstützt keine großen Objekte. Verwenden Sie die Option Lokaler Cache, um Objekte in NVMe oder EBS-Volumes auf dem EKS-Knoten zwischenzuspeichern.

  • Gebühren für API-Anfragen: Wenn Sie mit dem Mountpoint für S3 eine große Anzahl von Dateivorgängen ausführen, können die Gebühren für API-Anfragen zu einem Teil der Speicherkosten werden. Um dem entgegenzuwirken, sollten Sie, wenn keine starke Konsistenz erforderlich ist, immer das Zwischenspeichern von Metadaten aktivieren und den metadata-ttl Zeitraum festlegen, in dem die Anzahl der API-Operationen auf S3 reduziert werden soll.

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 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, für die 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:

  • Bursting-Durchsatz: Skaliert den Durchsatz mit der Größe des Dateisystems und eignet sich für unterschiedliche Workloads mit gelegentlichen Bursts.

  • Bereitgestellter Durchsatz: Dedizierter Durchsatz, ideal für konsistente ML-Trainingsaufgaben mit vorhersehbaren Leistungsanforderungen innerhalb bestimmter Grenzen.

  • Elastischer Durchsatz (empfohlen für ML): Automatische Skalierung je nach Arbeitslast, Kosteneffizienz für unterschiedliche ML-Workloads.

Leistungsspezifikationen finden Sie unter Amazon EFS-Leistungsspezifikationen.

Überlegungen zur Leistung:

  • Verwenden Sie Elastic Throughput für unterschiedliche Workloads.

  • Verwenden Sie die Standard-Speicherklasse für aktive ML-Workloads.

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.

Leistungsüberwachung Eine schlechte Festplattenleistung kann das Lesen von Container-Images verzögern, die Latenz beim Starten des Pods erhöhen und den Inferenz- oder Trainingsdurchsatz verringern. Wir empfehlen die folgenden Methoden, um die Leistungskennzahlen des jeweiligen AWS-Speicherservices zu überwachen, falls Engpässe auftreten, und Ihre Konfiguration gegebenenfalls anzupassen.