分享人陈荣华(Lucky)，网名采菊篱下，云智慧高级运维工程师，典型90后屌丝，技术观风者。2012年开始接触Linux，并且从此踏上了Linux运维之路，有着三年的从三线到一线的运维经验。现在比较关注Devops，云计算以及大数据，在云智慧主要负责后端中间件和大数据的运维工作，个人博客www.devopsh.com，喜欢交朋友,希望可以结识更多Ops Companion。

云智慧是一家应用性能管理服务商，在大数据方面采用了 Hadoop及Elasticsearch作为最终的存储系统。Elasticsearch是基于Lucene的搜索服务器，提供分布式多用户能力的全文搜索引擎。Elasticsearch的开发语言是Java，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎，常用于需要进行实时搜索的云计算平台，具有稳定，可靠，快速，安装使用方便等特点。

下面就是Lucky关于如何控制Elasticsearch分片和副本分配的技术分享：

因为云智慧的两款产品监控宝和透视宝，在大数据分析用到了Elasticsearch，所以我根据实际工作，分享一下关于控制Elasticsearch(以下简称ES)分片和副本的分配的内容。

ES集群中索引可能由多个分片构成，并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片，我们可以处理不能在一个单一的服务器上面运行的大型索引，简单的说就是索引的大小过大，导致效率问题。不能运行的原因可能是内存也可能是存储。

由于每个分片可以有多个副本，通过将副本分配到多个服务器，可以提高查询的负载能力。为了进行分片和副本的操作，ES需要确定将这些分片和副本放到集群节点的哪个位置，就是需要确定把每个分片和副本分配到哪台服务器/节点上。

下面我们就来，具体看看怎么控制，怎么按照我们想要的结果分配!

一、显式控制分配

生产情景如图

我这里列举了三个索引的名称：man、woman、katoey 。因为我们线上业务，根据不同的code lang和业务，分别设为 javatopic、pythontopic、phptopic、dotnettopi、 angettopic等。这里man 和woman 就是我们常见公司应用使用的语言环境，而 katoey就是使用环境比较少的语言环境，所以katoey索引大小也相对比较小。

下面我们看看这张图：

下面就围绕这张图，给大家讲解控制方法。需求，逻辑都有了，开始干活!

1、指定节点的参数

如上图所示，我们将ES集群划分为两个"空间"。当然你也可以叫做区域，随便命名。我们将左边的三台ES节点服务器放置到zone_one的空间上面，将右边的三台ES节点服务器放到zone_two的空间上。划分了空间，我们就要对服务器修改相对配置，这个其实最好是在上线之前就配置规划好!

为了做到我们需要的效果，我们需要将如下属性配置到左边三台ES集群节点服务器的elasticsearch.yml配置文件中： node.zone: zone_one

将如下属性配置到右边的三台ES集群节点服务器elasticsearch.yml配置文件中：node.zone: zone_two

在线修改配置，叫平滑修改配置，我们可以参考这篇文章：http://zhaoyanblog.com/archives/555.html

配置修改完成，使用curl -XGET "http://ESnode:9200/_cluster/health" 查看集群健康状态为green即可!配置修改好，之后就是按照我们的需求控制了。具体操作如下：

第一条命令是创建man索引;第二条命令是发送到_settings REST端点，用来指定这个索引的其他配置信息。我们将index.routing.allocation.include.zone属性设置为 zone_one值，就是我们所希望的把man索引放置到node.zone属性值为zone_one的ES集群节点服务器上。

同样对woman索引我们做类似操作：

不同的是，这次指定woman索引放置在node.zone属性值为zone_two的ES集群节点服务器上。

最后我们需要将katoey索引放置到上面所有的ES集群节点上面，配置设置命令如下：

这是一种方法，已经达到了我们的需求，男人、女人、人妖都被我们控制了!

2、分配时排除节点

下面我再给大家介绍第二种方法，跟我们上面操作为索引指定放置节点位置一样，我们也可以在索引分配的时候排除某些节点。参照之前的例子，我们新建一个people索引，但是不希望people索引放置到zone_one的ES集群节点服务器上，我们可以运行如下命令操作：

请注意，在这里我们使用的是index.routing.allocation.exclude.zone属性而不是index.routing.allocation.include.zone属性。

使用IP地址进行分配配置

除了在节点的配置中添加一些特殊的属性参数外，我们还可以使用IP地址来指定你将分片和副本分配或者不分配到哪些节点上面。为了做到这点，我们应该使用 _ip属性，把zone换成_ip就好了。例如我们希望lucky索引分配到IP地址为10.0.1.110和10.0.1.119的节点上，我们可以运行如下命令设置：

第二种方法和第一种方法的区别就是include和exclude的区别，还有就是IP地址分配的方法，可以达到动态预分配的效果，这下你就是土地的主人，当家做主了!

后面，我会把针对使用IP地址进行分配配置 的shell scripts和python scripts 分享给大家!

二、集群范围内分配

上面已经介绍了 显式控制分配 方法，它是居于在索引下操作的settings设置。下面我介绍居于整个集群下的设置，集群范围内分配。

除了索引层面指定分配活着排除分配之外(上面我们所做的都是这两种情况),我们还可以指定集群中所有索引的分配。例如，我们希望将所有的新索引分配到IP地址为10.0.1.112和10.0.1.114的节点上，我们可以运行如下命令设置：

当然这个集群级别的分配参数在集群重启后是会失效的，而写到配置文件中就是永久的!

三、每个节点上分片和副本数量的控制

接下来我们分享节点级别的分片和副本数量控制。除了指定分片和副本的分配，我们还可以对一个索引指定每个节点上的最大分片数量。例如我们希望ops索引在每个节点上只有一个分片，我们可以运行如下命令：

这个属性也可以直接配置到elasticsearch.ym配置文件中，或者使用上面命令在活动索引上更新。如果配置不当，导致主分片无法分配的话，集群就会处于red状态。

四、手动移动分片和副本

最后跟大家说说手动移动分片和副本。

1. 移动分片

假设我们有两个节点：es_node_one和es_node_two，ElasticSearch在es_node_one节点上分配了ops索引的两个分片，我们现在希望将第二个分片移动到es_node_two节点上，可以如下操作实现：

我们通过move命令的index属性指定移动哪个索引,通过shard属性指定移动哪个分片，最终通过from_node属性指定我们从哪个节点上移动分片，通过to_node属性指定我们希望将分片移动到哪个节点。

2、取消分配

如果希望取消一个正在进行的分配过程，我们通过运行cancel命令来指定我们希望取消分配的索引、节点以及分片，如下所示：

运行上面的命令将会取消es_node_one节上ops索引的第0个分片的分配。

3、分配分片

除了取消和移动分片和副本之外，我们还可以将一个未分配的分片分配到一个指定的节点上。假设ops索引上有一个编号为0的分片尚未分配，并且我们希望ElasticSearch将其分配到es_node_two上，可以运行如下命令操作：

一次HTTP请求包含多个命令 我们可以在一次HTTP请求中包含多个命令，例如：

好了，全部分享就到这结束了。

问：这个技术主要用于透视宝和监控宝的什么功能上，大数据分析么?

答：透视宝现在除掉页面详情，大部分数据存储在ES中，Web端页面的数据展示、搜索都是用ES实现的。监控宝只有现在新上的Docker监控中使用了ES

最后给大家讲下ES 的诞生记，多年前有一个叫做Shay Banon的刚结婚不久的失业开发者，由于妻子要去伦敦学习厨师，他便跟着也去了。在他找工作的过程中，为了给妻子构建一个食谱的搜索引擎，他开始构建一个早期版本的Lucene。

因为直接基于Lucene工作会比较困难，所以Shay开始抽象Lucene代码以便Java程序员可以在应用中添加搜索功能，为此他发布了第一个开源项目，叫做“Compass”。

后来Shay找到一份工作，这份工作处在高性能和内存数据网格的分布式环境中，因此高性能的、实时的、分布式的搜索引擎也是理所当然需要的。然后他决定重写Compass库使其成为一个独立的服务，这个服务叫做Elasticsearch。

Elasticsearch 的第一个公开版本出现在2010年2月，在那之后Elasticsearch成为Github上最受欢迎的项目之一，代码贡献者超过300人。一家主营 Elasticsearch的公司就此成立，他们一边提供商业支持一边开发新功能，不过Elasticsearch将永远开源且对所有人可用。

Shay的妻子依旧等待着她的食谱搜索……

为了老婆，ES诞生了，所以，女生找过IT男，挺好的。

问：我有个问题，对于ES集群本身的性能监控，怎么做?

答：从TSB架构来看，我们可以入手的点：

1.前端查询，查询语句是否存在性能问题，是否可以优化;

2.前端调度后端ES集群查询数据，调度的方法是否有问题;

3.后端ES集群本身配置设置问题;

4.ES集群对我们TSB整体架构适应性，在架构级别是否可以更好的适应;

发挥ES真正的优点和它的特性，考量整体业务架构逻辑，这是我个人看法和所能看到的。