阿里云Elasticsearch架构与规划

时间:2024-03-23 10:19:15

1、阿里云Elasticsearch架构图

阿里云Elasticsearch架构与规划

 

阿⾥云Elasticsearch和Kibana容器化运⾏在ECS中,监控agent(独⽴进程)负责收集监控指标,通过SLS发送给云监控完成监控报警。实例之间由VPC实现⽹络隔离,管控服务通过端口映射实现VPC反向接⼊,从而管理⽤⼾阿⾥云Elasticsearch实例。

2、Elasticsearch常规读写流程

 

阿里云Elasticsearch架构与规划

    A、增删改操作只能由primary shard处理

    B、发送请求时客户端可以选择任意node(此节点即作为coordinate node),以为任意node都知道每个document在哪个node上。

3、Elasticsearch节点类型图

阿里云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

阿里云Elasticsearch架构与规划

  1. 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)