Akselerasi akses data OSS dengan JindoFS - Container Service for Kubernetes

JindoRuntime adalah execution engine dari JindoFS yang dikembangkan oleh tim Alibaba Cloud E-MapReduce (EMR) dan diimplementasikan dalam C++. JindoRuntime menyediakan manajemen dataset dan caching untuk data Object Storage Service (OSS) dalam kluster Kubernetes. Alibaba Cloud menyediakan dukungan layanan cloud tingkat enterprise untuk JindoFS. Fluid mengelola dan menjadwalkan JindoRuntime untuk memberikan observabilitas, auto scaling, dan portabilitas dataset.

Topik ini memandu Anda melalui proses mengunggah dataset uji ke OSS, membuat Dataset dan JindoRuntime, serta memverifikasi efek akselerasi cache menggunakan pod benchmark.

Batasan

JindoRuntime memerlukan kluster ACK Pro yang menjalankan sistem operasi non-ContainerOS. Komponen ack-fluid saat ini tidak mendukung ContainerOS.
Jika Anda telah menginstal Fluid versi open-source, uninstall terlebih dahulu sebelum men-deploy komponen ack-fluid. Menjalankan keduanya secara bersamaan tidak didukung.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Kluster ACK Pro dengan sistem operasi non-ContainerOS yang menjalankan Kubernetes 1.18 atau lebih baru. Lihat Buat kluster ACK Pro.
Komponen ack-fluid yang telah di-deploy di kluster:
- Jika cloud-native AI suite belum diinstal, aktifkan Fluid acceleration saat menginstal suite tersebut. Lihat Deploy cloud-native AI suite.
- Jika cloud-native AI suite sudah diinstal, buka halaman Cloud-native AI Suite di ACK console dan deploy komponen ack-fluid.
Klien kubectl yang terhubung ke kluster ACK Pro Anda. Lihat Hubungkan ke kluster menggunakan kubectl.
OSS telah diaktifkan. Lihat Aktifkan OSS.

Langkah 1: Unggah data ke OSS

Langkah-langkah berikut menggunakan instance Elastic Compute Service (ECS) yang menjalankan Alibaba Cloud Linux 3.2104 LTS 64-bit untuk mengunggah dataset uji. Untuk sistem operasi lainnya, lihat ossutil dan ossutil 1.0.

Unduh dataset uji ke instance ECS Anda.

wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz

Instal ossutil pada instance ECS.
Buat bucket OSS bernama examplebucket.
```
ossutil64 mb oss://examplebucket
```
Output yang diharapkan:
```
0.668238(s) elapsed
```

Unggah dataset uji ke bucket tersebut.

ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket

Langkah 2: Buat dataset dan JindoRuntime

JindoRuntime membaca kredensial OSS dari Secret Kubernetes, sehingga buat Secret tersebut sebelum membuat Dataset.

Buat file bernama mySecret.yaml dengan konten berikut. Ganti xxx dengan ID AccessKey dan Rahasia AccessKey yang memiliki akses baca ke bucket OSS yang Anda buat di Langkah 1.
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: xxx
  fs.oss.accessKeySecret: xxx
```
Terapkan Secret tersebut. Kubernetes mengenkripsi nilai yang disimpan sehingga tidak terekspos sebagai teks biasa.
```
kubectl create -f mySecret.yaml
```

Buat file bernama resource.yaml dengan konten berikut. File ini mendefinisikan Dataset (yang mengarah ke data OSS Anda) dan JindoRuntime (yang menjalankan kluster caching).

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hadoop
spec:
  mounts:
    - mountPoint: oss://<oss_bucket>/<bucket_dir>
      options:
        fs.oss.endpoint: <oss_endpoint>
      name: hadoop
      path: "/"
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: hadoop
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 2Gi
        high: "0.99"
        low: "0.95"

Tabel berikut menjelaskan parameter utama.

Parameter	Deskripsi	Wajib	Default
`mountPoint`	Path ke underlying file system (UFS) dalam format `oss://<oss_bucket>/<bucket_dir>`. Titik akhir OSS tidak disertakan di sini.	Ya	—
`fs.oss.endpoint`	Titik akhir publik atau internal endpoint bucket OSS. Lihat Region dan titik akhir.	Ya	—
`replicas`	Jumlah worker dalam kluster caching JindoFS.	Ya	—
`mediumtype`	Media penyimpanan cache. Nilai yang valid: `HDD`, `SSD`, `MEM`.	Ya	—
`path`	Path penyimpanan lokal pada node pekerja. Hanya satu path yang diperbolehkan. Wajib saat `mediumtype` bernilai `MEM` untuk menyimpan data seperti log.	Ya	—
`quota`	Ukuran cache maksimum per worker.	Ya	—
`high`	Ambang batas penghapusan cache (watermark tinggi). Saat penggunaan melebihi rasio ini, penghapusan dimulai.	Tidak	—
`low`	Ambang batas retensi cache (watermark rendah). Penghapusan berhenti saat penggunaan turun ke rasio ini.	Tidak	—

Buat Dataset dan JindoRuntime.
```
kubectl create -f resource.yaml
```

Verifikasi bahwa Dataset telah terikat.

kubectl get dataset hadoop

Output yang diharapkan:

NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop        210MiB       0.00B    4.00GiB              0.0%          Bound   1h

Verifikasi bahwa JindoRuntime siap digunakan.

kubectl get jindoruntime hadoop

Output yang diharapkan:

NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
hadoop   Ready          Ready          Ready        4m45s

Verifikasi bahwa persistent volume (PV) dan persistent volume claim (PVC) telah dibuat.

kubectl get pv,pvc

Output yang diharapkan:

NAME                      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/hadoop   100Gi      RWX            Retain           Bound    default/hadoop                           52m

NAME                           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/hadoop   Bound    hadoop   100Gi      RWX                           52m

Dataset dan JindoRuntime siap digunakan ketika semua fase menunjukkan Ready dan status PVC adalah Bound.

Langkah 3: Uji akselerasi data

Deploy pod yang memasang PVC Dataset dan bandingkan waktu baca file sebelum dan sesudah data di-cache.

Buat file bernama app.yaml dengan konten berikut.

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
    - name: demo
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: hadoop
  volumes:
    - name: hadoop
      persistentVolumeClaim:
        claimName: hadoop

Deploy pod tersebut.
```
kubectl create -f app.yaml
```

Buka shell di dalam pod dan periksa ukuran file.

kubectl exec -it demo-app -- bash
du -sh /data/spark-3.0.1-bin-hadoop2.7.tgz

Output yang diharapkan:

210M    /data/spark-3.0.1-bin-hadoop2.7.tgz

Ukur waktu baca awal. Akses ini langsung berasal dari OSS, tanpa cache.
```
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null
```
Output yang diharapkan:
```
real    0m18.386s
user    0m0.002s
sys    0m0.105s
```
Membaca file membutuhkan waktu sekitar 18 detik.

Periksa data yang telah di-cache setelah pembacaan.

kubectl get dataset hadoop

Output yang diharapkan:

NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop   210.00MiB       210.00MiB    4.00GiB        100.0%           Bound   1h

Seluruh 210 MiB kini telah di-cache di penyimpanan lokal.

Hapus dan buat ulang pod untuk membersihkan OS page cache, sehingga pembacaan berikutnya berasal dari cache JindoFS, bukan dari memori.
```
kubectl delete -f app.yaml && kubectl create -f app.yaml
```
Ukur kembali waktu baca dengan data yang disajikan dari cache.
```
kubectl exec -it demo-app -- bash
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null
```
Output yang diharapkan:
```
real    0m0.048s
user    0m0.001s
sys     0m0.046s
```
Dengan cache JindoFS, pembacaan file yang sama selesai dalam 48 milidetik — lebih dari 300 kali lebih cepat dibandingkan akses langsung ke OSS.

(Opsional) Pembersihan

Jika akselerasi data tidak lagi diperlukan, hapus pod, Dataset, dan JindoRuntime.

Hapus pod:

kubectl delete pod demo-app

Hapus Dataset dan JindoRuntime:

kubectl delete dataset hadoop

Langkah selanjutnya

Untuk mengirimkan pekerjaan pelatihan machine learning yang menggunakan data yang dipercepat oleh JindoFS, lihat dokumentasi cloud-native AI suite.
Untuk mengeksplorasi opsi media penyimpanan cache lainnya (HDD, SSD), perbarui bidang mediumtype dan path dalam file resource.yaml.