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

1.背景介紹

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

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

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

2.成本比對(duì)

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

資源型別	原價(jià)（元/年）	折扣價(jià)（元/年）
NAS存儲(chǔ)-通用型	36,864	27,648
OSS-標(biāo)準(zhǔn)本地冗余	13,272	9,954

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

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

3.部署過程

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

3.1 安裝

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

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

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

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

有兩個(gè)前置步驟這里略過：

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

2. 元數(shù)據(jù)存儲(chǔ)因?yàn)槭褂昧?MySQL，庫(kù)及賬號(hào)的創(chuàng)建也略過，創(chuàng)建的庫(kù)名和用戶名均為：juicefs。

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

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

最終我的創(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é)點(diǎn)執(zhí)行一次
2. 【KEY】【SECRET】【PASSWORD】【RDS-URL】需要更換為實(shí)際值

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

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

1. --update-fstab：更新 /etc/fstab，這樣節(jié)點(diǎn)重啟后，會(huì)自動(dòng)掛載。

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

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

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

注意：

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

3.4 設(shè)置掛載目錄權(quán)限

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

chown elasticsearch:elasticsearch /backup

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

3.5 注冊(cè)Elasticsearch 快照倉(cāng)庫(kù)

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

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

注意：每個(gè)節(jié)點(diǎn)都需要修改配置，修改后需要重啟服務(wù)

每個(gè)節(jié)點(diǎn)重啟后，可以通過?Kibana?或者使用 Elasticsearch Snapshot API 注冊(cè)。

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?是快照倉(cāng)庫(kù)的名稱，可自定義

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

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

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

4. 踩坑經(jīng)歷

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

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

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

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

5.結(jié)語(yǔ)

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

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

希望這篇內(nèi)容能夠?qū)δ阌幸恍椭绻衅渌蓡枤g迎加入 JuiceFS 社區(qū)與大家共同交流。

總結(jié)

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

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