灾备中心建设案例

只看该作者 · 发表于 2026-10-9 17:41

零信任实施案例分享：xx基金灾备机房分布式集群如何把「冗余」做实

两个方案都能保障冗余，区别在于「在哪一层做冗余」

实施案例分享 · 同城双活 · aTrust 分布式集群· 2026-10

大家好，今天分享一个刚交付完的零信任实施案例。

项目本身不算大——就是给一家基金公司（下称 xx基金）做零信任改造。但过程中有两个点让我觉得值得写出来：一是客户明确要求「两个机房任何一个挂了业务都不能断」，二是在同一套分布式集群能力下，我们其实有两种都能实现冗余的组网方案，最后跟客户一起把两种方案都推演了一遍才定稿。

把过程和踩到的坑整理出来，希望对同样在做双机房零信任的同行有点参考。

一、项目背景

先交代一下项目所处的环境，这部分决定了后面方案的边界条件。

（一）客户现状

xx基金是持牌公募基金公司，办公与生产分布在同城两个数据中心（下称 A 机房、B 机房），两地之间已具备专线互通条件。业务访问上，两个机房各自有独立的互联网出口：

机房	互联网出口	出口设备	内部结构
A 机房	电信线路 1 、电信线路 2	出口设备	核心交换机 → 内网防火墙 / 业务交换机 / DMZ 业务
B 机房	联通线路、移动线路	出口设备	核心交换机 → 内网防火墙 / 业务交换机 / DMZ 业务

两个机房都承载业务，用户从互联网就近接入，访问各自需要访问的业务资源。

（二）核心诉求

客户这次要解决的问题，归纳起来是三条：

1. 缩小暴露面：业务不再直接对公网发布，改为通过零信任代理网关收敛访问入口。

2. 身份与权限最小化：按人、按终端、按资源做访问控制，取消传统的「网络可达即可访问」。

3. 双机房冗余：这是本次最硬的指标——任何一个机房的出口线路或代理节点故障，业务访问都不能中断，用户最好连重新登录都不需要。

其中第 3 条是项目的胜负手，也是后面两套方案分歧的根源。

二、客户基础网络环境

在动手前，先把客户的基础网络摸了一遍，几个关键前提是后面方案成立的基础：

· 两个机房均已部署防火墙、核心交换机，互联网出口各自独立，A 机房走电信双线，B 机房走联通 + 移动。

· 两机房之间已通专线，这条专线在整个方案里承担三个角色：分布式集群的数据同步、代理网关与控制中心的纳管互通、以及方案一下跨机房的业务流量转发。

· 用户侧网络环境不统一：A 机房侧用户以电信接入为主，B 机房侧用户联通、移动混杂，因此出口线路的质量差异是常态，不是例外。

· 控制器与代理网关需要对外发布统一接入地址，用户不感知后端有几个节点、分别在哪。

提示：专线带宽是被低估的约束。方案一里跨机房调度会占用专线，容量和质量必须提前跟客户对齐，否则冗余做成了，性能反而下来了。

三、方案设计

下面按「总体思路 → 控制器分布式 → 两个可选方案」的顺序展开。

（一）总体思路

我们没有采用「两台设备堆在一起做主备」的传统做法，而是用了 aTrust 分布式集群的形态，把两个机房的控制器和代理网关做成同城双活。整体依赖三个机制：

· 智能 DNS 就近接入：客户端访问统一的控制器域名，由智能 DNS 根据客户端归属地、后端地址健康状态、负载状态解析出最合适的后端地址。

· 数据同步：所有分支单元与中心持续同步持久化数据（用户、资源、授信终端等），保证任何一个节点都有完整的鉴权依据。

· 智能选路：客户端自动探测各线路网络质量，选择用户侧质量最好的线路接入。

一次完整的访问链路，可以拆成 7 步：

步骤	动作	说明
1	用户认证	客户端或浏览器访问控制器统一域名
2	解析至就近控制器单元	智能 DNS 按归属地、健康状态、负载状态返回合适地址
3	数据同步	分支单元与中心持续同步用户、资源、授信终端等持久化数据
4	资源访问	客户端发起资源访问请求
5	资源鉴权	代理网关向用户登录的控制器发起资源鉴权请求
6	资源配置同步	代理网关实时从中心控制器同步资源等配置
7	代理访问资源	代理网关代理访问后端资源

（二）控制器分布式：谁在同步，谁在承载

分布式集群里的控制器分两类角色，理解这两者才能理解容灾边界：

· 中心单元：分布式集群的主要控制节点，负责向其他单元做数据同步，同时自己也承载业务。管理员在中心节点改配置，数据先写中心节点，再由中心节点通过集群间的数据同步端口实时同步到分支节点。

· 分支单元：分布式集群的接入节点，主要承载业务。

有一点必须提前跟客户讲清楚，否则上线后一定会被质疑：

分布式集群的会话不会在节点之间同步。好处是用户在多节点之间切换不用重新登录——比如用户在电信机房登录后一直没注销，去联动机房办事可以直接接着用。但如果是用户当前登录的那个节点的机房整体故障（比如停电），会话是保不住的，用户需要重新登录。

这是分布式架构的固有限制，不是配置问题。提前说明白，验收时就不会变成争议点。

（三）方案一：统一逻辑区域 + 智能选路保冗余

方案一的核心思路是：把两个机房的代理网关划分到一个统一的逻辑节点区域，让它们变成「一个资源池」里的节点。

· 两个机房的控制器和代理网关都纳入同一个分布式集群；

· 代理网关通过专线加入控制中心并同步日志；

· 对外只发布一套资源，发布资源时不需要区分机房归属；

· 冗余由智能选路 + 时延机制来保障：客户端持续探测各条线路的时延，一旦当前线路恶化或网关故障，自动切换到剩余线路中最优的一条。图 1 xx基金双机房零信任组网（方案一）：两机房代理网关纳入同一逻辑区域

这个方案的特点非常明显——对管理员最友好：

· 资源配置只需维护一份，两个机房配置一致性好，不用考虑「这条资源属于哪个机房」；

· 双机房代理网关纳入同一资源池后，可以峰谷互补，避免单机房资源闲置；

· 单机房出口或代理节点故障时，对端机房节点可以接管流量，容灾能力最强。

代价在于业务流量：跨机房调度会导致流量跨机房转发，增加专线带宽开销与时延，需要持续关注专线容量与质量。

（四）方案二：本地代理网关 HA 冗余

方案二换了个思路：不做跨机房的资源池，而是在每个机房内部把代理网关做成冗余。

· 每个机房内部署两台代理网关，做本地 HA；

· 代理网关同样通过专线加入控制中心并同步日志；

· 冗余由本地集群保障，机房内任一代理网关故障，由同机房另一台接管；

· 对外资源按机房归属分别发布，用户就近访问本机房网关。
图 2 xx基金双机房零信任组网（方案二）：每机房内代理网关本地 HA 冗余

这个方案的特点是发布资源更清晰：

· 流量边界清楚，代理网关只在本地机房做转发，业务流量不用过专线，因此不需要担心专线容量和质量；

· 资源配置维度清晰，一条资源对应一个区域，出了问题定位范围小。

代价在于运维与容灾边界：

· 资源配置需要区分机房归属，单个资源仅允许匹配单个区域，配置量翻倍且容易写错；

· 本地集群的性能约为单台的 1.6 倍，利用率不如统一资源池，容易出现机房资源闲置；

· 容灾能力依赖本地集群——如果本地集群整体故障，该机房业务会中断，对端机房接不住。

四、两套方案对比

把差异摊开成一张表，客户当场就做出了判断：

对比维度	方案一：统一逻辑区域	方案二：本地代理网关 HA
冗余实现方式	两机房纳入同一逻辑区域，靠智能选路 + 时延机制切换	每机房内代理网关本地集群，靠本地 HA 接管
容灾能力	单机房出口或代理节点故障时，对端机房节点可接管流量	依赖本地集群，本地集群整体故障将导致该机房业务中断
资源利用率	双机房代理网关纳入同一资源池，峰谷互补，避免资源闲置	本地集群性能约为单台的 1.6 倍，易出现机房资源闲置
日常运维	资源配置无需区分机房归属，配置一致性好	资源配置需区分机房归属，单个资源仅允许匹配单个区域
业务流量	跨机房调度可能导致流量跨机房转发，增加专线带宽开销与时延	代理网关仅在本地机房做流量转发，无需关注专线容量与质量
资源发布体验	发布资源方便，一套配置全局生效	发布资源清晰，边界明确，便于定位

两套方案都能保障冗余，差别在于「在哪一层做冗余」：方案一把冗余做在区域层，方案二把冗余做在网关层。

五、关键机制说明

支撑上面两个方案跑通的，是三套底层机制，这里单独展开讲。

（一）智能 DNS 与健康检查

智能 DNS 是「整体冗余」的入口，它的判断依据不只是归属地，还包括后端地址的健康状态。配置了健康检查后，故障切换是自动完成的：

1. 中心节点故障；

2. 健康检查失败；

3. 将中心节点后端地址从可用 IP 列表中删除；

4. 分支节点正常工作，业务不受影响。

可选的健康检查方式有三种，实际项目里建议按业务敏感度组合使用：

检查方式	监控内容	异常处理
TCP 健康检查	IP 地址的网络可达性、端口可用性、延时等指标	异常时自动屏蔽该 IP ，恢复正常时自动取消屏蔽
Ping 健康检查	对地址池内每个 IP 分别监控，获取地址上应用服务的运行状态	异常时自动屏蔽，恢复时自动取消屏蔽
HTTP(S) 健康检查	以 http(s) 协议监控目标 IP ，监控 web 服务网络可达性、服务可用性、首包延迟等	异常时自动屏蔽，恢复时自动取消屏蔽

中心节点故障后会发生什么，也需要提前跟客户说明：

现象	影响说明
分支节点不会自动升级为中心节点	需管理员手动切换
数据同步中断	中心节点恢复后自动继续同步
中心节点上在线的用户	需重新登录，依赖智能 DNS 解析到其他节点完成认证
其他分支节点	无影响，可正常承载业务

（二）网关智能选路与线路切换

方案一的冗余最终落在「选路」上。客户端内部有三个模块协同：线路探测模块、线路选择模块、隧道连接模块。

完整过程是：客户端登录后获取网关地址列表，周期性 + 触发式探测各线路网络质量；当线路 1 的时延达到切换条件时，按选路策略重新选择线路，切换到线路 2 建立加密隧道，访问资源。

选路算法提供两种策略，选哪种取决于网关的数量：

选路策略	适用场景	选路方式
时延优先	单网关设备多运营商线路架构，帮助用户自动接入速度最快的线路；但多网关部署时可能导致所有连接集中在一个网关	首次接入优先选择最小时延线路，后续线路恶化至切换条件时重新选路
时延 + 负载	多网关架构，自动接入相对较快的线路，同时均衡流量分配，多个网关负载相对均衡	首次接入时，根据客户端到访问地址的最小时延（ Base ）及相对时延阈值（ Threshold ），在阈值范围内随机选择线路接入

线路切换机制的设计重点是防抖动，避免网络抖动引发反复横跳：

· 周期性探测：对线路定时进行时延探测；

· 触发性探测：在发起访问时，对当前线路进行触发性探测；

· 快速探测：当某次探测发现线路恶化时，连续快速探测多次，每次都探测到恶化才执行线路切换。

实际配置中，几个关键阈值建议按客户网络实测值来定，一个可参考的起点是：

参数	参考值	说明
周期性探测间隔	30 秒（ 30–60 秒）	自动对线路进行周期性探测
线路恶化判定时延	> 400 ms	判断为线路恶化
快速探测次数	3 次（ 3–6 次）	首次探测到恶化后连续快速探测，每次结论都为恶化才切换
相对时延阈值	20 ms	「时延 + 负载」策略下的阈值

另外有一条兜底逻辑值得注意：若所有线路都恶化至切换条件，则保持现有线路不变，不会把用户切到一条更差的线上。

（三）分布式集群端口矩阵

双机房组网最容易翻车的地方不是配置，而是防火墙策略。下面是本次实施梳理出的端口矩阵，建议在割接前一周就提给客户网络组，避免当天卡在策略上。

源设备	目标设备	目的端口	作用
A 机房控制中心	A 机房代理网关	4433 、 443	4433 ：控制中心查看代理网关日志； 443 ：代理网关加入控制中心管理
A 机房控制中心	B 机房代理网关	4433 、 443	同上，需双向访问
B 机房控制中心	A 机房代理网关	4433 、 443	同上，需双向访问
B 机房控制中心	B 机房代理网关	4433 、 443	同上，需双向访问
A 机房控制中心	B 机房控制中心	442 、 443	442 ：分布式集群数据同步； 443 ：组建分布式集群
A 机房控制中心	分析中心	30014 、 4443 、 4433 、 3346	30014 ： syslog 日志传输； 4443 ：沙箱文件导出审批、文件互传记录等审计记录上报； 4433 ：请求分析中心 WEB 审计的服务授权（无授权无法开启特性）； 3346 ：分析中心同步控制中心资产
B 机房控制中心	分析中心	30014 、 4443	同上，按实际开启的特性裁剪
A 机房代理网关	分析中心	30014 、 4443	syslog 日志传输与审计记录上报