📚 课程目录第3章集群部署与配置验收

3. 集群部署与配置验收

集群部署验收不是“装完能启动”就算通过，而是要把节点角色、关键配置、安全认证、跨集群连通性、自动化与漂移五条线同时对齐。任何一条线偏离设计基线，都可能在扩容、故障切换或版本升级时集中暴露。本节按“先看角色拓扑，再逐项核查配置，最后用自动化与漂移检查固化结果”的顺序展开。

一、节点角色规划：先定拓扑，再谈参数

Elasticsearch 集群的节点角色决定了数据分布、选举行为和故障域。验收时首先要确认每个节点的 node.roles 与规划一致。常见角色包括：master（参与选举与集群状态管理）、data（存储分片）、data_content/data_hot/data_warm（分层数据）、ingest（预处理管道）、ml（机器学习）、remote_cluster_client（跨集群客户端）、transform、voting_only（仅投票主节点）。

一个可验收的规划示例（示例参数，非实测）：3 个专用 master 节点（其中 1 个 voting_only 以打破偶数票僵局）、6 个 hot 数据节点、3 个 warm 数据节点、2 个 ingest 节点、2 个协调节点（node.roles: []）。验收动作是逐节点执行：

GET _cat/nodes?v&h=ip,name,node.role,master,heap.percent,disk.used_percent
GET _nodes/stats/process?filter_path=nodes.*.process.open_file_descriptors

判断依据：node.role 列中 m 只出现在 3 台 master 上，d 出现在数据节点上，协调节点角色列为空；master 列有且仅有一个 *。若发现数据节点同时承担 master 角色，或 master 节点上出现分片，即判定为角色漂移，必须整改后重新验收。

二、关键配置项核查：从 JVM 到分片分配

关键配置核查要覆盖“能启动、能稳定、能恢复”三类。建议按以下清单逐项比对，而不是只看 elasticsearch.yml 是否存在：

JVM 堆：jvm.options 中 -Xms 与 -Xmx 相等，且不超过物理内存的 50%，单节点不超过 31GB（压缩指针阈值）。
路径与磁盘：path.data 指向独立数据盘，path.logs 独立；数据盘使用率告警阈值建议 85%（低水位）/90%（高水位）。
发现与选举：discovery.seed_hosts 列出全部 master 候选地址，cluster.initial_master_nodes 仅在首次引导时使用，引导完成后必须移除。
分片分配：cluster.routing.allocation.awareness.attributes 按机架/可用区设置，避免同一分片的主副本落在同一故障域。
线程池与队列：写入节点关注 write 队列，查询节点关注 search 队列，拒绝数应长期为 0。

核查命令示例：

GET _cluster/settings?include_defaults=true&flat_settings=true
GET _nodes/settings?filter_path=nodes.*.settings.path,nodes.*.settings.node
GET _cat/allocation?v

判断依据：_cat/allocation 中每个数据节点的 shards 数量偏差不超过 ±20%，disk.percent 低于高水位；_cluster/settings 中不应出现临时手工设置的 cluster.routing.allocation.enable: none 残留。

三、安全与认证配置：传输层、用户与权限

安全验收的核心是“传输加密 + 身份认证 + 授权最小化”。生产集群必须开启 xpack.security.enabled: true，并配置 TLS：

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: elastic-http.p12

验收时用 GET _ssl/certificates 确认证书链完整、有效期大于 90 天；用 GET _security/_authenticate 确认当前用户身份与角色。授权方面，检查是否为业务账号分配了专用角色而非直接使用 superuser，索引级权限是否限定到具体索引模式（如 logs-app-*），并确认 kibana_system、beats_system 等内置账号密码已轮换。若使用 API Key，需核对 expiration 与 role_descriptors 是否与调用方匹配。

四、跨集群与远程集群配置

跨集群搜索（CCS）和跨集群复制（CCR）依赖 remote_cluster_client 角色与远程集群连接配置。验收要点：本地集群每个协调/数据节点具备 remote_cluster_client 角色；远程连接使用 cluster.remote.<alias>.seeds 或 proxy 模式，并配置 skip_unavailable: true 以避免远程集群故障拖垮本地查询。

PUT _cluster/settings
{
  "persistent": {
    "cluster.remote.cluster_b.seeds": ["10.0.2.11:9300","10.0.2.12:9300"],
    "cluster.remote.cluster_b.skip_unavailable": true
  }
}

验证命令：GET _remote/info 应返回 connected: true；执行 GET cluster_b:logs-app-*/_search?size=0 确认跨集群查询可返回结果。CCR 场景还需检查 GET _ccr/stats 中 follower 的 read_exceptions 为 0，且 leader 索引的 soft delete 已开启。

五、部署自动化与配置漂移检查

验收的最后一步是把“人工确认”变成“可重复校验”。推荐用 Ansible/Terraform 声明节点角色与配置，用 Elasticsearch 的 _nodes/settings 与基线文件做差异比对。漂移检查可写成脚本：拉取所有节点的 node.roles、path.data、JVM 参数、TLS 开关，与 Git 中的基线 YAML 逐字段比较，输出差异清单。

漂移检查建议纳入 CI：每次变更后自动运行，差异项分为“阻断级”（角色错误、安全关闭、初始主节点残留）和“告警级”（堆大小偏差、线程池队列微调）。阻断级必须回滚或修复后才能进入下一阶段验收。

六、把验收结果固化为可执行清单

为了让验收可复现，建议把上述五条线整理成一份可填写的检查表，每条记录“检查项、命令/证据、期望值、实际值、结论”。例如：

检查项	证据来源	期望值	结论
master 角色数量	`_cat/nodes?v`	3 台，且仅 1 台为当前 master	通过/不通过
JVM 堆	`_nodes/stats/jvm`	Xms=Xmx，≤31GB	通过/不通过
传输层 TLS	`_ssl/certificates`	启用且证书有效期 > 90 天	通过/不通过
远程集群连通	`_remote/info`	connected: true	通过/不通过
配置漂移	基线比对脚本	阻断级差异为 0	通过/不通过

验收结论应明确区分“阻断级”和“告警级”：角色错误、安全关闭、初始主节点残留、远程连接不可用属于阻断级，必须修复后重新验收；堆大小微调、线程池队列参数偏差属于告警级，可记录并限期整改。只有五条线全部达到阻断级通过，集群才具备进入下一阶段（如索引模板与生命周期策略验收）的条件。