容量规划与硬件管理

• BMC 独立于主机的带外管理能力
• IPMI 通道、SNMP 传感器、SEL 日志
• BMC 网络隔离与账号安全

BMC（基板管理控制器）是独立于 CPU 的带外管理芯片，即使主机宕机也能通过 IPMI/网络管理。IPMI 通道（LAN 通道）用于带外访问，可远程开关机、查看控制台、读取传感器。SEL（System Event Log）记录硬件事件日志（温度、风扇、电源、内存/磁盘错误），传感器通过 SNMP/IPMI 采集。运维要点：BMC 网络必须与业务网络隔离（独立管理网段），限制访问来源，禁用默认口令、启用强认证与加密，及时更新 BMC 固件修复漏洞。厂商差异：Dell iDRAC、HP iLO、Lenovo 及国产 BMC（如海光、飞腾平台）功能类似但 API/命令行/Web 界面不同，需适配各厂商的监控与管理的接口（如 racadm、conrep、ipmitool）。

BMC 是硬件运维的带外通道，核心是"独立管理能力 + 传感器/SEL 采集 + 网络与账号安全"，跨厂商需适配不同管理接口。

• RAID 6 双校验的读-改-写开销
• RAID 10 镜像无校验开销
• 容量与冗余代数

RAID 6 双校验，写密集时每次写需读-改-写两块校验数据，写放大与 CPU/IO 开销大，写性能显著低于 RAID 10；但可用容量高（N-2），可坏 2 块盘，适合大容量、读多写少数据。RAID 10 镜像+条带，无校验计算，写性能稳定、接近理论，故障重建快（只重建镜像盘），适合写密集、对性能敏感的生产（如数据库）。取舍：写密集与对性能敏感优先 RAID 10（牺牲容量换性能与稳定）；大容量、读多写少、可容忍写性能下降可选 RAID 6。写密集场景 RAID 10 是更稳妥选择。

写密集场景关键是"校验读改写开销 vs 镜像直接写"，RAID 10 无校验开销、写性能最优，RAID 6 用容量换冗余但写开销大。

• 重建速率参数（rebuild rate）
• 重建期间对业务 IO 的抢占
• 平衡重建速度与业务可用

RAID 重建（rebuild）是把新盘/热备盘数据恢复的过程，重建速率可调（如 MDADM 的 /proc/sys/dev/raid/speed_limit_min/max，硬件 RAID 卡的 rebuild rate 百分比）。调高重建速率可加速恢复、缩短危险窗口，但会抢占业务 IO；调低则保护业务性能但延长重建时间。控制策略：1) 设定合理的重建速率（如硬件卡 30-50%），兼顾速度与业务；2) 在业务低峰执行/调高重建；3) 使用热备盘（hot spare）自动重建；4) 监控重建进度与磁盘错误，避免重建中二次故障。关键是在"重建越快越好"与"业务不能受影响"间平衡。

rebuild 是"速度 vs 业务影响"的权衡，通过速率参数与热备盘、错峰重建控制，目标是缩短危险窗口又不拖垮业务。

• OP 预留的 NAND 空间
• OP 对 GC 与写放大的作用
• 用户 OP 与厂商 OP 的配置

SSD over-provisioning 指在 SSD 标称容量之外预留的 NAND 空间（不暴露给用户），用于 GC（垃圾回收）、磨损均衡与坏块替换。OP 空间越大，GC 时搬移数据越从容、磨损均衡越均匀，写放大（WAF）越低，从而延长 SSD 寿命并提升随机写性能。OP 分厂商级 OP（出厂固有）与用户级 OP（可配置，如通过裁剪容量在分区前端预留）。实际寿命延长主要靠降低写放大、减少块擦除次数。对高写入负载（数据库、日志）应用，增大 OP 是提升寿命与性能的常见手段。

OP 的核心价值是"降低写放大、改善磨损均衡"，从而延长寿命；这只是"预留空间换寿命"，需按写入负载配置。

• 十进制（GB/TB）与二进制（GiB/TiB）进制差异
• 厂商用十进制、系统用二进制导致"缩水"
• 容量规划中的换算

GB/TB 是十进制单位（1 GB = 10^9 字节，1 TB = 10^12 字节），GiB/TiB 是二进制单位（1 GiB = 2^30 = 1,073,741,824 字节，1 TiB = 2^40）。磁盘厂商按十进制标注（如 1TB 盘 = 10^12 字节），操作系统按二进制显示（如显示 931 GiB），于是"1TB 盘"在系统里显示约 931 GiB，造成"缩水"误解。容量规划与对比时需统一单位，避免换算错误导致容量评估偏差。精确计算用二进制，营销/采购用十进制。

核心是"厂商十进 vs 系统二进"的换算差异，规划容量必须统一单位，否则会低估实际可用空间。

• 业务峰值 vs 平均用量
• 历史趋势与增长率外推
• 冗余要求（N+1、RAID、告警余量）

容量规划需综合多维度：1) 业务峰值预测：以峰值（而非平均）为基准，考虑业务波峰、促销/大促等，避免峰值时资源不足；2) 历史趋势：基于历史用量曲线（CPU/内存/存储/带宽）分析增长趋势；3) 增长率：结合业务增长预期外推未来需求（如未来 2 年），并留出缓冲；4) 冗余要求：考虑冗余（RAID 损失、N+1 节点、热备）、告警阈值余量（如 80% 告警、预留 20% 缓冲）与牺牲容量。需求模型 = 峰值展望 × 增长率 × 冗余系数 + 缓冲余量，并定期根据实际数据校正偏差。

容量规划是"峰值+趋势+增长+冗余"的乘法模型，峰值与冗余是安全边界，趋势与增长是时间轴，需动态校正。

• 硬件 RAID 的独立处理器与缓存
• 软件 RAID 的 CPU 占用与灵活性
• 选型依据

硬件 RAID 卡有独立 RAID 处理器与缓存（含电池保护），处理 RAID 计算与校验，不占用主机 CPU，性能好、功能全（如在线扩容、快照），但成本高、需专用硬件、卡故障风险。软件 RAID（如 mdadm、LVM RAID）由主机 CPU 处理校验，无额外硬件成本、灵活可迁移、可跨平台，但占用 CPU、写性能（尤其校验型）一般，故障时依赖主机。选型：性能苛刻、大数据关键系统用硬件 RAID（带缓存）；成本敏感、追求灵活、性能要求一般用软件 RAID。现代 CPU 强，软件 RAID 在中小规模用得很广。

取舍核心是"硬件开销/性能 vs 成本/灵活性"，硬件 RAID 用成本换性能与功能，软件 RAID 用 CPU 换低成本与灵活。

• 各指标的采集口径（平均值/峰值/95 分位）
• 阈值设定（告警/预警）
• 关联业务场景

容量规划核心指标及采集口径：CPU 利用率（看峰值与核数，阈值如 80% 告警、长期 70% 预警）；内存水位（看可用/提交量，swap 使用为严重信号，阈值 80-90%）；磁盘 IOPS/空间（IOPS 看是否饱和、空间看使用率与增长，阈值 80% 预警、90% 告警）；带宽（看吞吐上限与利用率，延迟/丢包为信号）。采集口径建议用峰值与 95 分位（p95）而非简单平均，避免长尾掩盖；阈值需结合业务 SLA 与冗余（如 N+1）确定，并设多级（预警→告警→紧急）。各指标需关联业务场景（如大促峰值、大批量任务）综合判断。

指标口径与阈值是容量规划的关键，用峰值/p95 捕捉真实瓶颈，按业务与冗余设定多级阈值，避免平均掩盖。

• 线性回归预测线性趋势
• 季节性分解处理周期波动
• 业务活动驱动与人工校正

容量趋势预测：1) 线性回归：对历史用量做最小二乘拟合预测线性增长，适合稳定增长场景，但若增长非线性会偏差；2) 季节性分解：将时间序列分解为趋势+季节+残差，识别周期性波动（如日/周/月波峰），预测时结合季节因子提高准确性；3) 业务活动驱动：结合业务上线、促销、翻倍增长等事件调整预测，而非纯历史外推。校正偏差：定期用实际数据对比预测，更新模型参数，对业务事件做人工校正，综合多种方法并保留余量。核心是"预测+反馈校正"，避免纯外推失真。

趋势预测是"线性/季节/业务驱动"的组合，需结合季节与业务事件并用实际数据反馈校正，避免机械外推。

• 预警阈值分级（预警/告警/紧急）
• 扩容审批链（申请→评估→审批→执行）
• 紧急扩容执行清单

容量预警与扩容流程：1) 预警阈值分级：设定多级阈值（如 70% 预警、80% 更高预警、90% 告警、95% 紧急），不同级别触发不同告警与响应；2) 扩容审批链：预警触发后，运维提交扩容申请（含用量分析、需求预测、成本），经技术/业务/财务审批后执行，避免随意扩容；3) 紧急扩容执行清单：紧急时按清单执行（确认可用资源、选择扩容方式[在线/离线]、备份、执行、验证、监控），确保快速安全扩容。流程核心是"分级预警、审批管控、清单化紧急执行"，兼顾及时性与可控性。

容量管理是"分级预警 + 审批 + 紧急清单"的闭环，预警分级保证及时，审批链控制成本，清单保证紧急扩容安全。

• 机架位与单元规划
• 配电容量（U 位、KW/机柜）
• 制冷冗余与容量

数据中心容量规划需考虑三层物理约束：1) 机架位规划：按机柜 U 位、设备尺寸、网络/存储布线规划部署位置，避免超载；2) 配电容量：每机柜配电（如 8-10KW/机柜）决定可部署设备数，需按设备功耗与冗余（N/N+1）计算，避免超载跳闸；3) 制冷冗余：冷却能力（冷量）需匹配设备散热量，冗余设计（N+1 精密空调）保证单台故障不导致过热。容量规划需同时满足机架位、配电与制冷三维约束，任一超限都会限制部署。运维需监控机柜功耗、温度与制冷容量。

数据中心容量是"机架位+配电+制冷"三维约束，三者必须同时满足，是物理容量规划的核心。

• 采购验收标准
• 资产登记与上架
• 运行监控与报废销毁

服务器硬件生命周期闭环：1) 采购验收：进货后按规格验收（型号、序列号、固件、组件齐全）、上电自检，确保符合合同；2) 上架资产登记：登记资产台账（序列号、位置、配置、IP/BMC、维保期），贴资产标签，关联监控系统；3) 运行监控：纳入监控（SMART、温度、BMC、SNMP），记录维保与故障记录，跟踪生命周期；4) 报废数据销毁：退役时按合规销毁数据（擦除/加密/物理销毁），确保数据不泄露，注销资产。闭环管理让硬件从采购到报废全程可追溯、可控、可审计。

生命周期管理是"验收→登记→监控→报废销毁"的闭环，核心是资产可追溯与数据安全，保障合规与运维可控。

• SMART 属性监控
• 温度/功耗传感器
• BMC/IPMI 事件日志接入告警

硬件健康监控项与接入：1) SMART 属性：用 smartctl 采集磁盘健康（重映射扇区、坏扇区、温度），接入监控（如通过 node_exporter 或脚本）并阈值告警；2) 温度/功耗传感器：通过 IPMI/SNMP 采集 CPU、内存、磁盘温度与功耗，超阈值告警；3) BMC 事件日志：通过 IPMI 读取 SEL 事件（电源、风扇、内存错误），或厂商 API（racadm/iLO）拉取，接入告警平台。统一将以上指标写入监控（Prometheus/告警平台），设置分级阈值（预警/告警），实现硬件故障提前发现。核心是"指标采集 + 阈值告警 + 事件联动"。

硬件监控是"SMART+传感器+BMC 事件"多渠道采集，统一接入告警平台，实现故障预判与快速响应。

• SMART 预判故障
• 备件库存管理
• 在线/热插拔更换与业务影响

硬件故障更换流程：1) SMART 预判：通过 SMART 属性与 BMC 事件提前发现劣化磁盘，安排预防性更换，避免突发故障；2) 备件管理：维护备件库存（热备盘、内存、电源等），按故障率与冗余配置备件，确保可及时更换；3) 在线更换：对支持热插拔的组件（磁盘、电源、网卡）在线更换，避免停机；不支持热插拔的（CPU/主板）需安排维护窗口；4) 业务影响控制：更换前评估影响（RAID 重建、冗余损失），错峰执行，必要时迁移负载，监控更换过程与重建进度。核心是"预判+备件+在线+影响控制"。

故障更换是"预判→备件→在线更换→影响控制"的流程，预判与备件减少突发，在线更换减少停机，影响控制保障业务。

• 故障证据收集（日志、SEL、诊断）
• 厂商 SLA 与响应时间
• 备件与更换窗口管理

硬件故障 RMA 流程：1) 故障证据收集：收集故障日志、BMC SEL、诊断输出（smartctl、诊断工具）、序列号，作为向厂商报修的凭证；2) 厂商 SLA：明确厂商保修与 SLA（响应/修复时间、更换流程），按 SLA 提交工单并跟踪，确保在时限内修复；3) 备件库存：结合厂商备件与本地备件，评估是否需临时备件保障；4) 更换窗口：协调更换窗口（在线/维护窗口），与厂商上门时间对齐，更换后验证并记录。RMA 管理核心是"证据充分、SLA 明确、备件与窗口协同"，保障故障及时解决。

RMA 是"证据+ SLA+备件+窗口"的协调，充分证据加快处理，SLA 约束时限，备件与窗口保障业务连续性。

• TCO 计算（采购+运维+能耗+维保）
• 折旧周期与换代
• 换代升级对容量规划的影响

硬件采购生命周期评估：1) TCO 计算：除采购价外，纳入维保、能耗、机房占用、人力运维等全生命周期成本，评估真实总成本；2) 折旧周期：按财务折旧（如 3-5 年）与硬件寿命确定更新时间，评估每周期成本；3) 换代升级：新一代硬件性能/能效提升（如换新 CPU/更大容量盘），影响容量规划——换代时可用更高性能/容量降低台数或满足增长。规划时需结合 TCO 与换代周期，在"继续用旧机vs 换代升级"间权衡，将换代纳入容量增长模型。

采购评估是"TCO+折旧+换代"维度，换代升级会改变容量与性能供给，需纳入容量规划与成本决策。

• 超售比（overcommit ratio）
• 内存/CPU 装箱（packing）
• 虚拟机密度与安全边界

虚拟化容量规划需设定安全边界：1) 超售比：CPU 超售（如 1:2 到 1:4）与内存超售（通常不超售或少量超售，因内存不可压缩）需平衡，超售过高会导致资源争抢；2) 内存/CPU 装箱：把虚拟机按资源需求"装箱"到物理机，考虑 CPU 核数、内存容量、NUMA 与 IO 带宽，避免某个节点过载；3) 虚拟机密度：每物理机承载的虚拟机数需留余量（如 70-80% 资源利用率），考虑 HA 故障时相邻节点能否承接（N+1），避免单点过载。安全边界 = 资源利用率上限 + N+1 冗余 + 超售比控制，并定期监控实际使用校正。

虚拟化容量是"超售比+装箱+密度"的平衡，用资源利用率上限与 N+1 冗余定义安全边界，避免过载与故障连锁。