Elasticsearch Docker高可用環境搭建

介紹

做爲Elastic Stack 的核心，Elasticsearch 是一個分佈式、RESTful 風格的搜索和數據分析引擎，本次主要用於存儲業務數據和基於業務日誌進行數據統計分析。

目標

本次目標是搭建我的項目所使用的小型es高可用環境，目前須要使用es的服務有些部署在美國的服務器，有些部署在國內的服務器，帶寬延遲各不相同，爲了保證應用鏈接es延遲最小，計劃同時在美國和中國都部署節點，不一樣區域的應用鏈接不一樣的節點

基礎環境

本次配置全局使用真實服務器，服務器配置以下

名稱	CPU	內存	系統	Docker版本	磁盤大小	區域
es01	1	2G	CentOS 7	19.03.1	40 G	亞洲
es02	1	2G	CentOS 7	19.03.1	20G	美洲
es03	4	4G	CentOS 7	19.03.1	36G	美洲
es04	1	2G	CentOS 7	19.03.1	50G	亞洲

全部服務器部署的es版本均爲：6.6.2

從表中可見內存和磁盤都不大，若是是公司項目配置確定比這個好不少，但對於我的使用來講足夠了，至於爲何是須要4臺而不是3臺在最後搭建完成後會進行分析

部署前準備

就算使用了Docker容器，elasticsearch仍然不像普通鏡像那麼簡單啓動，es對虛擬內存敏感，所以服務器必須是內核虛擬化KVM架構，不支持OpenVZ虛擬，參考官方說明

Production modeedit

The vm.max_map_count kernel setting needs to be set to at least 262144 for production use. Depending on your platform:

• Linux

  The vm.max_map_count setting should be set permanently in /etc/sysctl.conf:

  $ grep vm.max_map_count /etc/sysctl.conf
  vm.max_map_count=262144
  複製代碼

  To apply the setting on a live system type: sysctl -w vm.max_map_count=262144

• macOS with Docker for Mac

  The vm.max_map_count setting must be set within the xhyve virtual machine:

  $ screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty
  複製代碼

  Just press enter and configure the sysctl setting as you would for Linux:

  sysctl -w vm.max_map_count=262144
  複製代碼

按照指引設置內存參數

$ sudo sysctl -w vm.max_map_count=262144
複製代碼

前置知識

裂腦事件

Elasticsearch犧牲了一致性，以確保可用性和分區容錯。其背後的緣由是短時間的不良行爲比短時間的不可用性問題少。換句話說，當羣集中的Elasticsearch節點沒法複製對數據的更改時，它們將繼續爲應用程序提供服務。當節點可以複製其數據時，它們將嘗試聚合副本並實現最終的一致性。

Elasticsearch經過選舉主節點來解決以前的問題，主節點負責數據庫操做，例如建立新索引，在羣集節點周圍移動分片等等。主節點與其餘節點主動協調其操做，確保數據能夠由非主節點匯聚。

在某些狀況下，先前的機制可能會失敗，從而致使裂腦事件。當Elasticsearch集羣分爲兩個區塊時，若每一個區塊都有一個節點都認爲它們是主節點，由於主節點將在數據上獨立工做，數據一致性就會丟失。所以，節點將對相同的查詢作出不一樣的響應。這將會是災難性的事件，由於來自兩個主節點的數據沒法自動從新加入，而且須要至關多的手動工做來糾正這種狀況。

節點部署

3個主節點節點均使用docker-compose命令部署，須要自行安裝好相關環境

version: '2'
services:

 es01:
 image: docker.elastic.co/elasticsearch/elasticsearch:6.6.2
 container_name: es01
 environment:
 - cluster.name=docker-cluster
 - bootstrap.memory_lock=true
 - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
 - "discovery.zen.ping.unicast.hosts=es2.xxx.com,es3.xxx.com,es4.xxx.com"
 - "discovery.zen.minimum_master_nodes=2"
 - "network.publish_host=es1..xxx.com"
 - "node.name=es01-XXX"
 ulimits:
 memlock:
 soft: -1
 hard: -1
 volumes:
 - ./elasticsearch/data:/usr/share/elasticsearch/data
 ports:
 - 9200:9200
 - 9300:9300
 networks:
 - fjyesnet
 mem_limit: 1g

networks:
 fjyesnet:
複製代碼

其餘節點配置均相同，修改服務發現域名配置便可，放行防火牆部分再也不贅述，須要能夠查看我之前發的文章

非主節點配置只需加入node.master=false配置便可

version: '2'
services:

 es01:
 image: docker.elastic.co/elasticsearch/elasticsearch:6.6.2
 container_name: es04
 environment:
 - cluster.name=docker-cluster
 - bootstrap.memory_lock=true
 - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
 - "discovery.zen.ping.unicast.hosts=es2.xxx.com,es3.xxx.com,es1.xxx.com"
 - "discovery.zen.minimum_master_nodes=2"
 - "network.publish_host=es4..xxx.com"
 - "node.name=es04-XXX"
 - "node.master=false"
 ulimits:
 memlock:
 soft: -1
 hard: -1
 volumes:
 - ./elasticsearch/data:/usr/share/elasticsearch/data
 ports:
 - 9200:9200
 - 9300:9300
 networks:
 - fjyesnet
 mem_limit: 1g

networks:
 fjyesnet:
複製代碼

參數解析

• discovery.zen.ping.unicast.hosts配置廣播地址，用於節點發現，此處配置的是指向其餘節點IP的域名地址，該域名在任何節點都可以被訪問

• discovery.zen.minimum_master_nodes配置主節點最小數量，該參數十分重要，用於防止腦裂（split-brain）事件的發生。

  原理：前面提到了腦裂事件發生的緣由，而避免的方法就是保證至少3個節點可靠地工做，由於一個或兩個節點不能造成多數投票，這也是爲何選擇使用4個節點並將該值配置爲2，確保分佈式環境還能夠隨機宕機一個節點以保證不會出現腦裂問題，所以第4個節點最好配置爲沒法成爲主節點的slave節點。而若僅配置爲3個節點的高可用狀態，實際上是一種「僞高可用」，此時隨機宕機一個節點將可能發生「腦裂」問題，2個節點的es環境沒法進行主節點的選舉，而且可能出現獨立的分塊。

• network.publish_host用於提供其餘節點服務發現的主機名，默認爲本地主機名映射爲IP的地址，但因爲使用容器提供服務發現，而且不在同一個網段，故須要手工指定

• mem_limit容器內存限制爲1G

節點數量與配置的主節點數對應關係

Master nodes	minimum_master_nodes	備註
1	1
2	1	若是另外一個節點宕機，集羣將中止工做!
3	2
4	3
5	3
6	4

對可能產生疑問的解釋

1.當前docker-compose已經更新到3.7了爲何還使用2這個老版本？

緣由：最新文檔地址，官方文檔指出3.x版本已經再也不支持mem_limit參數

Note: This replaces the older resource constraint options for non swarm mode in Compose files prior to version 3 (cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit, mem_swappiness), as described in Upgrading version 2.x to 3.x.

但對小內存機器以及數據量不會很是的大的環境，內存限制參數尤其重要，通過實測，空載或者小負載（1000 doc）如下的es節點內存佔用大約爲1.5G左右，故各環境限制爲1G不會影響性能，不只如此，es官方提供的部署文檔使用的也是2.2版本

2.當前Elasticsearch已經更新到7.3了爲何還使用6.6這個老版本？

緣由：7.x版本目前尚有許多外部服務不能兼容，例如graylog，而且Spring官方組件暫時也只能兼容到6.x的版本，因此綜合考慮使用6.x的最新版6.6.2

graylog官方文檔

Caution

Graylog 3.x does not work with Elasticsearch 7.x!

Spring官方文檔

Compatibility Matrix

Spring Data Elasticsearch	Elasticsearch
3.2.x (not yet released)	6.8.1
3.1.x	6.2.2
3.0.x	5.5.0
2.1.x	2.4.0
2.0.x	2.2.0
1.3.x	1.5.2

3.通常高可用不是部署3個節點就足夠了嗎，爲何要4個節點？

緣由：本次總共部署了3個主節點和一個非主節點，即4個都是數據節點，但只有3個參與選舉。若是僅部署3個節點，那麼3個都必須爲主節點，此時若其中一個主節點宕機，那麼不知足選舉「至少3個節點可靠地工做」的條件，故新增多一個冗餘數據節點，其不能競選爲主節點，但能對節點競選作出響應，依然知足條件，詳細算法能夠參考Raft協議的實現原理

節點啓動

使用docker-compose命令啓動便可

$ docker-compose up -d
複製代碼

這種直接啓動的方式會報文件夾無訪問權限的錯誤，須要在命令執行後手動賦予文件夾訪問權限

$ chmod 777 -R elasticsearch/
$ chown 1000:1000 -R elasticsearch/
複製代碼

若此時es容器已經中止則再執行一次啓動命令便可

部署結果

使用chrome插件elasticsearch-head鏈接任意一個節點查看狀況

4節點在線，接入業務系統後各節點狀況以下圖。

注意全部索引副本數都要是2或者3，不然都沒法實現高可用效果

因爲網絡問題或者服務器問題致使其中一個節點下線，es會自動對各個節點的副本從新路由，此時集羣顏色爲黃色，仍然可用，稍等片刻會實現最終一致性

若此時主節點下線，整個集羣會馬上從新選舉出新的主節點並路由各個分片，保證24小時服務都處在可用狀態

橙色表示還沒有路由完成，但全部索引數據都可用

注意

若某些索引的副本數設置爲1，則當某個節點宕機且其恰好存儲該索引的副本，則整個集羣的狀態將馬上變成紅色，意思是數據丟失

灰色表示已經下線的分片而且沒法被從新路由