配置基本三节点集群的分步指南

一个三节点Elasticsearch集群是我认为的最小真实集群形态，而非实验室环境。它可以通过多数投票选举主节点，将副本与主分片分离，并在数据和角色配置合理的情况下，能够承受一个节点宕机。但这并非魔法。三台磁盘满载的小型虚拟机并不会仅仅因为数量为三就表现得像一个弹性搜索平台。

本指南采用基本的现代Elasticsearch布局：三个节点，均具备主节点资格和数据能力，位于私有网络地址上。对于小型环境来说，这是一个合理的起点。较大的生产部署通常会分离专用主节点、数据层、摄取节点、机器学习节点和仅协调节点。这里从简单开始，当工作负载证明有必要时再拆分角色。

示例假设使用Linux主机以及包或归档安装。请根据您的环境调整服务命令。

编辑配置之前

您需要三台独立的主机或虚拟机。不要将三个“节点”放在一台笔记本电脑上并称之为高可用。它们可能对测试发现有用，但共享相同的故障域。

每台主机需要：

• 相同的Elasticsearch版本。
• 稳定的私有IP或DNS名称。
• 节点之间默认端口9300的传输连接。
• 如果需要，从管理主机或负载均衡器访问端口9200的HTTP。
• 足够的磁盘空间用于主分片和副本分片。
• 通过NTP或类似服务进行时间同步。
• 在可靠的本地或附加存储上配置的数据路径。

最近的Elasticsearch发行版包含捆绑的JDK。如果您的打包或版本需要外部JDK，请使用该Elasticsearch版本支持的Java版本，而不是猜测。

在discovery.seed_hosts中使用私有地址。除非您有非常特定的设计和强大的网络控制，否则避免使用公共IP。

在本指南中，节点为：

node-1  10.0.10.11
node-2  10.0.10.12
node-3  10.0.10.13

配置通用集群设置

在每个节点上，编辑elasticsearch.yml。文件位置取决于安装方法。包安装通常使用/etc/elasticsearch/elasticsearch.yml；归档安装使用解压目录下的config/elasticsearch.yml。

在所有三个节点上设置相同的集群名称：

cluster.name: my-three-node-cluster

在所有三个节点上设置发现种子主机：

discovery.seed_hosts:
  - 10.0.10.11:9300
  - 10.0.10.12:9300
  - 10.0.10.13:9300

仅首次引导时设置初始主节点：

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

值必须与node.name匹配，而不是IP地址，除非您的节点名称是类似IP的字符串。此设置仅用于形成全新的集群。集群成功形成后，从所有节点中删除cluster.initial_master_nodes，并在未来的重启中保持移除。保留它可能会在灾难恢复或意外重新引导尝试时造成混乱。

绑定到私有接口或安全的主机值：

network.host: 10.0.10.11
http.port: 9200
transport.port: 9300

对每个节点使用其自己的IP作为network.host。0.0.0.0在示例中很方便，但在生产环境中可能会在您不期望的接口上暴露Elasticsearch。如果您的版本启用了安全自动配置，您还需要处理TLS证书、注册和认证。

配置每个节点名称

在节点1上：

node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

在节点2上：

node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

在节点3上：

node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

如果您在一台机器上运行多个节点进行测试，请使用单独的path.data和path.logs值。对于真实集群，每个主机一个节点通常是更清晰的模型。

选择节点角色

对于小型三节点集群，所有三个节点可以承担标准角色：

node.roles: [ master, data, ingest, remote_cluster_client ]

这样您就有三个具备主节点资格的节点，因此主节点选举可以通过多数投票进行。拥有三个具备主节点资格的节点，集群可以丢失一个节点并仍然选举或保持主节点。如果两个节点消失，则无法安全地做出集群状态决策。

对于较大的集群，专用主节点通常更好，因为繁重的数据或摄取工作不会耗尽主节点职责。这是一个扩展优化，不是此基本设置的要求。

检查操作系统和网络基础

在启动Elasticsearch之前，测试每对节点之间的传输连接：

nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300

尽可能从每个节点运行这些命令。防火墙和云安全组必须允许节点到节点的传输流量。HTTP端口9200用于客户端和管理调用；传输端口9300是集群节点之间通信的端口。

还要检查数据和日志目录的文件所有权。Elasticsearch进程必须能够写入两者。

启动节点

对于使用systemd的包安装：

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

对于测试期间的归档安装：

bin/elasticsearch

启动所有三个节点。它们不必按完美顺序启动，但请观察日志。您希望看到集群形成一次，并且节点加入它。如果节点说无法发现主节点，请关注node.name、cluster.name、discovery.seed_hosts、传输连接和TLS/安全设置。

集群形成后，从每个节点的配置中删除cluster.initial_master_nodes，并在计划窗口内稍后重启（如果需要）。在您仍在尝试首次引导时不要删除它。

验证集群健康

从可以访问端口9200的主机：

curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

一个没有用户索引的全新集群可能会显示绿色，分片数为零。需要检查的字段是status、number_of_nodes和number_of_data_nodes。

对于紧凑视图：

curl -s "http://10.0.10.11:9200/_cat/health?v"

然后验证节点成员资格：

curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"

您应该看到所有三个节点。一个节点将具有选举主节点标记。所有三个应显示您期望的角色。

创建带副本的测试索引

创建一个测试索引以确认分片放置：

curl -X PUT "http://10.0.10.11:9200/test-data-index?pretty"   -H 'Content-Type: application/json'   -d '{
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }'

检查分片：

curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"

有三个主分片和一个副本，您应该看到六个分片副本分布在节点上。Elasticsearch将避免将副本放置在其主分片所在的同一节点上。

如果集群是黄色的，请询问原因：

curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty"   -H 'Content-Type: application/json'   -d '{}'

常见原因包括数据节点不足、磁盘水位线、分配禁用或分配感知规则与您的节点属性不匹配。

测试单节点故障行为

在非生产测试中，停止一个节点：

sudo systemctl stop elasticsearch

从另一个节点检查健康：

curl -s "http://10.0.10.12:9200/_cluster/health?pretty"

集群应该仍然有一个主节点，因为三个具备主节点资格的节点中还有两个存活。根据时间、分片重定位和副本放置，健康可能是绿色或黄色，而Elasticsearch正在反应。再次启动节点并观察恢复：

sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"

这个测试值得在集群变得重要之前进行。它教会您正常恢复的样子，这样真实事件就不会那么令人惊讶。

一些生产防护措施

为您的Elasticsearch版本启用并理解安全功能。不要将未经认证的HTTP API暴露给互联网或广泛的内部网络。

在依赖集群之前拍摄快照。副本保护免受节点丢失；快照保护免受删除、损坏和操作错误。

监控磁盘使用率、JVM堆压力、节点数、集群健康、待处理任务和快照成功。一个三节点集群只有在有足够容量恢复时才具有弹性。

保持分片数量适中。许多小分片会产生开销。即使数据量不大，一个基本集群也可能被数千个小索引压垮。

最后，记录引导设置并在形成后删除cluster.initial_master_nodes。大多数三节点设置问题来自小的不匹配：节点名称与引导名称不匹配、传输端口被阻塞、重用旧集群的数据目录或对安全默认值的假设。在更改更奇特的设置之前先检查这些。

当前Elasticsearch版本的安全说明

许多现代Elasticsearch安装会在设置期间启用安全功能。这意味着HTTP调用可能需要HTTPS、CA证书和凭据。如果您的集群自动配置了TLS，健康检查可能看起来更像这样：

curl --cacert /etc/elasticsearch/certs/http_ca.crt \
  -u elastic \
  https://10.0.10.11:9200/_cluster/health?pretty

不要仅仅为了让教程命令工作而禁用安全功能。相反，根据您的证书路径和服务帐户调整示例。对于生产环境，创建具有所需权限的命名用户或API密钥，而不是使用内置超级用户进行日常工作。

传输TLS也会影响节点加入。如果节点无法加入且日志提到证书信任、SAN不匹配、握手失败或远程传输错误，请先检查证书，然后再更改发现设置。一个完美的discovery.seed_hosts列表无法帮助在TLS握手期间互相拒绝的节点。

常见启动失败

如果节点未形成集群，请先检查简单的事情。

cluster.name必须在所有节点上匹配。具有不同集群名称的节点不会仅仅因为出现在种子主机列表中而加入。

node.name必须与首次引导期间cluster.initial_master_nodes中使用的值匹配。如果配置说node-1但引导列表是es-node-1，发现可能会停滞。

传输端口必须在节点之间可达。仅HTTP访问9200是不够的。如果需要，使用nc、安全组检查或数据包捕获。

数据目录不得包含来自旧集群的元数据，除非您打算重新加入该确切集群。重用先前测试的磁盘可能会产生关于集群UUID或不安全引导的令人困惑的错误。

当绑定到非回环地址时，内存和引导检查很重要。Elasticsearch可能会强制执行文件描述符、虚拟内存、内存锁定和发现配置的检查。阅读启动日志，而不是盲目重试。

集群正常工作后

在集群承载重要数据之前创建快照存储库。副本不是备份。错误的删除、映射错误或应用程序错误会迅速复制到每个副本。

在您的运行手册中记录节点名称、IP、角色、数据路径、证书位置和引导历史。在中断期间，没有人想逆向工程node-2是否应该具备主节点资格。

设置节点丢失、红色健康、长时间黄色健康、磁盘水位线、JVM堆压力、快照失败和频繁主节点选举的警报。一个三节点集群为您提供了承受一次故障的空间，但前提是您在第二次故障之前注意到并修复它。

规划容量时要考虑恢复。如果每个节点运行在非常高的磁盘使用率下，丢失一个节点可能会留下太少的空间供副本重建。健康的集群需要备用容量，而不仅仅是今天主分片的足够空间。

滚动重启实践

在需要为包升级进行滚动重启之前进行练习。重启一个节点，等待它重新加入，确认健康和恢复，然后转到下一个节点。不要同时重启所有三个节点，除非您有意进行全集群关闭。

一个简单的序列是：

sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

如果集群有大型分片，考虑是否应在计划重启前调整延迟分配。目标是避免在节点几分钟后回来时进行不必要的副本重建。维护后，验证分配已启用且临时设置已删除。

还要测试客户端行为。应用程序应使用多个Elasticsearch端点或一个移除故障节点的负载均衡器。一个三节点集群只有在客户端能够到达剩余健康节点时才有所帮助。

最后一个习惯有帮助：在配置管理中保留每个节点最终elasticsearch.yml的副本。设置期间进行的手动编辑往往会漂移，而漂移正是使下一个节点替换比必要更困难的原因。