文章目录
-
-
- 前言
- 配置文件
- 配置elasticsearch.yml信息
- 配置JVM信息
- 安全性设置
-
-
-
- Keystore
-
- X-pack里更专业的安全性设置
-
- docker-compose启动的集群开启xpack安全性验证
-
-
前言
对应考纲里的
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
）来进行热部署，不过按照正常考试的尿性，还是要从最基本的配置文件开始讲。
配置文件
一般用得到的配置文件分以下几个：
- elasticsearch.yml，基本上绝大部分ES的配置都在里面，包括集群信息、节点信息、部署信息之类的
- jvm.options，前文讲过，ES是一个Java应用，这个文件里就包含了ES所用的的一些JVM参数，堆栈信息、启动参数之类的
- log4j2.properties，ES应该是用的log4j作为它的日志组件，所以这里面还可以定制一些log4j的参数，不过一般情况下，90%我们是不大会改里面的东西的
一般情况下，这三兄弟都在$ES_HOME/config目录里面，对于RPM包安装的同学们来说，这三兄弟可能会在/etc/elasticsearch，当然了，我们也可以通过环境变量 ES_PATH_CONF指向我们想要放置的位置。
配置elasticsearch.yml信息
对于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的一大特点就是配置简单开箱即用，所以我们可能只会介绍一些基础配置，很骚的操作就放在课后好了。
- cluster.name： 集群名称，ES会尝试在网段里寻找和自己一样集群名称的节点组成一个集群，默认值是
elasticsearch
- node.name：节点名称，当前ES节点的名字，默认值是当前主机的hostname。虽然理论上不同节点的名字可以是一样的，但是个人建议还是取一个有意义的名字，方便后面的使用运维（e.g. node-${env}-${prod name}-${ipAddr} -> node-dev-logs-169 -> dev环境，logs产品，ip地址最后一位是169）
- network.host：es节点监听的ip地址，默认值是本机的回环地址
127.0.0.1
0.0.0.0
- 有的时候，我们会需要在单个物理机上启动多个节点，这就需要多个es节点在绑定同一个IP地址的同时通过不同的监听端口提供服务，这就用到了：
-
http.port
-
transport.port
http.port
-
-
discovery.seed_hosts
配置JVM信息
上面提到，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节点所组成的集群，它们的安全性设置可能会不完全相同。
Keystore
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里的内容。
X-pack里更专业的安全性设置
在考试中多半会有这部分内容，所以我们可以考虑在集群启动的时候就把xpack的安全性检查打开
xpack.security.enabled: true
docker-compose启动的集群开启xpack安全性验证
我自己是通过docker-compose启动的，发现有一大堆潜在坑点在等着我们，具体开启方式参考我之前的文章 Elastic Certified Engineer复习记录-集群搭建docker篇
TODO
![【51CTO学院三周年】自学路上的伴侣[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)