Lindorm S3协议兼容是Lindorm提供的优化海量小文件存储的插件。该插件使用S3协议对外提供访问接口。Fluid是一个开源的Kubernetes原生的分布式数据集编排和加速引擎，主要服务于云原生场景下的数据密集型应用，例如大数据应用、AI应用等。本文介绍如何使用Fluid加速Lindorm S3协议兼容的数据访问。
前提条件
云原生多模数据库 Lindorm实例已开通S3协议兼容功能，具体操作请参见开通S3协议兼容功能。
已创建ACK集群Pro版。如何创建，请参见创建ACK托管集群。
已将通过S3协议访问Lindorm数据的Kubernetes集群地址添加到Lindorm白名单中，具体操作请参见设置白名单。
步骤一：安装Fluid
登录容器服务管理控制台。
在左侧导航栏，选择。
搜索并选择应用ack-fluid。
单击右上角的一键部署。
在弹出的面板中，选择Lindorm关联的ACK集群，然后单击下一步。
在参数配置页面，选择版本号并设置相应参数，然后单击确定。
步骤二：创建Dataset和Runtime
为了方便管理数据，Fluid定义了数据集Dataset（数据集是逻辑上相关的一组数据的集合，会被计算引擎使用）和Runtime（实现数据集安全性、版本管理和数据加速等能力的执行引擎，定义了一系列生命周期的接口），更多信息请参见数据加速Fluid概述。
创建数据集对象。
您需要创建dataset.yaml文件来配置Lindorm S3数据集。以下为dataset.yaml文件的内容。
dataset.yaml文件中定义了一个数据集。数据存储在Lindorm S3中，为了保证Alluxio能成功挂载Lindorm S3的数据，需要在dataset.yaml文件中配置spec参数，建议配置以下参数。
说明Alluxio是一个面向基于云的数据分析和人工智能的开源的数据编排技术，Fluid通过使用Alluxio为云上应用提供数据预热与加速。
apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: lindorm spec: mounts: - mountPoint: s3://<BUCKET>/<DIRECTORY>/ options: aws.accessKeyId: <accessKeyId> aws.secretKey: <secretKey> alluxio.underfs.s3.endpoint: <LINDORM_ENDPOINT> alluxio.underfs.s3.disable.dns.buckets: "true" name: lindorm accessModes: - ReadWriteOnce placement: "Shared"参数
说明
mountPoint
表示挂载UFS的路径，路径格式为
s3://<BUCKET>/<DIRECTORY>。路径中不需要包含endpoint。
aws.accessKeyId
表示AccessKey ID，由于Lindorm S3协议兼容功能不支持鉴权，您可以自定义参数值。
aws.secretKey
表示AccessKey Secret，由于Lindorm S3协议兼容功能不支持鉴权，您可以自定义参数值。
alluxio.underfs.s3.endpoint
宽表引擎的S3协议兼容地址，获取方法请参见查看宽表引擎连接地址。
alluxio.underfs.s3.disable.dns.buckets
表示S3协议兼容功能是否支持Path style的访问方式。目前宽表引擎的S3协议兼容功能仅支持Path style的访问方式，所以固定取值为true。
accessModes
表示支持的读写模式。读写模式包括ReadWriteOnce、ReadOnlyMany、ReadWriteMany和ReadWriteOncePod，默认为ReadOnlyMany。
placement
表示独占节点模式，取值如下：
Exclusive：与不设置此参数的含义相同，表示独占一个节点。
Shared：表示多个Worker可以运行在同一个节点上。
执行以下命令，部署数据集。
kubectl create -f dataset.yaml
创建Runtime对象，示例中使用Alluxio作为Lindorm S3数据集的Runtime。
您需要在runtime.yaml文件中定义Runtime并配置spec参数。以下为runtime.yaml文件的内容。
apiVersion: data.fluid.io/v1alpha1 kind: AlluxioRuntime metadata: name: lindorm spec: replicas: 3 tieredstore: levels: - mediumtype: MEM path: /dev/shm quota: 32Gi high: "0.9" low: "0.8" properties: alluxio.user.file.writetype.default: THROUGH alluxio.user.ufs.block.read.location.policy.deterministic.hash.shards: "3" alluxio.user.ufs.block.read.location.policy: alluxio.client.block.policy.DeterministicHashPolicy参数
说明
replicas
表示Alluxio集群的Worker总数量。
mediumtype
表示缓存类型。定义创建AlluxioRuntime模板样例时，AlluxioRuntime支持的缓存类型为HDD、SSD或者MEM。
path
表示存储路径，只支持单个路径。当选择MEM缓存时，需指定一个本地路径来存储Log等文件。
quota
表示缓存最大容量，单位为GB。
high
表示缓存的高水位线与最大容量的比值。
low
表示缓存的低水位线与最大容量的比值。
properties
Alluxio的配置项，更多说明请参见Properties-List。
执行以下命令，创建AlluxioRuntime。
kubectl create -f runtime.yaml
步骤三：查看各组件状态
执行以下命令，查看AlluxioRuntime的创建情况。
kubectl get alluxioruntime lindorm输出结果如下：
NAME MASTER PHASE WORKER PHASE FUSE PHASE AGE lindorm Ready Ready Ready 52m执行以下命令，查看Pod运行状态。
kubectl get pods输出结果如下，可以看到一个Master，三个Worker正在运行。
NAME READY STATUS RESTARTS AGE lindorm-master-0 2/2 Running 0 54m lindorm-worker-0 2/2 Running 0 54m lindorm-worker-1 2/2 Running 0 54m lindorm-worker-2 2/2 Running 0 54m执行以下命令，查看数据集是否创建成功。
kubectl get dataset lindorm数据集创建成功会输出如下结果，如果没有结果输出表示创建失败。
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE lindorm 0.00B 0.00B 96.00GiB +Inf% Bound 60m执行以下命令，查看存储卷（Persistent Volume，PV）和存储卷声明（Persistent Volume Claim，PVC）是否创建成功。
说明PV是集群内的存储资源，类似节点是集群资源一样。PV独立于Pod的生命周期，可根据不同的StorageClass类型创建不同类型的PV。
PVC是资源的使用者。类似Pod消耗节点资源一样，而PVC消耗PV资源。
kubectl get pv,pvcPV和PVC创建成功会输出如下结果，如果没有结果输出表示创建失败。
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE persistentvolume/default-lindorm 100Gi RWO Retain Bound default/lindorm fluid 10m NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/lindorm Bound default-lindorm 100Gi RWO fluid 10m
步骤四：访问数据
方法一：使用Fluid加速数据访问
您可以通过创建应用容器来使用Fluid加速服务，或者提交机器学习作业来体验加速功能。以下示例中以创建一个应用容器多次访问同一数据，并通过比较访问时间来展示AlluxioRuntime的加速效果。请确保已将Lindorm S3的数据集成功部署到Kubernetes集群的Fluid中。
准备测试数据。执行以下命令生成test文件，文件大小为1000 MB，并将文件上传到Lindorm S3对应的Bucket上。
dd if=/dev/zero of=test bs=1M count=1000创建应用容器体验加速效果。
使用以下YAML文件样例，创建名为app.yaml的文件。
apiVersion: v1 kind: Pod metadata: name: demo-app spec: containers: - name: demo image: nginx volumeMounts: - mountPath: /data name: lindorm volumes: - name: lindorm persistentVolumeClaim: claimName: lindorm执行以下命令，创建应用容器。
kubectl create -f app.yaml执行以下命令，查看数据集的缓存信息。
kubectl get dataset输出结果如下，数据集的缓存为0 B。
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE lindorm 0.00B 0.00B 96.00GiB NaN% Bound 4m19s执行以下命令，查看文件大小。
kubectl exec -it demo-app -- bash du -sh /data/lindorm/test输出结果如下，文件大小为1000 MB。
1000M /data/lindorm/test执行如下命令，查看文件的拷贝时间。
time grep LindormBlob /data/lindorm/test输出结果如下，文件的拷贝时间为55.603秒。
real 0m55.603s user 0m0.469s sys 0m0.353s执行以下命令，查看此时数据集的缓存情况。
kubectl get dataset lindorm输出结果如下，此时1000 MiB的数据已经缓存到Lindorm实例中。
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE lindorm 0.00B 1000.00MiB 96.00GiB +Inf% Bound 11m删除之前的应用容器，并新建相同的应用容器。
说明这样做的目的是为了避免其他因素（例如：Page Cache）对结果造成影响。
kubectl delete -f app.yaml && kubectl create -f app.yaml执行如下命令，再次查看文件拷贝时间。
kubectl exec -it demo-app -- bash time grep LindormBlob /data/lindorm/test输出结果如下：
real 0m0.646s user 0m0.429s sys 0m0.216s可以看出，第二次的文件拷贝时间缩短到0.646秒。这种大幅度的加速效果是因为Fluid具有强大的缓存能力，只要您访问一次某个远程文件，该文件就会被缓存在Fluid中，您之后的访问都不需要读取远程文件，而是直接从Fluid中读取数据。
可选：当您不再使用该数据加速功能时，请执行以下命令清理环境。
kubectl delete -f .
方法二：使用elbencho工具测试Fluid数据访问
elbencho是一个分布式存储测试工具。以下示例中使用elbencho工具来简化数据读写任务的部署流程。请确保已将Lindorm S3的数据集成功部署到Kubernetes集群的Fluid中，只需要执行简单命令便能提交数据读写任务。
准备测试数据。
您需要在Lindorm S3中写入数据，如下示例使用write.yaml文件创建Job任务，利用elbencho镜像建立容器来写数据。示例中写入总数据量为15.625 GB。为了保证数据能及时写入到Lindorm S3，请确保runtime.yaml文件中properties的写模式设置为
alluxio.user.file.writetype.default: THROUGH。apiVersion: batch/v1 kind: Job metadata: name: fluid-elbencho-write spec: template: spec: restartPolicy: OnFailure containers: - name: elbencho image: breuner/elbencho command: ["/usr/bin/elbencho"] args: ["-d","--write", "-t", "10", "-n", "1", "-N", "100", "-s", "16M", "--direct", "-b", "16M", "/data/lindorm"] volumeMounts: - mountPath: /data name: lindorm-vol volumes: - name: lindorm-vol persistentVolumeClaim: claimName: lindorm以下是args参数的说明，其他参数说明请参见elbencho。
参数
说明
-d
创建测试目录。
--write
指定写数据。
-t
指定写数据的线程数。
-n
指定线程创建的目录数。
-N
指定每个目录中创建的文件数。
-s
指定写入的文件大小。
--direct
表示读写过程中无缓存。
-b
指定每次写操作的数据块大小。
/data/lindorm
表示数据写入的位置。
执行写操作并等待完成。
kubectl create -f write.yaml kubectl get pods输出结果如下：
NAME READY STATUS RESTARTS AGE fluid-elbencho-write-stfpq 0/1 Completed 0 3m29s lindorm-fuse-8lgj9 1/1 Running 0 3m29s lindorm-master-0 2/2 Running 0 5m37s lindorm-worker-0 2/2 Running 0 5m10s lindorm-worker-1 2/2 Running 0 5m9s lindorm-worker-2 2/2 Running 0 5m7s清除数据集的缓存，并重启Dataset和AlluxioRuntime。
kubectl delete -f . kubectl create -f dataset.yaml kubectl create -f runtime.yaml体验读数据的加速效果。
使用elbencho多次访问同一数据，比较查询耗时和文件访问的吞吐量来验证Fluid的加速效果。
使用read.yaml文件创建Job任务来读取Lindorm S3中的数据。
apiVersion: batch/v1 kind: Job metadata: name: fluid-elbencho-read spec: template: spec: restartPolicy: OnFailure containers: - name: elbencho image: breuner/elbencho command: ["/usr/bin/elbencho"] args: ["-d","--read", "-t", "10", "-n", "1", "-N", "100", "-s", "16M", "--direct", "-b", "16M", "/data/lindorm"] volumeMounts: - mountPath: /data name: lindorm-vol volumes: - name: lindorm-vol persistentVolumeClaim: claimName: lindorm执行读操作并等待完成。
kubectl create -f read.yaml kubectl get pods输出结果如下：
NAME READY STATUS RESTARTS AGE fluid-elbencho-read-stfpq 0/1 Completed 0 3m29s lindorm-fuse-8lgj9 1/1 Running 0 3m29s lindorm-master-0 2/2 Running 0 5m37s lindorm-worker-0 2/2 Running 0 5m10s lindorm-worker-1 2/2 Running 0 5m9s lindorm-worker-2 2/2 Running 0 5m7s执行以下命令，查看读数据速度。
kubectl logs fluid-elbencho-read-stfpq输出结果如下：
OPERATION RESULT TYPE FIRST DONE LAST DONE ========= ================ ========== ========= MKDIRS Elapsed ms : 33 120 Dirs/s : 30 83 Dirs total : 1 10 --- READ Elapsed ms : 17585 18479 Files/s : 54 54 Throughput MiB/s : 869 865 Total MiB : 15296 16000 Files total : 956 1000 ---执行以下命令，查看数据集状态。
kubectl get dataset lindorm输出结果如下，可以看到所有远程文件被缓存在Alluxio中。
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE lindorm 0.00B 15.63GiB 96.00GiB +Inf% Bound 9m54s删除之前的读操作，并新建相同的读操作。
kubectl delete -f read.yaml && kubectl create -f read.yaml执行如下命令，再次使用elbencho读取Lindorm S3中的数据，由于远程文件都已经被缓存到Fluid中，这次作业耗时大大减少。
kubectl get pods输出结果如下：
NAME READY STATUS RESTARTS AGE fluid-elbencho-read-9gxkk 0/1 Completed 0 9s lindorm-fuse-ckwd9 1/1 Running 0 4m1s lindorm-fuse-vlr6r 1/1 Running 0 3m6s lindorm-master-0 2/2 Running 0 10m lindorm-worker-0 2/2 Running 0 9m28s lindorm-worker-1 2/2 Running 0 9m27s lindorm-worker-2 2/2 Running 0 9m26s执行以下命令，再次查看读数据速度。
kubectl logs fluid-elbencho-read-9gxkk输出结果如下：
OPERATION RESULT TYPE FIRST DONE LAST DONE ========= ================ ========== ========= MKDIRS Elapsed ms : 7 32 Dirs/s : 132 312 Dirs total : 1 10 --- READ Elapsed ms : 8081 9165 Files/s : 110 109 Throughput MiB/s : 1771 1745 Total MiB : 14320 16000 Files total : 895 1000可以看出，文件访问的吞吐量由869 MiB/s提升到1771 MiB/s。因为Fluid具有强大的缓存能力，只要您访问一次某个远程文件，该文件就会被缓存在Fluid中，您之后的访问都不需要读取远程文件，而是直接从Fluid中读取数据，从而加速文件的访问。
可选：当您不再使用该数据加速功能时，请执行以下命令清理环境。
kubectl delete -f .