Elasticsearch 学习笔记Day 25

蛋挞Echo
145 阅读8分钟

hi，我是蛋挞，一个初出茅庐的后端开发，希望可以和大家共同努力、共同进步！

开启掘金成长之旅！这是我参与「掘金日新计划 · 4 月更文挑战」的第 9 天，点击查看活动详情

  • 起始标记->水平扩展Elasticsearch（6讲）：「59 | 常见的集群部署方式」
  • 结尾标记->水平扩展Elasticsearch（6讲）：「61 | 分片设计及管理」

常见的集群部署方式

节点类型

  • 不同角色的节点
    • Master eligible / Data / Ingest / Coordinating / Machine Learning
  • 在开发环境中，一个节点可承担多种角色
  • 在生产环境中,
    • 根据数据量，写入和查询的吞吐量，选择合适的部署方式
    • 建议设置单一角色的节点 (dedicated node)

节点参数配置

一个节点在默认情况会下同时扮演: master eligible，data node 和 ingest node image.png

单一职责的节点

一个节点只承担一个角色 image.png

单一角色:职责分离的好处

  • Dedicated master eligible nodes: 负责集群状态(cluster state)的管理
    • 使用低配置的 CPU，RAM 和磁盘
  • Dedicated data nodes: 负责数据存储及处理客户端请求
    • 使用高配置的 CPU，RAM 和磁盘
  • Dedicated ingest nodes: 负责数据处理
    • 使用高配置 CPU;中等配置的RAM; 低配置的磁盘

Dedicate Coordinating Only Node (Client Node)

  • 配置:将Master，Data，Ingest 都配置成 False
    • Medium/High CUP;Medium/High RAM; Low Disko
  • 生产环境中，建议为一些大的集群配置 Coordinating Only Nodes
    • 扮演 Load Balancers。降低 Master 和 Data Nodes 的负载o
    • 负责搜索结果的 Gather/Reduceo
    • 有时候无法预知客户端会发送怎么样的请求
      • 大量占用内存的结合操作，一个深度聚合可能会引发 OOM

Dedicate Master Node

  • 从高可用 & 避免脑裂的角度出发
    • 一般在生产环境中配置3台
    • 一个集群只有1台活跃的主节点
      • 负责分片管理，索引创建，集群管理等操作
  • 如果和数据节点或者 Coordinate 节点混合部署
    • 数据节点相对有比较大的内存占用
    • Coordinate 节点有时候可能会有开销很高的查询，导致 OOM
    • 这些都有可能影响 Master 节点，导致集群的不稳定

基本部署: 增加节点，水平扩展

  • 当磁盘容量无法满足需求时，可以增加数据节点;磁盘读写压力大时，增加数据节点

image.png

水平扩展: Coordinating Only Node

  • 当系统中有大量的复杂查询及聚合时候，增加 Coordinating 节点，增加查询的性能

image.png

读写分离

image.png

在集群中部署 Kibana

image.png

异地多活的部署

集群处在三个数据中心;数据三写;GTM分发读请求 image.png

本章知识总结

介绍了一些ES当中常见的部署，我们可以结合自身业务的场景去选择一个合适的部署方式，同时建议在生产环境当中应该配置一个Dedicate Master Node，使得我们的服务有更好的可用性和可靠性。

Hot & Warm 架构与 Shard Filtering

日志类应用的部署架构

image.png

什么是 Hot & Warm Architecture

  • Hot & Warm Architecture
    • 数据通常不会有 Update 操作;适用于 Time based 索引数据(生命周期管理)，同时数据量比较大的场景。
    • 引入Warm 节点，低配置大容量的机器存放老数据，以降低部署成本
  • 两类数据节点,不同的硬件配置
    • Hot 节点 (通常使用 SSD) : 索引有不断有新文档写入。通常使用 SSD
    • Warm 节点 (通常使用 HDD) : 索引不存在新数据的写入;同时也不存在大量的数据查询

Hot Nodes

  • 用于数据的写入
    • Indexing 对 CPU和O都有很高的要求。所以需要使用高配置的机器
    • 存储的性能要好。建议使用 SSD

image.png

Warm Nodes

  • 用于保存只读的索引，比较旧的数据
    • 通常使用大容量的磁盘(通常是 Spinning Disks)

image.png

配置Hot & Warm Architecture

  • 使用 Shard Filtering，步骤分为以下几步
    • 标记节点 (Tagging)
    • 配置索引到 Hot Node
    • 配置索引到Warm 节点

标记节点

  • 需要通过“node.attr”来标记一个节点
    • 节点的 attribute可以是任何的 key/value
    • 可以通过 elasticsearch.yml 或者通过 -E 命令指定

image.png

配置Hot 数据

  • 创建索引时候，指定将其创建在 hot 节点上

image.png

旧数据移动到 Warm 节点

  • Indexrouting.allocation 是一个索引级的 dynamic setting，可以通过 API在后期进行设定
    • Curator / Index Life Cycle Management Tool

image.png

Rack Awareness

  • ES的节点可能分布在不同的机架
    • 当一个机架断电，可能会同时丢失几个节点
    • 如果一个索引相同的主分片和副本分片，同时在这个机架上，就有可能导致数据的丢失
    • 通过 Rack Awareness 的机制就可以尽可能避免将同一个索引的主副分片同时分配在一个机架的节点上

image.png

标记 Rack 节点+配置集群

image.png

Forced Awareness

image.png

Shard Filtering

  • Shard Filtering
    • “node.attr”- 标记节点
    • "index.routingallocation”- 分配索引到节点

image.png

CodeDemo

# 标记一个 Hot 节点
bin/elasticsearch  -E node.name=hotnode -E cluster.name=geektime -E path.data=hot_data -E node.attr.my_node_type=hot

# 标记一个 warm 节点
bin/elasticsearch  -E node.name=warmnode -E cluster.name=geektime -E path.data=warm_data -E node.attr.my_node_type=warm

# 查看节点
GET /_cat/nodeattrs?v

# 配置到 Hot节点
PUT logs-2019-06-27
{
  "settings":{
    "number_of_shards":2,
    "number_of_replicas":0,
    "index.routing.allocation.require.my_node_type":"hot"
  }
}



PUT my_index1/_doc/1
{
  "key":"value"
}



GET _cat/shards?v


# 配置到 warm 节点
PUT PUT logs-2019-06-27/_settings
{  
  "index.routing.allocation.require.my_node_type":"warm"
}


# 标记一个 rack 1
bin/elasticsearch  -E node.name=node1 -E cluster.name=geektime -E path.data=node1_data -E node.attr.my_rack_id=rack1

# 标记一个 rack 2
bin/elasticsearch  -E node.name=node2 -E cluster.name=geektime -E path.data=node2_data -E node.attr.my_rack_id=rack2

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "my_rack_id"
  }
}

PUT my_index1
{
  "settings":{
    "number_of_shards":2,
    "number_of_replicas":1
  }
}

PUT my_index1/_doc/1
{
  "key":"value"
}


GET _cat/shards?v
DELETE my_index1/_doc/1



# Fore awareness
# 标记一个 rack 1
bin/elasticsearch  -E node.name=node1 -E cluster.name=geektime -E path.data=node1_data -E node.attr.my_rack_id=rack1

# 标记一个 rack 2
bin/elasticsearch  -E node.name=node2 -E cluster.name=geektime -E path.data=node2_data -E node.attr.my_rack_id=rack1


PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "my_rack_id",
    "cluster.routing.allocation.awareness.force.my_rack_id.values": "rack1,rack2"
  }
}
GET _cluster/settings

# 集群黄色
GET _cluster/health

# 副本无法分配
GET _cat/shards?v


GET _cluster/allocation/explain?pretty

相关阅读

本章知识总结

学习了什么是Hot & Warm Architecture，同时也学习了如何去配置Hot & Warm Architecture，通过对Shard Filtering基础的学习，我们也知道如何更好的配置Elasticsearch集群，使得它更好的满足高可用的特性。

分片设计及管理

单个分片

  • 7.0 开始，新创建一个索引时，默认只有一个主分
    • 单个分片，查询算分，聚合不准的问题都可以得以追
  • 单个索引，单个分片时候，集群无法实现水平扩展
    • 即使增加新的节点，无法实现水平扩展

image.png

两个分片

  • 集群增加一个节点后，Elasticsearch 会自动进行分片的移动，也叫 Shard Rebalancing

image.png

如何设计分片数

  • 当分片数 >节点数时
    • 一旦集群中有新的数据节点加入，分片就可以自动进行分配
    • 分片在重新分配时，系统不会有 downtime
  • 多分片的好处:一个索引如果分布在不同的节点，多个节点可以并行执行
    • 查询可以并行执行
    • 数据写入可以分散到多个机器

一些例子

  • 案例1
    • 每天 1GB 的数据，上个索引一个主分片，一个副本分片
    • 需保留半年的数据，接近 360 GB 的数据量
  • 案例2
    • 5 个不同的日志，每天创建一个日志索引。每个日志索引创建 10 个主分片
    • 保留半年的数据
    • 51030*6=9000 个分片

分片过多所带来的副作用

  • Shard 是 Elasticsearch 实现集群水平扩展的最小单位
  • 过多设置分片数会带来一些潜在的问题
    • 每个分片是一个 Lucene 的 索引，会使用机器的资源。过多的分片会导致额外的性能开销
      • Lucene Indices / File descriptors RAM / CPU
      • 每次搜索的请求，需要从每个分片上获取数据
      • 分片的 Meta 信息由 Master 节点维护。过多，会增加管理的负担。经验值，控制分片总数在 10 W 以内

如何确定主分片数

  • 从存储的物理角度看
    • 日志类应用，单个分片不要大于 50 GB
    • 搜索类应用，单个分片不要超过20 GB
  • 为什么要控制分片存储大小
    • 提高 Update 的性能
    • Merge 时，减少所需的资源
    • 丢失节点后，具备更快的恢复速度/便于分片在集群内 Rebalancing

如何确定副本分片数

  • 副本是主分片的拷贝
    • 提高系统可用性:相应查询请求，防止数据丢失
    • 需要占用和主分片一样的资源
  • 对性能的影响
    • 副本会降低数据的索引速度: 有几份副本就会有几倍的 CPU 资源消耗在索引上
    • 会减缓对主分片的查询压力，但是会消耗同样的内存资源
      • 如果机器资源充分，提高副本数，可以提高整体的查询 QPS

调整分片总数设定，避免分配不均衡

  • ES的分片策略会尽量保证节点上的分片数大致相同
    • 扩容的新节点没有数据，导致新索引集中在新的节点
    • 热点数据过于集中，可能会产生新能问题

image.png

相关阅读

本章知识总结

分享了一些关于分片设定的最佳实践 ，分片对性能来说是非常重要的，单个分片控制在50GB以内。

此文章为4月Day9学习笔记，内容来源于极客时间《Elasticsearch 核心技术与实战》

avatar
文章
阅读
粉丝