前言
本篇主要聊聊ES生产环境的一些规划，以及ES的集群搭建。
- 固态硬盘（SSD） 提供最佳“热”工作负载的性能。
- 普通磁盘（HDD） 成本低，用于“暖”和“冷”数据存储。
注意：RAID0 可以提高性能。RAID 是可选的，因为 Elastic 默认为 N + 1 分片复制策略。
为了追求硬件级别的高可用性，可以接受标准性能的 RAID 配置（例如 RA1/10/50 等）。不建议，副本机制已经保证了高可用
1.2.1 JVM Heap
存储有关集群索引、分片、段和 fielddata 数据。
建议：可用 RAM 的 50％，最多最大 30GB RAM，以避免垃圾回收。
官方文档最大指 32 GB：
https://www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing.html
1.2.2 操作系统缓存
Elasticsearch 将使用剩余的可用内存来缓存数据（Lucene 使用）， 通过避免在全文检索、文档聚合和排序环节的磁盘读取，极大地提高了性能。
大多数 Elasticsearch 部署往往对 CPU 要求不高。因此，相对其它资源，具体配置多少个（CPU）不是那么关键。你应该选择具有多个内核的现代处理器，常见的集群使用两到八个核的机器。
如果你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。
快速可靠的网络显然对分布式系统的性能是很重要的。 低延时能帮助确保节点间能容易的通讯，大带宽能帮助分片移动和恢复。现代数据中心网络（1 GbE, 10 GbE）对绝大多数集群都是足够的。
即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。
Elasticsearch 假定所有节点都是平等的—并不会因为有一半的节点在150ms 外的另一数据中心而有所不同。更大的延时会加重分布式系统中的问题而且使得调试和排错更困难。
和 NAS 的争论类似，每个人都声称他们的数据中心间的线路都是健壮和低延时的。这是真的—直到它不是时（网络失败终究是会发生的，你可以相信它）。 从我们的经验来看，处理跨数据中心集群的麻烦事是根本不值得的。
容量规划——预估集群中每个节点的分片数、内存及存储资源。
吞吐量规划——以预期的延迟和吞吐量估算处理预期操作所需的内存，计算和网络资源。
1.5.1 数据量预估
第一，问自己几个问题：
- 您每天将索引多少原始数据（GB）？
- 您将保留数据多少天？
- 每天增量数据是多少？
- 您将强制执行多少个副本分片？
- 您将为每个数据节点分配多少内存？
- 您的内存：数据比率是多少？
第二，预留存储以备错误。(Elastic 官方推荐经验值）
- 预留 15%警戒磁盘水位空间。
- 为错误余量和后台活动预留+ 5％。
- 保留等效的数据节点以处理故障。
第三，容量预估计算方法如下：
- 总数据量（GB） = 原始数据量（GB） /每天 X 保留天数 X 净膨胀系数 X （副本 + 1）
- 磁盘存储（GB） = 总数据量（GB）* ( 1 + 0.15 + 0.05)
- 数据节点 = 向上取整（磁盘存储（GB）/ 每个数据节点的内存量 / 内存：数据比率）+ 1
Tips：腾讯云 在 2019 4 月的 meetup 分享中建议：磁盘容量大小 = 原始数据大小 * 3.38。
1.5.2 分片预估
第一，问自己几个问题：
- 您将创建多少索引？
- 您将配置多少个主和副本分片？
- 您将在什么时间间隔旋转索引？
- 您将保留索引多长时间？
- 您将为每个数据节点分配多少内存？
第二，经验值（Elastic 官方推荐）
- 每 GB JVM 堆内存支持的分片数不超过 20 个。
- 每个分片大小不要超过 50GB。推荐阅读：https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
Tips：
- 将小的每日索引整合为每周或每月的索引，以减少分片数。
- 将大型（> 50GB）每日索引分拆分成小时索引或增加主分片的数量。
第三，分片预估方法如下：
- 总分片数 = 索引个数 X 主分片数 * （副本分片数 +1）X 保留间隔
- 总数据节点个数 = 向上取整（总分片数 / (20 X 每个节点内存大小））
1.5.3 搜索吞吐量预估
搜索用例场景除了考虑搜索容量外，还要考虑如下目标：
- 搜索响应时间；
- 搜索吞吐量。
这些目标可能需要更多的内存和计算资源。
第一：问自己几个问题
- 您期望每秒的峰值搜索量是多少？
- 您期望平均搜索响应时间是多少毫秒？
- 您期望的数据节点上几核 CPU，每核有多少个线程？
第二：方法论 与其确定资源将如何影响搜索速度，不如通过在计划的固定硬件上进行，可以将搜索速度作为一个常数，
然后确定集群中要处理峰值搜索吞吐量需要多少个核。
最终目标是防止线程池排队的增长速度超过了 CPU 的处理能力。
如果计算资源不足，搜索请求可能会被拒绝掉。
第三：吞吐量预估方法
- 峰值线程数 = 向上取整（每秒峰值检索请求数 _ 每个请求的平均响应时间（毫秒）/1000）
- 线程队列大小 = 向上取整（(每个节点的物理 cpu 核数 _ 每核的线程数 * 3 / 2）+ 1)
- 总数据节点个数 = 向上取整（峰值线程数 / 线程队列大小）
1.5.4 冷热集群架构
Elasticsearch 可以使用分片分配感知（shard allocation awareness）在特定硬件上分配分片。
索引密集型业务场景通常使用它在热节点、暖节点和冷（Frozen）节点上存储索引，
然后根据业务需要进行数据迁移（热节点->暖节点->冷节点），以完成数据的删除和存档需要。
这是优化集群性能的最经济方法之一，在容量规划期间，先确定每一类节点的数据规模，然后进行组合。
冷热集群架构推荐：
1.5.5 集群节点角色划分
Elasticsearch 节点执行一个或多个角色。通常，当集群规模大时，每个节点分配一个具体角色很有意义。
您可以针对每个角色优化硬件，并防止节点争夺资源。
主要是两步，1：创建配置文件参考官网提供，2：运行实例获取证书
2.3.1 elasticsearch.yml
- network.host 设置允许其他ip访问，解除ip绑定
- xpack.security 则是安全相关配置，其中ssl的证书需要自己生成
2.3.2 生成elastic-certificates.p12（证书）
es提供了生成证书的工具，我们可以在docker实例中生成它，然后复制出来，后面统一使用
2.8.1忘记密码怎么办？
可以进入机器去修改