基于JuiceFS 的低成本 Elasticsearch 云上备份存储
杭州火石創造是國內專注于產業大數據的數據智能服務商，為了解決數據存儲及高效服務客戶需求，選擇了?Elasticsearch?搜索引擎進行云上存儲。基于性能和成本的考慮，在阿里云選擇用本地 SSD ECS 機型自建集群。但由于是自建集群，如何同步解決數據備份問題并實現最優成本呢？
1.背景介紹
Elasticsearch 的數據備份是通過快照機制實現的。為了完成集群的快照，需要依賴一個共享存儲系統，即所有節點需要掛載到共享存儲的同一個目錄，并且每個節點對此目錄需有讀寫權限，最初我們使用 NAS（即 NFS）來實現備份，這個方案也已經穩定運行多年。
在此，我還是再強調一下數據備份重要性。很多小伙伴誤認為 Elasticsearch 具備副本機制，只要配置多副本就不怕數據丟失，為什么還要備份呢？需要指出是：再多的副本禁不住一個 DELETE 誤操作；而且副本機制也要平衡成本，是在一定程度內的冗余，超過閾值一樣會造成數據丟失，備份是業務持續性重要保障，有備才能無患！
云上成本的持續優化是運維人員始終面臨的挑戰。Snowflake 使用 S3 存儲在成本效率方面給了我們很大的觸動。接觸到?JuiceFS?后，我們認為這是一款非常不錯的存儲產品。本著循序漸進原則，備份存儲是一個非常不錯的切入點，于是便有了基于 JuiceFS 來構建通用低成本云上備份存儲解決方案，并著手實踐。
2.成本比對
本文的標題就是低成本，成本低在哪里呢，我們用數據說話，以 10T NAS 和 OSS 資源包價格對比如下表所示：
| 資源型別 | 原價（元/年） | 折扣價（元/年） |
|---|---|---|
| NAS存儲-通用型 | 36,864 | 27,648 |
| OSS-標準本地冗余 | 13,272 | 9,954 |
如果使用 OSS 替代 NAS，成本降低為原來 36%，接近 1/3，降本效果可謂顯著，沖這咱就必須干！
等下，其他成本呢？JuiceFS 社區版還需要元數據存儲，確實，這個也是需要計算成本。但是這年頭，誰家的云上沒有一個共享或者輔助用 RDS，作為備份系統，對 IO 的隨機讀寫需求不高，這里咱就共享一個 MySQL RDS 來作為元數據存儲。
3.部署過程
部署過程基本參照 JuiceFS 的官方文檔完成，具體分成了三個步驟：
3.1 安裝
安裝過程很簡單，一條命令搞定。默認是在安裝 /usr/local/bin 下，考慮到不是所有的操作系統都是將該目錄作為 PATH 的默認路徑，從更加通用和省事的角度，我建議安裝到 /usr/sbin 目錄下，執行安裝命令：
curl -sSL https://d.juicefs.com/install | sh - /usr/sbin
注意：該命令在所有的節點都要執行（所有的節點都要安裝）
3.2 創建文件系統
有兩個前置步驟這里略過：
-
OSS 的 Bucket 及 AK 的準備這里略過，創建的 Bucket 名為:?
juicefs-backup； -
元數據存儲因為使用了 MySQL，庫及賬號的創建也略過，創建的庫名和用戶名均為：juicefs。
有個小插曲，因為元數據使用了 MySQL，官方文檔快速上手及元數據引擎最佳實踐兩個章節找不到參考和范例，有?PostgreSQL?沒有 MySQL，開始我照貓畫虎參照 PostgreSQL 寫法，提示語法不對，最后在參考-如何設置元數據引擎章節找到了相關說明：
為啥要加這個括號我不是很理解，只能表示不明覺厲。不過建議官方文檔元數據引擎最佳實踐環節增加 MySQL 章節，這樣前后可以呼應，方便讀者查閱。
最終我的創建命令如下：
juicefs format \
--storage oss \
--bucket juicefs-backup.oss-cn-hangzhou-internal.aliyuncs.com \
--access-key 【KEY】 \
--secret-key 【SECRET】 \
mysql://juicefs:【PASSWORD】@(【RDS-URL】:3306)/juicefs \
elasticsearch
注意：
- 本條命令只需要在任一節點執行一次
- 【KEY】【SECRET】【PASSWORD】【RDS-URL】需要更換為實際值
3.3 掛載文件系統
掛載命令如下：
juicefs mount \
--update-fstab \
--background \
--writeback \
--cache-dir /data/juicefs-cache \
--cache-size 10240 \
-o user_id=$(id -u elasticsearch) \
mysql://juicefs:【PASSWORD】@\(【RDS-URL】:3306\)/juicefs \
/backup
掛載相關參數說明如下：
-
--update-fstab：更新/etc/fstab，這樣節點重啟后，會自動掛載。 -
--writeback：把數據寫入本地緩存后再寫到 OSS，提升備份效率，作為備份用途建議開啟。 -
--cache-dir /data/juicefs-cache和--cache-size 10240：在 Elasticsearch 存儲 SSD 上劃出 10G 作為緩存（默認值是 100GB，考慮到成本因素，選用了 10GB），提高讀寫性能。 -
-o user_id=$(id -u elasticsearch): 允許 elasticsearch 用戶讀寫，經咨詢官方工程師，這個參數不指定也可以。
注意：
- 本條命令需要在每個節點執行一次
- 【PASSWORD】【RDS-URL】需要更換為實際值
3.4 設置掛載目錄權限
最后要確保掛載的目錄能被 Elasticsearch 讀寫
chown elasticsearch:elasticsearch /backup
注意：本條命令需要在任一節點執行一次即可
3.5 注冊Elasticsearch 快照倉庫
首先需要在 Elasticsearch 的配置文件 elasticsearch.yaml 中配置 path.repo ,比如：
path:
??????repo:?
?????????????- /backup
注意：每個節點都需要修改配置，修改后需要重啟服務
每個節點重啟后，可以通過?Kibana?或者使用 Elasticsearch Snapshot API 注冊。
PUT?_snapshot/es-backup
{
????"type":?"fs",
????"settings":?{
??????"location":?"'/backup'",
??????"compress":?"true",
??????"max_snapshot_bytes_per_sec":?"100m",
??????"max_restore_bytes_per_sec":?"100m"
????}
??}
參數說明：
-
es-bakup?是快照倉庫的名稱，可自定義 -
compress?是否啟用壓縮，我們是啟用，可以節約空間占用 -
max_snapshot_bytes_per_sec/max_restore_bytes_per_sec?最大快照及恢復的速度根據自己的情況設置，我們設定為：100M/秒
最后，具體備份實施的操作這里就不再細寫，可參考Elasticsearch 官方文檔。
4. 踩坑經歷
完成上述準備工作后，本來滿心歡喜坐等備份成功，不想卻出現了新事物嘗試路上必有姿勢：踩坑！
在備份點創建過程中出現了個別節點的權限異常問題，這個就碰到分布式集群讀寫共享存儲的共性問題：不同節點進程的 username 和 id 是否完全一致？解決這個問題一般有兩個思路：
-
不動現有的環境，通過用戶映射的方式來解決這個問題，毫無疑問，這當然是最佳的方式。但是我翻了好幾遍官方文檔，并嘗試根據節點 Elasticsearch 用戶不同的 id 來掛載（見3.3 掛載命令），驗證結果掛載的文件系統的用戶屬性還是取決于實際進程；于是就想到了 NFS 文件系統有個參數叫?
all_squash，即將所有的用戶都映射到一個特定的用戶比如 nobody 上，但是很遺憾，JiuceFS 目前只能實現 root_squash，做不到 all_squash ，此問題最后反饋了 JuiceFS 的開發人員，詳見 Github 上的?PR。 -
改變現有的環境，使所有的 Elasticsearch 用戶的 id 保持一致，得益于 Elasticsearch 優秀的容災遷移能力，最終我通過在特定節點重裝了一下 Elasticserach 來解決這個問題（最后發現其實這個問題的產生源于 Elasticsearch 和 kibana 安裝先后順序）。
5.結語
通過上述步驟及措施的實施，最后 Elasticsearch 快照備份方案最終實現并持續運作，備份的效率也完全不輸 NAS 存儲。
本文以分布式集群備份為例，其方案完全可以用在其他各種單機系統備份中，同時借助 JuiceFS 廣泛的數據存儲和元數據引擎的適配性，也可以使其成為一個通用的低成本云上備份存儲解決方案。
希望這篇內容能夠對你有一些幫助，如果有其他疑問歡迎加入 JuiceFS 社區與大家共同交流。
總結
以上是生活随笔為你收集整理的基于JuiceFS 的低成本 Elasticsearch 云上备份存储的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 不懂乐理,也能扒谱,基于openvpi将
- 下一篇： 在Dash中更灵活地编写回调函数