ES集群安全配置
集群安全
- 启用安全策略
(1) 验证版本是否支持
① Elasticsearch的安全策略需要X-Pack插件的支持，不过对于7.X以上版本X-Pack已经内置，所以不需要额外的操作。
② 官方说明：
1) https://www.elastic.co/cn/subscriptions
2) 许可配置：https://www.elastic.co/guide/en/kibana/7.6/managing-licenses.html
③ 7.1以后安全功能免费，但是不包括单点登录、LDAP身份认证以及字段和文档级安全选项。
④ 6.8之前，需要手动安装x-pack：
1) bin/kibana-plugin install x-pack
2) bin/elasticsearch-plugin install x-pack
(2) 打开安全配置选项（xpack.security.enabled）：免费版本（基础版或者使用许可证）默认false，需要我们手动打开xpack.security.enabled=true，黄金VIP以上版本默认开启，但是建议仍然手动显式设置开启。
① [1] bootstrap checks failed
② [1]: Transport SSL must be enabled if security is enabled on a [basic] license. Please set [xpack.security.transport.ssl.enabled] to [true] or disable security by setting [xpack.security.enabled] to [false]
(3) 节点通讯安全性：未启用加密的群集将以纯文本格式（包括密码）发送所有数据。如果启用了Elasticsearch安全功能，除非您具有试用许可证，否则必须配置SSL / TLS进行节点间通信：
① 确认xpack.security.enabled设置为true
② 生成节点证书：TLS需要X.509证书才能对与之通信的应用程序执行加密和身份验证。为了使节点之间的通信真正安全，必须对证书进行验证。在Elasticsearch集群中验证证书真实性的推荐方法是信任签署证书的证书颁发机构（CA）。这样，将节点添加到群集时，它们只需要使用由同一CA签名的证书，即可自动允许该节点加入群集。此外，建议证书包含与节点的IP地址和DNS名称相对应的主题备用名称（SAN），以便可以执行主机名验证。
1) 为Elasticsearch集群创建证书颁发机构：您可以配置集群来信任所有拥有证书的节点，这些证书是由这个ca签署的。此文件是PKCS#12密钥存储库，其中包含您的CA的公共证书和用于为每个节点签署证书的私钥。elasticsearch-certutil命令还提示您输入密码以保护文件和密钥。如果您计划将来在集群中添加更多节点，请保留该文件的副本并记住其密码。
bin/elasticsearch-certutil ca
生成的 .p12包含CA的公共证书和用于对每个节点的证书签名的私钥。生成过程中 设置的密码在日后集群的横向扩容中需要用到，因此需要牢记。
2) 为集群中每个节点生成私钥及证书：
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
生成的 .p12文件包含了节点证书、节点密钥和CA证书。这个密码可以直接Enter 设置为空。节点证书默认不包含主机信息，所以每个节点都可以用此证书，但是节点 必须关闭主机认证。
3) 把节点证书复制到对应位置：需要将节点证书拷贝至config目录下
③ 配置每个节点启用TLS：Transport层必须配置，HTTP层非必须，但是建议最好配置。
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12
④ 重启集群
⑤ 其他通讯加密：
1) Kibana
2) Logstash
3) Beats
4) Java
5) Hadoop
(4) 设置用户名和密码：
bin/elasticsearch-setup-passwords interactive
elasticsearch-setup-passwords使用引导密码，使用一次后失效，并且当前命令也不可再次使用。
① Elasticsearch内置账户：
1) elastic：Elastic内置超级用户
2) apm_system：APM服务器在Elasticsearch中存储监视信息时使用的账户。
3) kibana：kibana连接elasticsearch的账户。
4) logstash_system：Logstash讲采集的日志输出到Elasticsearch时使用的账户。
5) beats_system：beats在存储数据输出到Elasticsearch时使用的账户。
6) remote_monitoring_user：Metricbeat用户在Elasticsearch中收集和存储监视信息时使用
② 内置账户信息：
1) 内置账户存储在.security索引中，由Elasticsearch统一管理。
(5) 修改密码：
curl -H "Content-Type:application/json" -XPOST -u kibana 'http://172.16.10.184:9200/_xpack/security/user/elastic/_password' -d '{ "password" : "123456" }'
(6) 关于Head插件登录问题：
① master节点增加配置：http.cors.allow-headers: "Authorization,X-Requested-With,Content-Length,Content-Type"
② host/?auth_user=elastic&auth_password=my_pwd
(7) Logstash和Beats增加需在配置文件中修改。
- ES集群调优：
(1) 慢日志：分片级的，针对于data_node。
① 现象：
1) 连接大量被拒绝
2) CPU居高不下
3) 查询超时
② 原因：
1) 软件配置不合理
2) 硬件资源不够
③ 配置：
1) 慢查询
- 配置
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms
index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug: 500ms
index.search.slowlog.threshold.fetch.trace: 200ms
index.search.slowlog.level: info
- setting
PUT /index/_settings
{
"index.search.slowlog.threshold.query.warn": "10s",
"index.search.slowlog.threshold.query.info": "5s",
"index.search.slowlog.threshold.query.debug": "2s",
"index.search.slowlog.threshold.query.trace": "500ms",
"index.search.slowlog.threshold.fetch.warn": "1s",
"index.search.slowlog.threshold.fetch.info": "800ms",
"index.search.slowlog.threshold.fetch.debug": "500ms",
"index.search.slowlog.threshold.fetch.trace": "200ms",
"index.search.slowlog.level": "info"
}
2) 慢写入
index.indexing.slowlog.threshold.index.warn: 10s
index.indexing.slowlog.threshold.index.info: 5s
index.indexing.slowlog.threshold.index.debug: 2s
index.indexing.slowlog.threshold.index.trace: 500ms
index.indexing.slowlog.level: info
index.indexing.slowlog.source: 1000
(2) 优化建议：
① 搜索：
1) 减小page size：搜索结果不要返回过大的结果集，每页搜索数量控制在1000以内。
2) 避免deeping：如果需要深度分页，建议使用scroll search，如果一定要使用深查询，考虑使用search after，下面是讲解：https://www.elastic.co/guide/en/elasticsearch/reference/7.7/search-request-body.html#request-body-search-search-after
3) 聚合查询避免过多分桶：对于桶数过多的聚合，应将数据切片：比如按时间、按地理位置等分词请求。
4) 能用filter的不要使用query。
5) 避免过多agg嵌套。
6) 尽量避免使用fuzzy、前缀和正则，可以使用suggest做模糊搜索。
② 写入优化：
1) 用bulk批量写入
2) 使用多线程将数据写入ES
3) 大量数据一次性写入： 如果我们需要一次性写入大量数据，可以先禁止refresh和replia复制，将index.refresh_interval设置为-1，将index.number_of_replicas设置为0。但是ES不需要创建segment file文件了，replica数据也不需要互相同步了。此时写入的速度会非常快，我们可以等数据写入完成之后，再把他们设置回来。
4) 增加buffer缓冲区大小：indices.memory.index_buffer_size，一般来说indices.memory.index_buffer_size/total_shards< jvm heap的10%，增大buffer的大小可以大大提高写入速度。
5) 把更多内存留给OS Cache：可能有人认为应该把Jvm heap调大会增加性能，这都是想当然的操作，我们不仅不应该增大Jvm heap，反而应该把更多内存留给OS Cache，因为Lucene底层的读写都是基于OS cache的，需要大量的内存。
③ 数据结构：
1) 尽量使用手工mapping，尽量手动指定string字段类型。
2) 避免稀疏数据结构：会产生磁盘浪费，同时降低读写性能。
3) 避免将没有任何关联性的数据写入同一个索引。
4) 检索和聚合解耦：避免把大量用于检索的数据和用于聚合的数据放在同一个index。
5) 仅用于检索的字段关闭doc value，仅用于聚合的字段关闭index。
6) 避免使用filelddata。
7) 禁用norms：对于不需要参与评分的字段，可设置false，常见的比如filter和agg字段。
8) 禁用 index_options.
9) 禁用 _all field
10) source和store分离（高级玩法，可节省带宽）。
11) 使用最小的数据类型：能用short的不要用long，这一点在ES里更为重要。
12) scripting查询参数化：script脚本会触发编译行为，并且会产生缓存，使用不当会造成查询巨慢，还会造成OOM。
13) Id：对于某些id字段，不需要我们做全文检索，使用keyword比数字类型性能更好
14) 尽量避免使用nested和parent/child：能在mapping阶段搞定的，尽量在mapping阶段搞定。
15) 避免自定义id。
16) 业务框架解耦：避免业务对ES过多的功能依赖，ES本身是一个搜索、存储、分析引擎，尽量把功能依赖放在这三个点上，有些功能虽然ES提供了，但是我们能用其他方案取代就用其他方案，这样留出更多资源让ES专注于搜索和聚合。即便ES提供的解决方案可能更好，但是代价却是占用了主要功能的资源。比如智能推荐、模糊查询等。
④ 集群：
1) 冷热分离：高频数据使用性能更好的硬件，HDD<SSD<RAM
2) 单一职责：关闭master节点的data-node设置（如果是开启状态的话），数据节点和Master节点一定要分开，集群规模越大，这样做的意义也就越大。
3) 增加协调节点的数量：稳定的Master节点对于群集健康非常重要！理论上讲，应该尽可能的减轻Master节点的压力，分片数量越多，Master节点维护管理shard的任务越重，并且节点可能就要承担更多的数据转发任务，可增加“仅协调”节点来缓解Master节点和Data节点的压力，但是在集群中添加过多的仅协调节点会增加整个集群的负担，因为选择的主节点必须等待每个节点的集群状态更新确认。
4) 高可用性（HA）群集至少需要三个主节点，其中至少两个不是仅投票节点。即使其中一个节点发生故障，这样的群集也将能够选举一个主节点。生产环境最好设置3台仅Master候选节点（node.master = true node.data = false）
5) 为确保群集仍然可用，集群不能同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用，群集仍可以正常工作。这意味着，如果存在三个或四个候选节点，则群集可以容忍其中一个节点不可用。如果有两个或更少的主机资格节点，则它们必须都保持可用
6) 禁用swapping：swapping会大大降低性能。
⑤ 索引：
1) 控制分片数量：每台节点的Shard数量越少，每个shard分配的CPU、内存和IO资源越多，单个Shard的性能越好，当一台机器一个Shard时，单个Shard性能最好。分片越少，分页查询越快。如果相同资源分配相同的前提下，shard数量越少，单个shard的体积越大，查询性能越低，速度越慢，这个取舍应根据实际集群状况和结合应用场景等因素综合考虑。单个分片不要太大尽量不要超过20-40G（不是绝对）
2) 搜索日志：统计高频词汇，对于命中率极高的关键词添加应用层缓存。
3) 冷热分离：把冷热数据放在不同索引。
⑥ 硬件：
1) 全能型：数据节点处理与数据相关的操作，例如CRUD，搜索和聚合。这些操作是I / O，内存和CPU密集型的，所以他们需要更高配置的服务器以及更高的带宽，并且集群的性能冗余非常重要。
2) 带宽：由于仅投票节不参与Master竞选，所以和真正的Master节点相比，它需要的内存和CPU较少。但是，所有候选节点以及仅投票节点都可能是数据节点，所以他们都需要快速稳定低延迟的网络。
(3) 监控
① ELK
② 熔断
- 总 分 实战
