简介
在我们的实际部署中,我们的各个 node(节点)的能力是不一样的。比如有的节点的计算能力比较强,而且配有高性能的存储,速度也比较快,同时我们可能有一些 node 的能力稍微差一点,比如计算能力及存储器的速度都比较差一点。针对这两种情况,我们其实可以把这两种节点用来做不同的用途:运算能力较强的节点可以用来做 indexing(建立索引表格)的工作,而那些能力较差一点的节点,我们可以用来做搜索用途。我们可以把这两种节点分别叫做:
• hot node:用于支持索引并写入新文档
• warm node:用于处理不太频繁查询的只读索引
这种架构在 Elasticsearch 中,我们称之为 hot/warm 架构。
Hot node
我们可以使用 hot node 来做 indexing:
• indexing 是 CPU 和 IO 的密集操作,因此热节点应该是功能强大的服务器
• 比 warm node 更快的存储
Warm node
对较旧的只读索引使用热节点:
• 倾向于利用大型附加磁盘(通常是旋转磁盘)
• 大量数据可能需要其他节点才能满足性能要求
Shard filtering
Shard filtering 在 Elasticsearch 中,我们可以利用这个能力来把我们想要的 index 放入到我们想要的 node 里。我们可以使用在 elasticsearch.yml 配置文件中的:
node.attr 来指定我们 node 属性:hot 或是 warm。
在 index 的 settings 里通过 index.routing.allocation 来指定索引(index)到一个满足要求的 node
为节点分配索引有三种规则:
就像上面的表格说明的一样:include 指的是至少包含其中的一个值;exclude 指的是不包含任何值;require 指的是必须包含里面索引的值。这些值实际上我们用来标识 node 的 tag。针对自己的配置这些 tag 可以由厂商自己标识。
标识 node
在上面的图中,我们标识 my_temp 属性为 hot 或是 warm,表明我们的 cluster 中分为两类:hot 或是 warm。在这里特别指出:这里的 my_temp,hot 及 warm 都是我们任意取的可以让我们记住的属性及名称。只要在使用时和 index.routing.allocation.include index.routing.allocation.exclude 及 index.routing.allocation.require 中的值相对应即可。
配置 index 的 settings
我们可以通过配置在 Index 中的 settings 来分配我们的index 到相应的具有哪些属性的 node 里,比如:
PUT logs-2019-03
{
"settings": {
"index.routing.allocation.require.my_temp": "hot"
}
}
在上面我们通过 logs-2019-03 的这个 index 的 settings 来控制这个 index 必须分配到具有 hot 属性的 node里。
假如我们上面的 index logs-2019-03 由于一些原因不再是当前的用来做 indexing 的 index,比如我们可以通过rollover API 接口来自动滚动我们的 index 名字。我们可以通过如下的命令把该 index 移动到 warm node 里:
PUT logs-2019-03
{
"settings": {
"index.routing.allocation.require.my_temp": "warm"
}
}
这样 Elasticsearch 会自动帮我们把 logs-2019-03 索引移动到 warm node 中,以便直供搜索之用。
例子
首先,我们我们按照如下的方式来做一个实验,虽然不能应用于实际的生产环境中:
1、按照“如何在 Linux,MacOS 及 Windows 上进行安装 Elasticsearch”安装好自己的 Elasticsearh,但是不要运行 Elasticsearch
2、按照“如何在 Linux 及 MacOS 上安装 Elastic 栈中的 Kibana ”安装好自己的 Kibana
3、或者免安装,一键配置“阿里云 Elasticsearch”,并直接进入 Kibana
在我们完成上面的两个安装后,我们分别打开两个 terminal,然后分别在两个 terminal 中运行如下的指令:
./bin/elasticsearch -E node.name=node1 -E node.attr.data=hot -Enode.max_local_storage_nodes=2
上面的指令运行一个名字叫做 node1 的,data 属性为 hot 的 node。
./bin/elasticsearch -E node.name=node2 -E node.attr.data=warm -Enode.max_local_storage_nodes=2
上面的指令运行一个名字叫做 node2 的,data 属性为 hot 的 warm。
我们可以在 Kibana 里查看我们的 nodes:
我们可以看出来有两个 node 正在运行:node1 及 node2。如果我们想了解这两个 node 的更多属性,我们可以打入如下的命令:
GET _cat/nodeattrs?v&s=name
显示的结果为:
我们可以看到 node 被标识为 hot node,而 node2 被标识为 warm node。
接下来,我们运用我们上面命令来把我们的 logs-2019-03 置于我们的 hot node 里。我们可以通过如下的命令:
PUT logs-2019-03
{
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0,
"index.routing.allocation.require.data": "hot"
}
}
运行上面的结果后,可以通过如下的命令来查看:
GET _cat/shards/logs-*?v&h=index,shard,prirep,state,node&s=index,shard,prirep
显示的结果为:
从上面我们可以看出来我们的 logs-2019-03 是分配到 node1 上面的。
假如我们由于某种原因,想把 logs-2019-03 分配到 node2 上面,那么该怎么做呢?我们可以通过如下的命令来实现:
PUT logs-2019-03/_settings
{
"index.routing.allocation.require.data": "warm"
}
运行上面的指令显示的结果是:
显然我们 logs-2019-03 已经成功地移到 node2 了。
针对硬件的 shard filtering
上面我们说了,对于 node.attr 来说,我们可以添加任意的属性。在上面的我们已经使用 hot / warm 来标识我们的 my_temp 属性。其实我们也可以同时定义一些能标识硬件的属性 my_server,这个属性值可以为 small,medium及 large。有多个属性组成的集群就像是如下的结构:
那么这样的集群里的每个 node 可能具有不同的属性。我们可以通过如下的方法来分配 index 到同时具有两个或以上属性的 node 里:
PUT my_index1
{
"settings": {
"number_of_shards": 2,
"number_of_replicas": 1,
"index.routing.allocation.include.my_server": "medium",
"index.routing.allocation.require.my_temp": "hot"
}
}
如上所示,我们把我们的 my_index1 分配到这么一个 node:这个 node 必须具有 hot 属性,同时也具有 medium 的属性。针对我们上面显示的图片,只有 node1 满足我们的要求。
总结
在今天的这篇文章中,我们介绍了如何使用 shard filtering 来控制我们的 index 的分配。在实际的操作中,可能大家会觉得麻烦一点,因为这个需要我们自己来管理这个。这个技术可以和我之前的文章“ Elasticsearch: rollover API ”一起配合使用。Elasticsearch 实际已经帮我做好了。在接下来的文章里,我会来介绍如何使用 Index life cycle policy 来自动管理我们的 Index。
声明:本文由原文作者“ Elastic 中国社区布道师——刘晓国”授权转载,对未经许可擅自使用者,保留追究其法律责任的权利。
出处链接:https://elasticstack.blog.csdn.net/.
【阿里云Elastic Stack】100%兼容开源ES,独有9大能力,提供免费 X-pack服务(单节点价值$6000)
相关活动
更多折扣活动,请访问阿里云 Elasticsearch 官网
阿里云 Elasticsearch 商业通用版,1核2G ,SSD 20G首月免费
阿里云 Logstash 2核4G首月免费