ELK 集羣部署

時間 2019-11-17

原文原文鏈接

Elasticsearch用於構建高可用和可擴展的系統。擴展的方式能夠是購買更好的服務器(縱向擴展)或者購買更多的服務器（橫向擴展）,Elasticsearch能從更強大的硬件中得到更好的性能，可是縱向擴展也有必定的侷限性。真正的擴展應該是橫向的，它經過增長節點來傳播負載和增長可靠性。對於大多數數據庫而言，橫向擴展意味着你的程序將作很是大的改動來利用這些新添加的設備。對比來講，Elasticsearch天生是分佈式的：它知道如何管理節點來提供高擴展和高可用。這意味着你的程序不須要關心這些。 html

對於Elasticsearch集羣搭建，能夠把索引進行分片存儲，一個索引能夠分紅若干個片，分別存儲到集羣裏面，而對於集羣裏面的負載均衡，副本分配，索引動態均衡（根據節點的增長或者減小）都是elasticsearch本身內部完成的，一有狀況就會從新進行分配。

如下先是介紹幾個關於elasticsearch 的幾個名詞 node

  cluster
表明一個集羣，集羣中有多個節點，其中有一個爲主節點，這個主節點是能夠經過選舉產生的，主從節點是對於集羣內部來講的。es的一個概念就是去中心化，字面上理解就是無中心節點，這是對於集羣外部來講的，由於從外部來看es集羣，在邏輯上是個總體，你與任何一個節點的通訊和與整個es集羣通訊是等價的。

shards
表明索引分片，es能夠把一個完整的索引分紅多個分片，這樣的好處是能夠把一個大的索引拆分紅多個，分佈到不一樣的節點上。構成分佈式搜索。分片的數量只能在索引建立前指定，而且索引建立後不能更改。

replicas
  表明索引副本，es能夠設置多個索引的副本，副本的做用一是提升系統的容錯性，當個某個節點某個分片損壞或丟失時能夠從副本中恢復。二是提升es的查詢效率，es會自動對搜索請求進行負載均衡。

recovery
表明數據恢復或叫數據從新分佈，es在有節點加入或退出時會根據機器的負載對索引分片進行從新分配，掛掉的節點從新啓動時也會進行數據恢復。

river
表明es的一個數據源，也是其它存儲方式（如：數據庫）同步數據到es的一個方法。它是以插件方式存在的一個es服務，經過讀取river中的數據並把它索引到es中，官方的river有couchDB的，RabbitMQ的，Twitter的，Wikipedia的，river這個功能將會在後面的文件中重點說到。

gateway
  表明es索引的持久化存儲方式，es默認是先把索引存放到內存中，當內存滿了時再持久化到硬盤。當這個es集羣關閉再從新啓動時就會從gateway中讀取索引數據。es支持多種類型的gateway，有本地文件系統（默認），分佈式文件系統，Hadoop的HDFS和amazon的s3雲存儲服務。

discovery.zen
表明es的自動發現節點機制，es是一個基於p2p的系統，它先經過廣播尋找存在的節點，再經過多播協議來進行節點之間的通訊，同時也支持點對點的交互。

Transport
表明es內部節點或集羣與客戶端的交互方式，默認內部是使用tcp協議進行交互，同時它支持http協議（json格式）、thrift、servlet、memcached、zeroMQ等的傳輸協議（經過插件方式集成）。 python

集羣和節點 linux

節點(node)是你運行的Elasticsearch實例。一個集羣(cluster)是一組具備相同cluster.name的節點集合，他們協同工做，共享數據並提供故障轉移和擴展功能，當有新的節點加入或者刪除節點，集羣就會感知到並平衡數據。集羣中一個節點會被選舉爲主節點(master),它用來管理集羣中的一些變動，例如新建或刪除索引、增長或移除節點等;固然一個節點也能夠組成一個集羣。算法

節點通訊 數據庫

咱們可以與集羣中的任何節點通訊，包括主節點。任何一個節點互相知道文檔存在於哪一個節點上，它們能夠轉發請求到咱們須要數據所在的節點上。咱們通訊的節點負責收集各節點返回的數據，最後一塊兒返回給客戶端。這一切都由Elasticsearch透明的管理。 json

分片與副本分片
分片用於Elasticsearch在你的集羣中分配數據。想象把分片看成數據的容器。文檔存儲在分片中，而後分片分配給你集羣中的節點上。當你的集羣擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集羣保持平衡。一個分片(shard)是一個最小級別的「工做單元(worker unit)」,它只是保存索引中全部數據的一小片.咱們的文檔存儲和被索引在分片中，可是咱們的程序不知道如何直接與它們通訊。取而代之的是，他們直接與索引通訊.Elasticsearch中的分片分爲主分片和副本分片,複製分片只是主分片的一個副本，它用於提供數據的冗餘副本，在硬件故障以後提供數據保護，同時服務於像搜索和檢索等只讀請求，主分片的數量和複製分片的數量均可以經過配置文件配置。可是主切片的數量只能在建立索引時定義且不能修改.相同的分片不會放在同一個節點上。 bootstrap

1)分片算法: 緩存

shard = hash(routing) % number_of_primary_shards 服務器

routing值是一個任意字符串，它默認是_id但也能夠自定義，這個routing字符串經過哈希函數生成一個數字，而後除以主切片的數量獲得一個餘數(remainder)，餘數的範圍永遠是0到number_of_primary_shards - 1，這個數字就是特定文檔所在的分片。這也解釋了爲何主切片的數量只能在建立索引時定義且不能修改：若是主切片的數量在將來改變了，全部先前的路由值就失效了，文檔也就永遠找不到了。全部的文檔API（get、index、delete、bulk、update、mget）都接收一個routing參數，它用來自定義文檔到分片的映射。自定義路由值能夠確保全部相關文檔.好比用戶的文章,按照用戶帳號路由,就能夠實現屬於同一用戶的文檔被保存在同一分片上。

2)分片和副本交互：

新建、索引和刪除請求都是寫(write)操做，它們必須在主分片上成功完成才能複製到相關的複製分片上,下面咱們羅列在主分片和複製分片上成功新建、索引或刪除一個文檔必要的順序步驟：

一、客戶端給Node 1發送新建、索引或刪除請求。

二、節點使用文檔的_id肯定文檔屬於分片0。它轉發請求到Node 3，分片0位於這個節點上。

三、Node 3在主分片上執行請求，若是成功，它轉發請求到相應的位於Node 1和Node 2的複製節點上。當全部的複製節點報告成功，Node 3報告成功到請求的節點，請求的節點再報告給客戶端。

客戶端接收到成功響應的時候，文檔的修改已經被應用於主分片和全部的複製分片。你的修改生效了。

3)副本分片複製時的相關的參數說明:

replication:

複製默認的值是sync。這將致使主分片獲得複製分片的成功響應後才返回，若是你設置replication爲async，請求在主分片上被執行後就會返回給客戶端。它依舊會轉發請求給複製節點，但你將不知道複製節點成功與否。

默認的sync複製容許Elasticsearch強制反饋傳輸。async複製可能會由於在不等待其它分片就緒的狀況下發送過多的請求而使Elasticsearch過載。

consistency:

默認主分片在嘗試寫入時須要**規定數量(quorum)**或過半的分片（能夠是主節點或複製節點）可用。這是防止數據被寫入到錯的網絡分區。規定的數量計算公式以下：

int( (primary + number_of_replicas) / 2 ) + 1

consistency容許的值爲one（只有一個主分片），all（全部主分片和複製分片）或者默認的quorum或過半分片。

注意number_of_replicas是在索引中的的設置，用來定義複製分片的數量，而不是如今活動的複製節點的數量。若是你定義了索引有3個複製節點，那規定數量是：int( (primary + 3 replicas) / 2 ) + 1 = 3

但若是你只有2個節點，那你的活動分片不夠規定數量，也就不能索引或刪除任何文檔。

注意: 新索引默認有1個複製分片，這意味着爲了知足quorum的要求**須要**兩個活動的分片。固然，這個默認設置將阻止咱們在單一節點集羣中進行操做。爲了避開這個問題，規定數量只有在number_of_replicas大於一時才生效。

timeout：
當分片副本不足時Elasticsearch會等待更多的分片出現。默認等待一分鐘。若是須要，你能夠設置timeout參數讓它終止的更早：100表示100毫秒，30s表示30秒。

搭建集羣實例:

環境:2臺機器作集羣

節點1: 10.59.74.54 hostname:dev-vhost031 (安裝ELK)
節點2: 10.59.74.57 hostname:dev-vhost034 (安裝elasticsearch)

2臺機器主機名ip各自加上/etc/hosts，後面集羣配置須要用到
10.59.74.57 es-node2
10.59.74.54 es-node1

1. es-node1 安裝ELK (具體見http://my.oschina.net/davehe/blog/539886)

2. es-node2 安裝elasticsearch (同上elasticsearch安裝)

3. 建立集羣配置信息

[root@dev-vhost031 elasticsearch]# egrep -v "^$|^#" elasticsearch.yml
cluster.name: elasticsearch     #配置集羣名稱  (注意:名稱會數據目錄/var/lib/elasticsearch/elasticsearch)
node.name: "es-node1"           #配置節點名稱
node.master: true               #容許這個節點被選舉爲一個主節點(默認容許)
node.data: true                 #容許這個節點存儲數據(默認容許)

elasticsearch 2.0版本注意
network.host: 0.0.0.0    （默認是127.0.0.1:9200 9300）
discovery.zen.ping.unicast.hosts: ["es-node1", "es-node2"]   (手動發現節點)


[root@dev-vhost034 elasticsearch]# egrep -v "^$|^#" elasticsearch.yml
cluster.name: elasticsearch    
node.name: "es-node2"
node.master: false
node.data: true

4.安裝插件
head插件: (以查看集羣幾乎全部信息，還能進行簡單的搜索查詢，觀察自動恢復的狀況等等。)

[root@dev-vhost031 elasticsearch]#/usr/share/elasticsearch/bin/plugin -install mobz/elasticsearch-head

kopf插件:(它提供了一個簡單的方法，一個elasticsearch集羣上執行常見的任務。)

[root@dev-vhost031 elasticsearch]#/usr/share/elasticsearch/bin/plugin install lmenezes/elasticsearch-kopf/1.6

bigdesk插件: (集羣監控插件，經過該插件能夠查看整個集羣的資源消耗狀況，cpu、內存、http連接等等。)

[root@dev-vhost031 elasticsearch]#/usr/share/elasticsearch/bin/plugin -install lukas-vlcek/bigdesk

5.啓動節點:
/etc/init.d/elasticsearch start

6.經過插件查看集羣狀態
http://10.59.74.54:9200/_plugin/head/

http://10.59.74.54:9200/_plugin/bigdesk/

http://10.59.74.54:9200/_plugin/kopf/

參數優化(提升ElasticSearch檢索效率)

1、Linux操做系統優化

1)  調整系統資源最大句柄數
    /etc/security/limits.conf
   在文件中增長
     * soft nofile 65536
     * hard nofile 65536

2) 設置bootstrap.mlockall: 爲true來鎖住內存。由於當jvm開始swapping時es的效率會下降，因此要保證它不swap，能夠把ES_MIN_MEM和ES_MAX_MEM兩個環境變量設置成同一個值，而且保證機器有足夠的內存分配給es。
同時也要容許elasticsearch的進程能夠鎖住內存，linux下能夠經過`ulimit -l unlimited`命令。

3)         關閉文件更新時間
     cat /etc/fstab
     /dev/sda7 /data/1 ext4 defaults,noatime 0 0

4)  提升ES佔用內存(elasticsearch.in.sh)
     ES_MIN_MEM=30g (通常爲物理內存一半，但不要超過31G)
     ES_MAX_MEM=30g
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops(官方建議)

2、Elasticsearch 字段緩存優化

1) Fielddata(字段數據)

Elasticsearh默認會將fielddata所有加載到內存。可是，內存是有限的,須要對fielddata內存作下限制:Indices.fieldata.cache.size 節點用於fielddata的最大內存,若是fielddata達到該閥值,就會把舊數據交換出去。默認設置是不限制,建議設置10%。

2) doc-values

其實就是在elasticsearch 將數據寫入索引的時候，提早生成好fileddata內容,並記錄到磁盤上。由於fileddata數據是順序讀寫的,因此即便在磁盤上,經過文件系統層的緩存，也能夠得到至關不錯的性能。doc_values只能給不分詞(對於字符串字段就是設置了 "index":"not_analyzed"，數值和時間字段默認就沒有分詞) 的字段配置生效。

如相應字段設置應該是:

"@timestamp":{

"type":"date",

"index":"not_analyzed",

"doc_values":true,

}