ElasticSearch 分布式特性和集群

2018-09-20 本文已影响14人溯水心生

一、ElasticSearch分布式特性

1.分布式特性，后台自动执行的操作：

分配文档到不同的容器或分片中，文档可以储存在一个或多个节点中
按集群节点来均衡分配这些分片，从而对索引和搜索过程进行负载均衡
复制每个分片以支持数据冗余，从而防止硬件故障导致的数据丢失
将集群中任一节点的请求路由到存有相关数据的节点
集群扩容时无缝整合新节点，重新分配分片以便从离群节点恢复

2. 集群内部原理

空集群
如果我们启动了一个单独的节点，里面不包含任何的数据和索引，那我们的集群看起来就是一个图 1 “包含空内容节点的集群”。

image

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到集群中的任何节点，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

集群健康

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

GET /_cluster/health

返回结果：

{
  "cluster_name": "elasticsearch",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 8,
  "active_shards": 8,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 5,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 61.53846153846154
}

status 字段是我们最关心的。

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

green

所有的主分片和副本分片都正常运行。

yellow

所有的主分片都正常运行，但不是所有的副本分片都正常运行。

red

有主分片没能正常运行。

添加索引

我们往 Elasticsearch 添加数据时需要用到索引 —— 保存相关数据的地方。索引实际上是指向一个或者多个物理分片的逻辑命名空间。
一个分片是一个 Lucene 的实例，应用程序是直接与索引而不是与分片进行交互。

Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。

一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。

在包含一个空节点的集群内创建名为 blogs 的索引。索引在默认情况下会被分配5个主分片，但是为了演示目的，我们将分配3个主分片和一份副本（每个主分片拥有一个副本分片）：

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

返回结果：

{
  "acknowledged": true,
  "shards_acknowledged": true,
  "index": "blogs"
}

我们的集群现在是图 2 “拥有一个索引的单节点集群”。所有3个主分片都被分配在 Node 1 。
图 2. 拥有一个索引的单节点集群

此时集群健康状态为yellow：

{
  "cluster_name": "elasticsearch",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 11,
  "active_shards": 11,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 8,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 57.89473684210527
}

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

添加故障转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。幸运的是，我们只需再启动一个节点即可防止数据丢失。
实现2个节点的伪集群，主要实现以下配置信息：

image

拷贝原有的安装文件夹一份，重命名新的文件夹：

cp -r elasticsearch-6.4.1/ elasticsearch-6.4.1-slave

更改Master主节点的elasticsearch.yml文件信息

cluster.name: notice-application
node.name: master
node.master: true
network.host: 192.168.92.50
http.port: 9200
transport.tcp.port: 9300
discovery.zen.ping.unicast.hosts: ["192.168.92.50:9300","192.168.11.21:9310"]

更改Slave节点的elasticsearch.yml文件信息：

cluster.name: notice-application
node.name: slave1
network.host: 192.168.92.50
http.port: 9210
transport.tcp.port: 9310
discovery.zen.ping.unicast.hosts: ["192.168.92.50:9300","192.168.92.50:9310"]

删除节点二文件夹里面文件夹data下的nodes文件夹

以上2个节点都必须非root用户启动

启动出现如下错误：

[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536

编辑 /etc/security/limits.conf 文件,增加如下内容：

* soft nofile 65536
* hard nofile 131072
* soft nproc 2048
* hard nproc 4096

启动后，仍然出错，内容如下：

[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

编辑 /etc/sysctl.conf, 行始增加一行，内容如下：

vm.max_map_count = 655360

执行如下命令：

sysctl -p

此时2个节点都可以起来，但是kibana无法连接到master节点，修改kibana.yml 配置文件
，定位到kinaba的conf文件夹，修改内容如下：

elasticsearch.url: "http://192.168.92.50:9200"

上述IP为我虚拟机测试的内网IP，此时再启动kibana，成功了！

image

可以看到2个节点正常启动且集群健康状态为green。

集群启动成功，我们看到了2个节点的集群。

image

继续按上述方法，在增加一个节点，结果状态如下：

{
  "cluster_name": "my-application",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 13,
  "active_shards": 26,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100
}

再次我们把副本调整到2：

PUT /blogs/_settings
{
   "number_of_replicas" : 2
}

集群健康状态

集群节点分布情况
当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少。你需要增加更多的硬件资源来提升吞吐量。

ElasticSearch 分布式特性和集群

一、ElasticSearch分布式特性

1.分布式特性，后台自动执行的操作：

2. 集群内部原理

猜你喜欢

热点阅读