Boost Kecepatan Akses Tepi OSS & Kurangi Latensi Menggunakan Fluid-ACK Edge - ApsaraDB for SelectDB

Dalam komputasi tepi, setiap akses file OSS melewati jaringan cloud-tepi, yang menimbulkan latensi signifikan. Fluid menyimpan cache data OSS di memori node tepi sehingga pembacaan berulang sepenuhnya menghindari jaringan. Tutorial ini memandu Anda mengunggah set data uji ke OSS, membuat Dataset dan JindoRuntime pada kelompok node tepi, men-deploy Pod uji, serta memverifikasi efek caching—mengurangi waktu baca file 210 MiB dari 18 detik menjadi hanya 48 milidetik.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Kluster ACK Edge yang menjalankan Kubernetes 1.18 atau versi lebih baru. Lihat Create an ACK Edge cluster.
Kelompok node tepi dengan node tepi yang telah ditambahkan. Lihat Create an edge node pool dan Add edge nodes.
Suite AI cloud-native yang telah diinstal dengan komponen ack-fluid dideploy.
Penting
Uninstall instalasi Fluid open-source apa pun sebelum mendeploy ack-fluid.
- Jika suite belum dideploy: aktifkan Fluid di bawah Data Access Acceleration saat mendeploy suite tersebut.
- Jika suite sudah dideploy: buka halaman Cloud-native AI Suite di ACK console dan deploy ack-fluid.
kubectl terhubung ke kluster ACK. Lihat Dapatkan kubeconfig kluster dan sambungkan ke kluster menggunakan kubectl.
Layanan Penyimpanan Objek (OSS) yang telah diaktifkan. Lihat Activate OSS.

Langkah 1: Unggah data ke OSS

Unduh set data uji ke instans Elastic Compute Service (ECS):

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

Unggah set data ke bucket OSS.
Penting
Langkah-langkah berikut menggunakan instans ECS yang menjalankan Alibaba Cloud Linux 3.2104 LTS 64-bit. Untuk sistem operasi lain, lihat ossutil dan ossutil 1.0.
1. Install ossutil.
2. Buat bucket bernama examplebucket:
```
ossutil mb oss://examplebucket
```
  Output yang diharapkan:
```
0.668238(s) elapsed
```
3. Unggah set data uji ke examplebucket:
```
ossutil cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket
```

Langkah 2: Buat Dataset dan JindoRuntime

Dalam kluster ACK Edge, baik manajemen node tepi maupun akses OSS menggunakan jaringan cloud-tepi. Deploy Dataset dan JindoRuntime ke kelompok node yang sama dengan beban kerja Anda agar akses data tetap berada dalam kelompok node tersebut dan bandwidth tersedia untuk saluran manajemen.

Buat file bernama mySecret.yaml dengan konten berikut. Ganti xxx dengan ID AccessKey dan Rahasia AccessKey yang digunakan pada Langkah 1.
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: xxx
  fs.oss.accessKeySecret: xxx
```
Buat Secret tersebut. Kubernetes mengenkripsi Secret untuk mencegah kredensial disimpan sebagai teks biasa.
```
kubectl create -f mySecret.yaml
```

Buat file bernama resource.yaml dengan konten berikut:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hadoop
spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: alibabacloud.com/nodepool-id
            operator: In
            values:
              - npxxxxxxxxxxxxxx
  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:
  nodeSelector:
    alibabacloud.com/nodepool-id: npxxxxxxxxxxxxxx
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 2Gi
        high: "0.99"
        low: "0.95"

Templat ini membuat dua resource:

Dataset yang menentukan path OSS untuk dipasang dan mereferensikan Secret untuk kredensial. Bidang nodeAffinity mengikat Dataset ke kelompok node target.
JindoRuntime yang meluncurkan kluster JindoFS untuk caching data. Atur nodeSelector ke kelompok node yang sama dengan nodeAffinity pada Dataset.

Parameter utama:

Parameter	Deskripsi
`mountPoint`	Path OSS yang akan dipasang, dalam format `oss://<oss_bucket>/<bucket_dir>`. Harus mengarah ke direktori, bukan file. Titik akhir ditentukan secara terpisah.
`fs.oss.endpoint`	Titik akhir publik atau pribadi dari bucket OSS. Lihat Regions and endpoints.
`replicas`	Jumlah worker dalam kluster JindoFS.
`mediumtype`	Jenis penyimpanan cache. Nilai yang valid: `HDD`, `SDD`, `MEM`.
`path`	Path penyimpanan lokal untuk data cache. Wajib diisi jika `mediumtype` bernilai `MEM`.
`quota`	Ukuran maksimum cache. Satuan: GiB.
`high`	Batas atas kapasitas penyimpanan.
`low`	Batas bawah kapasitas penyimpanan.

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

Verifikasi 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 JindoRuntime siap digunakan:

kubectl get jindoruntime hadoop

Output yang diharapkan:

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

Verifikasi volume persisten (PV) dan klaim volume persisten (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 menampilkan Ready dan status PVC menunjukkan Bound.

Langkah 3: Uji percepatan akses data

Deploy Pod uji ke kelompok node yang sama, baca file dua kali, lalu bandingkan waktu aksesnya untuk mengamati efek caching JindoFS.

Buat file bernama app.yaml dengan konten berikut:

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  nodeSelector:
    alibabacloud.com/nodepool-id: npxxxxxxxxxxxxx
  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

Catatan

Atur nodeSelector ke ID kelompok node yang sama seperti yang digunakan pada Langkah 2.

Deploy Pod tersebut:
```
kubectl create -f app.yaml
```

Verifikasi file dapat diakses dan periksa ukurannya:

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 pertama. Karena data belum di-cache, JindoFS mengambil file dari OSS melalui jaringan cloud-tepi—pembacaan ini akan lambat.
```
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
```

Konfirmasi bahwa file kini telah sepenuhnya di-cache:

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

Dataset menunjukkan 100% di-cache, artinya seluruh data disimpan di worker JindoFS pada kelompok node tersebut.

Buat ulang Pod untuk membersihkan cache halaman Linux. Hal ini memastikan pembacaan kedua hanya menggunakan cache JindoFS, bukan cache tingkat OS.
```
kubectl delete -f app.yaml && kubectl create -f app.yaml
```
Ukur waktu baca kedua:
```
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
```
Pembacaan kedua selesai dalam 48 milidetik—lebih dari 300 kali lebih cepat—karena JindoFS menyajikan data dari memori lokal node, bukan mengambilnya dari OSS.

(Opsional) Bersihkan lingkungan

Hapus Pod uji:

kubectl delete pod demo-app

Hapus Dataset dan JindoRuntime:

kubectl delete dataset hadoop