背景
稿定科技旗下稿定設計產品是一個聚焦商業設計的多場景線上設計平臺，打破了軟硬體間的技術限制，彙集創意內容與設計工具於一體，為不同場景下的設計需求提供優質的解決方案，滿足圖片、視訊等全型別媒介的設計需求，讓設計更簡單。
稿定科技使用 Elasticsearch（下文中簡稱為 ES） 作為日誌檢索元件，隨著業務量的增長，每天有 2T 左右的新增資料，需要儲存 15~30 天，給磁碟和系統帶來了不小的壓力。在 ES 中為了保證日誌的寫入和查詢的效能，大多使用單位儲存成本更高的高效能雲盤。但是，在實際的業務場景中，超過 7 天的資料僅作低頻使用，全部儲存在高效能雲盤必然會導致過高的成本和空間的浪費。
方案
Elasticsearch 7.10 版本推出了索引生命週期概念，開始支援資料分層儲存，可以指定不同節點使用不同的磁碟介質來區分冷熱資料，比如使用 HDD 磁碟來儲存溫冷資料，能獲得更大的使用空間和更低的成本。這個特性非常適合日誌索引場景。
在溫冷資料的儲存介質上，使用 JuiceFS 替代 HDD 磁碟，相當於獲得了無限容量的儲存空間。通過 ES 的索引生命週期管理，可以自動完成索引的建立 - 遷移 - 銷燬整個生命週期管理，無需手工干預。
在我們的實踐中，首先將 ES 叢集升級到目前最新的 7.13 版本。然後拆分冷熱節點，熱節點優先考慮效能，冷節點優先考慮儲存的容量和成本。同時，調整索引和模板方式，配置資料生命週期、索引模板和資料流，完成索引資料寫入。
調整後整個索引的流轉如下圖所示：
在索引建立時，配置 index.routing.allocation.require.box_type:hot 進行節點篩選；
等待索引進入 warm 週期時，調整 index.routing.allocation.require.box_type:warm，並遷移到 warm 節點後，資料進入冷節點儲存，實際儲存於 JuiceFS 中；
等待索引進入 delete 週期時，ES 會自動把索引資料刪除。
客戶收益
方案中使用的 JuiceFS 是什麼呢？
JuiceFS 是一款面向雲環境設計的企業級分散式檔案系統。提供完備的 POSIX 相容性，為應用提供一個低成本、空間無限的共享檔案系統。使用 JuiceFS 儲存資料，資料本身會被持久化在物件儲存（例如，Amazon S3、阿里雲 OSS 等），結合 JuiceFS 的後設資料服務來提供高效能檔案儲存。JuiceFS 在全球公有云服務中都提供有全託管服務，只需點點滑鼠，十分鐘配置好。同時 JuiceFS 在 2021年初在 GitHub 開源，受到全球開發者的關注和參與，目前已經獲得 3700+ stars。
在本方案中 ES 叢集 warm 節點使用 JuiceFS 做儲存之後，我們不用再對這些節點做容量規劃和擴容工作，也省去了節點故障時的資料遷移，降成本的同時還為運維帶來很大的便利。
JuiceFS 的持久層使用物件儲存，彈性計費，TCO 比使用普通雲盤還要低。在本方案的 ES 叢集中，Hot 節點使用的雲盤價格為 1000元/TB/月，使用全託管的 JuiceFS 服務加上物件儲存的開銷，價格約為 250元/TB/月。ES 叢集總容量 60TB+，通過冷熱分層處理，75% 的資料存在 JuiceFS 中，僅儲存成本已經節省近 60%。如果再加上運維團隊節省的時間精力，這個方案為客戶的資料儲存帶來的 TCO 下降至少有 70%。
實踐
叢集配置
叢集共 9 個節點，⼀個獨⽴的 master 節點（elastic_001），另外 8 個資料節點，其中有 5 個熱資料節點（elastic_002 ~ elastic_006），3 個冷資料節點（elastic_007 ~ elastic_009）。
目錄掛載與配置
JuiceFS 掛載在 ES 冷資料節點，提供 ES 的資料⽬錄。
節點配置有⼀塊 2T 的資料盤，掛載在 /data ⽬錄，ES 程式以容器的⽅式啟動，資料盤掛載的是系統的 /data/elastic ⽬錄，由於使⽤的容器掛載系統⽬錄的⽅式，不能通過 軟鏈 的⽅式將 ES 資料⽬錄 ( /data/elastic ) 指向 JuiceFS 掛載的某個⼦⽬錄，使⽤了 Linux 系統的 bind mount 將 JuiceFS 的⼦⽬錄掛載到 /data/elastic 這個路徑上。⽐如在 007 節點上：
# ./juicefs mount gd-elasticsearch-jfs \
--cache-dir=/data/jfsCache --cache-size=307200 \
--upload-limit=800 /jfs
# mount -o bind /jfs/data-elastic-pro-007 /data/elastic
這樣在 /data/elastic ⽬錄看到 /jfs/data-elastic-pro-007 的內容。
在 008 和 009 節點上也做類似掛載操作。
如果您還不熟悉 JuiceFS 的初始化、掛載等基本操作，請參考 JuiceFS 官方文件。
ES 索引 Rollover 時有很多隨機寫操作，為了保證寫的效能，掛載 JuiceFS 時加上了 writeback 引數，這樣會資料先寫本地磁碟，後臺非同步將資料上傳到物件儲存。本地磁碟⽬錄使⽤的是 /data/jfsCache/gd-elasticsearch-jfs/rawstaging/ ，請注意不要刪除這個⽬錄中的任何⽂件，否則可能出現資料丟失。
cache-size 和 upload-limit 分別⽤來限制本地的讀快取使⽤空間為 300GiB，寫物件儲存的頻寬不超過 800Mbps。attrcacheto 和 entrycacheto 分別表示核心的 attr cache 和 entry cache 的快取超時時間，單位是秒。
效能優化
降低節點負載
在採用 JuiceFS 之前，ES 叢集生命週期中配置了 Force Merge，具體配置項為 warm.actions.forcemerge.max_num_segments: 1，它會導致資料在 Rollover 時重新 Merge，給 CPU 帶來極大的壓力。而這步動作是完全沒必要的，關閉 Force Merge 配置即可避免不必要的效能開銷，降低節點負載。
Rollover 引數配置優化
由於 warm 階段資料寫入 JuiceFS，最終會持久化到物件儲存上，應用層不用再儲存多副本，可以在索引 Rollover 過程中，設定 replicas 為 0，即 warm.actions.number_of_replicas: 0。
另外，考慮當索引資料遷移到 warm 階段後，資料並不再寫入，可以設定 warm 階段索引只讀，即 warm.actions.readonly: {}，關閉索引的資料寫入可以減少記憶體佔用量。
總結
隨著時間的推移和業務量的增長，企業勢必面臨更大規模的資料儲存和管理上的雙重挑戰。在本案中，稿定科技充分發揮 Elasticsearch 的生命週期管理能力，根據業務需要將日誌資料進行分層儲存。將需要頻繁使用的熱資料儲存在 SSD，而超過 7 天的低頻使用資料則儲存在價效比更高的 JuiceFS，為客戶節省儲存成本 60%。同時，JuiceFS 還為應用提供近乎無限的彈性空間，省去了容量規劃、擴容、資料遷移等一系列的運維工作，提升了企業 IT 架構的效率。
推薦閱讀：
Shopee x JuiceFS：ClickHouse 冷熱資料分離儲存架構與實踐
JuiceFS v0.17 釋出，通過 1270 項 LTP 測試！