1. 课程导入与工程视角建立
Elasticsearch 在演示环境里往往表现得很“听话”：单节点、几百万条数据、少量查询，几乎不会出问题。但一旦进入生产环境，问题会立刻变得复杂：节点可能因为磁盘写满而拒绝写入，主分片可能因为网络抖动而频繁重选，一次批量导入可能把集群压到查询超时，一次容量估算失误可能让后续半年的扩容计划全部打乱。本课程要解决的，正是这些真实生产场景中的高可用与容量规划问题。
一、核心问题：高可用与容量规划是一体两面
很多团队把高可用和容量规划当成两件事：高可用交给运维，容量规划交给采购。但在 Elastic 集群中，这两者高度耦合。容量不足会直接引发可用性事故——磁盘水位超过 85% 后，Elasticsearch 会停止向该节点分配新分片；超过 90% 后，甚至可能触发分片迁移失败。反过来，为了“高可用”而过度设置副本数，又会成倍消耗存储和写入资源，让容量提前耗尽。
因此，本课程的第一个工程视角是：高可用不是靠堆副本实现的，容量规划也不是靠拍脑袋估算的。两者都需要基于分片模型、数据增长速率、查询负载和故障域来量化分析。
具体来说，生产环境中的核心问题可以归纳为四类：
- 故障域问题：节点、机架、可用区如何分布，才能保证单点故障不导致数据丢失或服务中断。
- 分片与副本问题：分片数、副本数、分片大小如何设计，才能兼顾写入吞吐、查询并发和恢复速度。
- 容量与水位问题：磁盘、堆内存、CPU、文件描述符分别如何估算和监控，水位线如何设置。
- 变更与恢复问题：扩容、缩容、滚动重启、快照恢复时，如何保证集群始终处于可服务状态。
二、工程目标：从“能跑”到“可预测”
本课程不追求让读者记住一堆参数默认值，而是建立一套可复用的工程判断能力。学完本课程后，你应该能够做到：
- 根据业务数据量、增长速率和保留周期，估算集群所需的热、温、冷存储容量。
- 根据节点规格和故障域，设计主分片数、副本数和分片分配策略。
- 识别集群中的单点故障、脑裂风险、水位风险和恢复瓶颈。
- 在扩容、重启、快照恢复等变更操作前，判断集群是否具备安全执行的条件。
- 用监控指标和日志，定位高可用或容量问题的根因，而不是盲目重启。
这些目标对应一个核心工程原则：让集群行为可预测。可预测意味着你知道在什么负载下集群会变慢，在什么水位下会拒绝写入，在什么故障下会触发重选，以及恢复需要多长时间。
三、真实生产场景概览
为了建立直观感受，先看一个典型的中型日志分析集群场景。假设某业务每天产生约 200 GB 原始日志，保留 30 天，使用 3 个热节点和 3 个温节点，每个节点配置 2 TB SSD。索引设置为 1 个主分片、1 个副本，按天滚动。
这个配置看起来合理，但实际运行中可能出现以下问题：
- 每天 200 GB 原始日志，经过索引和副本后，实际占用可能达到 400～600 GB，30 天保留期需要 12～18 TB 有效容量。
- 如果热节点只有 3 台、每台 2 TB，热层总容量 6 TB，但热层通常只保留最近 7 天数据，约 3～4 TB，看似够用，但水位线 85% 意味着实际可用只有约 5.1 TB，余量并不充裕。
- 如果某天日志量突增到 400 GB，热层可能在几小时内触及水位线，导致写入被拒绝。
- 如果某个热节点宕机，副本分片需要恢复，恢复速度受限于磁盘 IO 和网络带宽，可能持续数小时，期间查询性能明显下降。
这个例子说明：容量规划不是简单的“总量除以单节点容量”，而是要区分热、温、冷层，考虑副本开销、水位线、增长波动和恢复余量。
四、学习路径与工程视角
本课程按照“先建立模型，再设计架构，最后落地运维”的顺序展开。前几章会先讲清楚 Elasticsearch 的分布式模型、分片机制和故障检测原理，因为不理解这些，后面的容量计算和高可用设计就没有依据。中间部分会深入分片规划、副本策略、故障域设计、水位管理和扩容操作。最后部分会覆盖监控告警、快照恢复、滚动升级和典型故障排查。
整个课程贯穿一个工程视角：任何配置和操作，都要先问“故障时会发生什么”和“容量耗尽时会发生什么”。这两个问题，是 Elastic 集群高可用与容量规划的核心。
五、从本章开始建立判断力
本章没有给出具体的配置命令或计算公式，因为那些内容需要建立在理解集群模型的基础上。但本章给出了一个重要的判断框架：任何 Elastic 集群的设计和运维决策，都应该从业务输入出发，经过分层容量分配和分片模型，最终落到风险判断和恢复验证上。