基於 ACK Fluid 的混合雲優化數據訪問（五）：自動化跨區域中心數據分發

前文回顧：

本系列將介紹如何基於 ACK Fluid 支持和優化混合雲的數據訪問場景，相關文章請參考：

《基於 ACK Fluid 的混合雲優化數據訪問（二）：搭建彈性計算實例與第三方存儲的橋樑》

《基於 ACK Fluid 的混合雲優化數據訪問（三）：加速第三方存儲的讀訪問，降本增效並行》

《基於 ACK Fluid 的混合雲優化數據訪問（四）：將第三方存儲目錄掛載到 Kubernetes，提升效率和標準化》

在之前的文章中，我們討論了混合雲場景下 Kubernetes 與數據相結合的 Day 1：解決數據接入的問題，實現雲上計算和線下存儲的連接。在此基礎上，ACK Fluid 進一步解決了數據訪問的成本和性能問題。而進入 Day 2，當用戶真的在生產環境使用該方案時，最主要的挑戰就是運維側如何處理多區域集羣的數據同步。

概述

許多企業出於性能、安全、穩定性和資源隔離的目的，會在不同區域建立多個計算集羣。而這些計算集羣需要遠程訪問唯一中心化的數據存儲。比如隨着大語言模型的逐漸成熟，基於其的多區域推理服務也逐漸成爲各個企業需要支持的能力，就是這個場景的具體實例，它有不小的挑戰：

多計算集羣跨數據中心手動操作數據同步，非常耗時
以大語言模型爲例，參數多文件大，數量多，管理複雜：不同業務選擇不同的基礎模型和業務數據，因此最終模型存在差異。
模型數據會根據業務輸入不斷做更新迭代，模型數據更新頻繁
模型推理服務啓動慢，拉取文件時間長：大型語言模型的參數規模相當巨大，體積通常很大甚至達到幾百 GB，導致拉取到 GPU 顯存的耗時巨大，啓動時間非常慢。
模型更新需要所有區域同步更新，而在過載的存儲集羣上進行復製作業嚴重影響現有負載的性能。

ACK Fluid 除了提供通用存儲客戶端的加速能力，還提供了定時和觸發式數據遷移和預熱能力，簡化數據分發的複雜度。

節省網絡和計算成本：跨區流量成本大幅降低，計算時間明顯縮短，少量增加計算集羣成本；並且可以通過彈性進一步優化。
應用數據更新大幅加速：由於計算的數據訪問在同一個數據中心或者可用區內完成通信，延時降低，且緩存吞吐併發能力可線性擴展。
減少複雜的數據同步操作：通過自定義策略控制數據同步操作，降低數據訪問爭搶，同時通過自動化的方式降低運維複雜度。

演示

本演示介紹如何通過 ACK Fluid 的定時預熱機制更新用戶不同區域的計算集羣可以訪問的數據。

前提條件

已創建 ACK Pro 版集羣，且集羣版本爲 1.18 及以上。具體操作，請參見創建 ACK Pro 版集羣[1]。
已安裝雲原生 AI 套件並部署 ack-fluid 組件。重要：若您已安裝開源 Fluid，請卸載後再部署 ack-fluid 組件。
未安裝雲原生 AI 套件：安裝時開啓 Fluid 數據加速。具體操作，請參見安裝雲原生 AI 套件[2]。
已安裝雲原生 AI 套件：在容器服務管理控制檯[3]的雲原生 AI 套件頁面部署 ack-fluid。
已通過 kubectl 連接 Kubernetes 集羣。具體操作，請參見通過 kubectl 工具連接集羣[4]。

背景信息

準備好 K8s 和 OSS 環境的條件，您只需要耗費 10 分鐘左右即可完成 JindoRuntime 環境的部署。

步驟一：準備 OSS Bucket 的數據

1. 執行以下命令，下載一份測試數據。

$ wget https://archive.apache.org/dist/hbase/2.5.2/RELEASENOTES.md

2. 將下載的測試數據上傳到阿里雲 OSS 對應的 Bucket 上，上傳方法可以藉助 OSS 提供的客戶端工具 ossutil。具體操作，請參見安裝 ossutil[5]。

$ ossutil cp RELEASENOTES.md oss://<bucket>/<path>/RELEASENOTES.md

步驟二：創建Dataset和JindoRuntime

1. 在創建 Dataset 之前，您可以創建一個 mySecret.yaml 文件來保存 OSS 的 accessKeyId 和 accessKeySecret。

創建 mySecret.yaml 文件的 YAML 樣例如下：

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: xxx
  fs.oss.accessKeySecret: xxx

2. 執行以下命令，生成 Secret。

$ kubectl create -f mySecret.yaml

3. 使用以下 YAML 文件樣例創建一個名爲 dataset.yaml 的文件，且裏面包含兩部分：

創建一個 Dataset，描述遠端存儲數據集和 UFS 的信息。
創建一個 JindoRuntime，啓動一個 JindoFS 的集羣來提供緩存服務。

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo
spec:
  mounts:
    - mountPoint: oss://<bucket-name>/<path>
      options:
        fs.oss.endpoint: <oss-endpoint>
      name: hbase
      path: "/"
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeySecret
  accessModes:
    - ReadOnlyMany
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo
spec:
  replicas: 1
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 2Gi
        high: "0.99"
        low: "0.8"
  fuse:
   args:
    - -okernel_cache
    - -oro
    - -oattr_timeout=60
    - -oentry_timeout=60
    - -onegative_timeout=60

相關參數解釋如下表所示：

參數	說明
mountPoint	oss://<oss_bucket>/<path>表示掛載UFS的路徑，路徑中不需要包含endpoint信息。
fs.oss.endpoint	OSS Bucket的endpoint信息，公網或私網地址皆可。
accessModes	表示Dataset的訪問模式。
replicas	表示創建JindoFS集羣的Worker數量。
mediumtype	表示緩存類型。定義創建JindoRuntime模板樣例時，JindoFS暫時支持HDD/SSD/MEM中的其中一種緩存類型。
path	表示存儲路徑，暫時只支持單個路徑。當選擇MEM做緩存時，需指定一個本地路徑來存儲Log等文件。
quota	表示緩存最大容量，單位GB。緩存容量可以根據UFS數據大小自行配置。
high	表示存儲容量上限大小。
low	表示存儲容量下限大小。
fuse.args	表示可選的fuse客戶端掛載參數。通常與Dataset的訪問模式搭配使用。當Dataset訪問模式爲ReadOnlyMany時，我們開啓kernel_cache以利用內核緩存優化讀性能。此時我們可以設置attr_timeout（文件屬性緩存保留時間）、entry_timeout（文件名讀取緩存保留時間）超時時間、negative_timeout（文件名讀取失敗緩存保留時間），默認均爲7200s。當Dataset訪問模式爲ReadWriteMany時，我們建議使用默認配置。此時參數如下：- -oauto_cache- -oattr_timeout=0- -oentry_timeout=0- -onegative_timeout=0使用auto_cache以確保如果文件大小或修改時間發生變化，緩存就會失效。同時將超時時間都設置爲0。

4. 執行以下命令，創建 JindoRuntime 和 Dataset。

$ kubectl create -f dataset.yaml

5. 執行以下命令，查看 Dataset 的部署情況。

$ kubectl get dataset

預期輸出：

NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        0.00B       10.00GiB         0.0%                Bound   2m7s

步驟三：創建支持定時運行的 Dataload

1. 使用以下 YAML 文件樣例創建一個名爲 dataload.yaml 的文件。

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: cron-dataload
spec:
  dataset:
    name: demo
    namespace: default
  policy: Cron
  schedule: "*/2 * * * *" # Run every 2 min

相關參數解釋如下表所示：

參數	說明
dataset	表示執行dataload的數據集name和namespace。
policy	表示執行策略，目前支持Once和Cron。這裏創建定時dataload任務。
shcedule	表示觸發dataload的策略。

scheule 使用以下 cron 格式：

# ┌───────────── 分鐘 (0 - 59)
# │ ┌───────────── 小時 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)（週日到週一；在某些系統上，7 也是星期日）
# │ │ │ │ │                          或者是 sun，mon，tue，web，thu，fri，sat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

同時，cron 支持下列運算符：

逗號（,）表示列舉，例如：1,3,4,7 * * * * 表示在每小時的 1、3、4、7 分時執行Dataload。
連詞符（-）表示範圍，例如：1-6 * * * * 表示每小時的 1 到 6 分鐘內，每分鐘都執行一次。
星號（*）代表任何可能的值。例如：在“小時域”裏的星號等於是“每一個小時”。
百分號(%) 表示“每"。例如：*%10 * * * * 表示每 10 分鐘執行一次。
斜槓 (/) 用於描述範圍的增量。例如：*/2 * * * *表示每 2 分鐘執行一次。

您也可以在這裏查看更多信息。

Dataload 相關高級配置請參考如下配置文件：

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: cron-dataload
spec:
  dataset:
    name: demo
    namespace: default
  policy: Cron # including Once, Cron
  schedule: * * * * * # only set when policy is cron
  loadMetadata: true
  target:
    - path: <path1>
      replicas: 1
    - path: <path2>
      replicas: 2

相關參數解釋如下表所示：

參數	說明
policy	表示dataload執行策略，包括[Once, Cron]。
schedule	表示cron使用的計劃，只有policy爲Cron時有效。
loadMetadata	表示在dataload前是否同步元數據。
target	表示dataload的目標，支持指定多個目標。
path	表示執行dataload的路徑。
replicas	表示緩存的副本數。

6. 執行以下命令創建 Dataload。

$ kubectl apply -f dataload.yaml

7. 執行以下命令查看 Dataload 狀態。

$ kubectl get dataload

預期輸出：

NAME             DATASET   PHASE      AGE     DURATION
cron-dataload    demo      Complete   3m51s   2m12s

8. 等待 Dataload 狀態爲 Complete 後，執行以下命令查看當前 dataset 狀態。

$ kubectl get dataset

預期輸出：

NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        588.90KiB   10.00GiB         100.0%              Bound   5m50s

可以看出 oss 中文件已經全部加載到緩存。

步驟四：創建應用容器訪問 OSS 中的數據

本文以創建一個應用容器訪問上述文件以查看定時 Dataload 效果。

1. 使用以下 YAML 文件樣例，創建名爲 app.yaml 的文件。

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

2. 執行以下命令創建應用容器。

$ kubectl create -f app.yaml

3. 等待應用容器就緒，執行以下命令查看 OSS 中的數據：

$ kubectl exec -it nginx -- ls -lh /data

預期輸出：

total 589K
-rwxrwxr-x 1 root root 589K Jul 31 04:20 RELEASENOTES.md

4. 爲了驗證 dataload 定時更新底層文件效果，我們在定時 dataload 觸發前修改 RELEASENOTES.md 內容並重新上傳。

$ echo "hello, crondataload." >> RELEASENOTES.md

重新上傳該文件到 oss。

$ ossutil cp RELEASENOTES.md oss://<bucket-name>/<path>/RELEASENOTES.md

5. 等待 dataload 任務觸發。Dataload 任務完成時，執行以下命令查看 Dataload 作業運行情況：

$ kubectl describe dataload cron-dataload

預期輸出：

...
Status:
  Conditions:
    Last Probe Time:       2023-07-31T04:30:07Z
    Last Transition Time:  2023-07-31T04:30:07Z
    Status:                True
    Type:                  Complete
  Duration:                5m54s
  Last Schedule Time:      2023-07-31T04:30:00Z
  Last Successful Time:    2023-07-31T04:30:07Z
  Phase:                   Complete
...

其中，Status 中 Last Schedule Time 爲上一次 dataload 作業的調度時間，Last Successful Time 爲上一次 dataload 作業的完成時間。

此時，可以執行以下命令查看當前 Dataset 狀態：

$ kubectl get dataset

預期輸出：

NAME    UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo    588.90KiB        1.15MiB     10.00GiB         100.0%              Bound   10m

可以看出更新後的文件也已經加載到了緩存。

6. 執行以下命令在應用容器中查看更新後的文件：

$ kubectl exec -it nginx -- tail /data/RELEASENOTES.md

預期輸出：

  \<name\>hbase.config.read.zookeeper.config\</name\>
  \<value\>true\</value\>
  \<description\>
        Set to true to allow HBaseConfiguration to read the
        zoo.cfg file for ZooKeeper properties. Switching this to true
        is not recommended, since the functionality of reading ZK
        properties from a zoo.cfg file has been deprecated.
  \</description\>
\</property\>
hello, crondataload.

從最後一行可以看出，應用容器已經可以訪問更新後的文件。

環境清理

當您不再使用該數據加速功能時，需要清理環境。

執行以下命令，刪除 JindoRuntime 和應用容器。

$ kubectl delete -f app.yaml  $ kubectl delete -f dataset.yaml

總結

關於基於 ACK Fluid 的混合雲優化數據訪問的討論先到這裏告一段落，阿里雲容器服務團隊會和用戶在這個場景下持續的迭代和優化，隨着實踐不斷深入，這個系列也會持續更新。

相關鏈接：

[1] 創建 ACK Pro 版集羣

https://help.aliyun.com/document_detail/176833.html#task-skz-qwk-qfb

[2] 安裝雲原生 AI 套件

https://help.aliyun.com/zh/ack/cloud-native-ai-suite/user-guide/deploy-the-cloud-native-ai-suite#task-2038811

[3] 容器服務管理控制檯

https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Fcs.console.aliyun.com%2F

[4] 通過 kubectl 工具連接集羣

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/obtain-the-kubeconfig-file-of-a-cluster-and-use-kubectl-to-connect-to-the-cluster#task-ubf-lhg-vdb

[5] 安裝 ossutil

https://help.aliyun.com/zh/oss/developer-reference/install-ossutil#concept-303829

作者：車漾

點擊立即免費試用雲產品開啓雲上實踐之旅！

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。

基於 ACK Fluid 的混合雲優化數據訪問（五）：自動化跨區域中心數據分發

概述

演示

前提條件

背景信息

步驟一：準備 OSS Bucket 的數據

步驟二：創建Dataset和JindoRuntime

步驟三：創建支持定時運行的 Dataload

步驟四：創建應用容器訪問 OSS 中的數據

環境清理

總結

序列計數器和順序鎖【ChatGPT】

PPadleOCR 自己的數據訓練

C++ Qt開發：使用順序容器類

Python 潮流週刊第 30 期（摘要）

「行業應用」圖表控件LightningChart在工業遙測領域的應用

界面控件DevExpress中文教程 - 如何用Office File API組件填充PDF表單

彈彈play離線查看B站大會員彈幕

線程T1，T2，T3依次執行

線程wait和notify

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結