ES运维（三）架构与规划（阿里云）

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）