JindoRuntime是基于阿里云EMR團隊的JindoFS文件系統開發的Fluid運行時引擎。JindoFS基于C++實現,能夠為Fluid提供Dataset數據管理和緩存功能。JindoRuntime支持對Kubernetes環境主機目錄HostPath中的數據進行緩存,從而提升后續數據訪問過程的效率。在混合云場景下,您可以將主機目錄掛載到自建存儲系統,從而實現自建存儲系統的數據訪問加速。本文介紹如何基于JindoRuntime加速主機目錄數據訪問。
前提條件
已創建一個非ContainerOS操作系統的ACK Pro版集群,且集群版本為1.18及以上。具體操作,請參見創建ACK Pro版集群。
重要ack-fluid組件暫不支持在ContainerOS操作系統上使用。
已安裝云原生AI套件并部署ack-fluid組件,且ack-fluid版本為1.0.6以上。
重要若您已安裝開源Fluid,請卸載后再部署ack-fluid組件。
步驟一:準備主機目錄掛載點
JindoRuntime利用分布式緩存來加速主機目錄數據訪問,因此,對于使用JindoFS分布式緩存系統的用戶,需要在Master組件和Worker組件所運行的節點上提前準備好對應的主機目錄。操作示例如下。
執行如下命令,在
/mnt
目錄下創建一個新的子目錄作為主機目錄掛載點。$ mkdir /mnt/demo-remote-fs
執行如下命令,為
cn-beijing.192.168.1.45
和cn-beijing.192.168.2.234
兩個節點創建相應的主機目錄。# 此處兩個節點為本文的示例節點,具體生產環境請替換成您自己的節點名稱。 ssh cn-beijing.192.168.1.45 "mkdir -p /mnt/demo-remote-fs" ssh cn-beijing.192.168.2.234 "mkdir -p /mnt/demo-remote-fs"
執行如下命令,為
cn-beijing.192.168.1.45
和cn-beijing.192.168.2.234
節點打標簽。標簽demo-remote-fs=true
用于設置JindoRuntime的Master和Worker組件的節點調度約束條件。kubectl label node cn-beijing.192.168.1.45 demo-remote-fs=true kubectl label node cn-beijing.192.168.2.234 demo-remote-fs=true
步驟二:創建Fluid Dataset和JindoRuntime
使用如下YAML,創建
dataset.yaml
文件。下方
dataset.yaml
配置文件中包含兩個待創建的Fluid資源對象,分別是Dataset和JindoRuntime。Dataset:所需掛載的主機目錄信息。
JindoRuntime:待啟動的JindoFS分布式緩存系統配置,包括緩存系統Worker組件副本數,以及每個Worker組件最大可用的緩存容量等。
apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: hostpath-demo-dataset spec: mounts: - mountPoint: local:///mnt/demo-remote-fs name: data path: / accessModes: - ReadOnlyMany --- apiVersion: data.fluid.io/v1alpha1 kind: JindoRuntime metadata: name: hostpath-demo-dataset spec: master: nodeSelector: demo-remote-fs: "true" worker: nodeSelector: demo-remote-fs: "true" fuse: nodeSelector: demo-remote-fs: "true" replicas: 2 tieredstore: levels: - mediumtype: MEM volumeType: emptyDir path: /dev/shm quota: 10Gi high: "0.99" low: "0.99"
配置文件中資源對象的詳細參數說明如下。
參數
說明
mountPoint
需要掛載的數據源信息。主機目錄作為數據源,掛載時支持
local://<path>
格式。path
為掛載的主機目錄,需要設置為絕對路徑。nodeSelector
設置JindoRuntime的Master組件、Worker組件、FUSE組件的節點調度約束條件,控制各個組件Pod僅在已準備好主機目錄的節點上運行。
replicas
待啟動的JindoFS緩存系統Worker組件副本數。可根據需要進行調整。
mediumtype
緩存類型。僅支持HDD(機械硬盤)、SSD(固態硬盤)和MEM(內存)三種類型。
關于mediumtype的推薦配置,請參見策略二:選擇緩存介質。
volumeType
緩存介質存儲卷類型。僅支持emptyDir和hostPath兩種類型,默認為hostPath類型。
如果使用內存或本地存儲的系統盤作為緩存介質,推薦選擇emptyDir類型,避免節點上緩存數據殘留,進而影響節點可用性。
如果使用本地存儲的數據盤作為緩存介質,可使用hostPath類型,并配置path指定為宿主機上數據盤的掛載路徑。
關于volumeType的推薦配置,請參見策略二:選擇緩存介質。
path
JindoFS緩存系統Worker的緩存數據存儲目錄。為達到最優的數據訪問性能,建議使用/
dev/shm
或其他掛載了內存文件系統的路徑。quota
單個緩存Worker組件提供的最大緩存容量。可以根據需要進行調整。
執行如下命令,創建Dataset和JindoRuntime資源對象。
kubectl create -f dataset.yaml
執行如下命令,查看Dataset的部署情況。
kubectl get dataset hostpath-demo-dataset
預期輸出:
說明初次啟動JindoFS緩存系統時涉及鏡像拉取過程,因為網絡環境等因素的影響,可能需要耗時2~3分鐘。
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hostpath-demo-dataset 1.98GiB 0.00B 20.00GiB 0.0% Bound 3m54s
Dataset處于Bound狀態,表明JindoFS緩存系統已在集群內正常啟動,應用Pod可正常訪問Dataset中定義的數據。
(可選)步驟三:創建DataLoad執行緩存預熱
由于首次訪問無法命中數據緩存,可能導致應用Pod的數據訪問效率較低。Fluid提供了DataLoad緩存預熱操作提升首次數據訪問的效率。
創建
dataload.yaml
文件,代碼示例如下。apiVersion: data.fluid.io/v1alpha1 kind: DataLoad metadata: name: dataset-warmup spec: dataset: name: hostpath-demo-dataset namespace: default loadMetadata: true target: - path: / replicas: 1
上述資源對象的詳細參數說明如下所示。
參數
說明
dataset.name
需要預熱的Dataset對象名字。
dataset.namespace
需要預熱的Dataset對象所在的命名空間。該命名空間需要與DataLoad對象所在命名空間一致。
loadMetadata
預熱前是否進行元信息同步,對于JindoRuntime須設置為true。
target[*].path
需預熱的存儲目錄或文件,路徑為基于Dataset中聲明的掛載點的相對路徑。
例如,Dataset中掛載的數據源為
pvc://my-pvc/mydata
,那么設置path為/test
將會預熱my-pvc
對應存儲系統下的/mydata/test
目錄。target[*].replicas
需預熱的存儲目錄或文件的緩存數據副本數量。
執行如下命令,創建DataLoad對象。
kubectl create -f dataload.yaml
執行如下命令,查看DataLoad狀態。
kubectl get dataload dataset-warmup
預期輸出:
NAME DATASET PHASE AGE DURATION dataset-warmup pv-demo-dataset Complete 62s 9s
執行如下命令,查看數據緩存狀態。
kubectl get dataset
預期輸出:
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE hostpath-demo-dataset 1.98GiB 1.98GiB 20.00GiB 100.0% Bound 7m24s
DataLoad緩存預熱操作完成后,數據集的已緩存數據量
CACHED
已更新為整個數據集的大小,代表整個數據集已被緩存,緩存百分比CACHED PERCENTAGE
為100.0%。
步驟四:創建應用容器,訪問主機目錄中數據
使用如下YAML,創建
pod.yaml
文件,并修改YAML文件中的claimName名稱與步驟二已創建的Dataset名稱相同。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: hostpath-demo-dataset # 名稱需要與Dataset相同。
執行如下命令,創建應用Pod。
kubectl create -f pod.yaml
執行如下命令,登錄Pod訪問數據。
$ kubectl exec -it nginx bash
預期輸出:
# Nginx Pod中,/data目錄下有一個名為demo-file的文件,大小為2 GB。 $ ls -lh /data total 2.0G -rwxrwxr-x 1 root root 2.0G Jun 9 04:02 demo-file # 執行cat /data/demofile > /dev/null命令,將demofile文件中的內容讀取并寫入/dev/null設備中,用時2.061秒。 $ time cat /data/demofile > /dev/null real 0m2.061s user 0m0.015s sys 0m0.581s
由于數據集中的數據已經全部緩存在了JindoFS緩存系統中,讀取數據時將會從緩存中讀取,而不是從遠程存儲器中讀取,從而減少了網絡傳輸,提升了數據訪問效率。