📚 课程目录第3章故障转移基本概念

故障转移基本概念：冗余、高可用、自动故障切换

各位同学，今天我们聊点实在的。故障转移，说白了就是“别让单点坑了你”。很多刚入行的朋友觉得它就是个“备胎”方案，主系统挂了换副的顶上。这么说也对，但太粗略了。

核心就三个词：冗余、高可用、自动切换。这三者不是孤立的，它们是一根链条上的三个环。缺一个，故障转移就是个摆设。

冗余，本质上是“花两份钱，保一份活”。这不是浪费，这是保险。

我在早期的项目中，遇到过核心路由器单电源供电。结果某个雷雨天的下午，那个电源模块就这么没了声音，整栋楼的网络直接瘫了。那是真的“叫天天不应”。从那以后，我设计任何接入层以上的设备，必做冗余。

冗余的核心原则： 消除可用性链条上的任何单点故障。

冗余通常分为几种类型，我习惯用下面这个表格来给团队做培训：

注意： 冗余不是越多越好。我曾见过一个团队，每层设备都做了2倍冗余，结果网络复杂度翻了三倍，故障率反而更高了。冗余设计要遵循“够用就行”原则，别让冗余变成另一种灾难。

高可用，英文叫 High Availability，缩写 HA。它不是一个功能，而是一个指标。衡量的是系统能正常提供服务的时间比例。

你想想看，几个9的可用性背后是什么？是钱，是业务，是客户的信任。

常用的可用性等级表：

我记得有一次跟某金融机构做方案，对方张口就要 99.999%。我直接问：“你们愿意为最后那 0.009% 多花 300% 的预算吗？”

很多时候，大家把高可用理解成了“永远不挂”，这是不可能的。真正的 HA 是故障发生后，服务恢复的速度足够快，快到用户感知不到。或者感知到了，但影响时间在 SLA 允许范围内。

冗余准备好了，可用性目标也定好了。然后呢？
如果故障发生了，你指望运维半夜爬起来手动切换？

这就是自动故障切换的意义。它解决的是“谁来按下切换键”和“什么时候按”的问题。

我建议把自动故障切换拆成三个步骤，这样好理解：

这里面最难的是第二步——仲裁。为什么？

我经历过一个非常尴尬的案例：两个加密网关做主备，主网关因为某个不重要的应用进程假死，导致心跳超时。备机检测到后，立刻接管了业务。但问题是，主网关的加密隧道还活着。结果两个网关同时处理同一份流量，数据包来回乱窜，广播风暴。
这就是典型的“脑裂”问题。切换算法如果只依赖简单的心跳，很容易掉进这个坑。

一点建议： 千万别把切换逻辑写死。一定要加“多因素判断”。比如心跳 + 链路检测 + 外部仲裁节点。我现在的习惯是，对于核心加密网关，必须上第三方的仲裁网络（比如通过一个独立的IP网络做健康检查）。这叫“三权分立”。

好，我讲一下这张SVG图。它是我给团队讲这节课时必用的。你看，从左到右，从冗余出发，通过高可用指标量化目标，最终落实到自动切换这个执行层。
下面那三个框是切换的关键节点。记住这三个节点，你就理解了故障转移的百分之六十。

前面讲的是通用场景。但我们的课程主题是“加密接入”。加密隧道和普通TCP连接不一样。

在加密接入中做故障转移，有两个头疼的点：

会话连续性： 主网关挂了，备网关接管。但客户端的加密会话已经断了。是让客户端重新拨号握手？还是备机无缝继承会话状态？后者技术难度很大，设计不好就退化成“重连”。
密钥同步： 主备之间如果不共享密钥材料，切换后隧道无法解密。很多IPSec实现用预共享密钥还好。如果是基于证书的IKEv2，麻烦就大了。

我自己在做一个跨数据中心加密组网项目时，就遇到了这个问题。主站点的加密网关意外断电，备站点启动后，因为没有同步到动态建立的IKE SA，导致所有远程站点必须重新建立隧道。那段时间，网络中断了整整2分钟，虽然不是很久，但在金融客户那里，2分钟就是灾难。

一个小技巧： 在设计加密网关时，尽量用 状态同步通道。让主备之间通过专属的、高优先级的链路，实时同步会话状态和密钥材料。即使切换，也就像打了个盹，而不是重新投胎。

今天的三个概念，你只要记住一个链条：
冗余提供可能性 → 高可用提供衡量标尺 → 自动切换提供执行保障。

在加密接入里，稍微多了一层：你不仅要做通用故障转移，还得操心会话和密钥。别怕，后面我们会专门讲“无中断故障切换”的技术实现。

嗯，这节课先到这。大家回去想想，你手头的系统，如果切掉一条链路或者一个节点，用户会是什么反应？想到答案，你就知道该怎么做冗余了。