杭州火石創(chuàng)造是國內專注于產(chǎn)業(yè)大數(shù)據(jù)的數(shù)據(jù)智能服務商，為了解決數(shù)據(jù)存儲及高效服務客戶需求，選擇了?Elasticsearch?搜索引擎進行云上存儲。基于性能和成本的考慮，在阿里云選擇用本地 SSD ECS 機型自建集群。但由于是自建集群，如何同步解決數(shù)據(jù)備份問題并實現(xiàn)最優(yōu)成本呢？

1.背景介紹

Elasticsearch 的數(shù)據(jù)備份是通過快照機制實現(xiàn)的。為了完成集群的快照，需要依賴一個共享存儲系統(tǒng)，即所有節(jié)點需要掛載到共享存儲的同一個目錄，并且每個節(jié)點對此目錄需有讀寫權限，最初我們使用 NAS（即 NFS）來實現(xiàn)備份，這個方案也已經(jīng)穩(wěn)定運行多年。

在此，我還是再強調一下數(shù)據(jù)備份重要性。很多小伙伴誤認為 Elasticsearch 具備副本機制，只要配置多副本就不怕數(shù)據(jù)丟失，為什么還要備份呢？需要指出是：再多的副本禁不住一個 DELETE 誤操作；而且副本機制也要平衡成本，是在一定程度內的冗余，超過閾值一樣會造成數(shù)據(jù)丟失，備份是業(yè)務持續(xù)性重要保障，有備才能無患！

云上成本的持續(xù)優(yōu)化是運維人員始終面臨的挑戰(zhàn)。Snowflake 使用 S3 存儲在成本效率方面給了我們很大的觸動。接觸到?JuiceFS?后，我們認為這是一款非常不錯的存儲產(chǎn)品。本著循序漸進原則，備份存儲是一個非常不錯的切入點，于是便有了基于 JuiceFS 來構建通用低成本云上備份存儲解決方案，并著手實踐。

2.成本比對

本文的標題就是低成本，成本低在哪里呢，我們用數(shù)據(jù)說話，以 10T NAS 和 OSS 資源包價格對比如下表所示：

資源型別	原價（元/年）	折扣價（元/年）
NAS存儲-通用型	36,864	27,648
OSS-標準本地冗余	13,272	9,954

如果使用 OSS 替代 NAS，成本降低為原來 36%，接近 1/3，降本效果可謂顯著，沖這咱就必須干！

等下，其他成本呢？JuiceFS 社區(qū)版還需要元數(shù)據(jù)存儲，確實，這個也是需要計算成本。但是這年頭，誰家的云上沒有一個共享或者輔助用 RDS，作為備份系統(tǒng)，對 IO 的隨機讀寫需求不高，這里咱就共享一個 MySQL RDS 來作為元數(shù)據(jù)存儲。

3.部署過程

部署過程基本參照 JuiceFS 的官方文檔完成，具體分成了三個步驟：

3.1 安裝

安裝過程很簡單，一條命令搞定。默認是在安裝 /usr/local/bin 下，考慮到不是所有的操作系統(tǒng)都是將該目錄作為 PATH 的默認路徑，從更加通用和省事的角度，我建議安裝到 /usr/sbin 目錄下，執(zhí)行安裝命令：

curl -sSL https://d.juicefs.com/install | sh - /usr/sbin

注意：該命令在所有的節(jié)點都要執(zhí)行（所有的節(jié)點都要安裝）

3.2 創(chuàng)建文件系統(tǒng)

有兩個前置步驟這里略過：

1. OSS 的 Bucket 及 AK 的準備這里略過，創(chuàng)建的 Bucket 名為:?juicefs-backup；

2. 元數(shù)據(jù)存儲因為使用了 MySQL，庫及賬號的創(chuàng)建也略過，創(chuàng)建的庫名和用戶名均為：juicefs。

有個小插曲，因為元數(shù)據(jù)使用了 MySQL，官方文檔快速上手及元數(shù)據(jù)引擎最佳實踐兩個章節(jié)找不到參考和范例，有?PostgreSQL?沒有 MySQL，開始我照貓畫虎參照 PostgreSQL 寫法，提示語法不對，最后在參考-如何設置元數(shù)據(jù)引擎章節(jié)找到了相關說明：

為啥要加這個括號我不是很理解，只能表示不明覺厲。不過建議官方文檔元數(shù)據(jù)引擎最佳實踐環(huán)節(jié)增加 MySQL 章節(jié)，這樣前后可以呼應，方便讀者查閱。

最終我的創(chuàng)建命令如下：

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

注意：

1. 本條命令只需要在任一節(jié)點執(zhí)行一次
2. 【KEY】【SECRET】【PASSWORD】【RDS-URL】需要更換為實際值

3.3 掛載文件系統(tǒng)

掛載命令如下：

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

掛載相關參數(shù)說明如下：

1. --update-fstab：更新 /etc/fstab，這樣節(jié)點重啟后，會自動掛載。

2. --writeback：把數(shù)據(jù)寫入本地緩存后再寫到 OSS，提升備份效率，作為備份用途建議開啟。

3. --cache-dir /data/juicefs-cache 和 --cache-size 10240：在 Elasticsearch 存儲 SSD 上劃出 10G 作為緩存（默認值是 100GB，考慮到成本因素，選用了 10GB），提高讀寫性能。

4. -o user_id=$(id -u elasticsearch): 允許 elasticsearch 用戶讀寫，經(jīng)咨詢官方工程師，這個參數(shù)不指定也可以。

注意：

1. 本條命令需要在每個節(jié)點執(zhí)行一次
2. 【PASSWORD】【RDS-URL】需要更換為實際值

3.4 設置掛載目錄權限

最后要確保掛載的目錄能被 Elasticsearch 讀寫

chown elasticsearch:elasticsearch /backup

注意：本條命令需要在任一節(jié)點執(zhí)行一次即可

3.5 注冊Elasticsearch 快照倉庫

首先需要在 Elasticsearch 的配置文件 elasticsearch.yaml 中配置 path.repo ,比如：

path:
??????repo:?
?????????????- /backup

注意：每個節(jié)點都需要修改配置，修改后需要重啟服務

每個節(jié)點重啟后，可以通過?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"
????}
??}

參數(shù)說明：

1. es-bakup?是快照倉庫的名稱，可自定義

2. compress?是否啟用壓縮，我們是啟用，可以節(jié)約空間占用

3. max_snapshot_bytes_per_sec/max_restore_bytes_per_sec?最大快照及恢復的速度根據(jù)自己的情況設置，我們設定為：100M/秒

最后，具體備份實施的操作這里就不再細寫，可參考Elasticsearch 官方文檔。

4. 踩坑經(jīng)歷

完成上述準備工作后，本來滿心歡喜坐等備份成功，不想?yún)s出現(xiàn)了新事物嘗試路上必有姿勢：踩坑！

在備份點創(chuàng)建過程中出現(xiàn)了個別節(jié)點的權限異常問題，這個就碰到分布式集群讀寫共享存儲的共性問題：不同節(jié)點進程的 username 和 id 是否完全一致？解決這個問題一般有兩個思路：

1. 不動現(xiàn)有的環(huán)境，通過用戶映射的方式來解決這個問題，毫無疑問，這當然是最佳的方式。但是我翻了好幾遍官方文檔，并嘗試根據(jù)節(jié)點 Elasticsearch 用戶不同的 id 來掛載（見3.3 掛載命令），驗證結果掛載的文件系統(tǒng)的用戶屬性還是取決于實際進程；于是就想到了 NFS 文件系統(tǒng)有個參數(shù)叫?all_squash，即將所有的用戶都映射到一個特定的用戶比如 nobody 上，但是很遺憾，JiuceFS 目前只能實現(xiàn) root_squash，做不到 all_squash ，此問題最后反饋了 JuiceFS 的開發(fā)人員，詳見 Github 上的?PR。

2. 改變現(xiàn)有的環(huán)境，使所有的 Elasticsearch 用戶的 id 保持一致，得益于 Elasticsearch 優(yōu)秀的容災遷移能力，最終我通過在特定節(jié)點重裝了一下 Elasticserach 來解決這個問題（最后發(fā)現(xiàn)其實這個問題的產(chǎn)生源于 Elasticsearch 和 kibana 安裝先后順序）。

5.結語

通過上述步驟及措施的實施，最后 Elasticsearch 快照備份方案最終實現(xiàn)并持續(xù)運作，備份的效率也完全不輸 NAS 存儲。

本文以分布式集群備份為例，其方案完全可以用在其他各種單機系統(tǒng)備份中，同時借助 JuiceFS 廣泛的數(shù)據(jù)存儲和元數(shù)據(jù)引擎的適配性，也可以使其成為一個通用的低成本云上備份存儲解決方案。

希望這篇內容能夠對你有一些幫助，如果有其他疑問歡迎加入 JuiceFS 社區(qū)與大家共同交流。

總結

以上是生活随笔為你收集整理的基于JuiceFS 的低成本 Elasticsearch 云上备份存储的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。