容器服务 Kubernetes 版 ACK：Fluid数据缓存优化策略最佳实践

策略一：选择缓存系统ECS机型

性能估算

分布式文件缓存系统能够聚合多个节点上的存储资源和带宽资源，为上层应用提供更大的缓存容量和更高的可用带宽。关于缓存容量、可用带宽以及应用数据访问的最大带宽的理论上限值可根据以下公式估算：

• 缓存可用容量 = 每个分布式缓存Worker Pod提供的缓存容量 * 分布式缓存Worker Pod副本数

• 缓存可用带宽 = 分布式缓存Worker Pod副本数 * min{Worker Pod所在ECS节点的最大可用带宽, Worker Pod使用的缓存介质I/O吞吐}。另外，缓存可用带宽不代表数据访问过程中的实际带宽，数据访问过程的实际带宽受客户端ECS节点可用带宽，以及数据访问模式（顺序读、随机读）影响。

• 应用Pod数据访问过程的理论最大带宽 = min{应用Pod所在ECS节点的可用带宽，缓存可用带宽}。另外，当多个应用Pod并发访问数据时，缓存可用带宽将被这些应用Pod共享占用。

示例

例如，在ACK集群中扩容2台ecs.g7nex.8xlarge规格的ECS实例用于构建分布式缓存集群，分布式缓存集群包含2个缓存Worker Pod，每个Pod设置的缓存容量为100 GiB内存，两个Pod分别运行于两台ECS实例上。应用Pod部署于一台ecs.gn7i-c8g1.2xlarge（8 vCPU，30 GiB内存，16 Gbps带宽）规格的ECS实例，其缓存容量、可用带宽以及最大带宽的理论值如下所示：

• 缓存可用容量 = 100GiB * 2 = 200 GiB

• 缓存可用带宽 = 2 * min{40 Gbps, 内存访问I/O吞吐} = 80 Gbps

• 缓存命中时，应用Pod数据访问最大可用带宽 = min{80Gbps, 16Gbps} = 16 Gbps

推荐ECS机型规格

分布式缓存集群的可用带宽取决于集群中各个ECS节点的最大可用带宽和所使用的缓存介质，为提升分布式缓存系统性能，推荐您使用高带宽的ECS实例规格，并使用内存或本地HDD或本地SSD盘作为缓存介质。推荐使用的ECS实例规格如下所示。

关于ECS实例的详细信息，请参见实例规格族。

策略二：选择缓存介质

分布式缓存集群的可用带宽取决于集群中各个ECS节点的最大可用带宽和所使用的缓存介质，为提升分布式缓存系统性能，推荐您使用高带宽的ECS实例规格，并使用内存或本地SSD盘作为缓存介质。在Fluid中，可以通过配置Runtime资源对象的spec.tieredstore参数来设置不同的缓存介质以及缓存容量。

spec:
  tieredstore:
    levels:
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 30Gi # 为单个分布式缓存Worker副本所能提供的缓存容量。
        high: "0.99"
        low: "0.95"

策略三：配置数据缓存与应用间调度亲和性

当数据访问请求命中缓存时，应用Pod从缓存系统中读取数据。因此，如果应用Pod与缓存系统分别部署在不同的可用区内，应用需要跨可用区访问缓存数据。如果希望降低跨可用区网络波动对数据访问过程的影响，需要考虑应用Pod与缓存系统相关Pod之间的调度亲和性，具体而言：

• 缓存系统Worker Pod尽量亲和部署在相同可用区内。

• 应用Pod与缓存系统Worker Pod尽量亲和部署在相同可用区内。

在Fluid中，可以通过配置Dataset资源对象的spec.nodeAffinity，设置缓存系统Worker Pod的调度亲和性，如下所示：

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - <ZONE_ID> # 所在的可用区，例如cn-beijing-i。

上述配置将分布式缓存系统Worker Pod均部署在<ZONE_ID>可用区的ECS节点。

另外，Fluid可以在应用Pod中自动注入该应用Pod所需缓存的亲和性信息，实现应用Pod与缓存系统Worker Pod尽量同可用区亲和部署。更多信息，请参见数据缓存亲和性调度优化。

策略四：大文件全量顺序读场景参数配置优化

许多数据密集型场景中涉及大文件全量顺序读的数据访问模式，例如，基于TFRecord或Tar格式的数据集进行模型训练、AI模型推理服务启动时加载1个或多个模型参数文件、读取Parquet文件格式进行分布式数据分析等。针对此类场景，可以使用更加激进的预读策略，提升数据访问性能，例如适当增大缓存系统预读的并发度、预读数据量等。

在Fluid中，不同分布式缓存运行时在预读策略方面的配置需要有不同的参数配置，如下所示：

kind: JindoRuntime
metadata:
  ...
spec:
  fuse:
    properties:
      fs.oss.download.thread.concurrency: "200"
      fs.oss.read.buffer.size: "8388608"
      fs.oss.read.readahead.max.buffer.count: "200"
      fs.oss.read.sequence.ambiguity.range: "2147483647" # 约2G。

kind: JuiceFSRuntime
metadata:
  ...
spec:
  fuse:
    options:
      buffer-size: "2048"
      cache-size: "0"
      max-uploads: "150"
  worker:
    options:
      buffer-size: "2048"
      max-downloads: "200"
      max-uploads: "150"
  master:
    resources:
      requests:
        memory: 2Gi
      limits:
        memory: 8Gi
  ...

策略一：避免挂载包含大量文件的目录作为底层数据源

缓存系统需要维护挂载底层存储目录下全部文件的元信息，并记录各文件的缓存状态等额外元信息。如果缓存系统挂载了包含大量文件的底层存储目录（例如：大规模存储系统的根目录），缓存系统必须使用大量内存资源存储相关元信息，并使用更多CPU资源处理相关的元信息访问请求。

Fluid定义了Dataset的抽象概念，Dataset是面向上层特定应用，逻辑上是一组相关数据的集合。一个Dataset会对应启动一个分布式缓存系统，并且一个Dataset应当仅为一个或某些相关的数据密集型任务提供数据访问加速服务。因此，推荐您创建多个Dataset，并在每个Dataset中分别定义底层数据源的不同子目录，具体子目录级别与业务应用所需的数据集合相关，不同的业务应用可以使用不同的Dataset绑定的缓存系统访问数据，这将使得各业务应用间有着更好的隔离性，保证系统稳定性和性能。Dataset配置示例如下：

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  ...
  mounts:
  - mountPoint: oss://<BUCKET>/<PATH1>/<SUBPATH>/
    name: sub-bucket

创建多个缓存系统可能导致额外的运维复杂性，可根据实际业务需求灵活选择架构方案，例如：

• 如果所需缓存的数据集存储在单一后端存储系统中，且规模不大，文件数量不多，有较强的相关性，推荐创建单个Fluid Dataset和分布式缓存系统提供服务。

• 如果所需缓存的数据集规模较大、文件数量较多，推荐根据数据目录的业务含义，分拆为多个Fluid Dataset和分布式缓存系统提供服务，应用Pod可声明挂载一个或多个Fluid Dataset到指定目录下。

• 如果所需缓存的数据集来自于多个用户的不同的存储系统，并且业务要求保证用户间的数据隔离性。推荐为每个用户或用户的一系列数据相关的作业创建有着较短生命周期的Fluid Dataset，通过开发Kubernetes Operator灵活运维集群中多个Fluid Dataset。

策略二：使用元信息持久化提升缓存系统稳定性

许多分布式缓存系统采用Master-Worker的分布式架构，它们依赖于Master Pod组件维护挂载的后端存储系统目录的文件元信息，并记录各文件的缓存状态。当应用通过此类缓存系统访问数据时，首先需要从Master Pod组件中获取文件元信息，接着从底层文件存储或缓存Worker组件中获取数据。因此，缓存Master Pod组件的稳定性对缓存系统的高可用性至关重要。

如果使用JindoRuntime作为缓存运行时，在Fluid中推荐使用以下配置提升缓存Master Pod组件的可用性：

apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: sd-dataset
spec:
  ...
  volumes:
    - name: meta-vol
      persistentVolumeClaim:
        claimName: demo-jindo-master-meta
  master:
    resources:
      requests:
        memory: 4Gi
      limits:
        memory: 8Gi
    volumeMounts:
      - name: meta-vol
        mountPath: /root/jindofs-meta
    properties:
      namespace.meta-dir: "/root/jindofs-meta"

在上述YAML示例中，demo-jindo-master-meta为提前创建的PVC，该PVC使用ESSD云盘作为存储卷，这意味着Master Pod组件维护的元信息能够持久化存储，并能够随Pod迁移。更多信息，请参见通过配置JindoRuntime实现Master Pod组件状态持久化存储。

策略三：合理配置FUSE Pod资源

缓存系统客户端程序运行于FUSE Pod中，FUSE Pod在节点上挂载FUSE文件系统，该文件系统将被挂载到应用Pod的指定路径上，并暴露POSIX文件访问接口。这使得应用Pod往往不需要修改应用代码，即可像访问本地存储一样访问远程存储系统中的数据，并享受到缓存带来的加速效果。FUSE程序维持了应用和缓存系统之间的数据通道，因此推荐对FUSE Pod所使用的资源进行配置。

在Fluid中，可以通过配置Runtime资源对象的spec.fuse.resources设置FUSE Pod的资源使用。为避免因FUSE程序OOM导致的文件挂载点断裂问题，推荐您对FUSE Pod不设置或设置较大的内存限制。例如，可以设置FUSE Pod的内存限制接近ECS节点的可分配内存大小。

spec:
  fuse:
    resources:
      requests:
        memory: 8Gi
    # limits:
    #   memory: <ECS_ALLOCATABLE_MEMORY>

策略四：开启FUSE自愈功能提升数据访问客户端可用性

FUSE程序维持了应用和缓存系统之间的数据通道。默认情况下，如果FUSE程序因某些预期之外的行为崩溃，即使FUSE程序重启后恢复正常，应用容器也无法再通过该FUSE文件系统挂载点访问数据。为解决该问题，应用容器必须重启（重新触发FUSE文件系统挂载点到应用Pod的绑定挂载逻辑）来恢复数据访问，这将影响应用Pod的可用性。

Fluid提供了FUSE自愈机制，开启该机制后应用容器无需重启，即可在FUSE程序重启后的一段时间后，自动恢复应用容器内FUSE挂载点的数据访问。

如需开启并使用FUSE自愈功能，请参见如何开启FUSE自动恢复能力。FUSE自愈能力存在较多限制，推荐仅在某些具有明确需求且业务适合的应用场景选择性开启此能力，例如：交互式编程开发场景，即使用在线Notebook或其他环境交互式开发调试某些应用程序。