• Elasticsearch7.17 四 : ElasticSearch集群架构


    ElasticSearch集群架构

    分布式系统的可用性与扩展性:
    高可用性
    服务可用性-允许有节点停止服务
    数据可用性-部分节点丢失,不会丢失数据
    可扩展性
    请求量提升/数据的不断增长(将数据分布到所有节点上)
    ES集群架构的优势:
    提高系统的可用性,部分节点停止服务,整个集群的服务不受影响
    存储的水平扩容

    核心概念

    节点

    集群
    一个集群可以有一个或者多个节点
    不同的集群通过不同的名字来区分,默认名字“elasticsearch“
    通过配置文件修改,或者在命令行中 -E cluster.name=es-cluster进行设定’
    节点
    节点是一个Elasticsearch的实例;本质上就是一个JAVA进程
    一台机器上可以运行多个Elasticsearch进程,但是生产环境一般建议一台机器上只运行一个Elasticsearch实例
    每一个节点都有名字,通过配置文件配置,或者启动时候 -E node.name=node1指定
    每一个节点在启动之后,会分配一个UID,保存在data目录下
    节点类型

    • Master Node:主节点
      处理创建,删除索引等请求,负责索引的创建与删除
      决定分片被分配到哪个节点
      维护并且更新Cluster State
    • Master eligible nodes:可以参与选举的合格节点
      每个节点启动后,默认就是一个Master eligible节点,可以设置 node.master: false禁止。
      Master-eligible节点可以参加选主流程,成为Master节点。
      当第一个节点启动时候,它会将自己选举成Master节点
    • Data Node:数据节点
      可以保存数据的节点,叫做Data Node,负责保存分片数据。在数据扩展上起到了至关重要的作用。
      通过增加数据节点可以解决数据水平扩展和解决数据单点问题
    • Coordinating Node:协调节点
      负责接受Client的请求, 将请求分发到合适的节点,最终把结果汇集到一起。
      每个节点默认都起到了Coordinating Node的职责
    • 其他节点
      Hot & Warm Node
      不同硬件配置 的Data Node,用来实现Hot & Warm架构,降低集群部署的成本
      Ingest Node
      数据前置处理转换节点,支持pipeline管道设置,可以使用ingest对数据进行过滤、转换等操作
      Machine Learning Node
      负责跑机器学习的Job,用来做异常检测
      Tribe Node
      Tribe Node连接到不同的Elasticsearch集群,并且支持将这些集群当成一个单独的集群处理

    分片(Primary Shard & Replica Shard)

    主分片(Primary Shard)
    用以解决数据水平扩展的问题。通过主分片,可以将数据分布到集群内的所有节点之上
    一个分片是一个运行的Lucene的实例
    主分片数在索引创建时指定,后续不允许修改
    副本分片(Replica Shard)
    用以解决数据高可用的问题。 副本分片是主分片的拷贝
    副本分片数,可以动态调整
    增加副本数,还可以在一定程度上提高服务的可用性(读取的吞吐)

    # 指定索引的主分片和副本分片数
    PUT /blogs
    {
      "settings": {
        "number_of_shards": 3, #主分片
        "number_of_replicas": 1 #副分片
      }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    集群状态和分片设定

    分片的设定
    对于生产环境中分片的设定,需要提前做好容量规划。
    分片数设置过小,导致后续无法增加节点实现水平扩展;单个分片的数据量太大,导致数据重新分配耗时。
    分片数设置过大,影响搜索结果的相关性打分,影响统计结果的准确性;单个节点上过多的分片,会导致资源浪费,同时也会影响性能
    7.0 开始,默认主分片设置成1,解决了over-sharding(分片过度)的问题
    集群status
    Green: 主分片与副本都正常分配
    Yellow: 主分片全部正常分配,有副本分片未能正常分配
    Red: 有主分片未能分配。例如,当服务器的磁盘容量超过85%时,去创建了一个新的索引
    CAT API查看集群信息

    GET /_cat/nodes?v #查看节点信息
    GET /_cat/health?v #查看集群当前状态:红、黄、绿
    GET /_cat/shards?v #查看各shard的详细情况
    GET /_cat/shards/{index}?v #查看指定分片的详细情况
    GET /_cat/master?v #查看master节点信息
    GET /_cat/indices?v #查看集群中所有index的详细信息
    GET /_cat/indices/{index}?v #查看集群中指定index的详细信息

    集群搭建

    系统环境
    操作系统: CentOS7,准备用户es。关闭防火墙
    elasticsearch:elasticsearch-7.17.3
    需要删除es下的data目录里面的节点信息,否则会加载以前的节点信息导致集群搭建失败
    修改elasticsearch.yml

    # 指定集群名称3个节点必须一致
    cluster.name: elasticsearch
    #指定节点名称,每个节点名字唯一
    node.name: node-1
    #是否有资格为master节点,默认为true
    node.master: true
    #是否为data节点,默认为true
    node.data: true
    # 绑定ip,开启远程访问,可以配置0.0.0.0
    network.host: 0.0.0.0
    #指定web端口
    http.port: 9200
    #指定tcp端口
    transport.tcp.port: 9300
    #用于节点发现
    discovery.seed_hosts: ["192.168.10.111","192.168.10.112","192.168.10.114"]
    #7.0新引入的配置项,初始仲裁,仅在整个集群首次启动时才需要初始仲裁。
    #该选项配置为node.name的值,指定可以初始化集群主节点的名称
    cluster.initial_master_nodes: ["node-1","node-2","node-3"]
    #解决跨域问题
    http.cors.enabled: true
    http.cors.allow-origin: "*"
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22

    每个节点的配置文件,只要把node.name 修改即可,其他配置相同。
    切换为es用户启动es
    在这里插入图片描述
    查看启动时候publish的地址是否是 配置文件上的地址,如果是其他地址,需要通过ifconfig把其他网关禁止。
    验证集群
    访问:http://192.168.10.111:9200/_cat/nodes
    在这里插入图片描述
    到此集群搭建完毕

    安装Cerebro客户端

    Cerebro介绍
    Cerebro 可以查看分片分配和通过图形界面执行常见的索引操作。 完全开源,并且它允许添加用户,密码或 LDAP 身份验证问网络界面。
    Cerebro 基于 Scala 的Play 框架编写,用于后端 REST 和 Elasticsearch 通信。 它使用通过 AngularJS 编写的单页应用程序(SPA)前端。
    项目网址:https://github.com/lmenezes/cerebro
    下载地址:https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip
    运行 cerebro

    cerebro-0.9.4/bin/cerebro
    
    #后台启动
    nohup bin/cerebro > cerebro.log &
    
    • 1
    • 2
    • 3
    • 4

    访问:http://192.168.10.111:9000
    在这里插入图片描述
    输入ES集群节点:http://192.168.65.192:9200,建立连接:
    在这里插入图片描述

    安装kibana

    修改kibana配置 vim config/kibana.yml

    server.port: 5601
    server.host: "192.168.10.111" 
    elasticsearch.hosts: ["http://192.168.10.111:9200","http://192.168.10.112:9200","http://192.168.10.114:9200"]  
    i18n.locale: "zh-CN"   
    
    • 1
    • 2
    • 3
    • 4

    启动 访问kibana
    在这里插入图片描述

    ES安全认证

    ES敏感信息泄露的原因
    Elasticsearch在默认安装后,不提供任何形式的安全防护。不合理的配置导致公网可以访问ES集群。比如在elasticsearch.yml文件中,server.host配置为0.0.0.0
    免费的方案

    • 设置nginx反向代理
    • 安装免费的Security插件
      Search Guard : https://search-guard.com/
      readonlyrest: https://readonlyrest.com/
    • X-Pack的Basic版
      从ES 6.8开始,Security纳入x-pack的Basic版本中,免费使用一些基本的功能

    集群内部安全通信

    ElasticSearch集群内部的数据是通过9300进行传输的,如果不对数据加密,可能会造成数据被抓包,敏感信息泄露。
    解决方案: 为节点创建证书
    TLS 协议要求Trusted Certificate Authority (CA)签发x.509的证书。证书认证的不同级别:

    • Certificate ——节点加入需要使用相同CA签发的证书
    • Full Verification——节点加入集群需要相同CA签发的证书,还需要验证Host name 或IP地址
    • No Verification——任何节点都可以加入,开发环境中用于诊断目的

    生成节点证书

    # 为集群创建一个证书颁发机构
    bin/elasticsearch-certutil ca
    # 为集群中的每个节点生成证书和私钥
    bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
    # 移动到config目录下
    mv *.p12 config/
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    将如上命令生成的两个证书文件拷贝到另外两个节点作为通信依据。
    配置节点间通信
    三个ES节点增加如下配置:

    ## elasticsearch.yml 配置
    xpack.security.transport.ssl.enabled: true
    xpack.security.transport.ssl.verification_mode: certificate 
    xpack.security.transport.ssl.client_authentication: required
    xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
    xpack.security.transport.ssl.truststore.path: elastic-certificates.p12.
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    开启并配置X-Pack的认证

    修改elasticsearch.yml配置文件,开启xpack认证机制xpack.security.enabled: true # 开启xpack认证机制
    测试:
    使用Curl访问ES,返回401错误curl 'localhost:9200/_cat/nodes
    在这里插入图片描述
    浏览器访问http://192.168.10.111:9200/需要输入用户名密码
    在这里插入图片描述
    为内置账号添加密码
    ES中内置了几个管理其他集成组件的账号即:apm_system, beats_system, elastic, kibana, logstash_system, remote_monitoring_user,使用之前,首先需要添加一下密码。
    bin/elasticsearch-setup-passwords interactive
    interactive:给用户手动设置密码。
    auto:自动生成密码。
    在这里插入图片描述
    所有账号密码都是123456,for后面的就是对应的账号。比如上图访问http://192.168.10.111:9200 需要登录的账号密码就是 elastic ; 123456
    配置kibana账号密码
    开启了安全认证之后,kibana连接es以及访问es都需要认证。修改kibana.yml

    elasticsearch.username: "kibana_system"
    elasticsearch.password: "123456"
    
    • 1
    • 2

    注意上面的用户名密码是kibana 访问 es集群的认证,界面登录kibana的账号密码
    启动kibana服务 nohup bin/kibana &
    登录的账号密码是 elastic 123456

    配置cerebro账号密码
    修改配置文件

    vim conf/application.conf
    
    hosts = [
      {
        host = "http://192.168.10.111:9200"
        name = "es-cluster"
        auth = {
          username = "elastic"
          password = "123456"
        }
      }
    ]
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    在这里插入图片描述

    启动cerebro服务 nohup bin/cerebro > cerebro.log &

    生产环境常见集群部署方式

    在开发环境中,一个节点可承担多种角色。
    在生产环境中:
    根据数据量,写入和查询的吞吐量,选择合适的部署方式。建议设置单一角色的节点
    这种单一角色职责分离的好处:

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

    生产环境中,建议为一些大的集群配置Coordinating Only Nodes。扮演Load Balancers,降低Master和 Data Nodes的负载;负责搜索结果的Gather/Reduce;有时候无法预知客户端会发送怎么样的请求。比如大量占用内存的操作,一个深度聚合可能会引发OOM。

    增加节点水平扩展场景

    • 当磁盘容量无法满足需求时,可以增加数据节点;
    • 磁盘读写压力大时,增加数据节点
    • 当系统中有大量的复杂查询及聚合时候,增加Coordinating节点,增加查询的性能

    在这里插入图片描述
    读写分离架构
    在这里插入图片描述

    如何对集群的容量进行规划

    一个集群总共需要多少个节点?一个索引需要设置几个分片?规划上需要保持一定的余量,当负载出现波动,节点出现丢失时,还能正常运行。
    做容量规划时,一些需要考虑的因素:

    • 机器的软硬件配置
    • 单条文档的大小│文档的总数据量│索引的总数据量((Time base数据保留的时间)|副本分片数
    • 文档是如何写入的(Bulk的大小)
    • 文档的复杂度,文档是如何进行读取的(怎么样的查询和聚合)

    评估业务的性能需求:

    • 数据吞吐及性能需求
      数据写入的吞吐量,每秒要求写入多少数据?
      查询的吞吐量?
      单条查询可接受的最大返回时间?
    • 了解你的数据
      数据的格式和数据的Mapping
      实际的查询和聚合长的是什么样的

    ES集群常见应用场景:

    • 搜索: 固定大小的数据集
      搜索的数据集增长相对比较缓慢
    • 日志: 基于时间序列的数据
      使用ES存放日志与性能指标。数据每天不断写入,增长速度较快
      结合Warm Node 做数据的老化处理

    硬件配置:

    • 选择合理的硬件,数据节点尽可能使用SSD
    • 搜索等性能要求高的场景,建议SSD
      按照1∶10的比例配置内存和硬盘
    • 日志类和查询并发低的场景,可以考虑使用机械硬盘存储
      按照1:50的比例配置内存和硬盘
    • 单节点数据建议控制在2TB以内,最大不建议超过5TB
    • JVM配置机器内存的一半,JVM内存配置不建议超过32G
    • 不建议在一台服务器上运行多个节点

    内存大小要根据Node 需要存储的数据来进行估算

    • 搜索类的比例建议: 1:16
    • 日志类: 1:48——1:96之间

    假设总数据量1T,设置一个副本就是2T总数据量

    • 如果搜索类的项目,每个节点31*16 = 496 G,加上预留空间。所以每个节点最多400G数据,至少需要5个数据节点
    • 如果是日志类项目,每个节点31*50= 1550 GB,2个数据节点即可

    部署方式:

    • 按需选择合理的部署方式
    • 如果需要考虑可靠性高可用,建议部署3台单一的Master节点
    • 如果有复杂的查询和聚合,建议设置Coordinating节点
    • 集群扩容:
      增加Coordinating / Ingest Node:解决CPU和内存开销的问题
      增加数据节点:解决存储的容量的问题
      为避免分片分布不均的问题,要提前监控磁盘空间,提前清理数据或增加节点
  • 相关阅读:
    实践练习命令执行
    使用 Dify 和 AWS Bedrock 玩转 Anthropic Claude 3
    23种设计模式之jdk动态代理设计模式实战
    EPICS stream模块使用示例 -- 基于字符串协议的通信
    forEach和map区别
    单片机学习--->Keil多文件工程
    STM32CubeMX:串口DMA
    Excel-快速将公式运用到一整列
    利用京东云Web应用防火墙实现Web入侵防护
    某60区块链安全之Call函数簇滥用实战一学习记录
  • 原文地址:https://blog.csdn.net/admin522043032/article/details/125421162