跨集群操作

https://developer.aliyun.com/topic/elasticstack/playbook

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的连接方式是代理模式使用的代理地址proxy_address是"127.0.0.1:9302"。其中网络传输的压缩参数（compression）和tcp访问频率（ping_schedule）是可以动态调整的但必须要包括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进行跨集群搜索。

• 在cluster1 中插入数据

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

• 在cluster2 中插入数据

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

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

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

• 分别在两个集群上动态配置remote cluster。注意这里的cluster_one、cluster_two仅仅是别名，用来区别不同的集群。在seeds列表中填写的是集群节点间通信的TCP端口而不是HTTP端口。

• 执行跨集群搜索

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

跨集群复制

跨集群索引复制需要使用到Elastic官方的白金认证，你可以在官网申请试用，官方会很快的回复邮件。根据不同版本的ES集群下载json文件然后导入到集群即可。
跨集群复制是将特定索引从一个 ElasticSearch 集群复制到另外的集群。一般用于以下场景：

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

跨集群复制使用主动-被动模型：我们将索引写入领导者索引，数据会被复制到一个或多个只读跟随者索引。在将跟随者索引添加到集群之前，我们需要配置包含领导者索引的远程集群。
当领导者索引有写入请求时，跟随者索引从远程集群上的领导者索引中拉取增量数据。我们可以手动创建跟随者索引或配置自动跟随模式（auto-follow patterns）创建跟随者索引。

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

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

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

快速入门

我们在服务器上启动两个集群来模拟不同地区数据中心的集群：
“cluster1”：在端口 9200 上运行。我们会将文档从cluster1复制到cluster2。
“cluster2”：在端口 9400 上运行。cluster2将维护一个来自cluster1的复制索引。

• 配置远程集群

我们选择CCR的单向配置，CCR 是基于拉取模式的所以我们只需要确保cluster2连接到cluster1，不需要指定从“cluster2”到“cluster1”的连接。
下面让我们通过cluster2上的 API 调用来定义cluster1:

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 /products-copy/_search

![在这里插入图片描述](https://img-blog.csdnimg.cn/20210510153742414.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2R0emx5,size_16,color_FFFFFF,t_70)


   



CCR属于Elastic官方的白金付费（platinum license）的功能，一般企业还是会选择自研数据同步工具来同步集群间的数据。不过，需要体验的小伙伴可以在Elastic官网申请30天免费的使用。