ITPub博客

首页 > IT基础架构 > > NetDevOps随笔/监控与数据分析/Elastic_Stack/Elasticsearch_01

NetDevOps随笔/监控与数据分析/Elastic_Stack/Elasticsearch_01

作者:格伯纳 时间:2020-05-29 13:33:41 0 删除 编辑

NetDevOps技能领域中网络监控与数据分析是一个大类, 如果对技能领域分类有不同见解详见:

辣不麻:NetDevOps随笔/起点​zhuanlan.zhihu.com图标

本文着重介绍Elasticsearch入门自学需要了解的一些基础概念, 比起直接拿起文档开始啃, 或者拿起键盘一把梭, 前期建立一套完善的框架及术语的理解对后面的学习能起到事半功倍的效果.

申明:
- 本入门自学笔记基于Elasticsearch:7.6.2, 不保证实时随新版本更新.
- 本入门自学笔记包含基于辣不麻理解的中英文翻译, 不保证与官网中文文档完全匹配.

Elasticsearch集群架构

Elasticsearch本质上是一款Java软件, 大部分知道, Java的一大特点就是多平台支持, 只要有合适版本的Java运行环境, Elasticsearch就可以跑. 作为一名网络工程师, 我有爱扣底层的怪癖, 新学一款设备或者软件的时候要是不摸清楚二三四层怎么个通信的, 浑身不得劲.

  1. 和许多传统的网络设备的集群架构不一样, Elasticsearch的集群是基于仲裁(quorum)选举模式的全Active架构, 所以推荐集群节点最好是奇数, 为什么要是奇数呢? 这个问题必须得问自己吧?
  2. 和许多传统的网络设备的集群架构又不一样, Elasticsearch不需要在同一个二层, 那么初始化的时候是怎么互相发现的呢?
  3. Elasticsearch对外的两个TCP接口(默认): 9200和9300分别是做啥的.

偶数节点发生通信故障

目前主流的冗余部署需要至少两个物理机房, 基于偶数节点的集群那当然就是对半分.

当两地出现网络通信故障的时候, 数据无法继续实现同步, 这个时候必须有一方放弃Active的状态退居Standby, 才能保证届时通信恢复的时候不会出现不一致而导致无法同步的两份数据. 偶数节点情况下双方都是对等的, 无法在不与对方通信的情况下做出决策.

奇数节点发生通信故障

三节点集群发生通信故障

在奇数节点数量的情况下, 假设发生通讯故障, 必定有一方的节点数大于总节点数的一半, 比如图中三节点集群, 左侧机房有一个节点, 右侧机房有两个节点, 大于总节点数的半数: 2>1.5 = 3/2. 这个时候节点间将采取仲裁投票机制, 每个节点有一票, 必须投给所有能通信的节点里面的权重最大的节点, 成功获取大于半数票的节点将首先成为Master节点, 其余可以和Master通信的节点将成为非Master但是Active状态, 所有无法与主节点实现通信的节点会进入Standby状态.

自主思考: 基于上述的三节点架构如果2和3所在的右侧机房整个挂了, 左侧会不会成为Active的状态?

TCP 9200 与 TCP 9300

默认情况下, Elasticsearch会监听系统上loopback IP的TCP 9300端口, 这个端口是用来进行节点间的发现, 同步等通信.
默认情况下, Elasticsearch会监听系统上loopback IP的TCP 9200端口, 这个端口就是API 对外服务端口了. 对外服务端口采用的是REST API, 也就是HTTP request, 后文会有用法案例.

Bootstrap自检

这里辣不麻还想提一下大家做实验时候很大概率会遇到第一道坎: Bootstrap自检.

题外话: Bootstrap原意是指鞋后跟的一根带子, 让用户可以更方便的穿鞋子. 后来这个词衍生成了'不靠他人, 自力更生'的意思. 再后来被计算机界引用用来描述计算机自主加载系统启动的过程.

当用户更改了通信与服务端口的监听接口, Elasticsearch就认为自己有可能不是实验用而是生产环境用, 为了保证生产环境下重要配置的正确性, 会执行一系列的自检, 主要包含:
- 与性能相关的自检: 比如Java虚拟机内存分配大小, Unix的文件描述符等
- 与功能相关的自检: 比如节点间初始发现等

Elasticsearch实验集群

有了上述的基本理解之后, 辣不麻就开始搭建自己的第一个集群了. 思考再三, 决定用docker-compose, 高效干净无残留.

申明: 本入门自学笔记不涵盖docker以及docker-compose的基础知识与安装方法, 请移步自学
辣不麻的实验环境

docker-compose与elasticsearch配置文件

申明: 配置文件为yaml格式, 后缀为.yaml或.yml. 本入门自学笔记不涵盖yaml语法基础知识, 请移步自学

docker-compose是基于配置文件来创建container的, 我们把这份配置文件叫elasticlab.yml

version: '2.2'
services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.6.2
    container_name: es01
    environment:
      - node.name=es01
      - cluster.name=es-docker-cluster
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - network.host=_site_
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data01:/usr/share/elasticsearch/data
      - ./elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml
    ports:
      - 32771:9200
    networks:
      - elastic
  es02:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.6.2
    container_name: es02
    environment:
      - node.name=es02
      - cluster.name=es-docker-cluster
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - network.host=_site_
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data02:/usr/share/elasticsearch/data
      - ./elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml
    ports:
      - 32772:9200
    networks:
      - elastic
  es03:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.6.2
    container_name: es03
    environment:
      - node.name=es03
      - cluster.name=es-docker-cluster
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - network.host=_site_
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data03:/usr/share/elasticsearch/data
      - ./elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml
    ports:
      - 32773:9200
    networks:
      - elastic
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
networks:
  elastic:
    driver: bridge

Elasticsearch在启动, 加入集群的时候需要一些必须配置, 这部分基础配置可以通过环境变量方式供给每个节点, 也可以通过配置文件方式供给每个节点, 大家不难发现, 辣不麻已经通过给每个container设置环境变量这个方式提供了一部分的必须配置, 剩下的我们会用配置文件方式来提供, 我们把这个配置文件叫elasticsearch.yml

discovery.seed_hosts:
  - es01
  - es02
  - es03
  • cluster.initial_master_nodes
    之前讨论过Elasticsearch的集群是通过quorum投票方式选举, 辣不麻没有提到的部分是每个节点根据配置可以有投票全, 也可以没有投票权. 那么, 在一个崭新的集群刚启动, 节点间都不知道哪个有投票权哪个没有的时候如何进行投票选举? 这就是cluster.initial_master_nodes的存在目的, 预先手工设定有投票权的节点.
  • network.host
    之前讨论过Elasticsearch默认监听loopback IP TCP 9200/9300端口, 基于辣不麻的实验设计, 每个节点需要监听自己网卡的IP, network.host可以同时改变通信端口与服务端口的监听IP.
    当然, Elasticsearch也提供分别更改的方式, 有需求的可以查阅文档, 在此不做深入讨论. 需要注意的是, 一旦改变了监听IP配置, Elasticsearch会认为集群为生产环境部署, 我们需要保证所有节点可以通过Bootstrap自检.
  • volumes
    docker container的一个特性是每个container相当于一个独立的运行环境, 一旦删除某个container, 其中所有的属于也会一并删除. 你可以选择将container内的某个路径文件夹映射到CentOS的某个文件夹, 也可以选择将container内的某个路径文件夹映射到CentOS的一个docker虚拟存储卷. volume并非必须配置.
  • environment
    此处定义了各自节点的环境变量, 用来提供一部分的必须配置
  • discovery.seed_hosts
    之前提到过一个问题, Elasticsearch各节点并不要求在同一个二层, 也就无法通过广播/组播来互相发现. discovery.seed_hosts提供了一个静态指定其它节点的方式来实现初始化时的互相发现.
自主思考: 配置中的discovery.seed_hosts以及cluster.initial_master_nodes指定的不是IP而是es01, es02酱紫的hostname, 在没有DNS的情况下, 各container是如何解析主机名为IP的?

集群部署

集群部署前, 再次检查配置文件是否备齐, docker-compose是否正确安装.

[nexus@localhost elasticlab]$ ls -l
total 8
-rw-rw-r--. 1 nexus nexus 3048 Apr 11 20:08 elasticlab.yml
-rw-rw-r--. 1 nexus nexus  115 Apr 11 20:08 elasticsearch.yml
[nexus@localhost elasticlab]$ docker-compose --version
docker-compose version 1.24.1, build 4667896b

部署集群

[nexus@localhost elasticlab]$ docker-compose -f elasticlab.yml up -d
#等待部署完毕
[nexus@localhost elasticlab]$ docker-compose -f elasticlab.yml ps
  Name                Command                State                   Ports              
----------------------------------------------------------------------------------------
es01       /usr/local/bin/docker-entr ...   Up         0.0.0.0:32771->9200/tcp, 9300/tcp
es02       /usr/local/bin/docker-entr ...   Up         0.0.0.0:32772->9200/tcp, 9300/tcp
es03       /usr/local/bin/docker-entr ...   Up         0.0.0.0:32773->9200/tcp, 9300/tcp

通过REST API来检查集群状态

之前提及REST API就是http request, 那是不是可以用浏览器来与REST API进行通信呢?

没错, 浏览器访问相当于是一个http GET request, 我们可以看到集群的一些信息. REST API作为一个相当主流的API, 市场上REST API的客户端有千千万万, 辣不麻选取Postman作为实验用, 后续会替换成kibana.

申明: 本入门自学笔记不涵盖postman的基础知识与安装方法, 请移步自学
GET: http://IP:port/_cat/health

GET IP:port/_cat/health API 用来获取集群的健康状态, green代表健康, 任何少于三节点的集群都不会是绿色.

GET http://IP:port/_cat/nodes

GET IP:port/_cat/nodes API 用来获取集群内所有的节点, 我们可以看到172.18.0.3为master

申明: 大家或许会疑惑为什么IP是127.0.0.1而不是拓扑图中的10.0.2.4, 这是因为辣不麻用的是virtualbox的NAT 端口映射, 大家当作是10.0.2.4就是.

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/31509949/viewspace-3123569/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
管理员

注册时间:2018-03-30

  • 博文量
    2383
  • 访问量
    984203