ES v7.5.1如何提升GCP环境下GCS快照仓库的快照恢复速度

你已经完成了基础设施层面瓶颈排查、取消了ES恢复流量限速的基础操作，当前瓶颈集中在ES集群和GCS仓库的并发配置限制，可按照以下方案调整：

核心瓶颈说明 #

你扩容节点后集群总吞吐量保持4.5Gbps不变的表现，符合ES全局恢复并发数限制的特征：ES默认对全集群同时执行的恢复任务做了保守限制，无论集群节点规模多大，超过限制的恢复任务都会排队等待，直接导致整体吞吐量上不去。

可落地优化操作 #

• 调整集群级恢复并发配置
  这是解决当前瓶颈的核心配置，通过API修改集群持久化设置：

  PUT _cluster/settings
  {
    "persistent": {
      "cluster.routing.allocation.cluster_concurrent_recoveries": 60,
      "cluster.routing.allocation.node_initial_primaries_recoveries": 20,
      "cluster.routing.allocation.node_concurrent_recoveries": 12
    }
  }
  

  参数说明：cluster_concurrent_recoveries默认值仅为2，是全集群恢复任务的总并发上限，调整后可同时执行更多恢复任务；另外两个参数分别控制单节点主分片、所有分片的恢复并发上限，匹配你的10~20节点规模设置即可。

• 调整单恢复任务的传输配置
  提升单个恢复任务的GCS下载效率：

  PUT _cluster/settings
  {
    "persistent": {
      "indices.recovery.concurrent_streams": 10,
      "indices.recovery.max_concurrent_file_chunks": 5,
      "indices.recovery.chunk_size": "512mb"
    }
  }
  

  参数说明：这组参数分别控制每个恢复任务的并行下载流数、单文件并发传输块数、单块传输大小，大幅降低小文件传输的请求开销，充分利用GCS的带宽能力。

• 调整GCS快照仓库的并发配置
  更新你已创建的GCS快照仓库配置，放开GCS客户端的并发请求限制：

  PUT _snapshot/你的GCS仓库名称
  {
    "type": "gcs",
    "settings": {
      "bucket": "你的GCS桶名称",
      "chunk_size": "1gb",
      "max_concurrent_operations": 100
    }
  }
  

• 临时优化建议
  恢复期间可临时关闭副本分片分配，优先保证主分片恢复占用全部带宽，主分片恢复完成后再开启副本自动同步：

  // 恢复前执行，仅允许主分片分配
  PUT _cluster/settings
  {
    "persistent": {
      "cluster.routing.allocation.enable": "primaries"
    }
  }
  
  // 主分片恢复完成后执行，恢复全部分片分配
  PUT _cluster/settings
  {
    "persistent": {
      "cluster.routing.allocation.enable": "all"
    }
  }
  

效果预期 #

调整完成后重新触发快照恢复，集群总吞吐量可直接突破4.5Gbps限制，单节点恢复速度可达到300~450MBps，接近磁盘和GCS的性能上限。

内容的提问来源于stack exchange，提问作者Amit