角色 解释（包含了一些个人理解）
master-eligible node 可以被选择为主的节点
一个集群一定要有一个稳定的主节点
当集群比较大以及有较多的机器学习任务、连续变换（针对时序数据）时，就应该考虑区分专有主节点、专有数据节点以及机器学习节点、变换节点。
主要职责：
1.监控其他所有节点
2.维护集群内节点路由状态
3.监控切片与索引的数量
4.下发集群状态，做心跳检查等定时任务，在出现变动时，更新集群状态（如创建索引、节点加入离开等）
dedicated master-eligible node 专有主节点
为了集群健康，主节点应该有足够的资源履行职责，职责包括整个集群的操作：索引创建删除，跟踪节点状态、关注广播、决定 shards 归属和分配等。如果主节点因为其他的任务占用了过多资源，整个集群就没办法正常工作。
存储和搜索这种动作是资源非常密集的操作所以规模较大或者吞吐较大的集群，应该拥有专有的主节点，比如三个。
专有主节点只能拥有 master 角色，只做选举和集群管理的作用。
专有主节点也可以有下述协调节点的作用，不建议使用
voting-only master-eligible node 制选举节点，或者叫选民节点吧
只用于选举
通常用于解决脑裂、选举平局等问题
这个角色可以与其他角色共存
一个运行良好的的大规模的集群，至少拥有三个专有主节点，和两个选举节点
Data node 处理 CRUD，搜索，聚合等操作
重度 I/O 密集型操作，对内存、CPU 都非常敏感
如果数据节点长期处于 overload 状态，应该考虑横向拓展
专有的数据节点最大的好处就是区分主节点角色和数据角色 数据节点还可以细分为 data_content、data_hot、data_warm、data_cold，默认情况下 data 节点涵盖了以上所有细分角色的功能
data_content: 最主要的，处理读写查询聚合等操作的角色
data_hot: 处理刚进入 es 的数据，对硬件要求比较高
data_warm: 保存不需要更新但是仍然会被搜索的数据，对硬件要求稍低
data_cold: 只读的并且读取频率极低的索引数据，可以利用快照，对硬件要求极低
ingest node 预处理节点
每一次索引和查询（尤其是批量查询）都会过一下预处理，这个节点可以专门聚合这类操作。
coordinating-only node 协调节点
只能 route request，转发请求、分发批量请求
更多时候，只充当一个负载均衡的角色
Remote-eligible node 远程节点
跨集群行为，连接其他集群等功能
machine-learning node 机器学习节点（依赖 x-pack)
处理一些机器学习任务
transform node 变换节点（依赖 x-pack ）
处理一些时序数据的连续变换任务

对于角色搭配的想法

首先明确一个常识，默认情况，节点都是多角色共存的，比如一个默认三节点不配置任何角色的集群，任何节点都有以下几个角色：master, data,ingest,coordinating,也就是大家都可以选举，当选，承载数据，响应请求，做预处理等等。

我们上述所有的单独的角色出现的意义都只是为了让角色更加清晰，提升性能，让独立的节点只做它自己的事情。

所以除非是直观较小的数据规模和请求量，否则集群角色最好早点确认下来，避免后续的多角色共享造成的单节点压力过大，和为了修正角色必须进行的滚动重启。

在条件允许的情况下，最好在早期就构建出 3 专有主节点 + N 数据节点的集群结构，前置一个 slb 指向所有的数据节点，后续的集群扩容通过不断追加数据节点的方式进行。剥离 data 和 master 角色后，从前兼任多个角色的那个节点压力会减少，后面 data 和 master 处理各自的任务也会更得心应手。

关于 coordinating-only node，其实默认所有的节点都是 coordinating node ，所以这个 -only node 它就只做分发和响应请求的功能了，但是因为要收集结果并返回，仍然需要较高的内存和 CPU。基本上，当你的集群出现性能问题时，单单加一个这个节点是大概率没法从根源上解决问题（因为其他的数据节点没有得到相应的提升），所以我对它的看法就是，可以在后续的集群水平扩容，有需求随时加，但是在我看来，早期重点考虑的是先把 data 节点本身的物理配置拉满之后再考虑这个角色。

纯粹的选举节点，说是为了处理选举平局的问题，实际上这个角色的存在感和指责非常模糊，它不参与竞选，却可以投票，这件事明明所有 eligible-master node 都能做，感觉有点多此一举了。建议不使用。