白话Elasticsearch63-生产集群部署之硬件配置、jvm以及集群规划建议
文章目錄
- 概述
- 內存
- CPU
- 磁盤
- 網絡
- 自建集群 vs 云部署
- JVM
- 容量規劃
概述
繼續跟中華石杉老師學習ES，第63篇
課程地址： https://www.roncoo.com/view/55
內存
es吃內存，es吃的主要不是你的jvm的內存，一般來說es用jvm heap（堆內存）還是用的比較少的，主要吃的是你的機器可用的剩余內存
es底層基于lucene，lucene是基于磁盤文件來讀寫和保存你的索引數據的，倒排索引，正排索引，lucene的特點就是會基于os filesystem cache，會盡量將頻繁訪問的磁盤文件的數據在操作系統的內存中進行緩存，然后盡量提升磁盤文件讀寫的性能
es的性能感覺不太理想，es的性能80%取決于說，你的機器上，除了分配給jvm heap內存以外，還剩下多少內存，剩下的內存會留給es的磁盤索引文件做緩存，如果os cache能夠緩存更多的磁盤文件的數據，索引文件的數據，索引讀寫的性能都會高很多，特別是檢索
但是如果你的大量的索引文件在os cache中放不下，還是停留在磁盤上，那么搜索、聚合的時候大量的都是讀寫磁盤文件，性能當然低了，一個數量級，ms級，s級
問：es上千萬數據的搜索，要耗費10s±---->大量讀寫磁盤了
如果在es生產環境中，哪種資源最容易耗盡，那么就是內存了。排序和聚合都會耗費掉很多內存，所以給es進程分配足夠的jvm heap內存是很重要的。除了給jvm heap分配內存，還需要給予足夠的內存給os filesystem cache。因為lucene用的數據結構都是基于磁盤的格式，es是通過os cache來進行高性能的磁盤文件讀寫的。
關于機器的內存相關的知識先簡單提一下，一般而言，除非說你的數據量很小，比如就是一些os系統，各種信息管理系統，要做一個內部的檢索引擎，幾萬，幾十萬，幾百萬的數據量，對機器的資源配置要求還是蠻低的。一般而言，如果你的數據量過億，幾億，幾十億。那么其實建議你的每臺機器都給64G的內存的量。
如果一個機器有64G的內存，那么是比較理想的狀態，但是32GB和16GB的內存也是ok的。具體的內存數量還是根據數據量來決定。但是如果一個機器的內存數量小于8G，那么就不太適合生產環境了，因為我們可能就需要很多小內存的機器來搭建集群。而大于64G的機器也不是很有必要。
CPU
大多數的es集群對于cpu的要求都會比較低一些，因此一臺機器有多少個cpu core其實對生產環境的es集群部署相對來說沒有那么的重要了，至少沒有內存來的重要。當然，肯定是要用多核處理器的，一般來說2個cpu core~8個cpu core都是可以的。
此外，如果要選擇是較少的cpu core但是cpu性能很高，還是較多的cpu core但是cpu性能較為一般，那么肯定是選擇性能較為一般但是更多的cpu core。因為更多的cpu core可以提供更強的并發處理能力，遠比單個cpu性能高帶來的效果更加明顯。
磁盤
對于es的生產環境來說，磁盤是非常重要的，尤其是對那些大量寫入的es集群，比如互聯網公司將每天的實時日志數據以高并發的速度寫入es集群。在服務器上，磁盤是最慢的那個資源，所以對于大量寫入的es集群來說，會很容易因為磁盤的讀寫性能造成整個集群的性能瓶頸。
如果我們能夠使用SSD固態硬盤，而不是機械硬盤，那么當然是最好的，SSD的性能比機械硬盤可以高很多倍，可以讓es的讀寫性能都高很多倍。
所以，如果公司出的起錢大量使用固態硬盤，那么當然是最好的。
如果我們在用SSD硬盤的化，那么需要檢查我們的I/O scheduler，需要正確的配置IO scheduler。當我們將數據寫入磁盤時，IO scheduler會決定什么時候數據才會真正的寫入磁盤，而不是停留在os cache內存緩沖中。大多數機器上，默認的IO scheduler是cfq，也就是completely fair queuing。
這個scheduler會給每個進程都分配一些時間分片，time slice，然后會優化每個進程的數據如何寫入磁盤中，優化的思路主要 是根據磁盤的物理布局來決定如何將數據寫入磁盤，進而提升寫入磁盤的性能。這是針對機械硬盤做出的優化，因為機械硬盤是一種旋轉存儲介質，是通過機械旋轉磁盤+磁頭進行磁盤讀寫的機制。
但是scheduler的這種默認的執行機制，對于SSD來說是不太高效的，因為SSD跟機械硬盤是不一樣的，SSD不涉及到機械磁盤旋轉和磁頭讀取這種傳統的讀寫機制。對于SSD來說，應該用deadline/noop scheduler。deadline scheduler會基于寫操作被pending了多長時間來進行寫磁盤優化，而noop scheduler就是一個簡單的FIFO隊列先進先出的機制。
調整io scheduler可以帶來很大的性能提升，甚至可以達到數百倍。
如果我們沒有辦法使用SSD，只能使用機械硬盤，那么至少得盡量正確讀寫速度最快的磁盤，比如高性能的服務器磁盤。
此外，使用RAID 0也是一種提升磁盤讀寫速度的高效的方式，無論是對于機械硬盤，還是SSD，都一樣。
RAID 0也被稱之為條帶式存儲機制，striping，在RAID各種級別中性能是最高的。RAID 0的基本原理，是把連續的數據分散存儲到多個磁盤上進行讀寫，也就是對數據進行條帶式存儲。這樣系統的磁盤讀寫請求就可以被分散到多個磁盤上并行執行。但是沒有必要使用鏡像或者RAID的其他模式，因為我們不需要通過RAID來實現數據高可用存儲，es的replica副本機制本身已經實現了數據高可用存儲。
最后，我們要避免跟網絡相關的存儲模式，network-attached storage，NAS，比如基于網絡的分布式存儲模式。
雖然很多供應商都說他們的NAS解決方案性能非常高，而且比本地存儲的可靠性更高。但是實際上用起來會有很多性能和可靠性上的風險，一般因為網絡傳輸會造成較高的延時，同時還有單點故障的風險。
網絡
對于es這種分布式系統來說，快速而且可靠的網絡是非常的重要的。
因為高速網絡通信可以讓es的節點間通信達到低延時的效果，高帶寬可以讓shard的移動和恢復，以及分配等操作更加的快速。
現代的數據中心的網絡對于大多數的集群來說，性能都足夠高了。比如千兆網卡，這都是可以的。
但是要避免一個集群橫跨多個數據中心，比如異地多機房部署一個集群，因為那樣的話跨機房，跨地域的傳輸會導致網絡通信和數據傳輸性能較差。es集群是一種p2p模式的分布式系統架構，不是master-slave主從分布式系統。在es集群中，所有的node都是相等的，任意兩個node間的互相通信都是很頻繁和正常的。因此如果部署在異地多機房，那么可能會導致node間頻繁跨地域進行通信，通信延時會非常高，甚至造成集群運行頻繁不正常。
就跟NAS存儲模式一樣，很多供應商都說跨地域的多數據中心是非常可靠的，而且低延時的。一般來說，可能的確是這樣，但是一旦發生了網絡故障，那么集群就完了。通常來說，跨地域多機房部署一個es集群帶來的效益，遠遠低于維護這樣的集群所帶來的額外成本。
自建集群 vs 云部署
現在一般很容易就可以拿到高性能的機器來部署集群：很多高性能的機器可以有上百G的內存資源，還有幾十個cpu core。但是同時我們也可以再云供應商上，比如阿里云，租用大量的小資源的虛擬機。那么對于自己購買昂貴高性能服務器自建集群，以及租用云機器來部署，該選擇哪種方案呢？
你是自己購買5臺，比如說，8核64G的物理機，搭建es集群
或者是，比如說，上阿里云，或者其他的云服務，購買了2核4G，16臺，虛擬機，搭建es集群
你上阿里云，也可以買到大資源量的虛擬機，4/8/16核64G
一般來說，對于es集群而言，是建議擁有少數機器，但是每個機器的資源都非常多，盡量避免擁有大量的少資源的虛擬機。因為對于運維和管理來說，管理5個物理機組成的es集群，遠遠比管理100個虛擬機組成的es集群要簡單的多。
同時即使是自建集群，也要盡量避免那種超大資源量的超級服務器，因為那樣可能造成資源無法完全利用，然后在一個物理機上部署多個es節點，這會導致我們的集群管理更加的復雜。
JVM
對于最新的es版本，一般多建議用最新的jvm版本，除非es明確說明要用哪個jdk版本。es和lucene都是一種滿足特殊需求的軟件，lucene的單元測試和集成測試中，經常會發現jvm自身的一些bug。這些bug涵蓋的范圍很廣，因此盡量用最新的jvm版本，bug會少一些。
es 5.x版本以上，建議用jdk 8，而不是jdk 7，同時jdk 6已經不再被支持了。
如果我們用java編寫es應用程序，而且在使用transport client或者node client，要確保運行我們的應用程序的jvm版本跟es服務器運行的jvm版本是一樣的。
在es中，有些java的本地序列化機制都被使用了，比如ip地址，異常信息，等等。而jvm可能在不同的minor版本之間修改序列化格式，所以如果client和server的jvm版本不一致，可能有序列化的問題。
同時官方推薦，絕對不要隨便調整jvm的設置。雖然jvm有幾百個配置選項，而且我們可以手動調優jvm的幾乎方方面面。同時遇到一個性能場景的時候，每個人都會第一時間想到去調優jvm，但是es官方還是推薦我們不要隨便調節jvm參數。因為es是一個非常復雜的分布式軟件系統，而且es的默認jvm配置都是基于真實業務場景中長期的實踐得到的。隨便調節jvm配置反而有可能導致集群性能變得更加差，以及出現一些未知的問題。反而是很多情況下，將自定義的jvm配置全部刪除，性能是保持的最好的。
容量規劃
在規劃你的es集群的時候，一般要規劃你需要多少臺服務器，每臺服務器要有多少資源，能夠支撐你預計的多大的數據量。但是這個東西其實不是一概而論的，要視具體的讀寫場景，包括你執行多么復雜的操作，讀寫QPS來決定的。不過一般而言，實際經驗，對于很多的中小型公司，都是建議es集群承載的數據量在10億規模以內。用最合理的技術做最合理的事情。
這里可以給出幾個在國內es非常適合的幾個場景，es是做搜索的，當然可以做某個系統的搜索引擎。比如網站或者app的搜索引擎，或者是某些軟件系統的搜索引擎，此外es還可以用來做數據分析。那么針對這幾個不同的場景，都可以給出具體建議。比如做網站或者app的搜索引擎，一般數據量會相對來說大一些，但是通常而言，一個網站或者app的內容都是有限的，不會無限膨脹，通常數據量從百萬級到億級不等，因此用于搜索的數據都放在es中是合理的。
然后一些軟件系統或者特殊項目的搜索引擎，根據項目情況不同，數據量也是從百萬量級到幾十億，甚至幾百億，或者每日增量幾億，都有可能，那么此時就要根據具體的業務場景來決定了。如果數據量特別大，日增量都幾億規模，那么其實建議不要將每天全量的數據都寫入es中，es也不適合這種無限規模膨脹的場景。es是很耗費內存的，無限膨脹的數據量，會導致我們無法提供足夠的資源來支撐這么大的數據量。可以考慮是不是就將部分熱數據，比如最近幾天的數據，放到es中做高頻高性能搜索，然后將大量的很少訪問的冷數據放大數據系統做離線批量處理，比如hadoop系統里面。
比如說，你預計一下，你的數據量有多大，需要多少臺機器，每臺機器要多少資源，來支撐，可以達到多大的性能
數據量 -> 性能，10億 -> 要求1s內返回
es達到ms級的化，你必須要有足夠的os cache去緩存幾乎大部分的索引數據
10億，每條數據是多大，比如多少個字節，1k -> 假設數據大小為100G
如果有5臺，64G，8核，那么總內存就是300G左右 -> 100G的總數據量，300G的內存，一般要分給es jvm heap，150G （每臺32G）-> 那么100G的數據總量，100G落地到磁盤文件加入很多es自己的信息，假設100G -> 200G
200G落地磁盤的數據，物理內存剩余的只有150G，可能還有一些操作系統，還有其他的損耗100G
200G落地磁盤的數據，100G物理內存可以用來做os cache，50%的概率是基于os cache做磁盤索引文件的讀寫，幾秒，很正常啦。。。
根據我們的實踐經驗而言，一般來說，除非是你的機器的內存資源，完全可以容納所有的落地的磁盤文件的os cache，ms，否則的話，如果不是的話，會大量走磁盤，查詢秒級別很正常
同時如果數據量在10億以內的規模，那么一般而言，如果提供5臺以上的機器，每臺機器的配置到8核64G的配置，一般而言都能hold住。當然，這個也看具體的使用場景，如果你讀寫特別頻繁，或者查詢特別復雜，那么可能還需要更多的機器資源。如果你要承載更大的數據量，那么就相應的提供更多的機器和資源。
要提升你的es的性能，最重要的，還是說規劃合理的數據量，物理內存資源大小，os cache
總結
以上是生活随笔為你收集整理的白话Elasticsearch63-生产集群部署之硬件配置、jvm以及集群规划建议的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 白话Elasticsearch62-进阶
- 下一篇： 高并发编程-Daemon Thread的