跨集群操作—Elastic Stack 实战手册

· 更多精彩内容，请下载阅读全本《Elastic Stack实战手册》

· 加入创作人行列，一起交流碰撞，参与技术圈年度盛事吧

创作人：张刘毅
审稿人：吴斌

Elasticsearch 集群天然支持横向水平扩展，因此当业务规模扩大、对集群产生读写压力时，增加节点总是运维人员的“懒人选择”。但随着节点数增多，集群主节点要维护的 meta 信息也随之增多，这会导致集群更新压力增大，甚至无法提供正常服务。 另外每个企业的数据中心都需要有灾备方案，在集群间同步数据，因为单点集群会存在隐患。

鉴于此，Elastic官方提供了跨集群操作。主要包括：

（1）跨集群搜索（CCS）：允许配置多个远程集群并且在所有已配置的集群中实现联合搜索。

（2）跨集群复制（CCR）：允许跨多个集群复制索引，适合于做灾备方案和数据本地化场景。

跨集群配置

跨集群操作有两种配置模式连接远程的集群：嗅探模式（Sniff mode）或者代理模式（Proxy mode）。

• 在嗅探模式下，我们使用集群名称和种子节点列表注册远程集群。注册后，集群状态将被种子节点获取，该模式要求本地群集可以访问网关节点的发布地址。
• 在代理模式下，使用集群名称和单个代理地址注册远程集群。代理模式不需要远程集群节点具有可访问的发布地址。

我们可以在 Kibana 上动态配置远程集群，也可以在各个节点的 elasticsearch.yml 文件的上配置。

动态配置远程集群

我们在 Kibana 上使用 cluster update settings API 为每个节点动态配置远程集群。

例如：

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_one": {
          "seeds": [
            "127.0.0.1:9300"
          ],
          "transport.ping_schedule": "30s"
        },
        "cluster_two": {
          "mode": "sniff",
          "seeds": [
            "127.0.0.1:9301"
          ],
          "transport.compress": true,
          "skip_unavailable": true
        },
        "cluster_three": {
          "mode": "proxy",
          "proxy_address": "127.0.0.1:9302"
        }
      }
    }
  }
}

上面的配置中，当前集群是 cluster_one，一起联合远程访问的集群 cluster_two、cluster_three。其中 cluster_two 的连接方式是嗅探模式，cluster_three 的连接方式是代理模式，代理地址是 "127.0.0.1:9302"。

其中：

• transport.compress：网络传输的压缩参数
• transport.ping_schedule ：集群内部通信（tcp）的访问频率
• skip_unavailable：默认情况下如果请求中的任何集群都不可用则会返回错误。如果跳过不可用的集群，可以将 skip_unavailable 设置为 true。

以上这些参数是可以动态调整的，但必须要包括 seed 列表或者代理地址。

我们如果想关闭压缩、将 ping_schedule 由 30s 改成 60s可以通过如下示例方式

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_one": {
          "seeds": [
            "127.0.0.1:9300"
          ],
          "transport.ping_schedule": "60s"
        },
        "cluster_two": {
          "mode": "sniff",
          "seeds": [
            "127.0.0.1:9301"
          ],
          "transport.compress": false
        },
        "cluster_three": {
          "mode": "proxy",
          "proxy_address": "127.0.0.1:9302",
          "transport.compress": true
        }
      }
    }
  }
}

静态配置远程集群

在节点的 elasticsearch.yml 中配置远程连接，只有在 YAML 文件中设置的节点，才能连接到远程集群，并处理远程集群请求。

举例

cluster:
    remote:
        cluster_one: 
            seeds: 127.0.0.1:9300 
            transport.ping_schedule: 30s 
        cluster_two: 
            mode: sniff 
            seeds: 127.0.0.1:9301 
            transport.compress: true 
            skip_unavailable: true 
        cluster_three: 
            mode: proxy 
            proxy_address: 127.0.0.1:9302 

其中，cluster_one，cluster_two 和 cluster_three 是表示与每个集群的连接的集群名称，用于区分本地索引和远程索引。

跨集群搜索

跨集群搜索可以针对一个或多个远程集群，运行单个搜索请求。例如，我们可以使用跨集群搜索，来过滤和分析存储，在不同数据中心的集群中的日志数据。

在5.3.0之前的版本，Elastic 官方提供了 Tribe Node 实现多集群访问的解决方案。

Tribe Node 是以 Client Node 的角色添加到集群中。但是由于不保留集群的 meta 信息，每次重启需要重新加载初始化。因此，在5.3版本中 Elastic 官方提供了 CCS 的功能，允许集群中的任何节点可以联合查询。

快速入门

下面以两个集群的跨集群搜索为例。我们预先启动了两个集群：cluster1、cluster2，当前集群是 cluster1。现在的任务是联合远程访问的集群 cluter2 进行跨集群搜索。

我们分别在两个集群上动态配置 remote cluster。

注意：在 seeds 列表中填写的是集群节点间通信的 TCP 端口而不是 HTTP 端口。

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_one": {
          "seeds": [
            "192.168.2.2:9300"
          ]
        },
        "cluster_two": {
          "seeds": [
            "192.168.2.2:9500"
          ]
        }
      }
    }
  }
}

在 cluster1 中插入数据

PUT esfighttogether/_doc/1
{
  "teamname":"team 10"
}

在 cluster2 中插入数据

 PUT esfighttogether/_doc/1
{
  "teamname":"team 1"
}

PUT esfighttogether/_doc/2
{
  "teamname":"team 7"
}

在两个集群上分别验证数据。因为写入时 Elasticsearch 自带的默认分词器会对数据进行分词，我们通过 team 就可以查询到所有数据。

查询语句如下：

GET esfighttogether/_search
{
  "query": {
    "match": {
      "teamname": "team"
    }
  }
}

执行跨集群搜索

GET cluster_one:esfighttogether,cluster_two:esfighttogether/_search?timeout=5m
{
  "query": {
    "match": {
      "teamname": "team"
    }
  }
}

如上图所示，通过 CCS 查询到 3 条数据：cluster_one 的一条数据 team 10 以及 cluster_two 的两条数据 team 1 和 team 7，和之前写入的数据一致。

跨集群复制

跨集群复制是将特定索引，从一个 Elasticsearch 集群复制到另外的集群。

一般用于以下场景：

• 灾备：数据中心服务中断时，可以继续响应用户的搜索请求，防止用户大的查询影响到写入吞吐
• 数据本地化：将数据复制到更靠近用户的位置以降低搜索延迟

跨集群复制使用主动-被动模型，我们将索引写入领导者索引，数据会被复制到一个或多个只读跟随者索引。在将跟随者索引添加到集群之前，我们需要配置包含领导者索引的远程集群。

当领导者索引有写入请求时，跟随者索引从远程集群上的领导者索引中拉取增量数据。我们可以手动创建跟随者索引，或配置自动跟随模式（auto-follow patterns），创建跟随者索引。

我们可以单向或双向配置 CCR：

• 在单向配置中，一个集群仅包含领导者索引，而另一个集群仅包含跟随者索引。

• 在双向配置中，每个集群都包含领导者索引和跟随者索引

快速入门

我们在服务器上启动两个集群来模拟不同地区数据中心的集群：

• “cluster1”：在端口 9200 上运行。我们会将文档从 cluster1 复制到 cluster2。
• “cluster2”：在端口 9400 上运行。cluster2 将维护一个来自 cluster1 的复制索引。

配置远程集群

我们选择 CCR 的单向配置，因此 CCR 是基于拉取模式，所以我们只需要确保 cluster2 连接到cluster1 ，而不需要指定从 cluster2 到 cluster1 的连接。

下面让我们通过 cluster2 上的 API 调用来定义 cluster1:

PUT /_cluster/settings
{
  "persistent": {
    "cluster": {
      "remote":{
        "cluster1":{
          "seeds":["192.168.2.2:9300"]
        }
      }
    }
  }
}

Kibana 中远程集群管理的 UI，单击左侧导航面板中的 “Management”（齿轮图标），然后点击 “Stack Management” ，导航到 Elasticsearch 部分中的 “Remote Clusters”（远程集群）。

创建要复制的索引

PUT esfightalone
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 0,
      "soft_deletes": {
        "enabled": true
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "keyword"
      }
    }
  }
}

CCR 的 Leader 索引需要使用软删除（soft_deletes），无论何时删除或更新现有文档，都可以将操作历史记录保留在领导者分片上，等重新操作历史记录时，供追随者分片任务使用。

当追随者分片从领导者复制数据时，会在领导者分片上留下标记，这样领导者就知道追随者在历史记录中的所在位置。基于这些标记，领导者分片将会保留这些操作，直到分片历史记录保留到设定时间结束（默认为 12 个小时）。

我们已经为远程集群创建了一个别名，并创建了一个我们要复制的索引，接下来我们启动复制。在 cluster2 上，执行：

 PUT /esfightalone-copy/_ccr/follow
{
  "remote_cluster" : "cluster1",
  "leader_index" : "esfightalone"
}

注意，复制索引是只读的，不能接受写操作。至此，我们已配置了要从一个 Elasticsearch 集群复制到另一个集群的索引。

测试 CCR 复制

我们在 cluster1 上写入数据：

 POST /esfightalone/_doc
  {
    "name" :"team 1"
  }

然后在 cluster2 上查询，验证索引数据是否同步，发现此时数据已实时同步到 cluster2 中了：

   GET /esfightalone-copy/_search

CCR 属于 Elastic 官方的白金付费（Platinum License）的功能。一般企业还是会选择自研数据同步工具，来同步集群间的数据。

不过，需要体验的小伙伴可以在 Elastic 官网或阿里云 Elasticsearch 申请 30 天免费使用或者在自己的本地安装中启用试用功能。

创作人简介：
张刘毅，存储研发工程师，曾经做过 AI 大数据平台研发，负责过 80+ES 集群。目前专
注于生物医药和大数据。
博客： https://blog.csdn.net/dtzly