JuiceFS v1.0 beta3 釋出，支援 etcd、Amazon MemoryDB、Redis Cluster

JuiceFS發表於2022-05-09
UIRedis

JuiceFS v1.0 beta3 在後設資料引擎方面繼續增強，新增 etcd 支援小於 200 萬檔案的使用場景，相比 Redis 可以提供更好的可用性和安全性。同時支援了 Amazon MemoryDB for Redis 和 Redis Cluster。至此，JuiceFS 支援的後設資料引擎有：

  1. Redis：包括單機、Sentinel 和 Cluster 模式，適合小於 1 億檔案，同時追求高效能的場景。基於 AOF 的非同步複製有少量資料丟失的風險，Amazon MemoryDB for Redis 使用同步資料複製，資料安全性更高；
  2. 關係型資料庫：包括 MySQL、MariaDB、PostgreSQL，適合資料安全要求高，效能要求不高的場景；
  3. TiKV：適合海量檔案（1 億以上），對效能與資料安全都有高要求的場景，但運維門檻比前面的方案高；
  4. etcd：適合小於 200 萬檔案並且可用性與資料安全要求高的場景；
  5. 嵌入式資料庫：包括 BadgerDB 和 SQLite，適合不需要多機訪問的場景使用。

除了後設資料引擎的升級，JuiceFS S3 閘道器也提供了多租戶、許可權設定等高階功能，同時支援了非 UTF-8 編碼的檔名。

本次更新共有 22 位社群貢獻者參與貢獻了超過 240 次提交，感謝每一位的付出，也歡迎正在讀文章的你參與到 JuiceFS 社群中來。

下面，來為你解讀一下 JuiceFS v1.0 beta3 的詳細變化。

新增 etcd 後設資料引擎

etcd 是一個資料可靠的分散式 KV 儲存系統，在 Kubernetes 中廣泛使用，etcd 的資料修改會同步寫到磁碟上，保證資料安全，通過 Raft 共識演算法實現資料複製和故障切換，實現高可用。相比使用非同步落盤和非同步複製的 Redis 有更好的資料安全性和可用性。

但 etcd 能夠支撐的資料規模比較有限，從實際測試來看，小於 200 萬檔案時，是個不錯的選擇。

使用方法與其他引擎類似，協議頭為 etcd://，例如：

# 建立檔案系統
$ juicefs format etcd://localhost:2379/myjfs jfs-etcd
# 掛載檔案系統
$ juicefs mount -d etcd://localhost:2379/myjfs /mnt/jfs

關於 etcd 的效能表現，請檢視《後設資料引擎效能測試文件》。

支援 Redis Cluster 和 Amazon MemoryDB for Redis

由於 JuiceFS 依賴資料庫事務保證資料強一致性，而 Redis Cluster 採用分片機制將資料分散在不同的分片上，但不支援跨分割槽的事務，導致不能使用 Redis Cluster 作為 JuiceFS 的後設資料引擎。

v1.0 beta3 通過使用固定字首的方式讓所有的資料都分配到單一的 Redis 分割槽中，從而保證了 Redis 事務功能不受影響。這個方法不能充分享受 Redis 叢集的資料分片能力，但可以獲得資料複製和選舉方面的便利（類似於哨兵模式）。另外，這種字首方式類似於單機模式的多庫功能，有無限的擴充套件能力，適用於有很多小規模檔案系統的場景。

AWS 最新發布的 MemoryDB for Redis 只提供叢集模式，相比 ElastiCache 或者自己維護的 Redis，它的同步資料複製提供了更高的資料安全保證（但寫入延遲更高），適用於對資料的安全性要求非常高，寫少讀多的場景。因為所有後設資料都會集中在單個分片中，推薦使用一個分割槽加一份複製的部署模式（類似於主從模式），後續通過更換為更大記憶體的節點方式來擴容。

碎片延遲清理功能

JuiceFS 在讀寫檔案時，如果該檔案的資料碎片過多，就會自動觸發碎片合併流程，將碎片聚合成大段資料並清理掉舊的碎片。

然而，在後設資料遷移、故障恢復等場景中，使用者可能需要使用舊版本的後設資料備份，此時如果資料碎片已被清理，就會導致相關檔案讀取失敗。

另外，當 Redis 丟失少量後設資料時，也可能因為部分檔案使用了已經被清理的碎片而損壞。

為了解決上述問題，在 v1.0 beta3 中加入了碎片延遲清理功能，對於開啟了回收站的檔案系統，碎片會被延遲刪除，超過設定的回收站時間後才被自動清理，也可以用 gc 命令手動清理。

增強 Sync 命令

v1.0 beta3 進一步調整了 Sync 命令的功能，使其在用法上與大家熟知的 rsync 工具儘量保持一致，減少上手成本。

調整了用於過濾檔案列表的 --include 和 --exclude 的用法，跟 rsync 保持一致，允許指定多個過濾規則，根據它們在命令列中的順序和 Bash 萬用字元進行匹配，幾乎可以實現任意集合的檔案篩選需要，更具體的用法請參照 rsync 的文件。

Sync 命令預設會拷貝符號連結的目標檔案，可以通過 --links 引數調整為拷貝符號連結本身。

另外，還加了一個 --limit 引數用於限制操作的檔案個數，當設定為 1 時表示不進行遞迴遍歷。

S3 閘道器功能升級

JuiceFS 的 S3 閘道器是基於 MinIO 的早期版本實現的，並且裁剪了一些非必要的功能。新版本的 MinIO 改用了 AGPL 協議，不能被 JuiceFS 直接升級使用。

現在採取了反向整合的策略，在支援閘道器功能的最新版 MinIO 上整合 JuiceFS v1.0 beta3，整體基於 AGPL 協議開源，這樣可以使用新版本的 MinIO 提供的多租戶、許可權設定等更多高階功能，詳情請參考 S3 閘道器文件。

JuiceFS 仍然內建了基礎版的 S3 閘道器功能，而更完整的版本請使用這個反向整合的版本，程式碼請見。

其它新功能

  1. 支援 TLS 加密連線 TiKV 後設資料引擎。
  2. 建立檔案系統時，可以通過 --hash-prefix 選項為資料寫入物件儲存時新增雜湊字首。很多物件儲存有基於字首的 QPS 限制或者系統瓶頸，通過該特性可以繞過這類限制以獲得更好的效能。注意，已有資料寫入的舊檔案系統無法更改此選項。
  3. 掛載檔案系統時，可以通過 --heartbeat 選項設定客戶端的心跳間隔，這在一些關注故障切換時間的場景下能發揮作用。注意，預設的心跳過期時間已由 60s 調整為 12s。
  4. 資料儲存增加 Oracle Object Storage 支援。
  5. Java SDK 支援上報監控指標到 Graphite 或者相容的系統。
  6. SQL 引擎支援非 UTF-8 編碼的檔名，已有的檔案系統需要升級客戶端後再修改資料庫的表結構。

其它變化

  1. 在新建檔案系統時，會自動在資料儲存中寫入一個記錄了 UUID 的佔位物件，避免其他檔案系統重複使用相同的資料儲存造成混淆。
  2. juicefs dump 命令會自動隱藏物件儲存的 secret key 防止洩漏敏感資訊。
  3. 改用加密形式儲存物件儲存訪問金鑰，減小安全隱患；已有的檔案系統可通過 juicefs config META-URL --encrypt-secret 命令調整加密模式。注意，修改後舊版客戶端將無法掛載。
  4. 調整後設資料預設備份機制，當檔案數多於一百萬時，需要使用者顯式指定備份週期。
  5. 在 Linux 下使用非 root 使用者掛載時，將預設的快取和日誌目錄改為此使用者的家目錄，避免因許可權不足而失敗。
  6. 改進了往 Redis 和 SQL 資料庫匯入大型目錄（超過一百萬檔案）的能力。
  7. 為關係型資料庫所有表結構增加主鍵，提升日誌複製效能，詳情參考。

升級建議

請在升級新版前注意評估以下幾個變化：

會話管理格式調整

自 v1.0 beta3 開始，會話管理使用了新的格式，舊版本客戶端通過 juicefs status 或者 juicefs destroy 無法看到 v1.0 beta3 的會話，新版客戶端可以看到所有會話。

SQL 表結構調整，支援非 UTF-8 編碼檔名

為了更好地支援非 UTF-8 編碼的檔名，在 JuiceFS v1.0 beta3 中修改了關係型資料庫的表結構。

對於正在使用 MySQL、MariaDB、PostgreSQL 的使用者，如果需要讓已有的檔案系統支援非 UTF-8 編碼的檔名，需要手動修改表結構，詳情請參考文件。

修復的 Bug

  1. 修復了後設資料備份失敗時可能導致部分記憶體未及時釋放問題。
  2. 修復了使用 SQL 作為後設資料引擎時，掃描函式返回結果可能不正確問題。
  3. 修復了使用 juicefs load 命令載入後設資料時部分計數器可能統計不準確問題。
  4. 修復了物件儲存開啟多 buckets 時，掃描物件列表結果不正確問題。
  5. 修復了使用 Ceph RADOS 做物件儲存時，物件數過多時掃描卡住問題。

詳細的 Bug 修復列表請看 https://github.com/juicedata/juicefs/releases/tag/v1.0.0-beta3

快去下載體驗吧，Juicedata/JuiceFS

相關文章