备案控制台
文档
产品文档
输入文档关键字查找
首页 容器服务 Kubernetes 版 ACK 云原生AI套件 操作指南 弹性数据集 高级功能 通过配置JindoRuntime实现Master组件状态持久化存储

通过配置JindoRuntime实现Master组件状态持久化存储

更新时间：
一键部署
产品详情
相关技术圈
我的收藏

为避免运行Master组件的容器重启造成缓存系统元数据丢失，Fluid支持通过配置JindoRuntime，持久化存储JindoFS Master组件的元数据，从而提升JindoFS分布式缓存集群的可用性。

功能介绍

JindoFS来源于阿里云EMR团队，是基于C++实现的支撑Dataset数据管理和数据缓存的执行引擎，同时支持对OSS、OSS-HDFS和PVC等多种数据源提供数据缓存服务。更多信息，请参见JindoData概述。

JindoFS采用Master-Worker架构，Master组件和Worker组件均容器化运行于集群中，其中Master组件负责记录缓存数据元信息和挂载点信息等，Worker组件负责维护缓存数据信息。当运行Master组件的容器重启或重新调度时，Master组件缓存的数据元信息和挂载点信息可能会丢失，从而导致JindoFS分布式缓存集群不可用。您可以通过配置Fluid JindoRuntime，使JindoFS Master组件将元信息持久化存储于Kubernetes存储卷中，提高JindoFS分布式缓存集群的可用性。

前提条件

步骤一：准备云盘存储卷

  1. 创建pvc.yaml文件，配置云盘存储卷PVC。

    说明

    如果您需要为云盘存储卷PVC配置更多参数，请参见通过kubectl命令行使用云盘动态存储卷。

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-jindo-master-meta
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: alicloud-disk-topology-alltype
  resources:
    requests:
      storage: 30Gi

  2. 执行以下命令，创建PVC资源。

    kubectl create -f pvc.yaml

    预期输出：

    persistentvolumeclaim/demo-jindo-master-meta created

步骤二：创建Dataset和JindoRuntime

  1. 创建secret.yaml文件，保存用于RAM访问OSS Bucket的AccessKeyId（AK）和AccessKeySecret（SK）。

    apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ****** # 请输入AccessKeyId。
  fs.oss.accessKeySecret: ****** # 请输入AccessKeySecret。

  2. 执行以下命令，创建Secret资源。

    kubectl create -f secret.yaml

    预期输出：

    secret/access-key created

  3. 创建dataset.yaml文件，配置Fluid Dataset资源和Fluid JindoRuntime资源的参数信息。

    apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo
spec:
  mounts: 
    - mountPoint: oss://<OSS_BUCKET>/<BUCKET_DIR>
      name: demo
      path: /
      options:
        fs.oss.endpoint: <OSS_BUCKET_ENDPOINT>
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: access-key
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: access-key
              key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo
spec:
  replicas: 2
  volumes:
    - name: meta-vol
      persistentVolumeClaim:
        claimName: demo-jindo-master-meta
  master:
    volumeMounts:
      - name: meta-vol
        mountPath: /root/jindofsx-meta
    properties:
      namespace.meta-dir: "/root/jindofsx-meta"
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 12Gi
        high: "0.99"
        low: "0.99"

    与本功能相关的关键参数说明如下：

    参数

    说明

    JindoRuntime

    volumes

    配置JindoRuntime各组件可挂载的存储卷信息。您需要选择步骤一：准备云盘存储卷中创建的云盘存储卷PVC。

    master.volumeMounts

    配置运行JindoRuntime Master组件的容器所挂载的存储卷和挂载路径。

    master.properties

    配置JindoRuntime Master组件的详细参数信息。为启用Master组件的元信息持久化存储能力，需指定namespace.meta-dir: <path>，其中<path>为master.volumeMounts中指定的存储卷挂载路径（即mountPath参数值）。

  4. 执行以下命令，创建JindoRuntime和Dataset。

    kubectl create -f dataset.yaml

    预期输出：

    dataset.data.fluid.io/demo created
jindoruntime.data.fluid.io/demo created

  5. 执行以下命令，查看Dataset部署情况。

    kubectl get dataset

    预期输出：

    NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
demo 531.89MiB      0.00B  24.00GiB       0.0%              Bound 5m35s

    PHASE字段变为Bound状态，表明Dataset和JindoRuntime已部署成功。Fluid将自动为Bound状态的Dataset创建同名PVC，应用Pod可通过挂载该PVC，访问Dataset挂载点（Dataset.spec.mountPoint）中指定的数据。

步骤三：验证Master组件状态持久化存储功能

在本步骤中，通过对节点添加污点模拟运行Master组件的Pod重新调度的场景，以验证本功能是否正确配置并生效。

  1. 创建pod.yaml文件，用于挂载PVC。

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: demo

  2. 执行以下命令，在Kubernetes集群中部署Nginx应用。

    kubectl create -f pod.yaml

    预期输出：

    pod/nginx created

  3. 执行以下命令，从应用Pod中访问数据。

    kubectl exec -it nginx -- ls /data

    预期输出Dataset挂载点（Dataset.spec.mountPoint）中指定的OSS文件系统中的数据。

  4. 执行以下命令，获取运行JindoFS Master组件的Pod所在的节点。

    master_node=$(kubectl get pod -o wide | awk '/demo-jindofs-master-0/ {print $7}')

  5. 执行以下命令，通过污点阻止新的Pod调度至步骤4中查询的节点。

    kubectl taint node $master_node test-jindofs-master=reschedule:NoSchedule

    预期输出：

    node/cn-beijing.192.168.xx.xx tainted

  6. 执行以下命令，删除并自动重建JindoFS Master组件的Pod。

    kubectl delete pod demo-jindofs-master-0

    预期输出：

    pod "demo-jindofs-master-0" deleted

    此时，重建的Pod（demo-jindofs-master-0）将会被调度到集群中的另一个节点上。但是由于运行JindoFS Master组件的Pod挂载了存储卷，因此Master组件可以通过存储卷恢复到Pod被重建前的状态。

    说明

    由于云盘存储卷不支持跨可用区挂载，因此在使用云盘作为持久化存储时，重建的Pod只能被调度到同可用区的其他节点上。请确保集群中至少包含另一个与重建前Pod同可用区的ECS节点。

  7. 执行以下命令，重建应用Pod。

    kubectl delete -f pod.yaml && kubectl create -f pod.yaml

    预期输出：

    pod "nginx" deleted
pod/nginx created

  8. 执行以下命令，从重建后的应用Pod中再次访问数据。

    kubectl exec -it nginx -- ls /data

    预期输出Dataset挂载点（Dataset.spec.mountPoint）中指定的OSS文件系统中的数据。

步骤四：环境清理

  1. 执行以下命令，删除Pod。

    kubectl delete -f pod.yaml

    预期输出：

    pod "nginx" deleted

  2. 执行以下命令，删除为节点添加的污点。

    kubectl taint node $master_node test-jindofs-master-

    预期输出：

    node/cn-beijing.192.168.xx.xx untainted

  3. （可选）依次执行以下命令，清理云盘存储卷资源。

    重要

    • 本示例中创建的云盘存储卷将持续产生费用。如果您不再需要使用该数据加速功能，请及时清理环境。关于云盘存储卷产生的费用，请参见云盘存储卷概述。

    • 清理前，确保没有正在使用该数据集并进行I/O操作的应用Pod。

    kubectl delete -f dataset.yaml
kubectl delete -f pvc.yaml

文档推荐
  • 本页导读 （1）
文档反馈