前文《面對海量事件數據，我來告訴你怎麼辦！》中我們介紹了百度線上業務運維場景下海量事件數據存儲與計算平臺EventDB的系統架構、集群規劃及未來發展方向，本文將介紹我們在EventDB高可用方向面臨的問題、建設經驗及後續計劃，希望與業界同行一起交流學習。

作為百度雲Noah智能運維產品核心存儲平臺，其可用性的高低直接決定了上下游業務系統可用性的高低，我們建設可用性之初主要面臨如下幾個問題：

監控體系不完善：導致無法準確掌握系統狀況，排查問題困難。

流量管控不健全：一是終端用戶直接使用ES API很容易造成接口誤用；二是無法防禦惡意請求和非預期流量洪峰。

數據規模增速快：導致原有存儲模型無法滿足系統性能和擴展性需要。

參數配置不合理：默認配置參數沒有按業務場景進行優化調整。

可用性建設

為了提升平臺可用性，針對上述問題我們做了如下幾方面工作：

完善監控體系

我們建立了多層次監控指標，從機器、容器(Container)、JVM、ElasticSearch內部指標再到業務監控指標，這些監控指標對及時瞭解系統運行狀況、分析定位問題至關重要。

機器、容器：

CPU/MEMORY/DISK/NET/FD/PROCESS

JVM：

Eden/Survivor/Old/Full GC/Young GC/Thread

ElasticSearch：

Queue/Cache/Marvel/Search Context

業務監控：

PV/PVLOST/Response Time/主備數據一致性

其中ElasticSearch內部指標是通過API實時提供，為了圖形化展示這些指標並記錄歷史數據我們使用Marvel插件，Marvel插件通過定期調用ElasticSearch監控API提供更細粒度監控指標，能讓我們看到基於每個索引（Index）的監控數據，這個功能在我們定位IO突增問題時發揮了重要作用。

統一調用接口

ElasticSearch自身提供了非常豐富的API，從數據操作到參數配置再到集群管理。如果把所有ES API都開放給終端用戶會給平臺帶來非常大風險。

一是我們無法預料用戶行為，二是每個用戶對ElasticSearch掌握程度不同，很容易造成誤用。為了加強流量管理能力我們做了兩方面工作：

一是由平臺提供統一數據操作API。使用BigQuery API將所有存儲、查詢需求通過SQL來表達，用戶通過SQL來操作數據，如果SQL有問題或惡意請求會被直接阻止掉。

二是對所有接口進行配額限流管理。超出單位時間配額的請求會被拒絕訪問。

優化存儲模型

ElasticSearch數據存儲模型由索引(Index)、類型(Type)、文檔(Document)組成，分別對應關係型數據庫中庫(Database)、表(Table)、行(Row)。設計合理的存儲模型不光能滿足業務需求，還能極大提升系統擴展性和讀寫性能。

分庫設計

數據規模小的情況下我們為了簡便可以將數據都存放在一個庫中，當數據規模越來越大，這種存儲方式會帶來兩方面問題：

一是數據難以管理維護。例如我們想把某類業務數據清理掉，無法通過直接刪除索引的方式來清理數據。

二是影響性能。任何讀寫請求都會影響索引中其他數據讀寫。

所以平臺設計之初就需要我們合理規劃索引，一般的做法是按業務和時間兩個維度來進行分庫，不同的業務使用不同的索引，然後依據數據規模按天/月/年來創建索引。

合理設置分片

單個索引該設置幾個分片？每個分片大小多少合適？這兩個問題是我們在規劃設計索引時必須要考慮的問題。

索引分片過小一方面導致ElasticSearch在內存中維護大量索引分片元信息，集群管理負荷增加進而引發集群不穩定；另一方面ElasticSearch在查詢時會掃描所有索引分片，分片過多會影響查詢性能。

索引分片過大將導致數據過於集中，讀寫操作在同一分片上的概率增加進而影響操作性能。

合理的做法是先評估索引數據規模，按照單個分片不小於1G的原則來設置分片數，這樣能避免產生大量小分片；另一個原則是要讓分片在集群中儘量均勻分佈，實踐經驗就是分片數最好是數據節點數的1.5~3倍，這樣能避免單個分片過大。

過期數據處理

數據價值會隨著時間越來越低，任何一個存儲系統都不可能永久無限制地保存所有歷史數據，因為無論從成本投入、維護難度上都是得不償失。所以針對不同業務場景我們需要制定清晰的歷史數據清理策略，對於過期低價值數據進行定期清理，這對保持集群穩定，提高資源利用率至關重要。

優化配置參數

下面這些參數都是我們認為比較重要的參數，在這裡只說明其對系統的影響不作具體值建議，大家可以根據各自業務場景自行進行調整。

JVM參數

-Xms -Xmx：設置Heap大小，建議不超過32G（JVM使用壓縮指針用32位地址尋址32G空間）。

-XX:+ExitOnOutOfMemoryError：發生內存溢出時保證JVM進程及時退出，避免節點假死（JVM進程還在但無法正常提供服務） 。

backlog：已建立TCP連接處理隊列長度，該隊列滿時會丟棄TCP連接並拋出Connection Reset異常。JVM默認50，建議適當增大應對流量洪峰。

Elasticsearch參數

index.number_of_shards：索引分片數，需要依據數據規模來設置，在索引創建時設置，後期無法更改。

index.number_of_replicas：索引分片副本數，需要依據數據重要程度來設置，既能在索引創建時設置，也能後期通過API更改。

index.refresh_interval：內存中數據寫入到磁盤間隔，該參數越小數據可查詢延遲越小，可靠性越高但性能低；該參數越大數據可查詢延遲越大，可靠性越低但性能高；默認1s，建議增大。

ElasticSearch作為高可用集群，單個節點掛掉並不會影響整個集群功能。當故障節點恢復時，為了避免恢復工作對集群造成太多影響（主要是避免過多的I/O消耗），可以設置如下兩個參數：

cluster_concurrent_rebalance：集群中允許多少個分片同時遷移重分配。

node_concurrent_recoveries：一個node上允許多少個分片同時恢復。

成果及計劃

經過不懈努力，事件數據存儲平臺已擴展到上百量級的數據節點，日處理事件數據達到TB級，可用性達99.999%以上。用戶涵蓋業務報警、異常分析、根因定位、關聯分析、日誌追蹤，已經成為百度雲Noah智能運維產品核心存儲平臺。

為應對數據規模、流量持續增長的壓力，持續保持系統高可用性，我們正在開展如下兩方面的建設：

冷熱數據分離：建設冷熱數據分離存儲架構，一方面可以有效避免冷熱數據互相影響，有效提升熱數據讀寫性能；另一方面可以針對冷熱數據進行存儲介質優化，例如：使用SSD硬盤來保存熱數據，使用STAT硬盤保存冷數據，既能提升讀寫效率又能降低存儲成本。

ES版本升級：新版本ES在穩定性、易用性、安全性及可維護性上都有很大提升，定期升級版本能避免很多不必要的維護工作。

閱讀更多 pop說一下 的文章

關鍵字: 可用性 ElasticSearch SQL