1、阿里云Elasticsearch架构图
阿⾥云Elasticsearch和Kibana容器化运⾏在ECS中，监控agent（独⽴进程）负责收集监控指标，通过SLS发送给云监控完成监控报警。实例之间由VPC实现⽹络隔离，管控服务通过端口映射实现VPC反向接⼊，从而管理⽤⼾阿⾥云Elasticsearch实例。
2、Elasticsearch常规读写流程
A、增删改操作只能由primary shard处理
B、发送请求时客户端可以选择任意node（此节点即作为coordinate node），以为任意node都知道每个document在哪个node上。
3、Elasticsearch节点类型图
A、主节点数规划3个及以上
B、数据节点根据数据量及性能要求进行规划
C、协调节点根据请求压力规划（阿里云的协调节点一旦设置，路由请求之后从SLB分发到协调节点，不会直接访问数据节点）
4、阿里云Elasticsearch规划
A、磁盘容量
• 副本数量，⾄少1个副本。
• 索引开销，通常⽐源数据⼤10%（_all 等未计算）。
• 操作系统预留，默认操作系统会保留5%的⽂件系统供⽤⼾处理关键流程，系统恢复，磁盘碎⽚等。
• Elasticsearch内部开销，段合并，⽇志等内部操作，预留20%。
• 安全阈值，通常⾄少预留15%的安全阈值
规划说明：
• 最小磁盘总⼤小 = 源数据 * 3.4。
磁盘总⼤小 = 源数据 * (1 + 副本数量) * (1 + 索引开销) / (1 - Linux预留空间) / (1 - Elasticsearch开销) / (1 - 安全阈值)
= 源数据 * (1 + 副本数量) * 1.7
= 源数据 * 3.4
• 对于_all 这项参数，如果在业务使⽤上没有必要，我们通常的建议是禁⽌或者有选择性的添加。
• 对于需要开启这个参数的索引，其开销也会随之增⼤。根据我们的测试结果和使⽤经验，建议在上述评估的基础上额外增加⼀半的空间：
磁盘总⼤小 = 源数据 * (1 + 副本数) * 1.7 * (1 + 0.5)
= 源数据 * 5.1
B、集群规格
阿⾥云Elasticsearch的单机规格在⼀定程度上是限制了集群能⼒的，根据测试结果和使⽤经验给出如下建议。
集群最⼤节点数 = 单节点CPU * 5
使⽤场景不同，单节点最⼤承载数据量也会不同，具体如下：
• 数据加速、查询聚合等场景
单节点最⼤数据量 = 单节点Mem(G) * 10
• ⽇志写⼊、离线分析等场景
单节点最⼤数据量 = 单节点Mem(G) * 50
• 通常情况
单节点最⼤数据量 = 单节点Mem(G) * 30
- C、Shard大小和数量
Elasticsearch集群中任何⼀个索引都需要有⼀个合理的shard规划，很多情况下都会有⼀个更好的策略来替换Elasticsearch默认的5个shard（7以后的版本默认1个shard）。
• 建议在小规格节点下单shard⼤小不要超过30GB。更⾼规格的节点单shard⼤小不要超过50GB。
• 对于⽇志分析场景或者超⼤索引，建议单shard⼤小不要超过100GB。
• shard的个数（包括副本）要尽可能匹配节点数，等于节点数，或者是节点数的整数倍。
• 通常我们建议单节点上同⼀索引的shard个数不要超5个。
D、产品资源
• 节点数量限制：2〜50
• 磁盘⼤小限制：160〜2048GB
• 规格限制：
- elasticsearch.sn2ne.xlarge（4核16GB）
- elasticsearch.sn2ne.2xlarge（8核32GB）
- elasticsearch.sn2ne.4xlarge（16核64GB）