1. 课程导入与业务连续性框架

在数据中心里，服务器宕机从来不是一个"是否会发生"的问题，而是一个"何时发生、影响多大、多久恢复"的问题。业务连续性（Business Continuity, BC）讨论的正是这套应对逻辑：当硬件故障、断电、网络中断或人为误操作发生时，业务如何以可接受的速度和可接受的数据损失继续对外服务。故障切换（Failover）则是实现业务连续性的核心手段之一——把工作负载从失效组件转移到备用组件上，让服务重新可用。

要理解这套体系，先要区分两个容易混淆的概念。高可用（High Availability, HA）关注的是系统在正常运行期间尽量减少停机时间，通常用"几个9"来衡量，例如 99.99% 可用性意味着全年停机不超过约 52.6 分钟。容灾（Disaster Recovery, DR）关注的是站点级、机房级的灾难场景，强调在异地重建服务能力。业务连续性是一个更大的框架，它把高可用、容灾、备份恢复、应急预案和人员流程都纳入进来。故障切换既服务于高可用（如双机热备切换），也服务于容灾（如跨站点切换）。

RTO 与 RPO：业务连续性的两个核心指标

衡量一套故障切换方案是否合格，最常用的两个指标是 RTO 和 RPO，它们回答的是两个完全不同的问题。

• RTO（Recovery Time Objective，恢复时间目标）：业务中断后，允许多长时间内恢复服务。它约束的是"停机时长"。RTO = 5 分钟，意味着从故障发生到服务恢复，最多只能花 5 分钟。
• RPO（Recovery Point Objective，恢复点目标）：允许丢失多少时间窗口内的数据。它约束的是"数据损失量"。RPO = 0，意味着不允许丢失任何已确认的数据；RPO = 15 分钟，意味着最多可以回退到 15 分钟前的数据状态。

这两个指标直接决定了技术选型。例如，RPO = 0 通常要求同步复制，代价是写入延迟增加；RPO 允许几分钟，则可以采用异步复制，换取更低的延迟和更远的传输距离。RTO 越短，对检测速度、切换自动化和备用资源就绪程度的要求越高。下面这张图展示了从故障发生到业务恢复的完整时间轴，以及 RTO、RPO 在其中的位置关系。

从图中可以清楚看到：RPO 覆盖的是故障发生点之前的一段数据窗口，它由数据复制策略决定；RTO 覆盖的是从故障发生到服务恢复之间的整段时间，它由检测速度、切换机制和备用资源共同决定。两者在时间轴上并不重叠，但都直接影响业务损失。

Intel Xeon 平台在业务连续性中的角色定位

业务连续性不是纯软件问题。再完善的集群软件，如果底层硬件频繁出错、内存不可靠、I/O 路径没有冗余，故障切换就会频繁触发，甚至切换本身也会失败。Intel Xeon 可扩展处理器平台在业务连续性框架中承担的是"降低故障发生率、缩短故障检测与恢复时间"的基础设施角色，主要体现在几个层面。

第一是可靠性、可用性与可服务性（RAS）能力。Xeon 平台支持机器检查架构（MCA）、内存纠错（ECC）、内存镜像与内存备用、PCIe 高级错误报告（AER）等机制。以内存为例，ECC 可以纠正单比特错误，避免其演变为不可纠正错误导致宕机；内存镜像则把两份数据写到互为镜像的内存区域，当某个内存通道出现不可纠正错误时，系统可以从镜像副本继续运行。这些能力直接降低了非计划停机的概率。

第二是快速故障检测与隔离。Xeon 平台提供的机器检查异常、CMCI 中断、PCIe AER 等信号，可以让操作系统和虚拟化层更快地感知硬件错误，并决定是纠正、隔离还是触发切换。检测越快，RTO 中"检测"这一段就越短。

第三是虚拟化与集群的硬件辅助。Intel VT-x、VT-d 等技术为虚拟机迁移、设备直通和故障隔离提供硬件支撑，使得基于虚拟化的高可用集群（如双机热备、集群共享存储）能够更高效地完成切换。在典型的双节点 Xeon 服务器集群中，一台节点故障后，另一台节点通过心跳检测发现异常，接管虚拟机和存储资源，整个过程可以在分钟级甚至秒级完成。

一个可参考的指标设定示例

在实际项目中，RTO 和 RPO 不是拍脑袋定的，而是从业务影响分析（BIA）推导出来的。下面给出一个示例性的指标设定表，用于说明不同业务等级如何对应不同的技术方案。表中数值为教学示例，实际项目需根据业务调研确定。

以"关键"等级为例，RPO = 0 意味着任何已提交的事务都不能丢，因此存储层必须采用同步复制，主节点写入必须等备用节点确认后才返回成功。这会带来额外的写入延迟，通常增加 0.5～2 毫秒（取决于网络和存储配置，此处为示例量级）。RTO ≤ 5 分钟则要求心跳检测间隔足够短、切换脚本足够自动化，并且备用节点处于热备状态而非冷备状态。

本课程的学习路径