Elasticsearch 是一個開源的分佈式 RElasticsearchTful 搜索引擎,作爲一個分佈式、可擴展、實時的搜索與數據分析引擎,它可以快速存儲、搜索和分析大量數據。同時,Elasticsearch 也支持具有負責搜索功能和要求的應用程序的基礎引擎, 因此可以應用在很多不同的場景中。
Elasticsearch 在京東的使用場景
由於較高的性能和較低的使用門檻,京東內部有很多的場景都在使用 Elasticsearch。
2015 年 6 月,京東着手開發了 Elasticsearch 的託管平臺——傑思 (JElasticsearch)。傑思平臺主要負責 Elasticsearch 集羣的部署、運行監控、數據遷移、權限管理、插件開發、集羣升級等日常維護工作。
目前傑思平臺管理的集羣覆蓋了京東多條業務線,同時也覆蓋了很多應用場景:
補充關係型數據庫的結構化數據查詢
主要應用的業務是商品、促銷、優惠券、訂單、收銀臺、物流、對賬、評論等大數據量查詢。此場景的核心訴求是高性能、穩定性和高可用性,部分場景會有檢索要求,通常用於加速關係型數據庫,業務系統通過 binlog 同步或業務雙寫完成數據同步。
全文檢索功能
主要的應用場景是應用、安全、風控、交易等操作日誌,以及京東部分品類商品搜索。此類日誌化場景對寫要求很高,查詢性能及高可用等要求相對較低,大的業務寫會達到數千萬 / 秒,存儲以 PB 爲單位來計算。
這些場景對磁盤、內存有比較高的要求,因此,京東也做了相應優化,用於減少內存消耗,提升磁盤整體使用率,使用更廉價的磁盤來降低成本等等。
實時數據分析引擎,形成統計報表
主要應用的業務是物流單的各種分析、訂單數據分析、用戶畫像等。因爲業務數據分析緯度較多,flink、storm 等流式分析對於某些報表場景不太適用,批處理實時性又成爲問題,所以近實時分析的 Elasticsearch 就成爲了這些業務的選擇。
在應用 Elasticsearch 的 5 年時間中,京東從最初的幾個場景應用變成了覆蓋各條業務線,從最初的幾臺機器變成了現在的上千機器和幾千集羣的量級,運維壓力也隨之而來了。
目前,京東在日常運維 ELasticsearch 集羣時,主要面臨以下幾個問題:
-
IO 讀寫不均勻,部分節點 IO 壓力非常大;
-
冷數據節點存儲量受限制於單機的最大存儲;
-
close 後的索引節點故障無法進行 recovery,導致數據丟失的風險。
爲了解決這些問題,京東應用了 ChubaoFS。ChubaoFS 是京東自研的、爲雲原生應用提供高性能、高可用、可擴展、 穩定性的分佈式文件系統,設計初衷是爲了京東容器集羣提供持久化存儲方案,同時也可作爲通用雲存儲供業務方使用,幫助有狀態應用實現計算與存儲分離。
ChubaoFS 支持多種讀寫模型,支持多租戶,兼容 POSIX 語義和 S3 協議。ChubaoFS 設計的每個 pod 可以共享一個存儲卷,或者每個 pod 一個存儲卷,當容器所在的物理機宕機後,容器的數據可以隨着容器被同時調度到其他宿主機上, 保障數據可靠存儲。
Elasticsearch 實例管理演進之路
京東的 Elasticsearch 實例管理也是一個不斷摸索、不斷爬坑的過程。
初始階段
最初,京東 Elasticsearch 集羣部署是完全沒有架構可言的,集羣配置也都採用默認配置,一臺物理機啓動多個 Elasticsearch 進程,進程間完全共享服務器資源,不同業務之間使用集羣進行隔離,這種形式使用服務器 CPU 和內存得到了充分利用。
當系統運行了一段時間之後,這種部署方式的弊端開始顯現出了。
-
實例容易受到其他節點的影響,重要業務抖動問題沒有有效方式避免。
-
物理機內存被 cache 佔用,新創建實例啓動時耗時特別長。
-
實例存儲受單機磁盤容量限制,數據遷移時有發生。
容器隔離階段
由於物理機直接部署 Elasticsearch,無法管理 CPU、內存,各個節點相互影響明顯,甚至會影響到穩定性。所以,針對上述情況,京東做出了改善方案——調研資源隔離方式。
當時比較主流的資源隔離方式有兩種,Docker 容器化和虛擬機。
2016 年時 Docker 容器化技術已成型,但虛擬技術比較成熟有大量工具、生態系統完善。相對於虛擬機的資源隔離,Docker 不需要實現硬件虛擬化,只是利用 cgroup 對資源進行限制,實際使用的仍然是物理機的資源,所以在資源使用率方面效率更高,我們經過測試使用 Docker 化後性能損失相對較小几乎可以忽略。
Docker 是資源限制,啓動時不需要加載操作系統內核,可以毫秒級啓動。啓動對資源的消耗要低很多,可以做到快速的啓停。另外由於是資源限制類,只限制最大使用量而不隔離最小,這樣又可以做到虛擬化進行資源超買,提升資源使用率。
而在虛擬機的優勢方面,例如安全性,京東採用了內部資源共享平臺,通過流程管理或內部其它設施來彌補。這樣一來,原本的完全資源隔離優勢,反而成爲了內部系統資源最大化利用的劣勢。
因此,京東選擇了當時相對不太成熟的容器化部署方式,並進行了服務器上 Elasticsearcht 資源隔離:
- 內存完全隔離
-
數據 / 主數節點:默認按 jvm50%,預留一半給 Lucene 做 cache 使用。
-
網關 / 主節點:內存容量 -2 做爲 jvm 內存,預留 2G 給監控及其它服務。
- CPU 隔離
-
重要業務直接綁定 CPU,完全避免資源搶佔。
-
一般業務通過調整 cpu-sharElasticsearch、cpu-period、cpu-quota 進行 CPU 比例分配。
- IO 隔離
-
由於生產環境機器的多樣性,磁盤 IO 本身差別很大,另外對 IO 的限制會造成 Elasticsearch 讀寫性能嚴重下降,出於只針對內部業務的考慮,京東並未對 IO 進行隔離。
-
通過簡單的容器隔離,CPU 搶佔現象明顯改善。內存完全隔離之後,生產環境中節點之間相互影響很少發生 (IO 差的機器會有 IO 爭用),部署方式改造產生了應用的收益。
無狀態實例階段
隨着業務的不斷增長,集羣數量及消耗的服務器資源成比例上升,京東 Elasticsearch 實例上升爲上萬個,維護的集羣快速增長爲上千個,集羣規模從幾個到幾十個不等。
但是整體資源的利用率卻相對較低,磁盤使用率僅爲 28% 左右,日常平均讀寫 IO 在 10~20M/ 秒(日誌分區 IO 在 60-100M / 秒)。造成資源浪費的原因是集羣規模普遍較小,爲保證突發情況下,讀寫請求對 IO 的要求,我們一般會爲集羣分配較爲富餘的資源,物理機分配的容器也會控制在一定量級。
我們做個假設,如果大量的服務器 IO 都可以共享,那麼某個集羣突發請求對 IO 的影響其實可以忽略的。基於這種假設以及對提高磁盤使用率的迫切需要,我們考慮引入了公司內部部署的 ChubaoFS 作爲存儲,將 Elasticsearch 作爲無狀態的實例進行存儲計算分離。
得益於 ChubaoFS 是爲大規模容器集羣掛載而設計的通用文件系統,我們幾乎是零成本接入的,只需在物理機上安裝相應的客戶端,就可以將 ChubaoFS 當成本地文件系統來用。集成之後我們對 ChubaoFS 的性能進行了一系列對比。
我們使用 elasticsearch benchmark 測試工具 Elasticsearchrally 分別對 Elasticsearch 使用本地磁盤和 ChubaoFS 進行 benchmark 測試,測試使用了 7 個 elasticsearch 節點,50 個 shard。
Elasticsearchrally 測試參數如下:
Elasticsearchrally --pipeline=benchmark-only \--track=pmc \
--track-
params="number_of_replicas:${REPLICA_COUNT},number_of_shards:${SHARD_COUNT}" \--target-hosts=${TAR GET_HOSTS} \--report-file=${report_file}
其中 REPLICA_COUNT 0、1、2 分別 代表不同的副本數;SHARD_COUNT 爲 50。
從測試結果可以看出,Elasticsearch 集成 ChubaoFS 之後,在不同副本數情況下, index benchmark 性能和本地磁盤差距在 110%~120% 左右,僅有略微的下降;merge benchmark 性能在 replica > 0 時,Elasticsearch 使用 ChubaoFS 優於本地磁盤。refrElasticsearchh 和 flush benchmark 性能 ChubaoFS 不及本地磁盤。
目前使用效果
集成 ChubaoFS 之後,我們先是灰度運行了一段時間,效果表現良好之後,我們將京東日誌所有的 Elasticsearch 集羣底層全部切換爲 ChubaoFS。切換之後,我們在這些方面獲得了更好的效果:
- 節約資源
在採用 ChubaoFS 之前,我們使用了 500 臺物理機器,並且每個機器平時大概有 80% 的磁盤 IO 能力處於閒置狀態。採用 ChubaoFS 之後,ChubaoFS 的集羣規模約爲 50 臺,Elasticsearch 託管到公司的容器平臺,實現彈性可擴展。
- 管理和運維更加簡單便捷
採用 ChubaoFS 之後,我們不用再擔心某個機器的硬盤故障,或者某個機器的讀寫負載不均衡的問題。
- GC 頻率明顯降低
由於 ChubaoFS 底層對文件作了副本支持,業務層 Elasticsearch 將副本置爲 0,原先 segment 擠佔堆內存導致 FullGC 現象明顯,接入 ChubaoFS 後,GC 頻率明顯降低。
參考資料
ChubaoFS 京東開源雲原生應用分佈式文件系統
https://github.com/chubaofs/chubaofs
ChubaoFS 網站:
ChubaoFS 設計相關論文,收錄在 ACM SIGMOD 2019
CFS: A Distributed File System for Large Scale Container Platforms.
https://dl.acm.org/citation.cfm?doid=3299869.3314046
文檔
https://chubaofs.readthedocs.io/zh_CN/latElasticsearcht/
https://chubaofs.readthedocs.io/en/latElasticsearcht/
ChubaoFS 社區交流:
Twitter:@ChubaoFS
Mailing list: [email protected]
Slack: chubaofs.slack.com
作者簡介
王行行,京東零售計算存儲平臺架構部架構師,傑思平臺 (京東 Elasticsearch) 團隊負責人,2015 年加入京東,目前主要負責京東商城智能監控平臺底層、傑思平臺等基礎設施建設。
張麗穎,CNCF Ambassador,京東零售計算存儲平臺產品經理, 開源項目 ChubaoFS 的 contributor。