在生產環境中, 要保證服務在各種極限情況下的穩定和高可用, 所以在部署ES集群時, 需要考慮伺服器的記憶體、CPU、磁碟, 集群的網路、節點個數, 並且要優化JVM的各項參數. 首先從這些方面著手進行部署前的規劃. ...
目錄
在生產環境中, 要保證服務在各種極限情況下的穩定和高可用, 所以在部署ES集群時, 需要考慮伺服器的記憶體、CPU、磁碟, 集群的網路、節點個數, 並且要優化JVM的各項參數. 首先從這些方面著手進行部署前的規劃.
1 伺服器的記憶體
ES非常消耗記憶體 —— 不是JVM用到的記憶體, 而是機器的物理記憶體, 因為ES在運行期間對JVM Heap(堆記憶體)的需求較小.
ES底層是基於Lucene創建的, 而Lucene是基於磁碟中的文件來讀寫和保存索引數據(包括倒排索引、正排索引);
Lucene的特點是基於OS File System Cache(操作系統的文件緩存系統), 它會儘可能地把頻繁訪問的磁碟文件緩存在操作系統的記憶體中, 從而提高對磁碟文件的讀寫性能.
關於Lucene的更多資料, 可參考: https://www.cnblogs.com/shoufeng/category/1259723.html.
可以這樣說: ES的性能很大程度上(80%)取決於分配給JVM Heap記憶體之後、伺服器的剩餘記憶體大小.
—— 這些剩餘記憶體會緩存Lucene的索引文件, 緩存的越多, 索引的讀寫性能都越高, 尤其是檢索和聚合操作, 它們需要讀取幾乎所有的索引數據.
實踐建議: 數據量過億, 建議單台伺服器的記憶體至少要有64GB.
2 伺服器的CPU
ES集群對CPU的要求比較低, 一般來說2~8個CPU Core即可滿足集群的需求.
實踐建議: 儘可能使用多核處理器, 因為併發處理能力會更好.
3 伺服器的磁碟
ES生產環境中, 磁碟的讀寫能力是非常重要的, 尤其對於大量寫操作的集群, 比如電商公司將每天的實時日誌數據以高併發的方式寫入ES集群.
(1) 在磁碟的使用上, 推薦使用SSD(固態硬碟), 而不是(HDD)機械硬碟.
使用SSD, 就需要配置SSD的I/O Scheduler —— 數據寫入磁碟時, IO Scheduler會決定將數據從OS Cache刷入到磁碟的時機.
大部分SSD的預設IO Scheduler是CFQ (completely fair queuing), 它會為每個進程都分配一些時間片(time slice), 然後通過磁碟的物理佈局來決定如何將數據寫入磁碟 (對各個進程的數據寫入進行優化), 進而提升寫入磁碟的性能.
但是預設的CFQ並不高效. 對SSD來說, 推薦使用Deadline/Noop Scheduler, 它基於寫操作被Pending的時間長短來進行寫磁碟優化, 而Noop Scheduler就是一個簡單的FIFO(先進先出)隊列機制.
(2) 此外, 使用RAID 0也是一種提升磁碟讀寫速度的高效方式, 無論是HDD, 或者SSD都支持RAID 0.
RAID 0也被稱之為條帶式(striping)存儲機制, 在RAID各種級別中性能是最高的, 它的基本原理是:
把連續的數據分散存儲到多個磁碟上進行讀寫, 也就是對數據進行條帶式存儲 —— 磁碟的讀寫請求被分散到多個磁碟上並行執行.
沒有必要使用鏡像或者RAID的其他模式, 因為我們並不需要通過RAID來實現數據的高可用存儲 —— 這方面的工作ES的Replica副本機制已經實現了.
(3) 最後, 要避免使用與網路相關的存儲模式 (network-attached storage, NAS), 比如基於網路的分散式存儲模式.
雖然很多供應商都說他們的NAS解決方案性能非常高, 而且比本地存儲的可靠性更高, 但在實際使用上還是會有很多風險: 網路傳輸可能存在比較高的時延, 還可能存在單點故障.
實踐建議: 推薦使用SSD, 並調整其IO Scheduler為Deadline/Noop Scheduler, 這可以帶來很大的性能提升, 理想情況下可能達到上百倍.
4 集群的網路
對ES這種分散式系統來說, 快速可靠的網路是非常重要的:
高速網路通信可以讓ES節點間的通信時延降低;
高帶寬可以讓Shard的移動、恢復, 以及分配等操作更加快速.
不低於千兆網卡對大多數集群來說都已足夠, 但要避免一個集群橫跨多個數據中心, 比如異地多機房部署一個集群 —— 跨地域跨機房會降低網路通信和數據傳輸的效率.
① ES集群是一種p2p模式的分散式系統架構, 並不是master-slave主從分散式系統.
② ES集群中, 所有節點都是平等的, 任意兩個節點之間的通信都很頻繁, 如果部署在異地多機房, 就會導致各個節點之間頻繁跨地域通信, 通信時延會非常高, 甚至有可能造成集群運行頻繁出現異常.
③ 與NAS存儲模式一樣, 很多供應商都聲稱他們的跨地域多數據中心是可靠、低時延的, 即使果真如此, 一旦網路出現故障, 整個集群就會不可用. 大多數情況下, 跨地域多機房部署一個ES集群帶來的效益要遠遠低於維護這類集群所付出的額外成本.
實踐建議: 不低於千兆網卡, 且不要垮多個數據中心, 尤其不要跨地域多機房.
5 集群的節點個數
ES集群的節點個數:
① 建議部署少個節點, 但每個節點對應伺服器的資源都必須充足;
② 不建議在一臺高性能伺服器上部署多個節點: 不僅降低了集群的可用性, 而且集群的維護複雜度也變得更高了.
儘量避免部署大量的低資源的伺服器, 因為對運維和管理而言, 管理5個物理機組成的集群, 要比管理10個虛擬機組成的集群要簡單簡單太多.
實踐建議: 小規模、高配置, 但無需超高配置, 會造成資源的浪費.
6 JVM的參數設置
ES的版本越新, 使用的JDK的版本也應該越新, 既提高性能, 也避免一些不常見的系統Bug(包括Lucene和JDK的).
以本系列博文為例, 示例的ES版本為6.6.0, 使用的JDK版本是jdk1.8.0_151.
(1) 如果通過Java API操作ES服務, 那麼編譯Java程式的JVM版本最好與ES伺服器所運行的JVM版本一致.
ES中用到了很多與JVM版本相關的特性, 比如本地序列化機制 (包括IP地址、異常信息等等), 而JVM在不同的minor版本中可能會修改序列化機制, 版本不同可能會導致序列化異常.
(2) 同時官方強烈建議: 不要隨意調整JVM的參數設置.
ES是一個非常複雜的分散式軟體系統, 它預設的JVM配置經過了大量真實業務場景下的檢驗, 除非你很明確地知道自己的服務瓶頸出在哪幾個參數上, 否則不要調整.
ES服務中, JVM Heap堆記憶體的大小一般不超過伺服器物理記憶體的一半, 以1/4為宜, 且最多不宜超過32GB.
7 集群的數據量
對很多中小型公司, 建議ES集群承載的數據量在百億級規模以內.
(1) ES的常見使用場景有:
① 構建業務搜索功能模塊, 且多是垂直領域的搜索: 以網站或APP為例, 數據規模相對比較大, 通常是百萬級到億級;
② 進行數據分析: 需要消耗更大的記憶體, 但支持的數據規模要小很多, 通常是十萬級到千萬級;
③ 用於大規模數據的實時OLAP(聯機處理分析), 經典的如ELK Stack, 數據規模可能達到千億或更多, 集群規模可能達到幾十上百節點.
(2) 數據量特別大時的處理思路:
如果應用的數據量特別大, 日增量幾十上百萬, 那就不建議將數據全量寫入ES中, ES也不適合這種數據無限膨脹的場景 —— ES消耗記憶體, 無限膨脹的數據量會導致無法提供足夠的記憶體來支撐大規模數據的快速檢索.
此時可以考慮: 將部分熱數據 (比如最近一月的數據) 存放到ES中做高頻高性能搜索, 將大量的、較少訪問的冷數據存放至大數據系統 (比如Hadoop) 中做離線批量處理.
不同數據規模與記憶體容量下的檢索性能表現: 如果伺服器的記憶體可以將ES所需的文件全部納入到OS Cache中, 就能達到ms(毫秒)級的檢索性能; 否則檢索會大量訪問磁碟, 檢索時間就會上升到s(秒)級.
8 總結
要提升ES的性能, 最重要的是規劃合理的數據量, 配置足夠的物理記憶體用作OS Cache, 儘可能減少從磁碟中訪問數據.
版權聲明
