Container Service for Kubernetes：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或其他環境互動式開發調試某些應用程式。