雲原生高性能分佈式文件系統 JuiceFS 還真有點意思

JuiceFS 是一款面向雲原生設計的高性能分佈式文件系統,在 Apache 2.0 開源協議下發布。提供完備的 POSIX 兼容性,可將幾乎所有對象存儲接入本地作爲海量本地磁盤使用,亦可同時在跨平臺、跨地區的不同主機上掛載讀寫。

簡介

JuiceFS 採用 「數據」與「元數據」分離存儲 的架構,從而實現文件系統的分佈式設計。文件數據本身會被切分保存在對象存儲(例如 Amazon S3),而元數據則可以保存在 Redis、MySQL、TiKV、SQLite 等多種數據庫中,你可以根據場景與性能要求進行選擇。

JuiceFS 提供了豐富的 API,適用於各種形式數據的管理、分析、歸檔、備份,可以在不修改代碼的前提下無縫對接大數據、機器學習、人工智能等應用平臺,爲其提供海量、彈性、低價的高性能存儲。運維人員不用再爲可用性、災難恢復、監控、擴容等工作煩惱,專注於業務開發,提升研發效率。同時運維細節的簡化,對 DevOps 極其友好。

核心特性

應用場景

JuiceFS 爲海量數據存儲設計,可以作爲很多分佈式文件系統和網絡文件系統的替代,特別是以下場景:

數據隱私

JuiceFS 是開源軟件,你可以在 GitHub 找到完整的源代碼。在使用 JuiceFS 存儲數據時,數據會按照一定的規則被拆分成數據塊並保存在你自己定義的對象存儲或其它存儲介質中,數據所對應的元數據則存儲在你自己定義的數據庫中。

架構

JuiceFS 整體上主要由三個部分組成。

JuiceFS 採用多引擎設計,目前已支持 Redis、TiKV、MySQL/MariaDB、PostgreSQL、SQLite 等作爲元數據服務引擎,也將陸續實現更多元數據存儲引擎。

JuiceFS 如何存儲文件

與傳統文件系統只能使用本地磁盤存儲數據和對應的元數據的模式不同,JuiceFS 會將數據格式化以後存儲在對象存儲,同時會將文件的元數據存儲在專門的元數據服務中,這樣的架構讓 JuiceFS 成爲一個強一致性的高性能分佈式文件系統。

任何存入 JuiceFS 的文件都會被拆分成一個或多個 「Chunk」(最大 64 MiB)。而每個 Chunk 又由一個或多個 「Slice」 組成。Chunk 的存在是爲了對文件做切分,優化大文件性能,而 Slice 則是爲了進一步優化各類文件寫操作,二者同爲文件系統內部的邏輯概念。Slice 的長度不固定,取決於文件寫入的方式。每個 Slice 又會被進一步拆分成 「Block」(默認大小上限爲 4 MiB),成爲最終上傳至對象存儲的最小存儲單元

所以我們在對象存儲平臺的文件瀏覽器中找不到存入 JuiceFS 的源文件,存儲桶中只有一個 chunks 目錄和一堆數字編號的目錄和文件,這正是經過 JuiceFS 拆分存儲的數據塊。與此同時,文件與 Chunks、Slices、Blocks 的對應關係等元數據信息存儲在元數據引擎中。正是這樣的分離設計,讓 JuiceFS 文件系統得以高性能運作。

JuiceFS 的存儲設計,還有着以下技術特點:

安裝

JuiceFS 是採用 Go 語言開發的,所以具有良好的跨平臺能力,支持在幾乎所有主流架構的各類操作系統上運行,包括且不限於 Linux、macOS、Windows 等。

JuiceFS 客戶端只有一個二進制文件,可以下載預編譯的版本直接解壓使用,也可以用源代碼手動編譯,也可以直接使用一鍵安裝腳本 curl -sSL https://d.juicefs.com/install | sh - 自動下載安裝最新版 JuiceFS 客戶端。

如果你在 Mac 下面使用,需要先安裝 FUSE for macOS,這是因爲 macOS 默認不支持 FUSE 接口。

➜ juicefs --version
juicefs version 1.0.4+2023-04-06.f1c475d

單機模式

JuiceFS 文件系統由「對象存儲」和「數據庫」共同驅動,除了對象存儲,還支持使用本地磁盤、WebDAV 和 HDFS 等作爲底層存儲。這裏我們首先使用本地磁盤和 SQLite 數據庫快速創建一個單機文件系統用以瞭解和體驗 JuiceFS。

當然首先需要安裝 JuiceFS 的客戶端,然後接下來我們就可以使用 juicefs format 命令來創建一個 JuiceFS 文件系統了,該命令的格式爲:

juicefs format [command options] META-URL NAME

從命令可以看出格式化文件系統需要提供 3 種信息:

比如我們這裏創建一個名爲 ydzsfs 的文件系統,則可以使用如下所示的命令:

➜ juicefs format sqlite3://ydzsfs.db ydzsfs
2023/04/25 15:36:44.287211 juicefs[218656] <INFO>: Meta address: sqlite3://ydzsfs.db [interface.go:401]
2023/04/25 15:36:44.288042 juicefs[218656] <INFO>: Data use file:///home/ubuntu/.juicefs/local/ydzsfs/ [format.go:434]
2023/04/25 15:36:44.400391 juicefs[218656] <INFO>: Volume is formatted as {
  "Name""ydzsfs",
  "UUID""67a050b2-9a40-4852-882c-24c092c03b4a",
  "Storage""file",
  "Bucket""/home/ubuntu/.juicefs/local/",
  "BlockSize": 4096,
  "Compression""none",
  "TrashDays": 1,
  "MetaVersion"1
} [format.go:471]

從返回的信息中可以看到,該文件系統使用 SQLite 作爲元數據存儲引擎,數據庫文件位於當前目錄,文件名爲 ydzsfs.db,保存了 ydzsfs 文件系統的所有信息,它構建了完善的表結構,將用作所有數據的元信息的存儲。

SQLite

由於沒有指定任何存儲相關的選項,客戶端默認使用本地磁盤作爲存儲介質,根據返回的信息, ydzsfs 的存儲路徑爲 file:///home/ubuntu/.juicefs/local/ydzsfs/,即當前用戶主目錄下的 .juicefs/local/ydzsfs/

➜ ls -la ~/.juicefs/local/ydzsfs
total 12
drwxr-xr-x 2 ubuntu ubuntu 4096 Apr 25 15:36 .
drwxr-xr-x 3 ubuntu ubuntu 4096 Apr 25 15:36 ..
-rw-r--r-- 1 ubuntu ubuntu   36 Apr 25 15:36 juicefs_uuid

這樣我們就成功創建了一個文件系統了,接下來我們就可以使用 juicefs mount 命令來掛載文件系統了,該命令的一般格式爲:

juicefs mount [command options] META-URL MOUNTPOINT

與創建文件系統的命令類似,掛載文件系統需要提供以下信息:

由於 SQLite 是單文件數據庫,掛載時要注意數據庫文件的的路徑,JuiceFS 同時支持相對路徑和絕對路徑。比如我們這裏可以使用以下命令將 ydzsfs 文件系統掛載到 ./jfs 文件夾:

➜ juicefs mount sqlite3://ydzsfs.db ./jfs
2023/04/25 15:39:52.365555 juicefs[220965] <INFO>: Meta address: sqlite3://ydzsfs.db [interface.go:401]
2023/04/25 15:39:52.366833 juicefs[220965] <INFO>: Data use file:///home/ubuntu/.juicefs/local/ydzsfs/ [mount.go:431]
2023/04/25 15:39:52.367117 juicefs[220965] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/67a050b2-9a40-4852-882c-24c092c03b4a/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94]
2023/04/25 15:39:52.378120 juicefs[220965] <INFO>: Create session 1 OK with version: 1.0.4+2023-04-06.f1c475d [base.go:289]
2023/04/25 15:39:52.378749 juicefs[220965] <INFO>: Prometheus metrics listening on 127.0.0.1:9567 [mount.go:161]
2023/04/25 15:39:52.378819 juicefs[220965] <INFO>: Mounting volume ydzsfs at ./jfs ... [mount_unix.go:181]
2023/04/25 15:39:52.378851 juicefs[220965] <WARNING>: setpriority: permission denied [fuse.go:427]
2023/04/25 15:39:52.868233 juicefs[220965] <INFO>: OK, ydzsfs is ready at ./jfs [mount_unix.go:45]

默認情況下,客戶端會在前臺掛載文件系統,程序會一直運行在當前終端進程中,使用 Ctrl + C 組合鍵或關閉終端窗口,文件系統會被卸載。

爲了讓文件系統可以在後臺保持掛載,你可以在掛載時指定 -d--background 選項,即讓客戶端在守護進程中掛載文件系統:

➜ juicefs mount sqlite3://ydzsfs.db ~/jfs -d
2023/04/25 15:41:15.438132 juicefs[222009] <INFO>: Meta address: sqlite3://ydzsfs.db [interface.go:401]
2023/04/25 15:41:15.439334 juicefs[222009] <INFO>: Data use file:///home/ubuntu/.juicefs/local/ydzsfs/ [mount.go:431]
2023/04/25 15:41:15.439513 juicefs[222009] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/67a050b2-9a40-4852-882c-24c092c03b4a/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94]
2023/04/25 15:41:15.941069 juicefs[222009] <INFO>: OK, ydzsfs is ready at /home/ubuntu/jfs [mount_unix.go:45]

接下來,任何存入掛載點 ~/jfs 的文件,都會按照 JuiceFS 的文件存儲格式被拆分成特定的「數據塊」並存入 $HOME/.juicefs/local/ydzsfs 目錄中,相對應的「元數據」會全部存儲在 ydzsfs.db 數據庫中。

最後執行以下命令可以將掛載點 ~/jfs 卸載:

➜ juicefs umount ~/jfs

當然,在你能夠確保數據安全的前提下,也可以在卸載命令中添加 --force-f 參數,強制卸載文件系統。

使用對象存儲

通過前面的基本介紹我們可以對 JuiceFS 的工作方式有一個基本的認識,接下來我們仍然使用 SQLite 存儲元數據,但是把本地存儲換成「對象存儲」,做一個更有實用價值的方案。

幾乎所有主流的雲計算平臺都有提供對象存儲服務,如亞馬遜 S3、阿里雲 OSS 等,JuiceFS 支持幾乎所有的對象存儲服務。一般來說,創建對象存儲通常只需要 2 個環節:

以騰訊雲 COS 爲例,創建好的資源大概像下面這樣:

我們這裏以騰訊雲 COS 服務爲例來進行演示,首先創建一個 Bucket 存儲桶,命名爲 myjfs,然後創建一個子賬號,命名爲 juicefs,併爲其創建一個 API 密鑰,如下圖所示:

# 使用你自己所使用的對象存儲信息替換下方相關參數
➜ juicefs format --storage cos \
    --bucket https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com \
    --access-key xxxx \
    --secret-key xxx \
    sqlite3://myjfs.db myjfs
2023/04/25 15:56:18.198284 juicefs[233378] <INFO>: Meta address: sqlite3://myjfs.db [interface.go:401]
2023/04/25 15:56:18.198941 juicefs[233378] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [format.go:434]
2023/04/25 15:56:18.740526 juicefs[233378] <INFO>: Volume is formatted as {
  "Name""myjfs",
  "UUID""720c4b39-547e-43d8-8b22-02229f443194",
  "Storage""cos",
  "Bucket""https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com",
  "AccessKey""xxxx",
  "SecretKey""removed",
  "BlockSize": 4096,
  "Compression""none",
  "KeyEncrypted": true,
  "TrashDays": 1,
  "MetaVersion"1
} [format.go:471]

在上述命令中,我們指定了對象存儲的相關配置信息:

創建完成即可進行掛載:

➜ juicefs mount sqlite3://myjfs.db ~/jfs -d
2023/04/25 16:01:40.718645 juicefs[237796] <INFO>: Meta address: sqlite3://myjfs.db [interface.go:401]
2023/04/25 16:01:40.719901 juicefs[237796] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [mount.go:431]
2023/04/25 16:01:40.720136 juicefs[237796] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/720c4b39-547e-43d8-8b22-02229f443194/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94]
2023/04/25 16:01:41.221218 juicefs[237796] <INFO>: OK, myjfs is ready at /home/ubuntu/jfs [mount_unix.go:45]

掛載命令與使用本地存儲時完全一樣,這是因爲創建文件系統時,對象存儲相關的信息已經寫入了 myjfs.db 數據庫,因此客戶端不需要額外提供對象存儲認證信息,也沒有本地配置文件。

相比使用本地磁盤,SQLite 和對象存儲的組合實用價值更高。從應用的角度看,這種形式等同於將容量幾乎無限的對象存儲接入到了本地計算機,讓你可以像使用本地磁盤那樣使用雲存儲。

進一步的,該文件系統的所有數據都存儲在雲端的對象存儲,因此可以把 myjfs.db 數據庫複製到其他安裝了 JuiceFS 客戶端的計算機上進行掛載和讀寫。也就是說,任何一臺計算機只要能夠讀取到存儲了元數據的數據庫,那麼它就能夠掛載讀寫該文件系統。

比如現在我們在 ~/jfs 目錄下面任意創建一些文件:

➜ echo "Hello JuiceFS" > hello.txt

正常創建完成後該文件會按照 JuiceFS 的文件存儲格式被拆分成特定的「數據塊」並上傳到對象存儲中去,相對應的「元數據」會全部存儲在 myjfs.db 數據庫中。

很顯然,SQLite 這種單文件數據庫很難實現被多臺計算機同時訪問。如果把 SQLite 改爲 Redis、PostgreSQL、MySQL 等能夠通過網絡被多臺計算機同時讀寫訪問的數據庫,那麼就可以實現 JuiceFS 文件系統的分佈式掛載讀寫。

分佈式模式

前面我們通過採用「對象存儲」和「SQLite」數據庫的組合,實現了一個可以在任意主機上掛載的文件系統。得益於對象存儲可以被網絡上任何有權限的計算機訪問的特點,我們只需要把 SQLite 數據庫文件複製到任何想要訪問該存儲的計算機,就可以實現在不同計算機上訪問同一個 JuiceFS 文件系統。

很顯然,想要依靠在計算機之間複製 SQLite 數據庫的方式進行文件系統共享,雖然可行,但文件的實時性是得不到保證的。受限於 SQLite 這種單文件數據庫無法被多個計算機同時讀寫訪問的情況,爲了能夠讓一個文件系統可以在分佈式環境中被多個計算機同時掛載讀寫,我們需要採用支持通過網絡訪問的數據庫,比如 Redis、PostgreSQL、MySQL 等。

接下來我們將 SQLite 數據庫替換成基於網絡的數據庫,從而實現 JuiceFS 文件系統的分佈式掛載讀寫。JuiceFS 目前支持的基於網絡的數據庫有:

不同的數據庫性能和穩定性表現也各不相同,比如 Redis 是內存型鍵值數據庫,性能極爲出色,但可靠性相對較弱。PostgreSQL 是關係型數據庫,相比之下性能沒有內存型強悍,但它的可靠性要更強。

我們這裏以 Redis 爲例來演示分佈式模式的使用,我們就直接在 K8s 集羣中部署一個簡單的 Redis 服務來進行說明:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        image: redis/redis-stack-server:6.2.6-v6
        imagePullPolicy: IfNotPresent
        name: redis
        ports:
          - containerPort: 6379
            protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  ports:
    - name: redis-port
      port: 6379
      targetPort: 6379
  selector:
    app: redis
  type: NodePort

直接應用該資源清單即可:

➜ kubectl apply -f redis.yaml
➜ kubectl get svc redis -n kube-gpt
NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
redis     NodePort   10.103.134.144   <none>        6379:32199/TCP    19d

然後接下來我們就可以利用前面的對象存儲和這裏的 Redis 來創建一個分佈式的 JuiceFS 文件系統了,使用如下所示命令:

➜ juicefs format --storage cos \
    --bucket https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com \
    --access-key xxxx \
    --secret-key xxxx \
    redis://10.103.134.144:6379/1 myjfs
2023/04/25 16:21:41.847487 juicefs[252491] <INFO>: Meta address: redis://10.103.134.144:6379/1 [interface.go:401]
2023/04/25 16:21:41.849176 juicefs[252491] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly. [info.go:83]
2023/04/25 16:21:41.849459 juicefs[252491] <INFO>: Ping redis: 217.108µs [redis.go:2904]
2023/04/25 16:21:41.850047 juicefs[252491] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [format.go:434]
2023/04/25 16:21:42.263986 juicefs[252491] <INFO>: Volume is formatted as {
  "Name""myjfs",
  "UUID""6fb832cc-06a1-4b18-b9fc-087dbf67a105",
  "Storage""cos",
  "Bucket""https://myjfs-1304979731.cos.ap-nanjing.myqcloud.com",
  "AccessKey""xxxxxxxx",
  "SecretKey""removed",
  "BlockSize": 4096,
  "Compression""none",
  "KeyEncrypted": true,
  "TrashDays": 1,
  "MetaVersion"1
} [format.go:471]

文件系統創建完畢以後,包含對象存儲密鑰等信息會完整的記錄到數據庫中,JuiceFS 客戶端只要擁有數據庫地址、用戶名和密碼信息,就可以掛載讀寫該文件系統,所以 JuiceFS 客戶端不需要本地配置文件。

由於這個文件系統的「數據」和「元數據」都存儲在基於網絡的服務中,因此在任何安裝了 JuiceFS 客戶端的計算機上都可以同時掛載該文件系統進行共享讀寫,例如:

➜ juicefs mount redis://10.103.134.144:6379/1 ~/jfs -d
2023/04/25 16:25:40.254487 juicefs[255369] <INFO>: Meta address: redis://10.103.134.144:6379/1 [interface.go:401]
2023/04/25 16:25:40.255762 juicefs[255369] <WARNING>: AOF is not enabled, you may lose data if Redis is not shutdown properly. [info.go:83]
2023/04/25 16:25:40.255971 juicefs[255369] <INFO>: Ping redis: 164.248µs [redis.go:2904]
2023/04/25 16:25:40.256553 juicefs[255369] <INFO>: Data use cos://myjfs-1304979731/myjfs/ [mount.go:431]
2023/04/25 16:25:40.256743 juicefs[255369] <INFO>: Disk cache (/home/ubuntu/.juicefs/cache/6fb832cc-06a1-4b18-b9fc-087dbf67a105/): capacity (102400 MB), free ratio (10%), max pending pages (15) [disk_cache.go:94]
2023/04/25 16:25:40.757806 juicefs[255369] <INFO>: OK, myjfs is ready at /home/ubuntu/jfs [mount_unix.go:45]

數據強一致性保證

對於多客戶端同時掛載讀寫同一個文件系統的情況,JuiceFS 提供「關閉再打開(close-to-open)」一致性保證,即當兩個及以上客戶端同時讀寫相同的文件時,客戶端 A 的修改在客戶端 B 不一定能立即看到。但是,一旦這個文件在客戶端 A 寫入完成並關閉,之後在任何一個客戶端重新打開該文件都可以保證能訪問到最新寫入的數據,不論是否在同一個節點。

調大緩存提升性能

由於「對象存儲」是基於網絡的存儲服務,不可避免會產生訪問延時。爲了解決這個問題,JuiceFS 提供並默認啓用了緩存機制,即劃撥一部分本地存儲作爲數據與對象存儲之間的一個緩衝層,讀取文件時會異步地將數據緩存到本地存儲。

緩存機制讓 JuiceFS 可以高效處理海量數據的讀寫任務,默認情況下,JuiceFS 會在 $HOME/.juicefs/cache/var/jfsCache 目錄設置 100GiB 的緩存。在速度更快的 SSD 上設置更大的緩存空間可以有效提升 JuiceFS 的讀寫性能。

你可以使用 --cache-dir 調整緩存目錄的位置,使用 --cache-size 調整緩存空間的大小,例如:

juicefs mount
    --background \
    --cache-dir /mycache \
    --cache-size 512000 \
    redis://tom:mypassword@xxxx:6379/1 \
    ~/jfs

注意:JuiceFS 進程需要具有讀寫 --cache-dir 目錄的權限。

上述命令將緩存目錄設置在了 /mycache 目錄,並指定緩存空間爲 500GiB

當掛載好文件系統以後可以通過 juicefs bench 命令對文件系統進行基礎的性能測試和功能驗證,確保 JuiceFS 文件系統能夠正常訪問且性能符合預期。

➜ juicefs bench ~/jfs
Cleaning kernel cache, may ask for root privilege...
  Write big blocks count: 1024 / 1024 [==============================================================]  done
   Read big blocks count: 1024 / 1024 [==============================================================]  done
Write small blocks count: 100 / 100 [==============================================================]  done
 Read small blocks count: 100 / 100 [==============================================================]  done
  Stat small files count: 100 / 100 [==============================================================]  done
Benchmark finished!
BlockSize: 1 MiB, BigFileSize: 1024 MiB, SmallFileSize: 128 KiB, SmallFileCount: 100, NumThreads: 1
Time used: 16.4 s, CPU: 50.4%, Memory: 432.8 MiB
+------------------+------------------+---------------+
|       ITEM       |       VALUE      |      COST     |
+------------------+------------------+---------------+
|   Write big file |     266.43 MiB/s |   3.84 s/file |
|    Read big file |     220.25 MiB/s |   4.65 s/file |
| Write small file |     14.6 files/s | 68.50 ms/file |
|  Read small file |   1172.6 files/s |  0.85 ms/file |
|        Stat file |   4252.0 files/s |  0.24 ms/file |
|   FUSE operation | 17835 operations |    1.00 ms/op |
|      Update meta |   326 operations |    2.98 ms/op |
|       Put object |   356 operations |  214.20 ms/op |
|       Get object |   256 operations |  116.36 ms/op |
|    Delete object |     0 operations |    0.00 ms/op |
| Write into cache |   356 operations |    2.94 ms/op |
|  Read from cache |   100 operations |    0.07 ms/op |
+------------------+------------------+---------------+

運行 juicefs bench 命令以後會根據指定的併發度(默認爲 1)往 JuiceFS 文件系統中寫入及讀取 N 個大文件(默認爲 1)及 N 個小文件(默認爲 100),並統計讀寫的吞吐和單次操作的延遲,以及訪問元數據引擎的延遲。

測試後可以去對象存儲中查看多了很多數據了。

生產環境部署

爲了保證 JuiceFS 文件系統能符合生產環境的要求,這裏我們給出瞭如下一些生產環境部署的建議。

  1. 監控指標收集與可視化

務必收集 JuiceFS 客戶端的監控指標並通過 Grafana 可視化。

  1. 元數據自動備份

元數據自動備份是自 JuiceFS v1.0.0 版本開始加入的特性

元數據對 JuiceFS 文件系統非常關鍵,一旦丟失或損壞將可能影響大批文件甚至整個文件系統。因此必須對元數據進行定期備份。

元數據自動備份特性默認開啓,備份間隔爲 1 小時,備份的元數據會經過壓縮後存儲至對應的對象存儲中(與文件系統的數據隔離)。備份由 JuiceFS 客戶端執行,備份期間會導致其 CPU 和內存使用量上升,默認情況下可認爲會在所有客戶端中隨機選擇一個執行備份操作。

特別注意默認情況下當文件系統的文件數達到一百萬時,元數據自動備份功能將會關閉,需要配置一個更大的備份間隔(--backup-meta 選項)纔會再次開啓。備份間隔每個客戶端獨立配置,設置 --backup-meta 0 則表示關閉元數據自動備份特性。

注意:備份元數據所需的時間取決於具體的元數據引擎,不同元數據引擎會有不同的性能表現。

  1. 回收站

回收站是自 JuiceFS v1.0.0 版本開始加入的特性

回收站默認開啓,文件被刪除後的保留時間默認配置爲 1 天,可以有效防止數據被誤刪除時造成的數據丟失風險。

不過回收站開啓以後也可能帶來一些副作用,如果應用需要經常刪除文件或者頻繁覆蓋寫文件,會導致對象存儲使用量遠大於文件系統用量。這本質上是因爲 JuiceFS 客戶端會將對象存儲上被刪除的文件或者覆蓋寫時產生的需要垃圾回收的數據塊持續保留一段時間。因此,在部署 JuiceFS 至生產環境時就應該考慮好合適的回收站配置,回收站保留時間可以通過以下方式配置(如果將 --trash-days 設置爲 0 則表示關閉回收站特性):

  1. 客戶端後臺任務

同一個 JuiceFS 文件系統的所有客戶端在運行過程中共享一個後臺任務集,每個任務定時執行,且具體執行的客戶端隨機選擇。具體的後臺任務包括:

由於這些任務執行時會佔用一定資源,因此可以爲業務較繁重的客戶端配置 --no-bgjob 選項來禁止其參與後臺任務。

注意:請保證至少有一個 JuiceFS 客戶端可以執行後臺任務

  1. 客戶端日誌滾動

當後臺運行 JuiceFS 掛載點時,客戶端默認會將日誌輸出到本地文件中。取決於掛載文件系統時的運行用戶,本地日誌文件的路徑稍有區別。root 用戶對應的日誌文件路徑是 /var/log/juicefs.log,非 root 用戶的日誌文件路徑是 $HOME/.juicefs/juicefs.log

本地日誌文件默認不會滾動,生產環境中爲了確保日誌文件不佔用過多磁盤空間需要手動配置。以下是一個日誌滾動的示例配置:

# /etc/logrotate.d/juicefs
/var/log/juicefs.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

通過 logrotate -d /etc/logrotate.d/juicefs 命令可以驗證配置文件的正確性。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/Uar9hlaLdlAL6IIhMWNotw