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,

}