3. 需求分析与容量规划
高可用集群建设失败最常见的原因，不是技术选型错误，而是容量与可用性目标从一开始就没有量化。本节把业务语言翻译成工程参数，形成一份可评审、可采购、可验收的容量规划基线。
一、把业务SLA分解为可测量的工程指标
业务方通常只说“这套系统不能停”。工程上必须把它拆成三层：业务服务时段、允许中断时长、允许数据丢失量。例如某制造企业MES核心库要求“7×24可用，年度计划外停机不超过52分钟，故障切换后数据丢失不超过10秒”。由此可推导：
- 可用性目标 = 1 − 52/(365×24×60) ≈ 99.9901%，即约 99.99%（四个九）。
- RTO（恢复时间目标）≤ 52 分钟为年度累计上限，单次故障切换应控制在 5 分钟内。
- RPO（恢复点目标）≤ 10 秒，决定日志同步方式与存储复制策略。
注意区分“计划内维护窗口”与“计划外中断”。若维护窗口不计入SLA，则需在合同中明确，否则四个九几乎无法达成。可用性等级与年度允许停机时间的关系如下表，可作为与业务方对齐的谈判依据。
| 可用性等级 | 年度允许停机 | 典型场景 |
|---|---|---|
| 99.9%（三个九） | 约 8.76 小时 | 内部办公、非关键报表 |
| 99.95% | 约 4.38 小时 | 一般生产辅助系统 |
| 99.99%（四个九） | 约 52.6 分钟 | MES、ERP 核心库 |
| 99.999%（五个九） | 约 5.26 分钟 | 交易、实时控制 |
二、可用性指标的串联计算
集群整体可用性由各组件串联决定，公式为 A_total = A₁ × A₂ × … × Aₙ。若单台服务器可用性 99.9%、交换机 99.99%、存储 99.95%、数据库软件 99.9%，则串联后约为 99.74%，远低于业务要求的 99.99%。这说明：单靠提高单机可靠性无法达标，必须引入冗余并联。并联冗余的可用性为 A_parallel = 1 − (1 − A)ⁿ。两台 99.9% 的服务器做双机热备，可用性提升至 1 − 0.001² = 99.9999%，但前提是故障切换机制本身可靠、且不存在共享单点（如单台交换机、单路市电）。
三、计算、存储、网络容量估算方法
计算容量：先取业务峰值时段的CPU与内存使用率，再乘以冗余系数。冗余系数不是拍脑袋，它由“单机故障后剩余节点能否承载全部负载”决定。双机热备场景下，单机需能承载 100% 负载，故系数取 1.5～2.0；N+1 集群中系数取 (N+1)/N。示例：某应用峰值需 4.8 核、22.4GB 内存，取系数 1.5，则单节点配置不低于 8 核、34GB，实际选 16 核/64GB 留出增长空间。
存储容量：按“裸容量 = 年数据量 × 增长系数^年数 × RAID系数 × 快照/副本系数”估算。RAID10 系数为 2，RAID5 为 1.2～1.3（含热备盘）。若数据库日志与数据分盘，需分别计算。IOPS 同样要估算：OLTP 场景按每事务 4～8 次随机 IO 计，示例 500 TPS × 6 = 3000 IOPS，SSD 单盘约 5000～8000 IOPS，故至少 2 块 SSD 做 RAID1 并留余量。
网络容量：区分业务流量、存储流量、心跳流量、管理流量。业务峰值 200Mbps，冗余系数 2 得 400Mbps，双万兆绑定可满足。心跳必须独立链路，避免与业务争抢导致误判脑裂。跨站点复制还需按 RPO 反推带宽：若 RPO=10s、每次增量 50MB，则带宽 ≥ 50MB×8/10s = 40Mbps，再乘 1.5 冗余得 60Mbps。
四、冗余系数与TCO初步测算
冗余系数直接决定采购成本。以双机热备为例，硬件成本约为单机的 2.2 倍（含共享存储、双交换机、双电源）。TCO 应覆盖三年：硬件采购、软件许可、机柜电力、维保、人力运维。示例测算（假设值，仅作方法演示）：
项目 单机方案 双机高可用方案
服务器 8万 16万
共享存储 0 12万
交换机/线缆 1万 3万
数据库许可 5万 10万
三年维保(15%) 2.1万 6.15万
电力/机柜(3年) 1.5万 3万
运维人力(3年) 18万 24万
合计 35.6万 74.15万
年停机损失 约120万(按4h) 约1万(按5min)
可见高可用方案初期投入翻倍，但一次 4 小时停机造成的损失即可覆盖差额。TCO 测算的关键是把“停机业务损失”显性化，否则永远算不过只买一台服务器的方案。建议在评审时同时给出“可用性—成本”曲线，让业务方在 99.9% 与 99.99% 之间做知情选择。