Curve 文件存儲在 Elasticsearch 冷熱數據存儲中的應用實踐
Elasticsearch在生產環境中有廣泛的應用，本文介紹一種方法，基于網易數帆開源的Curve文件存儲，實現Elasticsearch存儲成本、性能、容量和運維方面的顯著提升。
ES 使用 CurveFS 的四大收益
1、CurveFS提供的成本優勢
為了高可靠，ES如果使用本地盤的話一般會使用兩副本，也就是說存儲1PB數據需要2PB的物理空間。但是如果使用CurveFS，由于CurveFS的后端可以對接S3，所以可以利用對象存儲提供的EC能力，既保證了可靠性，又可以減少副本數量，從而達到了降低成本的目的。
以網易對象存儲這邊當前主流的EC 20+4使用為例，該使用方式就相當于是1.2副本。所以如果以ES需要1PB使用空間為例，那么使用CurveFS+1.2副本對象存儲只需要1.2PB空間，相比本地盤2副本可以節省800TB左右的容量，成本優化效果非常顯著。
2、CurveFS提供的性能優勢
以下文將要介紹的使用場景為例，對比ES原來使用S3插件做snapshot轉存儲的方式，由于每次操作的時候索引需要進行restore操作，以100G的日志索引為例，另外會有傳輸時間，如果restore的恢復速度為100M，那么也要300多秒。實際情況是在一個大量寫入的集群，這樣的操作可能要幾個小時。
而使用CurveFS后的新模式下基本上只要對freeze的索引進行unfreeze，讓對應節點的ES將對應的meta數據載入內存就可以執行索引，大概耗時僅需30S左右，相比直接用S3存儲冷數據有數量級的下降。
3、CurveFS提供的容量優勢
本地盤的容量是有限的，而CurveFS的空間容量可以在線無限擴展。同時減少了本地存儲的維護代價。
4、CurveFS提供的易運維優勢
ES使用本地盤以及使用S3插件方式，當需要擴容或者節點異常恢復時，需要增加人力運維成本。CurveFS實現之初的一個目標就是易運維，所以CurveFS可以實現數條命令的快速部署以及故障自愈能力。
另外如果ES使用CurveFS，就實現了存算分離，進一步釋放了ES使用者的運維負擔。
選用 CurveFS 的原因
背景： 在生產環境有大量的場景會用到ES做文檔、日志存儲后端，因為ES優秀的全文檢索能力在很多時候可以大大的簡化相關系統設計的復雜度。比較常見的為日志存儲，鏈路追蹤，甚至是監控指標等場景都可以用ES來做。
本地盤到 MinIO
為了符合國內的法律約束，線上系統需要按照要求存儲6個月到1年不等的系統日志，主要是國內等保、金融合規等場景。按照內部管理的服務器數量，單純syslog的日志存儲空間每天就需要1T，按照當前手頭有的5臺12盤位4T硬盤的服務器，最多只能存儲200多天的日子，無法滿足日志存儲1年的需求。
針對ES使用本地盤無法滿足存儲容量需求這一情況，網易ES底層存儲之前單獨引入過基于S3的存儲方案來降低存儲空間的消耗。如下圖，ES配合minio做數據存儲空間的壓縮。舉例來說100G的日志，到了ES里面因為可靠性需求，需要雙副本，會使用200G的空間。ES針對索引分片時間，定期性轉存儲到minio倉庫。
MinIO 到 CurveFS
這個方案從一定程度上緩解了存儲空間的資源問題，但是實際使用的時候還會感覺非常不便利。
- 運維成本。ES節點升級的時候需要額外卸載安裝S3插件，有一定的運維成本。
- 性能瓶頸。自己私有化搭建的Minio隨著bucket里面數據量的增長，數據存儲和抽取都會成為一個很大的問題
- 穩定性問題。在內部搭建的Minio集群在做數據restore的時候，因為文件處理性能等因素，經常遇到訪問超時等場景，所以一直在關注是否有相關的系統可以提供更好的讀寫穩定性。
由于S3協議經過多年的演化，已經成了對象存儲的工業標準。很多人都有想過用fuse的方式使用S3的存儲能力。事實上基于S3的文件系統有很多款，例如開源的s3fs-fuse、ossfs、RioFS、CurveFS等。
在通過實際調研以及大量的測試后，基于Curve的性能（尤其是元數據方面，CurveFS是基于RAFT一致性協議自研的元數據引擎，與其他沒有元數據引擎的S3文件系統(比如s3fs,ossfs)相比具備巨大的性能優勢），易運維，穩定性，Curve可以同時提供塊存儲以及文件存儲能力等能力以及Curve活躍的開源氛圍，最終選用了CurveFS。
CurveFS 結合 ES 的實踐
CurveFS簡介
CurveFS是一個基于 Fuse實現的兼容POSIX 接口的分布式文件系統，架構如下圖所示:
CurveFS由三個部分組成：
- 客戶端curve-fuse，和元數據集群交互處理文件元數據增刪改查請求，和數據集群交互處理文件數據的增刪改查請求。
- 元數據集群metaserver cluster，用于接收和處理元數據(inode和dentry)的增刪改查請求。metaserver cluster的架構和CurveBS類似，具有高可靠、高可用、高可擴的特點：MDS用于管理集群拓撲結構，資源調度。metaserver是數據節點，一個metaserver對應管理一個物理磁盤。CurveFS使用Raft保證元數據的可靠性和可用性，Raft復制組的基本單元是copyset。一個metaserver上包含多個copyset復制組。
- 數據集群data cluster，用于接收和處理文件數據的增刪改查。data cluster目前支持兩存儲類型：支持S3接口的對象存儲以及CurveBS（開發中）。
Curve除了既能支持文件存儲，也能支持塊存儲之外，從上述架構圖我們還能看出Curve的一個特點：就是CurveFS后端既可以支持S3，也可以支持Curve塊存儲。這樣的特點可以使得用戶可以選擇性地把性能要求高的系統的數據存儲在Curve塊存儲后端，而對成本要求較高的系統可以把數據存儲在S3后端。
ES使用CurveFS
CurveFS定位于網易運維的云原生系統，所以其部署是簡單快速的，通過CurveAdm工具，只需要幾條命令便可以部署起CurveFS的環境，具體部署見[1][2]；部署后效果如下圖:
在日志存儲場景，改造是完全基于歷史的服務器做的在線改造。下圖是線上日志的一個存儲架構示例，node0到node5可以認為是熱存儲節點，機器為12*4T，128G的存儲機型，每個節點跑3個ES實例，每個實例32G內存，4塊獨立盤。node6到node8為12*8T的存儲機型，3臺服務器跑一個Minio集群，每臺機器上的ES實例不做數據本地寫。
可以看到主要的改造重點是將node6到node8，3個節點進行ES的配置改造，其中以node6節點的配置為例：
如配置所示，主要的改造為調整ES的數據存儲目錄到CurveFS的fuse掛載目錄，然后新增 node.attr.box_type 的設置。在node6到node8上分別配置為cold，node1到node5配置對應屬性為hot，所有節點配置完成后進行一輪滾動重啟。
ES設置
除了底層配置外，很重要的一點就是調整index索引的設置。這塊的設置難度不高，要點是：
- 對應索引設置數據分配依賴和aliases。
- 設置對應的index Lifecycle policy。
其實在新節點開放數據存儲后，如果沒有親和性設置，集群馬上會啟動relocating操作。因此建議對存量的索引新增routing.alloction.require的設置來避免熱數據分配到CurveFS存儲節點。針對每天新增索引，建議加入以下這樣的index template配置。
這個index template設置的核心要點：
- routing部分要指定新索引寫到熱數據節點。
- lifecycle中的新增rollover_alias設置。
index部分的lifecycle是指索引的生命周期策略，需要注意rollover_alias里面的值要和下面的aliases定義對齊。
冷數據的切換，可以在kibana的index_lifecycle_management管理頁面設置。針對上面的syslog場景，hot部分設置如下圖，其余基本默認的就可以了。
在索引周期管理配置頁面中，除了設置hot phase，還可以設置warm phase，在warm phase可以做一些shrink，force merge等操作，日志存儲場景我們直接做hot到cold的處理邏輯。
從技術上講，日志存儲類型的業務，底層索引一旦完成寫后基本不做再次的數據更改，設置索引副本數量主要是為了應對分布式系統節點宕機等異常場景的數據恢復。如果存儲層面有更可靠的方式，那么自然而然可以將es的副本數量調整為0。因此杭研云計算存儲團隊研發的一款基于S3后端的存儲文件系統CurveFS，自然而然進入了冷數據選型的視野。從技術上講內部S3存儲基于EC糾刪碼的實現，通過降低ES的副本數量為0，可以明顯的降低對存儲空間的使用需求。
后續規劃
與 Curve 社區小伙伴溝通后，社區在 CurveFS 在存算分離方向的后續規劃為：
- Curve文件存儲后端完全支持Curve塊存儲，滿足一些場景下對性能的需求。預計2023 Q1發布。
- Curve文件存儲支持生命周期管理，支持用戶自定義數據冷熱，數據按需存儲在不同集群中。預計2023 Q2發布。
- Curve完全支持云原生部署。當前客戶端已經支持CSI，集群的部署支持預計2023 Q2發布。
