关于数据可用与高可用的部署方法和设计

这篇文档主要说明 HA（服务高可用）和数据可用之间的区别。设计 EMS 可靠性时，建议先从“数据丢了能不能恢复”入手，再考虑“服务器坏了能不能自动切换”。具体安装命令请查看目标版本的 Fortinet 官方文档和本手册对应的安装章节。

重要

EMS 能自动切换，不代表数据一定安全；有可用的数据库备份（Database Restore，DR），也不代表 EMS 故障时不会中断。

数据可用关注的是数据是否完整，以及出现问题后能不能恢复；
HA关注的是服务中断后，另一台节点能不能快速或自动接管；
DR关注的是整个机房或地域不可用后，能不能在其他站点恢复业务。

所以，本文的建议是：先准备恢复更快的 VM 快照和 Server List，同时保留数据库备份作为最后兜底，再根据规模和业务连续性要求决定是否部署 HA。

先说结论

本文比较长，结合现有项目的运行情况，可以先记住下面几条：

优先准备恢复更快的方式。 VM 快照回退和 Server List 通常比重新安装 EMS、再恢复数据库快得多，因此应作为单机 EMS 的首选快速恢复手段。
快照用于快速回退。 EMS 升级、安装补丁或进行重大配置变更前创建 VM 快照，出现问题时可以直接回到变更前状态。
Server List 用于快速恢复终端接入，但会增加成本。 首选 EMS 不可达时，FortiClient 可以继续尝试备用 EMS，减少终端长时间失联。但备用 EMS 需要额外的 License 容量、服务器资源和维护投入，而且多个 EMS 的配置和数据库不会自动同步。
数据库备份负责最后兜底。 当快照不可用、快照中也包含错误，或者数据库已经损坏时，再使用数据库备份进行完整恢复。这个过程通常明显慢于快照回退和 Server List 切换。
HA 主要解决节点故障。 一台 EMS 或数据库节点停止后，备用节点可以继续提供服务；但错误配置、误删除和数据损坏也可能同步到备用节点，仍然需要恢复手段，且HA集群故障切换需要一定时间。EMS 7.4/8.0需要约1分钟，EMS7.2/7.0需要约5分钟切换完成。
单台 EMS 通常已经比较稳定。 5000 个 License（授权终端席位）以下，通常优先使用单台 EMS，并根据成本准备快照、Server List 和数据库备份；达到 5000 个 License 以上，再重点评估 HA。如果业务不能接受 EMS 中断，即使数量不足 5000，也可以根据 RTO/RPO 提前部署 HA。
完整 HA 不只是两台 EMS。 还要考虑数据库、负载均衡、DNS、证书、网络、监控和备份，否则只是把单点转移到了其他位置。

建议准备的恢复手段

第一步：建立 VM 快照规范，重大变更前保留可回退快照
              ↓
第二步：评估额外 License 和服务器成本，按需准备备用 EMS 和 Server List
              ↓
第三步：同时做好数据库备份，作为快照不可用时的兜底
              ↓
第四步：分别演练快照回退、Server List 切换和数据库恢复
              ↓
第五步：达到 5000 个 License 以上，或业务连续性要求较高时，评估完整 HA

这套思路不是取消数据库备份，而是把恢复方式分成“快速恢复”和“完整兜底”两层。快照回退和 Server List 优先解决恢复速度，数据库备份负责处理快照无法解决的数据损坏和整机重建。对于大多数中小规模环境，这种分层恢复方式通常比直接部署复杂 HA 更实用。

HA 和数据可用有什么区别

对比项	数据可用与恢复	HA（服务高可用）
主要目标	数据损坏或丢失后能够找回来	节点故障后尽快继续提供服务
主要手段	数据库备份、异机副本、恢复文档、恢复演练、变更前快照	EMS 应用 HA、PostgreSQL HA、负载均衡和健康检查
能处理的问题	误删除、错误配置、数据损坏、升级失败、勒索软件、整机重建	EMS 节点宕机、数据库节点宕机、部分网络或宿主机故障
是否自动切换	通常需要人工判断和恢复	在设计覆盖范围内可以自动或快速切换
最大限制	恢复需要时间，恢复点之后的数据可能丢失	错误数据可能同步到所有节点，不能代替备份
关注指标	RPO：最多能接受丢失多少数据	RTO：服务最多能中断多久

可以把数据可用理解成“东西坏了以后能找回来”，把 HA 理解成“正在工作的机器坏了以后有人接班”。接班解决不了数据本身已经错误的问题，因此恢复方案和 HA 都要准备；在恢复方案内部，则优先选择速度更快的快照回退和 Server List，把数据库备份恢复留作最后兜底。

为什么优先使用快照回退和 Server List

从数据库备份恢复 EMS，通常需要准备服务器、安装匹配版本、还原数据库、恢复证书和外部集成，并完成业务验证。数据量越大，整个过程越长。相比之下，VM 快照可以直接把整台虚拟机回退到较早状态；Server List 则可以让终端改连已经准备好的备用 EMS，恢复速度通常更快。

不过，这两种方式各有边界：快照只能回到创建快照时的状态，Server List 也不会自动恢复主 EMS 的数据库和配置。因此，数据库备份不能取消，只是实际故障处理中通常排在快照和 Server List 之后使用。

几种方式的定位可以这样理解：

恢复方式	相对恢复速度	主要用途	不能解决的问题
Server List	最快，取决于终端重连时间	首选 EMS 不可达时，让终端尝试备用 EMS	不会同步主 EMS 的数据库、策略和实时状态，并会增加 License 和备用 EMS 成本
VM 快照回退	较快，通常明显快于重装和数据库恢复	升级、补丁或配置变更失败后回到变更前状态	快照过旧、快照损坏或快照中已经包含错误
数据库备份恢复	较慢，受数据量和重建步骤影响	数据库损坏、快照不可用或需要完整重建	恢复过程需要人工操作，并可能丢失备份点之后的数据
EMS/数据库 HA	自动或较快	节点故障后由其他节点接管	不能防止错误数据同步，也不能代替备份

发生故障时，可以按下面的顺序判断：

如果只是首选 EMS 不可达，先确认终端能否通过 Server List 连接备用 EMS；
如果问题来自刚刚完成的升级、补丁或重大变更，优先考虑回退到确认可用的 VM 快照；
如果快照不可用、数据已经损坏，或者需要重建服务器，再使用数据库备份恢复；
如果规模超过 5000 个 License，或者以上恢复时间仍不能满足业务要求，再考虑完整 HA。

先认识几个常用词

名词	通俗解释
FQDN	EMS 对外使用的完整域名，例如 `ems.example.com`
VIP	负载均衡器对外提供的统一访问地址，后面可以对应多台 EMS
故障域	可能一起发生故障的一组基础设施，例如同一台宿主机、同一套存储或同一机房
见证节点	数据库集群中的“投票节点”，帮助判断故障后应该由谁当主库
脑裂	主备节点失去联系后，两边都认为自己是主节点，可能产生两份不一致的数据
回切	故障修复后，把业务从临时接管节点安全地切回原来的运行方式

优先方案：单台 EMS 先做好恢复

对于 5000 个 License 以下、能够接受人工恢复的环境，建议先保留单台 EMS 架构，把恢复方案做好。单台架构组件少、故障点清楚，升级和排错也更容易。

建议至少准备以下内容：

虚拟机快照：在 EMS 升级、安装补丁或进行重大配置变更前创建，用于短期快速回退；
备用 EMS 和 Server List：让终端在首选 EMS 不可达时尝试备用 EMS；部署前先核算额外 License、服务器和维护成本，并准备备用 EMS 的策略和证书；
EMS 数据库备份：按照固定周期备份并保存到 EMS 之外，在快照不可用或数据损坏时作为最后兜底；
恢复操作文档：记录快照回退、Server List 切换，以及完整数据库恢复的不同操作步骤；
基础监控：及时发现 EMS 服务、数据库、磁盘、证书和备份异常；
定期恢复测试：分别测试快照能否回退、终端能否连接备用 EMS，以及数据库备份能否完整恢复。

这里的优先级可以简单理解为：

快速恢复：Server List / VM 快照回退
                 ↓
完整兜底：数据库备份恢复
                 ↓
恢复时间仍不满足要求：评估完整 HA

这里表示的是故障发生后的处理优先级，不代表数据库备份可以以后再做。快照和 Server List 必须提前准备，数据库备份也要按计划持续执行；只是实际恢复时，优先选择耗时更短的方法。

确实需要 HA 时的参考架构

HA 切换需要多长时间

EMS HA 切换需要一定时间，设计业务中断窗口时，可以按以下时间进行预估：

EMS 版本	预计完成 HA 切换的时间
EMS 7.4/8.0	约 1 分钟
EMS 7.2/7.0	约 5 分钟

以上为 EMS HA 切换的参考时间，实际耗时受故障检测、节点状态、数据库可用性及负载均衡健康检查等因素影响，应以现场故障演练结果为准。终端重连和外部集成恢复还需单独验证，不能直接把上述时间视为所有业务恢复完成的时间，也不适用于 Server List 切换或数据库备份恢复。

单区域平台级高可用

这套架构同时为 EMS 和数据库准备了备用节点。不过，前面的负载均衡、DNS、网络出口和后面的备份存储也要一起考虑。如果负载均衡器只有一台，那么即使 EMS 和数据库都有两台，入口坏了以后用户仍然无法访问。

注

官方 EMS 7.4.6 单区域 PostgreSQL HA 参考方案使用五台 Linux 服务器：两台 EMS、两台 PostgreSQL 数据库节点和一台见证节点。如果希望合并服务器角色、改用云数据库或调整拓扑，需要先确认目标版本是否支持。不要只是减少服务器数量，却仍然把它当作完整 HA 使用。

EMS 应用 HA + 单实例远程数据库

这种方式可以解决单台 EMS 故障，但数据库仍然只有一台。数据库一旦不可用，两台 EMS 都会受到影响。它比较适合分阶段建设，或者数据库已经由其他平台提供保护的环境。无论哪种情况，都要为数据库准备正式的备份和恢复方案。

EMS 应用 HA + PostgreSQL HA

PostgreSQL HA 一般由一个主库、一个备库和一个见证节点组成。正常情况下只有主库可以写入，备库持续同步数据。见证节点负责在故障时参与判断“谁应该成为主库”，它并不保存一套完整业务数据，不能当作第三份数据库备份。目前PostgreSQL HA有EMS PostgreSQL HA Docker 镜像和原生 PostgreSQL 两种思路：

EMS 应用 HA + Docker PostgreSQL HA

需要注意，使用 Docker 不代表自动拥有 HA。数据库节点、见证节点、持久化存储、网络、自动重启和监控仍然要按官方拓扑配置完整。

注

因为Bitnami 于2025年8月要求收费机制，Bitnami提供的Docker Swarm部署被废弃。目前的部署架构必须要使用见证（witness）节点

EMS VM appliance HA

EMS VM appliance 可以组成应用 HA 集群，但集群中的 EMS 节点需要连接远程 PostgreSQL 数据库，不能继续使用各自虚拟机中的本地数据库。虚拟化平台 HA 解决的是“宿主机坏了以后把虚拟机重新拉起来”，EMS 应用 HA 解决的是“EMS 服务坏了以后由其他 EMS 接管”。两者可以配合使用，但不能互相替代。

地理冗余

地理冗余主要应对整个机房或地域不可用。EMS 节点可以放在不同地点，但数据库需要跨站点同步，还会受到网络时延、丢包和选主机制的影响。因此，这类方案更接近灾难恢复项目，不能简单理解为“把两台服务器放远一点”。

采用跨地域架构前，至少要确认下面这些事情：

按目标版本的官方 geo-redundancy 拓扑确认 EMS 和数据库应该放几台、分别放在哪里；
实际测量站点之间的时延、抖动、丢包和可用带宽，不能只看运营商提供的标称带宽；
提前规定两个站点失联后哪一侧继续工作，避免两边同时把自己当作主节点；
写清楚什么时候自动切换、什么时候人工接管，以及业务恢复后怎样切回来；
确认每个站点都具备所需的 DNS、证书、负载均衡、监控和备份；
用断开站点链路、关闭整个站点等方式进行演练，确认实际 RTO 和 RPO。

应该选择哪一种方案

方案	可以解决什么问题	主要限制	什么时候考虑
单机 EMS + VM 快照	升级、补丁或重大变更失败后快速回退	依赖有效快照，不能代替数据库备份	虚拟机部署环境中的优先快速恢复方案
多个独立 EMS + Server List	首选 EMS 不可达时，终端尝试备用 EMS	需要额外 License 和备用服务器，配置与数据库也不会自动统一	需要快速恢复终端接入，且额外成本可以接受
单机 EMS + 数据库备份	数据库恢复、整机重建	恢复步骤多，通常比快照和 Server List 耗时更长	所有环境都应准备，作为快速恢复方式失效后的最终兜底
单机 EMS + 虚拟化平台 HA + 备份	物理宿主机故障后重新拉起虚拟机	应用异常、数据损坏和存储故障未必自动处理	已有成熟虚拟化平台，能够接受虚拟机重启时间
EMS 应用 HA + 单数据库	单个 EMS 应用节点故障	数据库和入口仍可能是单点	超过 5000 个 License 后分阶段建设，或数据库已有其他保护
EMS 应用 HA + PostgreSQL HA	EMS 节点和单个数据库节点故障	成本和维护复杂度较高，仍要处理入口、仲裁和备份	超过 5000 个 License，或业务要求分钟级自动恢复
地理冗余 + 独立备份	整个站点发生故障	高度依赖跨站点网络、仲裁和日常演练	有明确站点级灾备目标的大型环境

选型建议

5000 个 License 以下：通常优先使用单台 EMS 和 VM 快照。是否增加 Server List，需要同时比较恢复速度和额外 License 成本；数据库备份继续作为完整恢复兜底。只要这些方式的恢复时间能够满足业务要求，不必为了节点数量而增加架构复杂度。
5000 个 License 以上：建议正式评估 EMS HA。终端数量越多，单台 EMS 维护或故障时的影响范围越大，更值得通过自动切换降低中断时间。
未达到 5000，但业务不能接受中断：不要机械地等待达到 License 门槛，可以根据 RTO/RPO 提前部署 HA。
只需要终端有备用接入地址：可以考虑 Server List，但要先核算备用 EMS 的 License 和运行成本，再准备相应策略并验证真实终端的切换行为。
数据库也不能成为单点：使用官方支持的 PostgreSQL HA，或者满足 EMS 支持要求的托管数据库服务，同时仍要保留独立备份。
整个机房故障后也要继续服务：先把单区域 HA 运行稳定，再建设地理冗余，并把它作为单独的灾备项目进行设计和验收。

Server List 与 EMS HA 的区别

Telemetry Server List 可以理解成 FortiClient 保存的一份“备用 EMS 通讯录”。第一台 EMS 连接不上时，客户端会继续尝试列表中的其他 EMS。它可以提供备用接入地址，但这些 EMS 仍然是各自独立的系统，与共享数据库的 EMS HA 不是一回事。

对比项	EMS 应用 HA	Telemetry Server List
管理平面	同一 EMS HA 集群	多个独立 EMS
数据库	节点连接同一数据库或数据库集群	各 EMS 通常使用各自数据库
配置一致性	按 HA 机制共享/同步	不应假设自动同步
客户端入口	通常通过统一 FQDN/VIP	客户端依次尝试列表内服务器
主要用途	EMS 服务连续性	终端备用接入或独立管理域容灾
许可与容量	按目标版本和 HA 授权规则核算	备用 EMS 需要额外 License，并按可能接管的终端数量准备容量

使用 Server List 前，要提前在备用 EMS 上准备好授权、策略、安装包、证书和外部集成。还应找几台真实终端进行测试，确认切换后能否重新注册、拿到正确策略，以及主站恢复后应该怎样处理。

Server List 的成本需要单独评估

Server List 的切换速度较快，但它依赖另一套独立 EMS。备用 EMS 不只是多准备一台服务器，还需要考虑以下成本：

额外 License：备用 EMS 需要具备足够的授权席位。应按照可能同时切换到备用 EMS 的最大终端数量核算，而不是只为测试终端购买少量授权；
服务器和基础设施：包括计算、存储、操作系统、数据库、备份以及可能使用的云资源；
配置维护：两个独立 EMS 的策略、安装包、证书和外部集成不会自动保持一致，需要人工维护和定期检查；
测试投入：需要持续验证终端切换、策略匹配、License 余量以及主 EMS 恢复后的处理方式。

因此，不能只因为 Server List 恢复快就默认使用。设计时应把额外 License 和长期维护成本，与 VM 快照的恢复时间、数据库恢复时间以及完整 HA 的建设成本放在一起比较。具体 License 数量和授权方式应以当前合同、目标版本许可规则及 Fortinet 商务确认结果为准。

部署时要注意什么

1. 服务器应该放在哪里

不要把 EMS-A 和 EMS-B 放在同一台物理宿主机上。条件允许时，它们还应使用不同的电源、交换机、存储故障域或可用区。
PostgreSQL 主库、备库和见证节点也不要全部放在同一个故障域，否则底层故障可能一次带走所有节点。
负载均衡器本身也要有备用。只有一台 FortiGate 或一台软件负载均衡器时，它仍然是单点。
除非目标版本的官方文档明确支持，否则不要为了节省服务器，随意把 EMS、数据库和见证角色装在同一台机器上。

2. 一台服务器要能接住全部业务

每台 EMS 都要按照全部终端同时连接时的负载来配置。这样另一台故障后，剩下的一台才不会因为性能不足再次出问题。
数据库磁盘要重点关注稳定的 IOPS、较低的访问时延，以及足够的数据增长空间。
备份、生成报表、更新签名和大量终端同时上线都会产生额外负载，容量评估时不要漏掉这些高峰。
不同 EMS 版本的资源要求可能变化，应查看目标版本的 Management Capacity 和 System Requirements，不要直接照搬旧项目规格。

3. 统一访问地址和证书

为终端、管理员和 FortiGate 使用一个固定的 EMS 域名，不要把某台 EMS 的实际 IP 写死在终端配置里。
VIP 上使用的证书要包含这个对外域名，同时要监控证书到期时间，避免证书突然过期导致所有节点都“看起来不可用”。
不要用简单的 DNS 轮询代替负载均衡。DNS 只能返回地址，不一定知道哪台 EMS 当前真正能够处理业务；FortiGate Fabric Connector 连接到非活动节点时也可能失败。
修改 DNS 前要考虑 TTL 和客户端缓存，并准备好改错后的回退办法。

4. 负载均衡要能判断 EMS 是否真的可用

负载均衡器不能只判断服务器“还开着”，还要尽量判断 EMS 服务是否真的能用。服务器可以正常响应 Ping，端口也可能处于打开状态，但 EMS 服务已经卡住、数据库已经断开，或者该节点并不是当前活动节点。

配置负载均衡时，至少要把下面这些问题弄清楚：

哪些服务和端口需要通过 VIP 对外提供；
健康检查用哪个端口或路径，多长时间检查一次，失败几次后才切换；
健康检查能否区分活动节点、备用节点和服务异常；
是否需要会话保持，以及地址转换会不会影响日志中的源地址和访问控制；
TLS 是在负载均衡器上解密，还是直接转发给 EMS，证书应该装在哪里；
FortiGate Fabric Connector 是否会通过正确的 VIP 连接到活动 EMS。

5. 数据库切换时要避免出现两个主库

正常情况下只能有一个数据库主节点接受写入。
要持续查看谁是主库、备库有没有正常同步、数据落后多少，以及 WAL（PostgreSQL 写入日志）、磁盘和网络状态是否正常。
见证节点只参与“投票”，既不能代替数据库备份，也不会保存完整业务数据。
两个数据库节点互相看不到时，最危险的情况是双方都认为自己是主库，这就是“脑裂”。因此要提前规定由谁继续工作、怎样隔离旧主库，以及旧主库恢复后怎样重新加入。
自动切换完成后，不要只看新主库已经启动；还要确认 EMS 已经连接新主库、数据可以正常写入，并且数据库复制已经恢复。

6. 防火墙需要放通哪些端口

下表只列出 HA 中最常见的通信端口，方便设计时快速检查。正式实施时仍要查看目标版本的 Required services and ports，并逐一检查主机防火墙、上游防火墙、云安全组、NAT 和负载均衡策略。

通信方向	默认端口	用途	设计要点
FortiClient → EMS/VIP	TCP 8013	Telemetry 和终端管理	VIP 健康检查与证书/FQDN保持一致
管理员/FortiOS → EMS/VIP	TCP 443	Web 管理、REST API	仅开放给需要的管理和集成来源
FortiClient → EMS/VIP	TCP 10443	安装包、允许列表签名和自定义页面下载	如修改默认端口，同步修改负载均衡和防火墙
EMS ↔ FortiOS	TCP 8015	Fabric 通知/WebSocket	HA 场景建议通过受支持的 LB 设计连接活动节点
EMS/VIP	TCP 4001、4002	SCEP/证书签发	仅在启用相应功能时开放
AD Connector → EMS/VIP	TCP 8871	AD Connector 通信	仅在部署 AD Connector 时开放
EMS/数据库 HA 节点之间	TCP 5432	PostgreSQL、HA 心跳与同步	仅允许集群节点，双向验证连通性

完整端口规划参见EMS 部署前注意事项。如果安装时改过默认端口，防火墙和负载均衡器也要跟着修改，不能继续照抄默认端口表。

7. 有 HA 也要做好备份

使用 EMS 支持的方式备份数据库，并把备份放到 HA 集群以外。否则集群存储一起损坏时，备份也可能跟着丢失。
除数据库外，还要保存恢复时会用到的证书、密钥、安装参数和外部集成信息。
备份文件需要加密并限制访问，同时设置保留周期和完整性检查。
定期在隔离环境中真正恢复一次。只有成功恢复过的备份，才能说明它是可用的。
VM 快照只适合在升级或重大变更期间辅助回退。创建快照前先确认数据库一致性要求，验证完成后按计划清理，避免快照长期堆积。

出了故障应该发生什么

高可用不能只看拓扑图，必须实际制造故障进行测试。下面列出了最常见的测试场景，以及切换后需要确认的结果。

故障场景	期望行为	必须验证的结果
活动 EMS 节点停止	备用 EMS 接管，入口流量转移	终端重连、控制台可用、策略与标签正常
备用 EMS 节点停止	活动节点继续服务并产生告警	集群状态可见，当前节点可承载全部负载
PostgreSQL 主节点停止	备库按设计提升为新主	EMS 恢复写入、无双主、复制关系可重建
PostgreSQL 备节点停止	主库继续服务并产生告警	业务不受影响，修复后追平复制
见证节点停止	数据库仍服务，但自动故障转移能力可能降级	明确告警并优先恢复见证，不误触发切换
单台负载均衡器停止	另一负载均衡实例接管 VIP	FQDN/VIP 可达，现有和新连接行为符合预期
节点间网络中断	按仲裁规则保留唯一活动角色	不出现双主，隔离侧不会继续写入
数据库数据损坏/误删除	不依赖 HA 副本，进入备份恢复流程	能恢复到目标时间点并验证数据完整性
整个站点中断	按 DR 流程启用备用站点	DNS、证书、入口、数据库和外部集成均可用

建议按照什么顺序部署

如果经过规模和 RTO/RPO 评估后确定需要 HA，建议按照下面的顺序实施。不要一开始就把所有生产终端切过来，也不要因为准备部署 HA 就跳过原有备份和恢复演练：

先定目标：说明业务最多能停多久、最多能丢多少数据、需要覆盖哪些故障，以及最多会有多少终端接入。
确认版本能否配套：固定 EMS 版本和构建号，并检查操作系统、数据库、容器镜像、FortiClient 和 FortiOS 是否兼容。
画清楚部署图：提前确定 FQDN、VIP、节点地址、服务器位置、端口、证书、时间同步、DNS、监控和备份位置。
先把数据库搭好：完成主库、备库和见证节点，确认数据能够同步和切换，再安装 EMS。
安装 EMS 节点：所有节点使用相同版本和构建号，连接同一套数据库，并确认 EMS HA 角色正常。
配置统一入口：完成高可用负载均衡、健康检查、证书和所需服务端口。
接入监控和备份：至少覆盖 EMS 服务、节点角色、数据库复制、VIP、证书、容量和备份结果。
先用少量终端试运行：检查 Telemetry、策略、标签、安装包下载、ZTNA 证书和 FortiGate 集成。
主动做一次故障演练：分别关闭 EMS、数据库和负载均衡节点，记录实际切换时间、业务表现和恢复过程。
最后再正式上线：只有 HA 切换和备份恢复都测试通过，才把生产终端全部迁入。

上线验收清单

下面的清单可以直接用于上线前检查。某项没有通过时，应先记录原因和影响，再决定是否可以带风险上线。

基础状态

所有 EMS 节点版本、构建号、时区和时间同步一致。
EMS、数据库和见证节点分布在计划的故障域。
VIP/FQDN、证书链和证书到期时间正确。
负载均衡器自身不存在未接受的单点。
PostgreSQL 只有一个可写主节点，备库复制正常。
监控能够识别节点角色、复制延迟和入口异常。
最近一次独立备份成功，并已完成恢复验证。

业务验证

Windows、macOS 和 Linux 代表性终端能够通过 VIP 注册和重连。
终端策略、动态标签、ZTNA 标签和证书下发符合预期。
管理员可通过 FQDN 登录，关键管理操作正常。
FortiGate Fabric Connector、REST API、AD/LDAP、SMTP 等集成正常。
安装包和必要的签名/自定义页面可正常下载。

故障与恢复

EMS 活动节点故障转移测试通过。
数据库主节点故障转移测试通过，未发生双主。
负载均衡单节点故障转移测试通过。
网络分区的仲裁结果符合设计。
回切步骤已验证，不依赖未记录的人工操作。
数据库备份可在隔离环境恢复，并达到 RPO/RTO。

上线后怎么维护

把 EMS 节点状态、数据库角色和复制延迟、VIP、证书有效期、磁盘容量及备份结果接入统一告警，尽量在用户报障前发现问题。
发生自动切换后，先确认终端、管理页面和数据库写入正常，再处理故障节点。数据库角色还没确认清楚时，不要同时启动多个可写主库。
EMS 升级前先完成官方支持的完整备份，再使用 Fortinet Upgrade Path 检查升级路径，并按目标版本的 EMS HA Upgrade Guide 确认升级顺序。
不要默认所有版本都能无中断滚动升级。每次升级都要单独准备维护窗口和回退方案。
架构、版本、网络或证书发生变化后，至少重新测试一次最关键的故障切换场景。
日常维护方法参见EMS 的基本维护，备份操作参见EMS 的备份和还原。

这些做法看似是HA，其实并不可靠

下面这些做法看起来节省资源，但很容易让 HA 只停留在拓扑图上：

部署了两台 EMS，却只保留一台数据库和一台负载均衡器，然后把整套系统称为“全链路 HA”。
使用 DNS 轮询代替负载均衡，希望客户端自己找到正确的 EMS 节点。
认为用了 Docker、虚拟化平台或共享存储，EMS 应用和数据库就会自动保持一致。
把见证节点当成第三份完整数据库，因此取消正式备份。
把 Server List 当成会自动同步配置的 EMS 集群，没有检查备用 EMS 的授权和策略。
长期使用虚拟机快照代替数据库备份，或者在数据库持续写入时创建未经验证的一致性快照。
所有节点都放在同一台宿主机、同一台交换机或同一套存储上，底层一出问题就全部离线。
只测试“能不能切过去”，不测试恢复后“怎样安全切回来”，最后出现双主或流量走错节点。
跨地域部署时只看链路带宽，不检查时延、抖动、丢包、仲裁和数据同步时间。

EMS 7.4 起转向 Linux/PostgreSQL 架构，可以组合使用 EMS 应用 HA 和 PostgreSQL HA。根据版本不同，可以选择 Fortinet 提供的 PostgreSQL HA Docker 镜像、原生 PostgreSQL、远程数据库、VM appliance 或地理冗余方案。补丁版本变化后，镜像、安装参数、升级顺序和支持拓扑也可能变化，因此实施前要重新查看目标版本文档。

EMS 7.0/7.2

EMS 7.0/7.2 使用 Windows Server 和 Microsoft SQL Server，HA 方法与 7.4 之后的 Linux/PostgreSQL 完全不同。维护旧环境时，要继续参考对应版本的 EMS 文档、SQL Server FCI/Always On 设计和 Fortinet 支持矩阵。新建环境不要直接照搬旧架构，也不要把 PostgreSQL HA 的步骤用于 7.0/7.2。 EMS 7.0/7.2 已经EOS/EOES，原则上Fortinet不再对其维护，请尽快迁移到7.4以上版本，迁移步骤请参考：EMS 7.2 迁移到EMS 7.4

参考资料

更新历史

Ver	Description	Author	Rev	Date
2.3	Added details regarding the additional licenses, servers, and long-term maintenance costs required for the "Server List" approachRefined the strategy to prioritize VM snapshot rollbacks and the "Server List" method for rapid recovery, with database backup restoration serving as a comprehensive fallbackRestructured the article’s narrative flow: first clarify the distinction between data recovery and High Availability (HA), then cover HA selection and deployment	ysheng	tanga	2026.10.18
2.2	Included selection recommendations for a 5,000-license scale; shifted the implementation philosophy to prioritize recovery, with HA as a secondary layer	ysheng	tanga	2026.10.18
2.1	Adopted a more accessible, plain-language tone and added explanations for technical terms	ysheng	tanga	2026.04.22
2.0	Completely revised the sections on HA deployment methods, architectural selection, fault domains, acceptance criteria, and maintenance requirements	ysheng	tanga	2026.03.15
1.0	First Complete	ysheng	tanga	2025.03.20
0.9	Draft Version	ysheng	tanga	2024.08.18