一、ES集群的相关概念
ES集群是一个 P2P类型(使用 gossip 协议)的分布式系统,除了集群状态管理以外,其他所有的请求都可以发送到集群内任意一台节点上,这个节点可以自己找到需要转发给哪些节点,并且直接跟这些节点 通信。所以,从网络架构及服务配置上来说,构建集群所需要的配置极其简单。在 Elasticsearch 2.0 之前,无阻碍的网络下,所有配置了相同 cluster.name 的节点都自动归属到一个集群中。2.0 版本之后, 基于安全的考虑避免开发环境过于随便造成的麻烦,从 2.0 版本开始,默认的自动发现方式改为了单播(unicast)方式。配置里提供几台节点的地址,ES 将其视作 gossip router 角色,借以完成集群的发现。由于这只是 ES 内一个很小的功能,所以 gossip router 角色并不需要单独配置,每个 ES 节点都可以担任。所以,采用单播方式的集群,各节点都配置相同的几个节点列表作为 router 即可。
集群中节点数量没有限制,一般大于等于2个节点就可以看做是集群了。一般处于高性能及高可用方 面来考虑一般集群中的节点数量都是3个及3个以上。
一个集群就是由一个或多个节点组织在一起,它们共同持有整个的数据,并一起提供索引和搜索功能。 一个集群由一个唯一的名字标识,这个名字默认就是“elasticsearch”。这个名字是重要的,因为一个节 点只能通过指定某个集群的名字,来加入这个集群
一个节点是集群中的一个服务器,作为集群的一部分,它存储数据,参与集群的索引和搜索功能。和集 群类似,一个节点也是由一个名字来标识的,默认情况下,这个名字是一个随机的漫威漫画角色的名 字,这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的,因为在这个管理过程 中,你会去确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。
一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下,每个节点都会被安排加入 到一个叫做“elasticsearch”的集群中,这意味着,如果你在你的网络中启动了若干个节点,并假定它们 能够相互发现彼此,它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。
在一个集群里,只要你想,可以拥有任意多个节点。而且,如果当前你的网络中没有运行任何
Elasticsearch节点,这时启动一个节点,会默认创建并加入一个叫做“elasticsearch”的集群。
一个索引可以存储超出单个结点硬件限制的大量数据。比如,一个具有10亿文档的索引占据1TB的磁盘 空间,而任一节点都没有这样大的磁盘空间;或者单个节点处理搜索请求,响应太慢。为了解决这个问 题,Elasticsearch提供了将索引划分成多份的能力,这些份就叫做分片。当你创建一个索引的时候,你 可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”,这个“索引”可以被 放置到集群中的任何节点上。分片很重要,主要有两方面的原因:
- 允许你水平分割/扩展你的内容容量。
- 允许你在分片(潜在地,位于多个节点上)之上进行分布式的、并行的操作,进而提高性能/吞吐 量。
至于一个分片怎样分布,它的文档怎样聚合回搜索请求,是完全由Elasticsearch管理的,对于作为用户 的你来说,这些都是透明的。
在一个网络/云的环境里,失败随时都可能发生,在某个分片/节点不知怎么的就处于离线状态,或者由 于任何原因消失了,这种情况下,有一个故障转移机制是非常有用并且是强烈推荐的。为此目的, Elasticsearch允许你创建分片的一份或多份拷贝,这些拷贝叫做副本分片,或者直接叫副本。
副本之所以重要,有两个主要原因: 在分片/节点失败的情况下,提供了高可用性。因为这个原因,注 意到复制分片从不与原/主要(original/primary)分片置于同一节点上是非常重要的。扩展你的搜索量/ 吞吐量,因为搜索可以在所有的复制上并行运行。总之,每个索引可以被分成多个分片。一个索引也可 以被复制0次(意思是没有复制)或多次。一旦复制了,每个索引就有了主分片(作为复制源的原来的 分片)和副本分片(主分片的拷贝)之别。分片和副本的数量可以在索引创建的时候指定。在索引创建 之后,你可以在任何时候动态地改变副本的数量,但是你事后不能改变分片的数量。
默认情况下,Elasticsearch中的每个索引被分片5个主分片和1个副本,这意味着,如果你的集群中至少 有两个节点,你的索引将会有5个主分片和另外5个副本分片(1个完全拷贝),这样的话每个索引总共 就有10个分片。
二、集群搭建及使用
1、集群搭建
略
2、集群的使用
1、节点类型
master节点特点:
|
master节点的作用:
|
master节点的配置如下(elasticsearch.yml)
|
|
data节点的配置如下(elasticsearch.yml)
|
6 7 协调节点最好不要分离,跟数据节点在一起就行。 |
协调节点的配置如下(elasticsearch.yml)
|
注意:
一个节点可以充当一个或多个角色。默认 3个角色都有。
分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中,然 后分片分配到你集群中的节点上。当你的集群扩容或缩小,Elasticsearch将会自动在你的节点间 迁移分片,以使集群保持平衡。 属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据,每一个分片都是一个搜索 引擎。 # 分片详情(文档存储、主分片、分片引擎) 分片可以是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每个文档 属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据,每一个分片都是一个搜索 引擎。 # 分片存储大小限制 • 理论上主分片能存储的数据大小是没有限制的,限制取决于你实际的使用情况。分片的最大容量完 全取决于你的使用状况:硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档,以及你期 望的响应时间。 # 副本分片作用 • 复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求,比 如搜索或者从别的shard取回文档。 # 主分片数量及 副本分片数量 • 当索引创建完成的时候,主分片的数量就固定了,但是复制分片的数量可以随时调整。 |
3、集群选举
选举的时机
master选举当然是由master-eligible节点发起,当一个master-eligible节点发现满足以下条件时发起选举:
-
- 该master-eligible节点的当前状态不是master。并且该master-eligible节点通过ZenDiscovery模块的ping操作询问其已知的集群其他节点,没有任何节点连接到master。
- 包括本节点在内,当前已有超过minimum_master_nodes 个节点没有连接到master。
总结一句话,即当一个节点发现包括自己在内的多数派的master-eligible节点认为集群没有master时, 就可以发起master选举。
选举的过程
先根据节点的clusterStateVersion比较,clusterStateVersion越大,优先级越高。clusterStateVersion 相同时,进入compareNodes,其内部按照节点的Id比较(Id为节点第一次启动时随机生成)。
-
- 当clusterStateVersion越大,优先级越高。这是为了保证新Master拥有最新的clusterState(即集 群的meta),避免已经commit的meta变更丢失。因为Master当选后,就会以这个版本的clusterState为基础进行更新。(一个例外是集群全部重启,所有节点都没有meta,需要先选出一 个master,然后master再通过持久化的数据进行meta恢复,再进行meta同步)。
- 当clusterStateVersion相同时,节点的Id越小,优先级越高。即总是倾向于选择Id小的Node,这个Id是节点第一次启动时生成的一个随机字符串。之所以这么设计,应该是为了让选举结果尽可能 稳定,不要出现都想当master而选不出来的情况。
4、脑裂问题
由于部分节点网络断开,集群分成两部分,且这两部分都有master选举权。就成形成一个与原集群一样 名字的集群,这种情况称为集群脑裂(split-brain)现象。这个问题非常危险,因为两个新形成的集群 会同时索引和修改集群的数据。
|
场景分析
一个生产环境的es集群,至少要有3个节点,同时将discovery.zen.minimum_master_nodes设置为
2, 那么这个是参数是如何避免脑裂问题的产生的呢?
比如我们有3个节点,quorum是2。现在网络故障,1个节点在一个网络区域,另外2个节点在另 外一个网络区域,不同的网络区域内无法通信。这个时候有两种情况情况:
-
- 如果master是单独的那个节点,另外2个节点是master候选节点,那么此时那个单独的master节点因为没有指定数量的候选master node在自己当前所在的集群内,因此就会取消当前master的角色,尝试重新选举,但是无法选举成功。然后另外一个网络区域内的node因为无法连 接到master,就会发起重新选举,因为有两个master候选节点,满足了quorum,因此可以成功选举出一个master。此时集群中就会还是只有一个master。
- 如果master和另外一个node在一个网络区域内,然后一个node单独在一个网络区域内。那 么此时那个单独的node因为连接不上master,会尝试发起选举,但是因为master候选节点数量不到quorum,因此无法选举出master。而另外一个网络区域内,原先的那个master还会继续工作。这也可以保证集群内只有一个master节点。
综上所述,通过在elasticsearch.yml 中配置discovery.zen.minimum_master_nodes: 2 ,就可以避免脑裂问题的产生。
但是因为ES集群是可以动态增加和下线节点的,所以可能随时会改变quorum 。所以这个参数也是可以通过api随时修改的,特别是在节点上线和下线的时候,都需要作出对应的修改。而且一旦修改过后, 这个配置就会持久化保存下来。
1 PUT /_cluster/settings { "persistent" : { "discovery.zen.minimum_master_nodes" : 2 } } |
一个索引可以存储超出单个结点硬件限制的大量数据。
3 4 Node3 包含了分别来自 Node 1 和 Node 2 的一个分片,这样每个节点就有两个分片,和之前相比少了一个,这意味着每个节点上的分片将获得更多的硬件资源(CPU、RAM、I/O) |
注意:分片本身就是一个完整的搜索引擎,它可以使用单一节点的所有资源。我们拥有6个分片(3个 主分片和三个复制分片),最多可以扩展到6个节点,每个节点上有一个分片,每个分片可以100%使用 这个节点的资源。
如果我们要扩展到6个以上的节点,要怎么做?
|
更新副本数量:
4 "number_of_replicas" : 2 5 } |
从图中可以看出, 索引现在有9个分片:3个主分片和6个复制分片。这意味着我们能够扩展到9个节点,再次变成每个节点一个分片。这样使我们的搜索性能相比原始的三节点集群增加三倍。
当然,在同样数量的节点上增加更多的复制分片并不能提高性能,因为这样做的话平均每个分片的所 占有的硬件资源就减少了(大部分请求都聚集到了分片少的节点,导致一个节点吞吐量太大,反而降低 性能),你需要增加硬件来提高吞吐量。不过这些额外的复制节点使我们有更多的冗余:通过以上对节 点的设置,我们能够承受两个节点故障而不丢失数据。
6、故障转移
ES有两种集群故障探查机制:
-
- 通过master进行的,master会ping集群中所有的其他node,确保它们是否是存活着的。
- 每个node都会去ping master来确保master是存活的,否则会发起一个选举过程。
有下面三个参数用来配置集群故障的探查过程:
|
分片不会放在同一个节点上
从图可知:
- 每个索引被分成了5个分片;
- 每个分片有一个副本;
3)5个分片基本均匀分布在3个dataNode上;
注意分片的边框(border)有粗有细,具体区别是: 粗边框代表:primary(true)
细边框代表:replica
演示负载均衡效果: 关闭集群中其中一个节点,剩余分片将会重新进行均衡分配。