Container Service for Kubernetes:Praktik terbaik untuk optimasi cache data Fluid

Pilih tipe instans ECS untuk sistem cache

Cache terdistribusi menggabungkan kapasitas penyimpanan dan bandwidth di seluruh node. Perkirakan batas atas untuk kluster cache Anda:

• Kapasitas cache tersedia = Kapasitas cache per Worker Pod × Jumlah replika Worker Pod

• Bandwidth cache tersedia = Jumlah replika Worker Pod × min{Bandwidth maksimum yang tersedia pada node ECS tempat Worker Pod berjalan, Throughput I/O media cache yang digunakan oleh Worker Pod}

• Bandwidth aplikasi maksimum teoretis = min{Bandwidth yang tersedia pada node ECS tempat aplikasi Pod berjalan, Bandwidth cache tersedia}

Bandwidth aktual bergantung pada bandwidth node aplikasi dan pola akses (sequential vs. random). Saat beberapa aplikasi Pod mengakses data secara konkuren, bandwidth cache dibagi bersama.

Pilih media cache

Media cache menentukan batas throughput I/O untuk setiap node. Bahkan jika instans ECS memiliki bandwidth jaringan tinggi, media cache yang lambat akan menjadi bottleneck.

Media cache yang tersedia:

Konfigurasikan media cache dan kapasitasnya di spec.tieredstore pada resource Runtime:

spec:
  tieredstore:
    levels:
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 30Gi # Kapasitas cache per replika Worker Pod.
        high: "0.99"
        low: "0.95"

spec:
  tieredstore:
    levels:
      - mediumtype: SSD
        volumeType: emptyDir # emptyDir mengikat siklus hidup cache ke Worker Pod, mencegah data sisa.
        path: /var/lib/fluid/cache
        quota: 100Gi # Kapasitas cache per replika Worker Pod.
        high: "0.99"
        low: "0.95"

spec:
  tieredstore:
    levels:
      - mediumtype: SSD
        volumeType: hostPath
        path: /mnt/disk1,/mnt/disk2 # Jalur mount disk data pada Host.
        quota: 100Gi # Kapasitas cache per replika Pod Worker. Kapasitas didistribusikan secara merata: /mnt/disk1 dan /mnt/disk2 masing-masing mendapatkan 50 GiB.
        high: "0.99"
        low: "0.95"

spec:
  tieredstore:
    levels:
      - mediumtype: SSD
        volumeType: hostPath
        path: /mnt/disk1,/mnt/disk2 # Path pemasangan disk data pada host.
        quota: 100Gi # Kapasitas cache per replika Worker Pod. Kapasitas didistribusikan merata: /mnt/disk1 dan /mnt/disk2 masing-masing mendapat 50 GiB.
        high: "0.99"
        low: "0.95"

Konfigurasikan afinitas penjadwalan antara cache dan aplikasi

Latensi jaringan lintas zona antara aplikasi Pod dan cache Worker Pod menurunkan kinerja akses data. Deploy keduanya dalam zona yang sama.

Secara spesifik:

• Deploy cache Worker Pod dalam zona yang sama bila memungkinkan.

• Deploy aplikasi Pod dalam zona yang sama dengan cache Worker Pod bila memungkinkan.

Tentukan zona cache dengan mengonfigurasi spec.nodeAffinity pada resource Dataset:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - <ZONE_ID> # Zona untuk deploy cache Worker Pod, misalnya cn-beijing-i.

Ini menempatkan cache Worker Pod pada node di zona yang ditentukan. Fluid juga dapat secara otomatis menyuntikkan aturan afinitas agar aplikasi Pod dijadwalkan berdekatan dengan cache Worker Pod. Lihat Optimalkan penjadwalan berdasarkan afinitas cache data.

Sesuaikan parameter prefetch untuk pembacaan sequential file besar

Workload yang melakukan pembacaan sequential penuh pada file besar dapat memperoleh manfaat dari pengaturan prefetch agresif. Contoh umum meliputi:

• Pelatihan AI pada dataset dalam format TFRecord atau Tar

• Startup layanan inferensi memuat file parameter model

• Analitik terdistribusi membaca file Parquet

Prefetch agresif meningkatkan amplifikasi baca. Untuk pembacaan acak atau file kecil, pengaturan ini membuang bandwidth pada data yang tidak digunakan. Gunakan nilai default untuk workload campuran atau pembacaan acak.

Konfigurasi prefetch bervariasi tergantung runtime.

kind: JindoRuntime
metadata:
  ...
spec:
  fuse:
    properties:
      fs.oss.download.thread.concurrency: "200"
      fs.oss.read.buffer.size: "8388608"
      fs.oss.read.readahead.max.buffer.count: "200"
      fs.oss.read.sequence.ambiguity.range: "2147483647" # Sekitar 2 GB.

kind: JuiceFSRuntime
metadata:
  ...
spec:
  fuse:
    options:
      buffer-size: "2048"
      cache-size: "0"
      max-uploads: "150"
  worker:
    options:
      buffer-size: "2048"
      max-downloads: "200"
      max-uploads: "150"
  master:
    resources:
      requests:
        memory: 2Gi
      limits:
        memory: 8Gi
  ...

Hindari pemasangan direktori dengan terlalu banyak file

Sistem cache mempertahankan metadata untuk setiap file dalam direktori yang dipasang. Memasang direktori dengan terlalu banyak file (seperti root sistem penyimpanan skala besar) menghabiskan memori dan CPU berlebihan.

Pasang subdirektori spesifik yang sesuai dengan cakupan data Anda. Buat Dataset terpisah untuk koleksi data berbeda.

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  mounts:
  - mountPoint: oss://<BUCKET>/<PATH1>/<SUBPATH>/
    name: sub-bucket

Beberapa sistem cache menambah kompleksitas operasional. Pilih granularitas yang tepat berdasarkan kebutuhan Anda.

Pertahankan metadata dengan penyimpanan tahan lama

JindoRuntime dan sistem cache serupa menggunakan arsitektur Master-Worker. Pod Master menyimpan metadata file dan status cache untuk penyimpanan backend yang dipasang. Tanpa metadata persisten, restart memerlukan pembangunan ulang status penuh.

Gunakan persistent volume claim (PVC) yang didukung ESSD untuk menyimpan metadata secara tahan lama:

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: sd-dataset
spec:
  ...
  volumes:
    - name: meta-vol
      persistentVolumeClaim:
        claimName: demo-jindo-master-meta
  master:
    resources:
      requests:
        memory: 4Gi
      limits:
        memory: 8Gi
    volumeMounts:
      - name: meta-vol
        mountPath: /root/jindofs-meta
    properties:
      namespace.meta-dir: "/root/jindofs-meta"

Di sini, demo-jindo-master-meta adalah PVC yang telah dibuat sebelumnya dan didukung oleh ESSD. Metadata tetap ada setelah restart Pod dan bermigrasi bersama Pod. Lihat Gunakan JindoRuntime untuk mempertahankan status Pod Master.

Alokasikan resource Pod FUSE

Pod FUSE memasang sistem file FUSE pada node dan melakukan bind-mount ke dalam aplikasi Pod, menyediakan antarmuka POSIX untuk membaca data remote sebagai file lokal.

Untuk mencegah kegagalan pemasangan akibat OOM, hindari menetapkan batas memori Pod FUSE, atau atur mendekati memori alokasi node:

spec:
  fuse:
    resources:
      requests:
        memory: 8Gi
    # limits:
    #   memory: <ECS_ALLOCATABLE_MEMORY>

Jika Pod FUSE di-kill karena OOM, titik pemasangan aplikasi Pod rusak. Restart aplikasi untuk membangun kembali pemasangan, kecuali self-healing FUSE diaktifkan (lihat di bawah).

Aktifkan self-healing FUSE

Secara default, crash FUSE membuat titik pemasangan tidak dapat diakses. Kontainer aplikasi harus direstart untuk memicu kembali bind mount.

Mekanisme self-healing FUSE Fluid secara otomatis memulihkan akses titik pemasangan setelah restart FUSE tanpa memerlukan restart kontainer aplikasi.

Self-healing FUSE memiliki keterbatasan. Aktifkan hanya jika restart mengganggu, seperti lingkungan interaktif Jupyter Notebook atau VS Code.

Lihat Cara mengaktifkan kemampuan auto-recovery FUSE.

Skenario 1: Data read-only tanpa perubahan backend

Kapan digunakan: Satu job pelatihan AI membaca dataset tetap selama beberapa epoch. Cache dihapus setelah pelatihan.

Konfigurasi: Fluid secara default menggunakan mode read-only. Gunakan konfigurasi Dataset default atau atur secara eksplisit:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  # accessModes: ["ReadOnlyMany"] ReadOnlyMany adalah nilai default.
---
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: demo-dataset-warmup
spec:
  ...
  policy: Cron
  schedule: "0 0 * * *" # Pra-ambil data pada pukul 00:00 setiap hari.
  loadMetadata: true # Sinkronkan perubahan metadata dari penyimpanan backend selama pra-ambil.
  target:
  - path: /path/to/warmup # Jalur di penyimpanan backend untuk di-pra-ambil.

Mengatur accessModes: ["ReadOnlyMany"] mencegah penulisan tidak disengaja ke dataset selama pelatihan.

Skenario 2: Data read-only dengan perubahan backend periodik

Kapan digunakan: Data bisnis dikumpulkan setiap hari di penyimpanan backend. Job analisis malam hari memproses data harian tersebut. Hasil ditulis langsung ke penyimpanan backend, melewati cache.

Konfigurasi: Gunakan resource DataLoad dengan kebijakan Cron untuk menyinkronkan perubahan dari penyimpanan backend secara berkala:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  # accessModes: ["ReadOnlyMany"] ReadOnlyMany adalah nilai default.
---
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: demo-dataset-warmup
spec:
  ...
  policy: Cron
  schedule: "0 0 * * *" # Prefetch data setiap hari pukul 00:00.
  loadMetadata: true # Sinkronkan perubahan metadata dari penyimpanan backend selama prefetch.
  target:
  - path: /path/to/warmup # Path di penyimpanan backend untuk prefetch.

loadMetadata: true juga menyegarkan metadata selama setiap prefetch, menjaga konsistensi cache dengan penyimpanan backend.

Skenario 3: Data read-only dengan perubahan backend berbasis event

Kapan digunakan: Pengguna mengunggah model kustom ke penyimpanan backend dan memilihnya untuk inferensi. Cache harus mencerminkan unggahan baru tanpa menunggu sinkronisasi terjadwal.

Konfigurasi: Nonaktifkan cache metadata sisi server dan atur timeout metadata FUSE yang singkat untuk memaksa pemeriksaan penyimpanan backend pada setiap akses.

Menggunakan JindoRuntime:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  mounts:
    - mountPoint: <MOUNTPOINT>
      name: data
      path: /
      options:
        metaPolicy: ALWAYS # Nonaktifkan cache metadata sisi server.
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo-dataset
spec:
  fuse:
    args:
      - -oauto_cache
      # Timeout metadata dalam detik. Mengatur ke 0 memberikan konsistensi kuat tetapi dapat sangat mengurangi efisiensi baca.
      - -oattr_timeout=30
      - -oentry_timeout=30
      - -onegative_timeout=30
      - -ometrics_port=0

Mengatur metaPolicy: ALWAYS menonaktifkan cache metadata sisi server, memaksa setiap akses metadata untuk langsung mengkueri penyimpanan backend.

Mengatur attr_timeout, entry_timeout, dan negative_timeout ke 0 memberikan konsistensi kuat tetapi dapat secara signifikan mengurangi kinerja baca. Nilai 30 (detik) menyeimbangkan kesegaran dan kinerja untuk sebagian besar skenario berbasis event.

Skenario 4: Baca dan tulis di direktori terpisah

Kapan digunakan: Pelatihan terdistribusi skala besar membaca data dari direktori A dan menulis checkpoint ke direktori B setiap epoch. Caching tulisan meningkatkan efisiensi checkpoint.

Konfigurasi: Buat dua Dataset. Atur satu sebagai read-only untuk data pelatihan dan yang lain sebagai read-write untuk checkpoint:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: train-samples
spec:
  ...
  # accessModes: ["ReadOnlyMany"] ReadOnlyMany adalah nilai default.
---
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: model-ckpt
spec:
  ...
  accessModes: ["ReadWriteMany"]

Pasang kedua Dataset ke aplikasi Pod:

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  containers:
  ...
    volumeMounts:
    - name: train-samples-vol
      mountPath: /data/A
    - name: model-ckpt-vol
      mountPath: /data/B
  volumes:
    - name: train-samples-vol
      persistentVolumeClaim:
        claimName: train-samples
    - name: model-ckpt-vol
      persistentVolumeClaim:
        claimName: model-ckpt

Ini mengisolasi dataset pelatihan dari checkpoint. Dataset train-samples read-only mencegah masalah konsistensi terkait penulisan, sedangkan Dataset model-ckpt read-write memungkinkan caching tulisan.

Skenario 5: Baca dan tulis di direktori yang sama

Kapan digunakan: Pengembangan interaktif, seperti ruang kerja Jupyter Notebook online atau VS Code, di mana file sering dibuat, dimodifikasi, dan dihapus dalam direktori bersama.

Konfigurasi: Atur mode akses Dataset ke read-write. Gunakan backend penyimpanan kompatibel POSIX:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: myworkspace
spec:
  ...
  accessModes: ["ReadWriteMany"]

ReadWriteMany memungkinkan akses baca/tulis konkuren ke direktori yang sama oleh beberapa pengguna atau proses.