对应考纲里的
Installation and Configuration
Configure the nodes of a cluster to satisfy a given set of requirements
和
Secure a cluster using Elasticsearch Security
到这里开始后面的内容应该只会因为ES的版本有所区别,而不会因为ES的部署环境、部署方式有所不同了。
ES节点在部署的时候,需要特殊配置的东西很少,而且大部分配置都可以通过调用集群设置接口(PUT /_cluster/settings
)来进行热部署,不过按照正常考试的尿性,还是要从最基本的配置文件开始讲。
一般用得到的配置文件分以下几个:
一般情况下,这三兄弟都在$ES_HOME/config目录里面,对于RPM包安装的同学们来说,这三兄弟可能会在/etc/elasticsearch,当然了,我们也可以通过环境变量 ES_PATH_CONF指向我们想要放置的位置。
对于elasticsearch.yml来说,我们可以看到它后缀是yml,也就是说它支持yml的语法,包括
path:
data: /usr/local/data
logs: /usr/local/logs
和
path.data: /usr/local/data
path.logs: /usr/local/logs
这两种都可以,我个人比较喜欢第一种,毕竟第二种虽然不需要注意层级结构了,但是每一个key特别是层级比较深的key要写好长,BTW,没记错的话在内存中ES的配置信息是按第二种方式存的key-value对,不过它封装了一个很神奇的类叫settings帮助存取里面的配置信息,有兴趣的同学可以去翻翻源码。
同时,我不确定这是不是ES实现的功能,因为我在Spring里面也见过的,就是通过${SOME_KEY}的方式从环境变量里替换yml配置里的信息,比如:
node.name: ${HOSTNAME}
我们知道ES的一大特点就是配置简单开箱即用,所以我们可能只会介绍一些基础配置,很骚的操作就放在课后好了。
elasticsearch
127.0.0.1
,一般建议用本机的内网地址,当然也可以是hostname、IPv6地址之类的。如果设置成0.0.0.0
意味着es节点会监听所有网络接口。http.port
——用来监听http请求,支持从9200到9300之间的端口,可以设置单一端口或者一个端口范围,设定成端口范围时es节点会尝试绑定在端口区间中第一个可用端口。transport.port
——用来做节点之间的通信,支持从9300到9400之间的端口,同样的,它也支持单一或者端口范围,尝试绑定方式和http.port
一样。discovery.seed_hosts
,理论上为了能和其他节点组成集群,配置文件里会需要写一些其他es节点的节点信息,如ip地址、hostname等,如果是同一个IP地址中的多个节点,还需要将端口添上,如:192.168.1.2:9300, 192.168.1.2:9301……不过如果不填的话理论上也是可以彼此发现的,只是如果在es节点轮询查找的时候人品比较差,在规定时间内找不到通集群的兄弟,可能会超时报错。上面提到,ES是个Java项目,所以我们可以通过修改一些JVM的相关配置来对ES服务进行调优。
它里面支持的语法和普通的Java项目大致相同,不过文件里面一行就只有一个参数,暂时还没试过能否多个参数放一起的,还有就是它会支持一些自己定制的语法。
比较普通和常见的是最大最小内存
-Xms2g
-Xmx2g
这里官方包括各种帖子里都会提到说,最好把ES的可用内存设为当前服务器可用内存的一半,因为ES同时也是基于Lucene搭建的,所以在自己需要使用内存的同时,还要留下另外的内存给Lucene,除此之外,系统的一些缓存也会存在在这里,比如page cache、ES的query cache之类的。
对于ES来说,它的启动和各种插件的加载(即使是OSS版)也会消耗掉不少内存,所以如果启动内存小于1G(如512mb)很有可能启动都启动不了。虽然官网的docker示例里面设置的启动内存是512mb,但是在阿里云CentOS服务器里直接tar包启动的时候很容易就因为OOM而启动失败。
与此同时,官方文档里面也会建议ES的启动内存不要大于32G,这是因为对象指针压缩的原因,当启动内存小于32G的时候,指针会以int型存储最大只会占32位,但是如果启动内存大于32G的时候,内存指针会变成以long型进行存储进而占用64位,所以调大内存看起来有用,其实变大的部分会被浪费,反而得不偿失。
特别是对于一些壕门企业,比如国家队的一些机构、银行、电信运营商们,他们的机器可能都是40C256G甚至更高,那么最好还是一个物理机上启动多个ES实例,以保证每个ES实例的启动内存不要大于32G。
在JVM设置中,最好将最大最小内存都设置成一样的,因为这样就不会出现因为频繁的申请内存、GC等导致的内存、时间消耗了。
我们可以通过启动日志里的这句话来看堆栈内存使用量和对象指针压缩的开启情况
heap size [989.8mb], compressed ordinary object pointers [true]
同时,我们也可以通过这俩参数来观察堆栈内存地址和对象指针压缩情况
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintCompressedOopsMode
Heap address: 0x00000007c0000000, size: 1024 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
接下来就是一些比较冷门的语法了,比如
8:-Xmx2g
这种在正常参数前面加上 [8:] 的写法,表示当jdk版本 等于 8的时候,这个参数才会生效。
然后就是会存在区间计算的写法了,比如:
8-:-Xms2g
8-9:-Xmx2g
[8-:] 代表了当jdk 版本 大于等于 8的时候,这个命令才会生效,而[8-9:]则代表了当jdk版本为 8到9之间 的版本这个命令才会生效。
不过,JVM的配置并不一定要通过这个文件来设置,也可以通过设置 ES_JAVA_OPTS 来进行配置或补充,export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/temp" ./bin/elasticsearch
BTW,记得这里的参数后面不能有空格
-XX:+UnlockDiagnosticVMOptions \n // wrong
-XX:+PrintCompressedOopsMode\n // right
多数时候,仅仅依靠文件系统的权限控制可能无法彻底保护ES集群和它们的数据,所以Elastic团队通过一些安全性设置来进一步保护ES集群。但是请记得,每个节点的安全性设置要单独配置+加载,它们不会像其他集群设置一样一处修改整个集群生效的,我猜是因为设计的时候考虑到每个节点的实际状况可能不大相同,比如一个由各版本Unix、LInux甚至Windows节点所组成的集群,它们的安全性设置可能会不完全相同。
Elastic团队弄了一个key储存小工具叫Keystore,用来把密钥存在里面,默认会生成一个二进制文件位于$ES_HOME/bin/elasticsearch-keystore里面。
可以通过./$ES_HOME/bin/elasticsearch-keystore $params
的方式来调用这个工具。
常用参数:
参数 | 作用 | 例子 |
---|---|---|
create | 创建keystore文件 | ./elasticsearch-keystore create |
list | 列举储存项目 | ./elasticsearch-keystore list |
add | 添加条目 | ./elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password |
remove | 删除条目 | ./elasticsearch-keystore remove xpack.security.transport.ssl.keystore.secure_password |
upgrade | 升级keystore格式 | ./elasticsearch-keystore upgrade |
调用这个命令之后只会修改keystore文件里内容,并不会将其更新之后的内容自动在正在运行中的节点中进行热加载,所以需要手动调用POST _nodes/reload_secure_settings
来重新加载keystore里面的内容,在这个接口成功返回之后,keystore里面的内容才算真正在节点中生效,当然,重新启动节点也会让节点重新加载keystore里的内容。
在考试中多半会有这部分内容,所以我们可以考虑在集群启动的时候就把xpack的安全性检查打开xpack.security.enabled: true
我自己是通过docker-compose启动的,发现有一大堆潜在坑点在等着我们,具体开启方式参考我之前的文章 Elastic Certified Engineer复习记录-集群搭建docker篇
TODO