Elasticsearch 集群规划

1. 我们需要多大规模的集群

需要从以下两个方面考虑:

1. 当前的数据量有多大?数据增长情况如何?
2. 你的机器配置如何?cpu、多大内存、多大硬盘容量?

推算的依据:

Elasticsearch JVM heap 最大可以设置32G 。
30G heap 大概能处理的数据量 10 T。如果内存很大如128G，可在一台机器上运行多个ES节点实例。
备注:集群规划满足当前数据规模+适量增长规模即可，后续可按需扩展。

两类应用场景:

A. 用于构建业务搜索功能模块，且多是垂直领域的搜索。数据量级几千万到数十亿级别。一般2-4台机 器的规模。
B. 用于大规模数据的实时OLAP(联机处理分析)，经典的如ELK Stack，数据规模可能达到千亿或更 多。几十到上百节点的规模。

2. 集群中的节点角色如何分配

节点角色:

Master
node.master: true 节点可以作为主节点

DataNode
node.data: true 默认是数据节点

Coordinate node 协调节点，一个节点只作为接收请求、转发请求到其他节点、汇总各个节点返回数 据等功能的节点，就叫协调节点，如果仅担任协调节点，将上两个配置设为false。

一个节点可以充当一个或多个角色，默认三个角色都有

节点角色如何分配:
A. 小规模集群，不需严格区分。
B. 中大规模集群(十个以上节点)，应考虑单独的角色充当。特别并发查询量大，查询的合并量大，可以增加独立的协调节点。角色分开的好处是分工分开，不互影响。如不会因协调角色负载过高而影响数据节点的能力。

3. 如何避免脑裂问题

脑裂问题: 一个集群中只有一个A主节点，A主节点因为需要处理的东西太多或者网络过于繁忙，从而导致其他从节 点ping不通A主节点，这样其他从节点就会认为A主节点不可用了，就会重新选出一个新的主节点B。过 了一会A主节点恢复正常了，这样就出现了两个主节点，导致一部分数据来源于A主节点，另外一部分数 据来源于B主节点，出现数据不一致问题，这就是脑裂。

6.x和之前版本 尽量避免脑裂，需要添加最小数量的主节点配置:

discovery.zen.minimum_master_nodes: (有master资格节点数/2) + 1 这个参数控制的是，选举主节点时需要看到最少多少个具有master资格的活节点，才能进行选举。官方 的推荐值是(N/2)+1，其中N是具有master资格的节点的数量。

在新版7.X的ES中，对es的集群发现系统做了调整，不再有discovery.zen.minimum_master_nodes这 个控制集群脑裂的配置，转而由集群自主控制，并且新版在启动一个新的集群的时候需要有 cluster.initial_master_nodes初始化集群列表。

在es7中，discovery.zen.* 开头的参数，有些已经失效

Old name	new Name	作用
discovery.zen.ping.unicast.hosts	discovery.seed_hosts	设置集群中符合主资格的节点的地址列表，可以通过这些节点来自动发现新加入集群的节点。
discovery.zen.hosts_provider	discovery.seed_providers	指定用于获取用于启动发现过程的种子节点的地址的种子主机提供程序的类型。默认情况下，从discovery.seed_hosts设置，也支持其他Discovery Plugins，包括EC2 Discovery，Azure Classic discovery，GCE discovery，当指定的时候，可以在该指定文件中填写ip，方便单独维护
discovery.zen.no_master_block	cluster.no_master_block	设置没有主节点时限制的操作，有如下三个参数， all：所有操作均不可做， write：默认为write，写操作被拒绝执行，基于最后一次已知的正常的集群状态可读，这也许会读取到已过时的数据。 metadata_write:只有元数据写操作(如映射更新，路由表更改)被拒绝，但常规的索引操作继续工作。根据最后已知的集群配置，读写操作成功。这种情况可能导致读取部分陈旧数据，因为此节点可能与集群的其他节点隔离。
discovery.zen.minimum_master_nodes		这个参数控制的是，选举主节点时需要看到最少多少个具有master资格的活节点，才能进行选举。官方 的推荐值是(N/2)+1，其中N是具有master资格的节点的数量。
	cluster.initial_master_nodes	初始主节点名称列表
discovery.zen.ping_timeout	discovery.request_peers_timeout	设置集群中自动发现其它节点时ping连接超时时间，默认为3秒，对于比较差的网络环境可以高点的值来防止自动发现时出错。
discovery.zen.ping.multicast.enabled		设置是否打开多播发现节点，默认是true。当多播不可用或者集群跨网段的时候集群通信还是用单播吧
	discovery.find_peers_interval	节点在尝试另一轮发现之前需要等待多长时间。默认为1。
discovery.zen.ping.unicast.hosts.resolve_timeout	discovery.seed_resolver.timeout	在解析种子节点的地址时，等待每个DNS查找的时间。默认为5 s。
discovery.zen.ping.unicas .concurrent_connect	discovery.seed_resolver.max_concurrent_resolvers	在解析种子节点的地址时要执行多少个并发DNS查找。默认为10

常用做法(中大规模集群):
1)Master 和 dataNode 角色分开，配置奇数个master，如3
2)单播发现机制，配置master资格节点(5.0之前): discovery.zen.ping.multicast.enabled: false —— 关闭多播发现机制，默认是关闭的
3)延长ping master的等待时长
discovery.zen.ping_timeout: 30(默认值是3秒)——其他节点ping主节点多久时间没有响应就认为主节点不可用了。
es7中换成了 discovery.request_peers_timeout

4 索引应该设置多少个分片

说明:分片数指定后不可变，除非重建索引。

分片设置的可参考原则:
ElasticSearch推荐的最大JVM堆空间是30~32G, 所以把你的分片最大容量限制为30GB, 然后再对分片数 量做合理估算. 例如, 你认为你的数据能达到200GB, 推荐你最多分配7到8个分片。
在开始阶段, 一个好的方案是根据你的节点数量按照1.5~3倍的原则来创建分片. 例如,如果你有3个节点, 则推荐你创建的分片数最多不超过9(3x3)个。当性能下降时，增加节点，ES会平衡分片的放置。 对于基于日期的索引需求, 并且对索引数据的搜索场景非常少. 也许这些索引量将达到成百上千, 但每个 索引的数据量只有1GB甚至更小. 对于这种类似场景, 建议只需要为索引分配1个分片。如日志管理就是 一个日期的索引需求，日期索引会很多，但每个索引存放的日志数据量就很少。

5. 分片应该设置几个副本

副本设置基本原则:

为保证高可用，副本数设置为2即可。要求集群至少要有3个节点，来分开存放主分片、副本。 如发现并发量大时，查询性能会下降，可增加副本数，来提升并发查询能力。

注意:新增副本时主节点会自动协调，然后拷贝数据到新增的副本节点,副本数是可以随时调整的!

PUT /my_temp_index/_settings
{
    "number_of_replicas": 1
}