环境

1.操作系统：centos7.2
2.elasticsearch 版本：6.2.2
3.服务器信息

安装 Java

yum -y install java

安装 Elasticsearch

rpm -ivh https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.2.2.rpm

配置集群

elasticsearch 工作原理

elasticsearch 只要它的其他节点和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。 但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表，也就是配置文件中的：

discovery.zen.ping.unicast.hosts:["host1"，“host2”]

Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。

使用单播，你可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。 当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 master 节点，并加入集群。

启动过程

当 ElasticSearch 的节点启动后，它会利用多播 (multicast) (或者单播，如果用户更改了配置) 寻找集群中的其它节点，并与之建立连接。这个过程如下图所示

在集群中，一个节点被选举成主节点 (master node) 。这个节点负责管理集群的状态，当群集的拓扑结构改变时把索引分片分派到相应的节点上。

从用户的角度来看，主节点在ElasticSearch中并没有占据着重要的地位，这与其它的系统(比如数据库系统)是不同的。实际上用户并不需要知道哪个节点是主节点；所有的操作需求可以分发到任意的节点，>ElasticSearch内部会完成这些让用户感到不明觉历的工作。在必要的情况下，任何节点都可以并发地把查询子句分发到其它的节点，然后合并各个节点返回的查询结果。最后返回给用户一个完整的数据集。所有的这些工作都不需要经过主节点转发(节点之间通过P2P的方式通信)。

主节点会去读取集群状态信息；在必要的时候，会进行恢复工作。在这个阶段，主节点会去检查哪些分片可用，决定哪些分片作为主分片。处理完成后，集群就会转入到黄色状态。

10.173.32.34

# cat /etc/elasticsearch/elasticsearch.yml | grep -v ^#
cluster.name: awentest # 集群名称，必须一致
node.name: node-34 # 节点名称，必须不一致
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
bootstrap.memory_lock: false
network.host: 0.0.0.0 
http.port: 9200
discovery.zen.ping.unicast.hosts: ["10.173.32.34", "10.173.32.32"] # 配置单播方式查找同一集群名称的集群
discovery.zen.minimum_master_nodes: 2 # 最小主节点数

10.173.32.32

# cat /etc/elasticsearch/elasticsearch.yml | grep -v ^#
cluster.name: awentest # 集群名称，
node.name: node-32
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
http.port: 9200
discovery.zen.ping.unicast.hosts: ["10.173.32.32", "10.173.32.34"]
discovery.zen.minimum_master_nodes: 2

推荐阅读 《elasticsearch》 权威指南关于 es 集群的重要参数

启动集群

systemctl enable elasticsearch
systemctl restart elasticsearch

查看集群信息

查看集群健康状态

1.方法1

# curl -X GET 10.173.32.34:9200/_cat/health?v
epoch      timestamp cluster  status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1520817197 09:13:17  awentest green           2         2      0   0    0    0        0             0                  -                100.0%

2.方法2

     # curl -X GET 10.173.32.34:9200/_cluster/health | python2 -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   385  100   385    0     0  84783      0 --:--:-- --:--:-- --:--:-- 96250
{
    "active_primary_shards": 8,
    "active_shards": 16,
    "active_shards_percent_as_number": 100.0,
    "cluster_name": "awentest",
    "delayed_unassigned_shards": 0,
    "initializing_shards": 0,
    "number_of_data_nodes": 2,
    "number_of_in_flight_fetch": 0,
    "number_of_nodes": 2,
    "number_of_pending_tasks": 0,
    "relocating_shards": 0,
    "status": "green",
    "task_max_waiting_in_queue_millis": 0,
    "timed_out": false,
    "unassigned_shards": 0
}    

Elasticsearch 的集群监控信息中包含了许多的统计数据，其中最为重要的一项就是集群健康 ， 它在 status 字段中展示为 green 、 yellow 或者 red 。

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

• green
  所有的主分片和副本分片都正常运行。
• yellow
  所有的主分片都正常运行，但不是所有的副本分片都正常运行。
• red
  有主分片没能正常运行。

集群的健康状况为 yellow 则表示全部主分片都正常运行（集群可以正常服务所有请求），但是 副本 分片没有全部处在正常状态。 实际上，所有3个副本分片都是 unassigned —— 它们都没有被分配到任何节点。 在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。

green/yellow/red 状态是一个概览你的集群并了解眼下正在发生什么的好办法。剩下来的指标给你列出来集群的状态概要：

• number_of_nodes 和 number_of_data_nodes 这个命名完全是自描述的。
• active_primary_shards 指出你集群中的主分片数量。这是涵盖了所有索引的汇总值。
• active_shards 是涵盖了所有索引的_所有_分片的汇总值，即包括副本分片。
• relocating_shards 显示当前正在从一个节点迁往其他节点的分片的数量。通常来说应该是 0，不过在 Elasticsearch 发现集群不太均衡时，该值会上涨。比如说：添加了一个新节点，或者下线了一个节点。
• initializing_shards 是刚刚创建的分片的个数。比如，当你刚创建第一个索引，分片都会短暂的处于 initializing 状态。这通常会是一个临时事件，分片不应该长期停留在 initializing 状态。你还可能在节点刚重启的时候看到 initializing 分片：当分片从磁盘上加载后，它们会从 initializing 状态开始。
• unassigned_shards 是已经在集群状态中存在的分片，但是实际在集群里又找不着。通常未分配分片的来源是未分配的副本。比如，一个有 5 分片和 1 副本的索引，在单节点集群上，就会有 5 个未分配副本分片。如果你的集群是 red 状态，也会长期保有未分配分片（因为缺少主分片）。

测试

我们在 10.173.32.34 上 PUT 一条数据

PUT /blogs
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

然后我们在10.173.32.32上查看

# curl -X GET http://10.173.32.32:9200/blogs | python -m  json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   229  100   229    0     0  50630      0 --:--:-- --:--:-- --:--:-- 57250
{
    "blogs": {
        "aliases": {},
        "mappings": {},
        "settings": {
            "index": {
                "creation_date": "1520818544632",
                "number_of_replicas": "1",
                "number_of_shards": "3",
                "provided_name": "blogs",
                "uuid": "t1vTwRvoQp-AX3xrN3ZOgQ",
                "version": {
                    "created": "6020299"
                }
            }
        }
    }
}

发现是一致的。