文章详情广告pc

【经验贴】从一个浪漫的故事,谈谈Elasticsearch的前世今生(二)

陈华华
原创 5390       2017-03-02  
上一篇,已经介绍了ES由来于一个浪漫的爱情故事,也详细介绍了其核心概念(请戳蓝色字体:谈谈Elasticsearch的前世今生(一)),今天本文将基于实践经验进行Elasticsearch集群管理与监控的介绍。


【 硬件配置】

1.内存 

 因为ES天生是集群模式,所以要求一个ES最好2个节点以上,当然1个节点也可以使用ES的功能,但是因为一个节点无法创建副本分片,对数据的安全和容灾是没有保证的,单个节点一旦挂掉或者分片出现问题,那么数据将不可访问。

2.0以上的版本默认为ES分配的内存是1G,这个是可以根据实际业务场景修改的。ES为了加快索引查询的速度,会将一部分数据缓存到内存中,另外Lucene也需要很大一部分缓存,所以建议修改ES默认的内存设置。我们现在采用的是64G内存+8核CPU+1T磁盘的方式。


2.磁盘  

现在大部分的应用场景瓶颈其实都在磁盘上,所以如果有SSD磁盘那是最好的选择,ES索引数据的时候需要比较高的磁盘IO,现在普通的机械硬盘或者类似阿里云上的普通云硬盘也可以满足小批量的数据索引入库或者对实时性要求没有那么高的场景。

如果是自建机房,只有机械硬盘,也可以考虑采用Raid0的方式,也能对ES的索引性能有比较大的提高,做Raid0不需要从硬件层面考虑数据安全和完整性的问题,因为ES集群默认是有副本备份的,一旦主分片出现问题,对应的副本分片马上会被提升为主分片,保证功能和数据的完整。

另外综合考虑硬件成本和性能以及业务场景问题,可以考虑在ES集群中将冷热数据进行分离。


3.CPU 

 CPU核数需要根据具体的业务场景和数据量来决定,但如果生产环境,最好不要太低(比如1核或者2核)


【版本选择】

生产环境现在使用的ES-2.3.2(因为我们使用ES的时候最新的版本就是2.3.2),属于version-2.x系列,该系列最新最高的版本号为version-2.4.4,而ES最新的版本为ES-5.1.2。

version-5.x版本提供了许多新的特性,同时索引性能也有30%以上的提高,在节点启动过程中加入了许多系统参数的校验,如Max File Descriptors,Memory Lock, Virtual Memory等,这些系统参数都是会影响ES集群稳定性的关键因素,如果配置不符合要求,提早抛出,是非常明智的选择。

至于到底是该选择2.x还是5.x系列,要根据实际情况决定:如果你还有接触过ES或者是刚刚开始接触ES,那么推荐从version-5.x最新版本开始,体验最新的功能和性能;如果是现在已经部署上了version-2.x系列的ES,并且当前集群稳定运行,没有大的问题,建议不要升级,毕竟生产环境升级ES版本,本身来说就是一个考验,同时已经在跑的很多应用可能都要重写代码,得不偿失,当然,喜欢折腾并且不怕出问题的,请忽略上面的建议。

另外这里插句题外话,很多人多ES的版本号从2.x直接跳跃到5.x感到困惑,一般是当有非常大的升级改进的时候才会有类似大版本的跨越,但是ES-5.x相较于2.x其实并没有像版本号那么大的飞跃,这里这么做是因为Elastic公司考虑将旗下的ELK及相关的插件服务统一版本号,并且都归并到Elastic Stack中。

而彼时,ElasticSearch最新的版本为2.x,Logstash为2.x,Kibana则为4.x,Kibana的下一个大版本5.0,所以Elastic索性将ES和Logstash都统一升级到5.x,并在接下来的升级中统一ELK的步伐。


【 集群管理与监控】

1.ES集群的部署 

 如果ES集群规模比较大,那么部署ES实例将会成为一个比较繁琐和麻烦的事情,如果后期涉及到集群的参数修改或者调优,那么修改配置文件也将是一个头疼的问题,官方提供了Puppet和Chef,自动化部署和运维。

不过目前使用的是Ansible,功能类似,但是不需要部署Agent,通过SSH来完成远程一键安装部署、修改配置文件的工作。当然,你也可以选择其他的方式。


2.管理集群
API调用官方提供了很多Restful形式的API,可以直接调用来查看ES的集群状态,并且可以随时修改ES的配置参数(临时和永久),如下面的两个Restful命令分别是查看集群当前的健康状况和索引的详细情况:

这为我们随时监控管理ES集群提供了比较方便的方式。

同时也需要做以下几个方面的考虑:

节点角色细分 

在部署ES之初就应该根据业务量规划好ES集群各个节点的功能。

ES的节点有三种角色:data,master,client,角色不同,功能也不同,默认节点都有data和maser的角色,业务量较小的时候,这些角色不仔细区分,不会有多大影响,但是当数据量大起来,导致ES集群规模增大后,需要考虑将不同的节点划归为不同的角色。

冷热数据分离 

对于日志型应用来说,一般采用以天或者月为单位建立索引,当天/当月的热索引在写入的同时也会有较多的查询。

N台机器做热数据的存储, 上面只放当天的数据。这N台热数据节点上面的elasticsearc.yml中配置node.tag: hot,之前的数据放在另外的M台机器上。这M台冷数据节点中配置node.tag: stale,模板中控制对新建索引添加hot标签:

每天计划任务更新索引的配置, 将tag 更改为stale, 索引会自动迁移到M台冷数据节点

这样,写操作集中在N台热数据节点上,大范围的读操作集中在M台冷数据节点上。避免了堵塞影响。

定期对较大索引进行force merge  

最好是每个shard merge成一个segment。heap消耗与segment数量有关系,force merge可以显著降低这种消耗。 如果merge成一个segment还有一个好处,就是对于terms aggregation,搜索时无需构造Global Ordinals,可以提升聚合速度。


3.集群的监控 
除了上面提到的采用API的方式监控和管理集群,也可以使用web的方式监控和管理集群。

version-2.x系列中官方和第三方都提供了很多ES管理和监控的工具,如Head,marvel等;version-5.x因为是最近升级的,所以第三方的监控管理插件还比较少,官方将Kibana和marvel等都集成在一个叫做X-pack的服务中,只需安装这一个插件就可以了,这也极大的简化了原来的工作量。


【集群备份】

在使用ES作为主存储和搜索引擎之后,数据的归档备份就是必须要考虑的一个问题,每天有上百G、几千万的数据源源不断的被写入ES集群中,现有的硬盘容量肯定无法长久支持这样的业务量,并且很多场景也没必要一直将数据存放在生产环境的ES集群中,所以备份出来以备后期可能对这些冷数据的二次处理分析,就显得比较迫切,这里提供一种我们在使用的ES集群的备份方案。


1.ES集群创建共享目录
ES集群的每个节点上都安装sshfs


▪  利用sshfs创建共享目录的挂载点 选定一个节点的一个目录作为共享目录(不要放在系统盘所在目录,该目录所在的空间要比ES所有索引主分片的总空间大)


▪  在每个节点的相同位置创建目录,并挂载共享目录,IP和共享目录具体执行时请根据实际情况替换


▪  测试运行hadoop的用户是否有对共享目录的写权限


▪  可以在各个节点上查看 /mnt/backup目录下是否有test文件


2.修改elasticsearch.yml配置文件
▪ 新版本的ES中加强了对安全的控制,所以创建的仓库路径必须在ES的配置文件elasticsearch.yml中写入,否则创建不成功 ES集群每个节点的配置文件中添加如下配置,可以配置多个repo,中间以逗号分隔。

▪ 每个节点的ES配置文件都要添加该配置项,然后重启ES


3.创建仓库 

利用sense控制台中调用ES的restful API执行命令或者利用curl的方式在linux命令行中执行

 针对ES中单个的index创建快照备份,快照名字自定义,这里以snapshot_test举例,可以创建多个快照,每个快照的名字必须唯一

或者是针对集群中所有处于open和started状态的索引创建快照,注意处于red状态的索引是无法创建快照备份的

*注意:需要保证ES集群的状态为green,如果为red,以上创建快照会失败


▪ 查看备份状态

现在可以开始进行迁移了,备份创建好之后,在共享目录/data/es_backup里是这样的:


▪ 迁移目标的集群上重复上面创建仓库的操作
将源集群的备份内容(/opt/es_backup里的所有文件),复制到迁移目标的集群仓库目录里。
在sense中使用RESTful API进行备份的恢复,设置恢复速度为100mb/s。


▪ 查看恢复的状态



【 ES索引性能提升方案】

ES生产环境在使用过程中碰到的最大问题就是索引速度慢,这个和ES自身的索引机制有一定关系,但是最大的问题在于我们使用的阿里云的普通云盘,IOPS只有500不到,并且没有其他可以替换的磁盘(包括高效云盘和SSD云盘),所以硬件层面得不到解决,我们只能考虑一些ES的索引性能优化方案。


主要包括以下几方面:
1. replica数目 
可以在建index mapping时将副本数设为0,待数据入库完毕或者过了高峰期以后再将副本数设为1,这样即使在普通云盘上,索引入库的速度也会有很大的提升,在测试中会有30%以上的性能提升。


2. refresh时间间隔
ES是是近实时搜索,数据被索引进ES以后,默认的可搜索延迟是1s,对于写入量很大的场景,这样的配置会导致写入吞吐量很低,如果对搜索时间没有实时性的要求,可以适当提高索引刷新间隔,提升写入量。


3.修改translog 
Elasticsearch 2.0 以后为了保证不丢失数据,每次 index、bulk、delete、update 完成的时候,会触发刷新 translog 到磁盘上(Write Ahead Log),才给请求返回 200 OK。这个改变在提高数据安全性的同时当然也降低了一点性能,默认是5000条刷新一次,可以将该值适当增加,具体数值需要结合硬件和数据进行测试,找到一个平衡点。降低数据flush到磁盘的频率。如果对数据丢失有一定的容忍,可以打开async模式,如下两个配置项:


版权所有 侵权必究

如需转载请联系

0571-28829811

恒生技术之眼原创文章,未经授权禁止转载。详情见转载须知

联系我们

恒 生 技 术 之 眼