elasticsearch centos集群

解压缩 elasticsearch 包:

最新es版本要求有JDK 8以上的版本

bin:存放es的一些可执行脚本,比如用于启动进程的elasticsearch命令,以及用于安装插件的elasticsearch-plugin插件
conf:用于存放es的配置文件,比如elasticsearch.yml
data:用于存放es的数据文件,就是每个索引的shard的数据文件
logs:用于存放es的日志文件
plugins:用于存放es的插件
script:用于存放一些脚本文件

在生产环境中的多台机器上部署es集群,就涉及到了es的discovery机制,也就是集群中各个节点互相发现然后组成一个集群的机制,同时discovery机制也负责es集群的master选举

master node和data node两种角色,es是一种peer to peer,也就是p2p点对点的分布式系统架构,

es是一种peer to peer,也就是p2p点对点的分布式系统架构,不是hadoop生态普遍采用的那种master-slave主从架构的分布式系统。集群中的每个node是直接跟其他节点进行通信的,几乎所有的API操作,比如index,delete,search,等等,都不是说client跟master通信,而是client跟任何一个node进行通信,那个node再将请求转发给对应的node来进行执行。正常情况下,就只有一个master node。master node的责任就是负责维护整个集群的状态信息,也就是一些集群元数据信息,同时在node加入集群或者从集群中下线时,重新分配shard,或者是创建或删除了一个索引。包括每次cluster state如果有改变的化,那么master都会负责将集群状态同步给所有的node。master node负责接收所有的cluster state相关的变化信息,然后将这个改变后的最新的cluster state推动给集群中所有的data node,集群中所有的node都有一份完整的cluster state。只不过master node负责维护而已。其他的node,除了master之外的node,就是负责数据的存储和读写的,写入索引,搜索数据。

如果要让多个node组成一个es集群,首先第一个要设置的参数,就是cluster.name,多个node的cluster.name如果一样,才满足组成一个集群的基本条件。这个cluster.name的默认值是elasticsearch,在生产环境中,一定要修改这个值,否则可能会导致未知的node无端加入集群,造成集群运行异常。而es中默认的discovery机制,就是zen discovery机制,zen discovery机制提供了unicast discovery集群发现机制,集群发现时的节点间通信是依赖的transport module,也就是es底层的网络通信模块和协议。es默认配置为使用unicast集群发现机制,以让经过特殊配置的节点可以组成一个集群,而不是随便哪个节点都可以组成一个集群。但是默认配置下,unicast是本机,也就是localhost,因此只能在一台机器上启动多个node来组成一个集群。虽然es还是会提供multicast plugin作为一个发现机制,但是已经不建议在生产环境中使用了。虽然我们可能想要multicast的简单性,
就是所有的node可以再接收到一条multicast ping之后就立即自动加入集群。但是multicast机制有很多的问题,而且很脆弱,
比如网络有轻微的调整,就可能导致节点无法发现对方。因此现在建议在生产环境中用unicast机制,提供一个es种子node作为中转路由节点就可以了。

这里有相关配置,这里来说一下 jvm

默认jvm 堆2g

其他信息

## GC configuration    
-XX:+UseConcMarkSweepGC    # cms垃圾回收器
-XX:CMSInitiatingOccupancyFraction=75  #cms触发回收老年代gc的百分比,新生代是 partNew并行回收,复制算法
-XX:+UseCMSInitiatingOccupancyOnly # 只是用设定的回收阈值(上面指定的75%,他俩配合使用),如果不指定,JVM仅在第一次使用设定值,后续则自动调整.

## optimizations

# disable calls to System#gc   禁止在代码中调用gc
-XX:+DisableExplicitGC 

# pre-touch memory pages used by the JVM during initialization

在没有配置-XX:+AlwaysPreTouch参数即默认情况下,JVM参数-Xms申明的堆只是在虚拟内存中分配,而不是在物理内存中分配:它被以一种内部数据结构的形式记录,从而避免被其他进程使用这些内存。这些内存页直到被访问时,才会在物理内存中分配。当JVM需要内存的时候,操作系统将根据需要分配内存页。

配置-XX:+AlwaysPreTouch参数后,JVM将-Xms指定的堆内存中每个字节都写入’0’,这样的话,除了在虚拟内存中以内部数据结构保留之外,还会在物理内存中分配。并且由于touch这个行为是单线程的,因此它将会让JVM进程启动变慢。
-XX:+AlwaysPreTouch

## basic

# force the server VM (remove on 32-bit client JVMs)  强制使用 server VM
-server

# explicitly set the stack size (reduce to 320k on 32-bit client JVMs) 线程栈大小
-Xss1m

# set to headless, just in case  Headless模式是系统的一种配置模式。在该模式下,表示系统可能缺少了显示设备、键盘或鼠标。
-Djava.awt.headless=true

# ensure UTF-8 encoding by default (e.g. filenames) 文件名 UTF-8 编码
-Dfile.encoding=UTF-8

# use our provided JNA always versus the system one  使用es自己提供的JNA来访问底层从,c ,c++代码
-Djna.nosys=true

# use old-style file permissions on JDK9
-Djdk.io.permissionsUseCanonicalPath=true

# flags to configure Netty
-Dio.netty.noUnsafe=true   # 默认会使用Heap堆内存创建ByteBuf
-Dio.netty.noKeySetOptimization=true  #优化选择器key集合
-Dio.netty.recycler.maxCapacityPerThread=0   # 禁用netty recycler 回收功能

# log4j 2
-Dlog4j.shutdownHookEnabled=false
-Dlog4j2.disable.jmx=true
-Dlog4j.skipJansi=true

## heap dumps

# generate a heap dump when an allocation from the Java heap fails 申请内存错误的时候导出堆信息,在jvm的工作目录下
# heap dumps are created in the working directory of the JVM
-XX:+HeapDumpOnOutOfMemoryError

一些其他gc 日志打印信息略过

 

master node,master eligible node,data node

你配置的时候,是配置多个node变成master eligible node,但是只是说,从这些master eligible node选举一个node出来作为master node,其他master eligible node只是接下来有那个master node故障的时候,接替他的资格,但是还是作为data node去使用的,一般建议master eligible node给3个即可:node.master: true,node.data: false,剩下的node都设置为data node:node.master: false,node.data: true,但是如果一个小集群,就10个以内的节点,那就所有节点都可以作为master eligible node以及data node即可,超过10个node的集群再单独拆分master和data node吧,如果你的节点数量小于10个,小集群,那所有的node,就不要做额外的配置了,都是master eligible node,同时也是data node,默认情况下,es会将自己绑定到127.0.0.1上,对于运行一个单节点的开发模式下的es是ok的。但是为了让节点间可以互相通信以组成一个集群,需要让节点绑定到一个ip地址上,非回环的地址,一般会配置:network.host: 192.168.93.128(本机地址)。一旦我们配置了network.host,那么es就会认为我们从开发模式迁移到生产模式,同时会启用一系列的bootstrap check。

ping:ping是一个node用discovery机制来发现其他node的一个过程

unicast discovery集群发现机制是要求配置一个主机列表,用来作为gossip(流言式)通信协议的路由器。这些机器如果通过hostname来指定,那么在ping的时候会被解析为ip地址。unicast discovery机制最重要的两个配置如下所示:

hosts:用逗号分割的主机列表
hosts.resolve_timeout:hostname被DNS解析为ip地址的timeout等待时长

简单来说,如果要让多个节点发现对方并且组成一个集群,那么就得有一个中间的公共节点,然后不同的节点就发送请求到这些公共节点,接着通过这些公共节点交换各自的信息,进而让所有的node感知到其他的node存在,并且进行通信,最后组成一个集群。这就是基于gossip流言式通信协议的unicast集群发现机制。当一个node与unicast node list中的一个成员通信之后,就会接收到一份完整的集群状态,这里会列出集群中所有的node。接着那个node再通过cluster state跟master通信,并且加入集群中。这就意味着,我们的unicast list node是不需要列出集群中的所有节点的。只要提供少数几个node,比如3个,让新的node可以连接上即可。如果我们给集群中分配了几个节点作为专门的master节点,那么只要列出我们那三个专门的master节点即可。
用如下的配置即可:discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]。

cluster.name
node.name
network.host
discovery.zen.ping.unicast.hosts

(1)已经初步配置好了,各个节点,首先通过network.host绑定到了非回环的ip地址,从而可以跟其他节点通信
(2)通过discovery.zen.ping.unicast.hosts配置了一批unicast中间路由的node
(3)所有node都可以发送ping消息到路由node,再从路由node获取cluster state回来
(4)接着所有node会选举出一个master
(5)所有node都会跟master进行通信,然后加入master的集群
(6)要求cluster.name必须一样,才能组成一个集群
(7)node.name就标识出了每个node我们自己设置的一个名称

master选举

在ping发现过程中,为集群选举出一个master也是很重要的,es集群会自动完成这个操作。这里建议设置discovery.zen.ping_timeout参数(默认是3s),如果因为网络慢或者拥塞,导致master选举超时,那么可以增加这个参数,确保集群启动的稳定性。

在完成一个集群的master选举之后,每次一个新的node加入集群,都会发送一个join request到master node,可以设置discovery.zen.join_timeout保证node稳定加入集群,增加join的timeout等待时长,如果一次join不上,默认会重试20次。

如果master node被停止了,或者自己宕机了,那么集群中的node会再次进行一次ping过程,并且选举出一个新的master。如果discovery.zen.master_election.ignore_non_master_pings 设置为了true,那么会强制区分master候选节点,
如果node的 node.master 设置为了false,还来发送ping请求参与master选举,那么这些node会被忽略掉,因为他们没有资格参与。

discovery.zen.minimum_master_nodes参数用于设置对于一个新选举的master,要求必须有多少个master候选node去连接那个新选举的master。而且还用于设置一个集群中必须拥有的master候选node。如果这些要求没有被满足,那么master node就会被停止,然后会重新选举一个新的master。这个参数必须设置为我们的master候选node的quorum数量。一般避免说只有两个master候选node,因为2的quorum还是2。如果在那个情况下,任何一个master候选节点宕机了,集群就无法正常运作了。

集群故障的探查

es有两种集群故障探查机制,第一种是通过master进行的,master会ping集群中所有的其他node,确保它们是否是存活着的。第二种,每个node都会去ping master node来确保master node是存活的,否则就会发起一个选举过程。

有下面三个参数用来配置集群故障的探查过程:

ping_interval:每隔多长时间会ping一次node,默认是1s
ping_timeout:每次ping的timeout等待时长是多长时间,默认是30s
ping_retries:如果一个node被ping多少次都失败了,就会认为node故障,默认是3次

集群状态更新

master node是集群中唯一一个可以对cluster state进行更新的node。master node每次会处理一个集群状态的更新事件,应用这次状态更新,然后将更新后的状态发布到集群中所有的node上去。每个node都会接收publish message,ack这个message,但是不会应用这个更新。如果master没有在discovery.zen.commit_timeout指定的时间内(默认是30s),从至少discovery.zen.minimum_master_nodes个节点获取ack响应,那么这次cluster state change事件就会被reject,不会应用。但是一旦在指定时间内,指定数量的node都返回了ack消息,那么cluster state就会被commit,然后一个message会被发送给所有的node。所有的node接收到那个commit message之后,接着才会将之前接收到的集群状态应用到自己本地的状态副本中去。接着master会等待所有节点再次响应是否更新自己本地副本状态成功,在一个等待超时时长内,如果接收到了响应,那么就会继续处理内存queue中保存的下一个更新状态。discovery.zen.publish_timeout默认是30s,这个超时等待时长是从plublish cluster state开始计算的。

不因为master宕机阻塞集群操作

如果要让集群正常运转,那么必须有一个master,还有discovery.zen.minimum_master_nodes指定数量的master候选node,都在运行。discovery.zen.no_master_block可以控制当master当即时,什么样的操作应该被拒绝。有下面两个选项:

all:一旦master当即,那么所有的操作都会被拒绝
write:这是默认的选项,所有的写操作都会被拒绝,但是读操作是被允许的

 

基本参数设置:

一般情况下,,更改集群名称和节点名称。

在RAID 0的存储级别下,每个磁盘上回存储一部分数据,但是如果一个磁盘故障了,那么可能导致这台机器上的部分数据就丢失了。如果我们的es是有replica的,那么在其他机器上还是会有一份副本的。如果data file指定了多个目录,为了尽量减少数据丢失的风险,es会将某个shard的数据都分配到一个磁盘上去。这就意味着每个shard都仅仅会放在一个磁盘上。es不会将一个shard的数据条带化存储到多个磁盘上去,因为如果一个磁盘丢失了,就会导致整个shard数据丢失。但是这又引入了性能的问题,如果我们给一个机器添加更多的磁盘来提升单个索引的读写性能,是没有效果的。因为这个索引在这个机器上的shard仅仅存在于一个磁盘上。因此data file指定多个目录,仅仅对于你的一台机器上存储了多个index的多个shard时,才会有效果的。因为不同index的shard可能就被存储到不同的磁盘上去了,对多个index的shard读写可以走不同磁盘,提升了性能。

虽然multiple data path是一个很有用的功能,但是es毕竟不是一个专门的RAID软件。如果我们要对RAID存储策略进行更多的配置,提高存储的健壮性以及灵活性,还是要用专门的RAID软件来进行机器的磁盘数据存储,而不是用multiple data path策略。

综上所述,multiple data path功能在实际的生产环境中,其实是较少使用的。

es有两个配置文件,elasticsearch.yml,用于配置es,还有一个log4j.properties用来配置es日志打印。这些文件都被放在config目录下,默认就是ES_HOME/config。
可以通过下面的命令来重新设置:./bin/elasticsearch -Epath.conf=/path/to/my/config/。

 

日志配置:

es使用log4j2来记录日志,log4j2可以通过log4j2.properties文件来进行配置。比如下面的这份配置文件:

appender.rolling.type = RollingFile 
appender.rolling.name = rolling
appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log 
appender.rolling.layout.type = PatternLayout
appender.rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c] %.10000m%n
appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}.log 
appender.rolling.policies.type = Policies
appender.rolling.policies.time.type = TimeBasedTriggeringPolicy 
appender.rolling.policies.time.interval = 1 
appender.rolling.policies.time.modulate = true 

appender.rolling.type = RollingFile,就配置了appender类型是RollingFile

appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log,就配置了日志路径是/var/log/elasticsearch/production.log

appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}.log,就配置了将日志每天写一份到/var/log/elasticsearch/production-2017-01-01.log文件中

appender.rolling.policies.time.type = TimeBasedTriggeringPolic,这里配置了用基于时间的roll策略

appender.rolling.policies.time.interval = 1,这个设置了每天一份日志文件

appender.rolling.policies.time.modulate = true,这个设置了根据自然天来划分文件,而不是24小时

还可以配置将日志文件保留一段时间内,同时删除之前的日志文件

appender.rolling.strategy.type = DefaultRolloverStrategy 
appender.rolling.strategy.action.type = Delete 
appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path} 
appender.rolling.strategy.action.condition.type = IfLastModified 
appender.rolling.strategy.action.condition.age = 7D 
appender.rolling.strategy.action.PathConditions.type = IfFileName 
appender.rolling.strategy.action.PathConditions.glob = ${sys:es.logs.cluster_name}-* 

第一行是配置了默认的DefaultRolloverStrategy
第二行是配置了Delete action,在rollover之后,就会删除文件
第三行是配置了es log的基础路径
第四行是配置了rollover发生的条件,是基于IfLastModified
第五行是配置了保留的天数,这里是7天
第六行是配置了删除匹配7天前的文件
第七行是配置了一个删除文件的格式,这样就只是删除过期日志文件,但是不要删除慢查询日志

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值