Accelerate data access in persistent volumes

Prerequisites

• You have created an ACK Pro cluster of v1.18 or later that runs on an operating system other than ContainerOS. For more information, see Create an ACK Pro cluster.

  Important

  The ack-fluid component does not support ContainerOS.

• You have installed the cloud-native AI suite and deployed the ack-fluid component. The version of the ack-fluid component must be 1.0.6 or later.

  Important

  If you have installed open-source Fluid, uninstall it before you deploy the ack-fluid component.

  • If you have not installed the cloud-native AI suite, enable Fluid acceleration during installation. For more information, see Install the cloud-native AI suite.

  • If you have already installed the cloud-native AI suite, deploy ack-fluid from the Cloud-native AI Suite page in the ACK console.

• You have connected to your Kubernetes cluster using kubectl. For more information, see Connect to a Kubernetes cluster by using kubectl.

• You have created the required persistent volume (PV) and persistent volume claim (PVC) for the storage system that you want to access.

  In a Kubernetes environment, the method for creating volumes varies depending on the storage system. To ensure a stable connection between your storage system and the Kubernetes cluster, follow the official documentation for your storage system to prepare the resources.

Step 1: Query the PV and PVC

Run the following command to query the persistent volume and persistent volume claim in your Kubernetes cluster:

kubectl get pvc,pv

Expected output:

NAME                                          STATUS   VOLUME                          CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/demo-pvc                Bound    demo-pv                         5Gi        RWX                           19h

NAME                                             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                           STORAGECLASS   REASON   AGE
persistentvolume/demo-pv                         30Gi       RWX            Retain           Bound    default/demo-pvc                                        19h

The demo-pv persistent volume has a capacity of 30 GiB, supports the RWX access mode, and is bound to the persistent volume claim named demo-pvc. Both resources are ready for use.

Step 2: Create a Dataset and a JindoRuntime

1. Create a file named dataset.yaml with the following content.

   The following dataset.yaml file defines two Fluid resource objects: a Dataset and a JindoRuntime.

   • Dataset: Specifies the persistent volume claim to mount.

   • JindoRuntime: Configures the JindoFS distributed cache system, specifying the number of worker replicas and the maximum cache capacity available for each worker.

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: pv-demo-dataset
   spec:
     mounts:
       - mountPoint: pvc://demo-pvc
         name: data
         path: /
     accessModes:
       - ReadOnlyMany
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: pv-demo-dataset
   spec:
     replicas: 2
     tieredstore:
       levels:
         - mediumtype: MEM
           volumeType: emptyDir
           path: /dev/shm
           quota: 10Gi
           high: "0.9"
           low: "0.8"

   The following table describes the parameters for the resource objects in the configuration file.

   Parameter	Description
   mountPoint	The data source to mount. When you use a persistent volume claim as a data source, you can specify a mount point in the format pvc://<pvc_name>/<path>. The fields are described as follows: pvc_name: The name of the persistent volume claim to mount. The persistent volume claim and the Dataset must be in the same namespace. path: The subdirectory of the volume to mount. This subdirectory must exist for the mount operation to succeed.
   replicas	The number of worker replicas for the JindoFS cache system. You can adjust this value as needed.
   mediumtype	The type of cache medium. Valid values are HDD (Hard Disk Drive), SSD (Solid State Drive), and MEM (Memory). For recommended configurations for mediumtype, see Strategy 2: Select a cache medium.
   volumeType	The volume type of the cache medium. Valid values are emptyDir and hostPath. The default value is hostPath. If you use memory or the local system disk as the cache medium, select emptyDir. This prevents residual cached data on the node from affecting node availability. If you use a local data disk as the cache medium, you can use hostPath and set the path to the mount path of the data disk on the host. For recommended configurations for volumeType, see Strategy 2: Select a cache medium.
   path	The directory where the JindoFS cache system worker stores cached data. For optimal data access performance, use /dev/shm or another path mounted as a memory-based file system.
   quota	The maximum cache capacity for a single cache worker. You can adjust this value as needed.

2. Run the following command to create the Dataset and JindoRuntime resource objects:

   kubectl create -f dataset.yaml

3. Run the following command to check the deployment status of the Dataset:

   kubectl get dataset pv-demo-dataset

   Expected output:

   Note

   When you start the JindoFS cache system for the first time, it pulls images. This process may take 2 to 3 minutes, depending on your network conditions.

   NAME              UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   pv-demo-dataset   10.96GiB         0.00B    20.00GiB         0.0%                Bound   2m13s

   If the Dataset is in the Bound state, the JindoFS cache system is running in the cluster, and application pods can access the data defined in the Dataset.

(Optional) Step 3: Prefetch data with DataLoad

Accessing data for the first time can cause a cache miss, leading to low access efficiency. Fluid provides the DataLoad operation to prefetch data, improving first-time access efficiency.

1. Create a file named dataload.yaml with the following content.

   apiVersion: data.fluid.io/v1alpha1
   kind: DataLoad
   metadata:
     name: dataset-warmup
   spec:
     dataset:
       name: pv-demo-dataset
       namespace: default
     loadMetadata: true
     target:
       - path: /
         replicas: 1

   The following table describes the parameters for this resource object.

   Parameter	Description
   dataset.name	The name of the Dataset to prefetch.
   dataset.namespace	The namespace where the Dataset resides. This must be the same as the namespace of the DataLoad object.
   loadMetadata	Specifies whether to synchronize metadata before prefetching. For JindoRuntime, you must set this to true.
   target[*].path	The directory or file to prefetch. The path is relative to the mount point declared in the Dataset. For example, if the mounted data source in the Dataset is pvc://my-pvc/mydata, setting path to /test prefetches the /mydata/test directory in the storage system corresponding to the my-pvc persistent volume claim.
   target[*].replicas	The number of cache replicas for the directory or file to prefetch.

2. Run the following command to create the DataLoad object:

   kubectl create -f dataload.yaml

3. Run the following command to check the status of the DataLoad object:

   kubectl get dataload dataset-warmup

   Expected output:

   NAME             DATASET           PHASE      AGE   DURATION
   dataset-warmup   pv-demo-dataset   Complete   62s   12s

4. Run the following command to check the data caching status:

   kubectl get dataset

   Expected output:

   NAME              UFS TOTAL SIZE   CACHED     CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   pv-demo-dataset   10.96GiB         10.96GiB   20.00GiB         100.0%              Bound   3m13s

   After the data prefetching operation is complete, the cached data size (CACHED) is equal to the total dataset size, and the cached percentage (CACHED PERCENTAGE) is 100.0%.

Step 4: Create a pod and access data

1. Create a file named pod.yaml with the following content. Set the claimName to the name of the Dataset that you created in Step 2.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx
   spec:
     containers:
       - name: nginx
         image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         command:
         - "bash"
         - "-c"
         - "sleep inf"
         volumeMounts:
           - mountPath: /data
             name: data-vol
     volumes:
       - name: data-vol
         persistentVolumeClaim:
           claimName: pv-demo-dataset # This name must be the same as the Dataset name.

2. Run the following command to create the application pod:

   kubectl create -f pod.yaml

3. Run the following command to log in to the pod and access the data:

   kubectl exec -it nginx bash

   Expected output:

   # In the Nginx pod, an 11 GiB file named demofile is in the /data directory.
   ls -lh /data
   total 11G
   -rw-r----- 1 root root 11G Jul 22  2022 demofile
   
   # The command `cat /data/demofile > /dev/null` reads the content of demofile and writes it to /dev/null. This operation takes 11.004 seconds.
   time cat /data/demofile > /dev/null
   real    0m11.004s
   user    0m0.065s
   sys     0m3.089s

   With the dataset fully cached in the JindoFS cache system, data is read from the cache instead of the remote storage system. This reduces network I/O and improves data access efficiency.