Penyimpanan - Amazon EKS
Manajemen dan Penyimpanan Data

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Penyimpanan

Manajemen dan Penyimpanan Data

Menerapkan Model AI ke Pod Menggunakan Driver CSI

Beban kerja AI/ML seringkali memerlukan akses ke artefak model besar (misalnya, bobot terlatih, konfigurasi), dan pod memerlukan cara yang andal dan dapat diskalakan untuk mengaksesnya tanpa menyematkannya dalam gambar kontainer, yang dapat meningkatkan ukuran gambar dan waktu tarik registri Container. Untuk mengurangi overhead operasional pengelolaan volume mount, kami merekomendasikan penerapan model AI ke pod dengan memasang layanan penyimpanan Amazon (misalnya, S3, untuk FSx Lustre, EFS) sebagai Persistent Volume (PVs) menggunakan driver CSI masing-masing. Untuk detail implementasi, lihat topik selanjutnya di bagian ini.

Optimalkan Penyimpanan untuk Cache Model ML di EKS

Memanfaatkan solusi penyimpanan yang optimal sangat penting untuk meminimalkan latensi start-up pod dan aplikasi, mengurangi penggunaan memori, mendapatkan tingkat kinerja yang diinginkan untuk mempercepat beban kerja, dan memastikan skalabilitas beban kerja ML. Beban kerja ML sering bergantung pada file model (bobot), yang bisa berukuran besar dan memerlukan akses bersama ke data di seluruh pod atau node. Memilih solusi penyimpanan yang optimal bergantung pada karakteristik beban kerja Anda, seperti efisiensi simpul tunggal, akses multi-node, persyaratan latensi, kendala biaya, dan juga persyaratan integrasi data (seperti dengan repositori data Amazon S3). Kami merekomendasikan untuk membandingkan solusi penyimpanan yang berbeda dengan beban kerja Anda untuk memahami mana yang memenuhi persyaratan Anda, dan kami telah menyediakan opsi berikut untuk membantu Anda mengevaluasi berdasarkan persyaratan beban kerja Anda.

Driver EKS CSI mendukung layanan AWS Storage berikut, masing-masing memiliki driver CSI sendiri dan dilengkapi dengan kekuatan mereka sendiri untuk alur kerja AI dan ML:

Pilihan layanan AWS Storage bergantung pada arsitektur penerapan, skala, persyaratan kinerja, dan strategi biaya Anda. Driver CSI penyimpanan harus diinstal pada kluster EKS Anda, yang memungkinkan driver CSI untuk membuat dan mengelola Persistent Volume (PV) di luar siklus hidup Pod. Dengan menggunakan driver CSI, Anda dapat membuat definisi PV dari layanan AWS Storage yang didukung sebagai sumber daya kluster EKS. Pod kemudian dapat mengakses volume penyimpanan ini untuk volume datanya melalui pembuatan Persistent Volume Claim (PVC) untuk PV. Bergantung pada layanan penyimpanan AWS dan skenario penerapan Anda, satu PVC (dan PV terkait) dapat dilampirkan ke beberapa Pod untuk beban kerja. Misalnya, untuk pelatihan ML, data pelatihan bersama disimpan di PV dan diakses oleh beberapa Pod; untuk inferensi online real-time, model LLM di-cache pada PV dan diakses oleh beberapa Pod. Contoh file YAMM PV dan PVC untuk layanan AWS Storage disediakan di bawah ini untuk membantu Anda memulai.

Skenario: Beberapa instans GPU beban kerja

Amazon FSx for Lustre: Dalam skenario di mana Anda memiliki beberapa lingkungan instans komputasi EC2 GPU dengan beban kerja dinamis throughput bandwidth tinggi yang sensitif terhadap latensi, seperti pelatihan terdistribusi dan penayangan model, dan Anda memerlukan integrasi repositori data Amazon S3 asli, kami merekomendasikan Amazon untuk Lustre. FSx FSx untuk Lustre menyediakan sistem file paralel kinerja tinggi yang dikelola sepenuhnya yang dirancang untuk beban kerja intensif komputasi seperti komputasi kinerja tinggi (HPC), Machine Learning.

Anda dapat Menginstal driver FSx for Lustre CSI untuk memasang sistem FSx file di EKS sebagai Persistent Volume (PV), lalu menerapkan sistem file Lustre sebagai cache kinerja tinggi mandiri atau sebagai sistem file terkait S3 FSx untuk bertindak sebagai cache kinerja tinggi untuk data S3, memberikan throughput cepat dan tinggi untuk akses data di seluruh instance komputasi GPU Anda. I/O FSx untuk Lustre dapat digunakan dengan opsi penyimpanan Scratch-SSD atau persistent-SSD:

  • Penyimpanan Scratch-SSD: Direkomendasikan untuk beban kerja yang bersifat sementara atau berumur pendek (jam), dengan kapasitas throughput tetap per TIB yang disediakan.

  • Penyimpanan SSD persisten: Direkomendasikan untuk beban kerja yang kritis dan berjalan lama yang memerlukan tingkat ketersediaan tertinggi, misalnya simulasi HPC, analisis data besar, atau pelatihan Machine Learning. Dengan penyimpanan SSD persisten, Anda dapat mengonfigurasi kapasitas penyimpanan dan kapasitas throughput (per-TIB) yang diperlukan.

Pertimbangan kinerja:

  • Pod administratif FSx untuk mengelola sistem berkas Lustre: Konfigurasikan Pod “administratif” yang memiliki klien lustre diinstal dan sistem berkas terpasang. FSx Ini akan memungkinkan titik akses untuk mengaktifkan fine-tuning sistem FSx file, dan juga dalam situasi di mana Anda perlu melakukan pra-pemanasan sistem FSx file dengan data pelatihan ML atau model LLM Anda sebelum memulai instance komputasi GPU Anda. Hal ini sangat penting jika arsitektur Anda menggunakan instans GPU/komputasi EC2 Amazon berbasis Spot, di mana Anda dapat memanfaatkan Pod administratif untuk “menghangatkan” atau “memuat” data yang diinginkan ke dalam FSx sistem file, sehingga data siap diproses saat Anda menjalankan instans Amazon berbasis Spot. EC2

  • Elastic Fabric Adapter (EFA): Jenis penyebaran penyimpanan SSD persisten mendukung Elastic Fabric Adapter (EFA), di mana penggunaan EFA sangat ideal untuk kinerja tinggi dan beban kerja berbasis GPU berbasis throughput. Perhatikan bahwa FSx untuk Lustre mendukung NVIDIA GPUDirect Storage (GDS), di mana GDS adalah teknologi yang menciptakan jalur data langsung antara penyimpanan lokal atau jarak jauh dan memori GPU, untuk memungkinkan akses data yang lebih cepat.

  • Kompresi: Aktifkan kompresi data pada sistem file jika Anda memiliki jenis file yang dapat dikompresi. Ini dapat membantu meningkatkan kinerja karena kompresi data mengurangi jumlah data yang ditransfer antara FSx untuk server file Lustre dan penyimpanan.

  • Konfigurasi striping sistem file lustre:

    • Data striping: Memungkinkan Luster FSx untuk mendistribusikan data file di beberapa Object Storage Target (OSTs) dalam sistem file Lustre memaksimalkan akses paralel dan throughput, terutama untuk pekerjaan pelatihan ML. skala besar.

    • Pengupasan sistem file mandiri: Secara default, konfigurasi striping Lustre 4 komponen dibuat untuk Anda melalui kemampuan tata letak file Progresif (PFL) untuk Lustre. FSx Dalam sebagian besar skenario, Anda tidak perlu memperbarui hitungan/ukuran garis PFL Lustre default. Jika Anda perlu menyesuaikan striping data Lustre, maka Anda dapat secara manual menyesuaikan lustre striping dengan mengacu pada parameter striping dari sistem file for Lustre. FSx

    • Sistem File Tertaut S3: File yang diimpor ke sistem FSx file menggunakan integrasi Amazon S3 asli (Data Repository Association atau DRA) tidak menggunakan tata letak PFL default, melainkan menggunakan tata letak dalam parameter sistem file. ImportedFileChunkSize File yang diimpor S3 yang lebih besar dari file ImportedFileChunkSize akan disimpan di beberapa OSTs dengan jumlah garis berdasarkan nilai yang ImportedFileChunkSize ditentukan (default 1GiB). Jika Anda memiliki file besar, kami sarankan menyetel parameter ini ke nilai yang lebih tinggi.

    • Penempatan: Menerapkan sistem file FSx for Lustre di Availability Zone yang sama dengan node komputasi atau GPU Anda untuk mengaktifkan akses latensi terendah ke data, hindari pola akses akses lintas Availability Zone. Jika Anda memiliki beberapa node GPU yang terletak di Availability Zone yang berbeda, sebaiknya gunakan sistem FSx file di setiap Availability Zone untuk akses data latensi rendah.

Contoh

Definisi Persistent Volume (PV) untuk sistem file FSx for Lustre, menggunakan Static Provisioning (di mana FSx instance telah disediakan).

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]

Contoh

Definisi Klaim Volume Persisten untuk PV disebutfsx-pv:

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

Contoh

Konfigurasikan pod untuk menggunakan Klaim Volume Persisten darifsx-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

Untuk contoh selengkapnya, lihat FSx untuk Contoh Pengemudi Lustre di. GitHub

Skenario: Beban kerja instance GPU tunggal

Mountpoint untuk Amazon S3 dengan Driver CSI: Anda dapat memasang bucket S3 sebagai volume di pod Anda menggunakan driver Mountpoint untuk Amazon S3 CSI. Metode ini memungkinkan kontrol akses berbutir halus di mana Pod dapat mengakses bucket S3 tertentu. Setiap pod memiliki instans mountpoint dan cache lokal (5-10GB) sendiri, mengisolasi kinerja pemuatan dan pembacaan model antar pod. Pengaturan ini mendukung otentikasi tingkat pod dengan IAM Roles for Service Accounts (IRSA) dan versi model independen untuk model atau pelanggan yang berbeda. Trade-off adalah peningkatan penggunaan memori dan lalu lintas API, karena setiap pod mengeluarkan panggilan API S3 dan mempertahankan cache-nya sendiri.

Contoh sebagian contoh penerapan Pod YAMB dengan 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

Pertimbangan kinerja:

  • Caching data: Mountpoint untuk S3 dapat menyimpan konten cache untuk mengurangi biaya dan meningkatkan kinerja untuk pembacaan berulang ke file yang sama. Lihat konfigurasi Caching untuk opsi dan parameter caching.

  • Ukuran bagian objek: Saat menyimpan dan mengakses file berukuran lebih dari 72GB, lihat Mengonfigurasi kinerja Mountpoint untuk memahami cara mengonfigurasi parameter --write-part-size baris perintah --read-part-size dan profil data untuk memenuhi persyaratan profil data dan beban kerja Anda.

  • Shared-cache dirancang untuk objek berukuran hingga 1MB. Itu tidak mendukung benda besar. Gunakan opsi cache lokal untuk caching objek dalam NVMe atau volume EBS pada node EKS.

  • Biaya permintaan API: Saat melakukan sejumlah besar operasi file dengan Mountpoint untuk S3, biaya permintaan API dapat menjadi bagian dari biaya penyimpanan. Untuk mengurangi ini, jika konsistensi yang kuat tidak diperlukan, selalu aktifkan caching metadata dan atur metadata-ttl periode untuk mengurangi jumlah operasi API ke S3.

Untuk detail selengkapnya, lihat Mountpoint untuk Driver CSI Amazon S3 di dokumentasi resmi Amazon EKS. Kami menyarankan untuk memantau metrik kinerja Amazon S3 dengan metrik CloudWatch Amazon jika terjadi kemacetan dan menyesuaikan konfigurasi Anda jika diperlukan.

Amazon EFS untuk cache model bersama

Dalam skenario di mana Anda memiliki beberapa lingkungan instans komputasi EC2 GPU dan memiliki beban kerja dinamis yang memerlukan akses model bersama di beberapa node dan Availability Zone (misalnya, inferensi online real-time dengan Karpenter) dengan kinerja moderat dan kebutuhan skalabilitas, sebaiknya gunakan sistem file Amazon Elastic File System (EFS) sebagai Volume Persisten melalui Driver EFS CSI. Amazon EFS adalah sistem file NFS berbasis cloud yang dikelola sepenuhnya, sangat tersedia, dan dapat diskalakan yang memungkinkan EC2 instance dan wadah dengan penyimpanan file bersama, dengan kinerja yang konsisten, dan di mana tidak diperlukan penyediaan penyimpanan di muka. Gunakan EFS sebagai volume model, dan pasang volume sebagai sistem file bersama dengan mendefinisikan Volume Persisten pada kluster EKS. Setiap Klaim Volume Persisten (PVC) yang didukung oleh sistem file EFS dibuat sebagai titik akses EFS ke sistem file EFS. EFS memungkinkan beberapa node dan pod untuk mengakses file model yang sama, menghilangkan kebutuhan untuk menyinkronkan data ke setiap sistem file node. Instal driver EFS CSI untuk mengintegrasikan EFS dengan EKS.

Anda dapat menerapkan sistem file Amazon EFS dengan mode throughput berikut:

  • Meledak Throughput: Timbangan throughput dengan ukuran sistem file, cocok untuk berbagai beban kerja dengan semburan sesekali.

  • Throughput yang Disediakan: Throughput khusus, ideal untuk pekerjaan pelatihan ML yang konsisten dengan kebutuhan kinerja yang dapat diprediksi dalam batasnya.

  • Throughput Elastis (direkomendasikan untuk ML): Secara otomatis menskalakan berdasarkan beban kerja, efektivitas biaya untuk berbagai beban kerja ML.

Untuk melihat spesifikasi performa, lihat Spesifikasi performa Amazon EFS.

Pertimbangan kinerja:

  • Gunakan Elastic Throughput untuk berbagai beban kerja.

  • Gunakan kelas penyimpanan Standar untuk beban kerja MS aktif.

Untuk contoh lengkap penggunaan sistem file Amazon EFS sebagai Volume persisten dalam cluster EKS dan Pod Anda, lihat Contoh Driver EFS CSI di GitHub.

Kinerja pemantauan Kinerja disk yang buruk dapat menunda pembacaan gambar kontainer, meningkatkan latensi startup pod, dan menurunkan inferensi atau throughput pelatihan. Kami merekomendasikan metode berikut untuk memantau metrik kinerja masing-masing layanan AWS Storage jika terjadi kemacetan dan menyesuaikan konfigurasi Anda jika diperlukan.