摘要

  • Red Hat 的 RHEL 指南把系统间主动的同步或异步数据卷复制计入热备，热备需要付费订阅。没有正常客户流量，仍可能已经跨过采购边界。
  • 自主管理 OpenShift 的规则更细：外部存储设备执行复制仍可属于温备，临时维护测试与运行工作负载也分开处理。购买恢复能力，要沿实际数据和工作负载路径算账。

一台备机没有接过客户，不妨碍它成为订阅预算里的常客。2026 年 7 月 21 日版 Red Hat Enterprise Linux 订阅指南，把主动同步或异步复制数据卷的系统计入热备。采购若只问“这台服务器有没有对外服务”，问题已经问窄了。

这里的商品是提前准备好的接管能力。数据在主系统仍工作时不断到达另一端，备端就承担了一部分随时接班的工作。企业希望出事后少做恢复动作，供应商则给这种准备程度划出付费范围。业务没有正式切过去，商业边界可以先到。

“温”字里还有恢复工作

RHEL 指南规定，灾备环境中的热备需要付费订阅。热备完整运行，与生产系统并行，准备在主环境出问题时立即接收流量。温备已经准备好承载近似原系统的工作负载，但不含原系统的客户工作负载，也不应进行主动数据卷复制；恢复时，要从源系统外部把客户数据还原到已有硬件。冷备则尚未具备恢复服务所需的全部技术条件。

这些区别把一笔长期预算和一组事故发生后的动作连在一起。温备、冷备在灾难发生时可转移主环境订阅来恢复服务。转移的是订阅资格；数据还原、应用启动和业务恢复，仍各有自己的工序。采购表里少一份平时的灾备订阅，操作手册里可能多一段必须完成的路。

因此，比较两种设计时，应该把“少付什么”和“稍后要做什么”摆在一起。订阅节省本身可以很真实，恢复工作也很真实。让其中一项躲进另一个部门的表格，才会做出廉价的假象。

同一家厂商，复制规则也不能串用

2026 年 1 月 23 日版自主管理 OpenShift 订阅指南，同样把热备列为需要付费的灾备环境，却进一步区分复制在哪里发生。

OpenShift 托管的软件定义存储在集群间主动同步或异步复制，进入指南的热备定义。温备规则还涉及备端把复制数据挂载到正在运行的容器工作负载。外部存储设备执行卷复制，在这份 OpenShift 指南下仍属于温备。使用 OpenShift 托管的软件定义存储做温备恢复，则要从集群外把客户数据恢复到已有集群硬件。

这一处差别足以让报价讨论从“买几台备机”变成“复制工作由哪一层承担”。同一个恢复目标，可以涉及平台内存储、外部阵列、挂载方式和启动顺序。它们的成本归属也不同。供应商的产品名称可以共用一顶红帽子，订阅定义没有因此合并成一条。

把 OpenShift 的外部存储规定直接套进 RHEL，会把产品范围抹掉；看见“主动复制”便把所有产品和存储方案都归入同一个付费类别，也会丢掉指南保留的差别。采购需要看到实际路径，而不是抽象的冷热标签。

睡着的集群，也未必退出账本

OpenShift 指南还堵住了一个看似诱人的捷径：休眠本身不会自动带来灾备例外。未专门配置、设计为温备或冷备的集群，例如需求下降后暂时休眠的云集群，仍需订阅。

真正的温备、冷备被唤醒来运行工作负载时，需要订阅；临时唤醒做例行维护或测试，则不需要为 Red Hat OpenShift 软件产品中的组件另加订阅。这一区分给演练留出了空间，也要求采购知道一次唤醒究竟在做什么。

测试让恢复方案有机会在事故前暴露问题。把演练省掉，只为把备端维持在一个漂亮的静止状态，等于把未知工作积攒到最差的一天。反过来，工作负载已经运行，再把它叫作测试，也不能替代指南中的用途区别。

缺的是买方实际的存储与工作负载路径、恢复实测时间及适用报价；三者到齐，才能判断哪种设计更合算。

对采购最有用的计量单位，是业务能接受的恢复过程。热备准备程度、温备还原步骤、外部存储费用、人员工作和其他依赖，要放在同一个选择里。关掉保护来压低订阅金额，会把一张小账单换成另一种业务赌注。

备机有没有客户，是流量问题。恢复要做多少事，是运营问题。哪些能力进入付费范围，是产品和采购问题。三者若由三张互不见面的表管理，“备用”就会变成全公司最忙的形容词。

来源