SafeKit：全合一 SANless 高可用性与应用程序集群软件

SafeKit 在单一软件产品中为 Windows 和 Linux 提供以下功能：

• 负载均衡
• 同步实时文件复制
• 应用程序自动故障转移
• 服务器故障后的自动回切（Failback）

不需要。SafeKit 部署简单——无需高级专业知识即可操作。

不需要。SafeKit 运行在您现有的服务器、虚拟机或云端——无需共享磁盘或 SAN 存储。

不需要。SafeKit 适用于标准版的 Windows 和 Linux，并且不需要企业级数据库许可。

SafeKit 解决了：

• 硬件故障（占问题的 20%），包括整个机房的全面故障
• 软件故障（占问题的 40%），包括关键进程的重新启动
• 人为错误（占问题的 40%），这得益于其易用性

您可以为以下对象实现实时复制和故障转移：

• 所有类型的应用程序、文件目录和服务
• 数据库
• 完整的 Hyper-V 或 KVM 虚拟机
• Docker、Podman 和云应用程序

SafeKit 消除了对以下各项的需求：

• 网络负载均衡器或专用代理服务器
• 共享磁盘或复制的 SAN 存储
• 企业版操作系统和数据库
• 专门的集群维护技能

不足以。数据复制仅仅是将数据从服务器 A 拷贝到服务器 B 的行为。虽然复制至关重要，但它本身并不提供可用性。如果没有 HA 堆栈的其他组件，复制只是一份“被动副本”，需要耗时的人工干预才能发挥作用：

• 如果服务器 A 宕机，数据复制软件不会自动将用户引导至服务器 B。
• 它不会检测到应用程序已停止运行。
• 它不会重新启动服务。

许多供应商要求您将数个不同的产品“拼凑”在一起，以实现基于主机的复制、故障转移和负载均衡。对于关键业务系统而言，这种碎片化的架构是一种危险的策略：

• 集成脆弱：当您使用产品 A 进行复制，使用产品 B 进行集群管理时，您实际上构建了一个“纸牌屋”。每一次操作系统更新或安全补丁都有可能破坏这些独立引擎之间脆弱的通信链路。
• 高认知负荷与人为错误：管理多个界面会增加出错的风险。在压力巨大的系统故障期间，在不同的图形用户界面（GUI）之间切换，或使用不同的命令行（CLI）语法来诊断问题，会导致混乱并延长停机时间。
• 供应商推诿责任：如果故障转移失败，复制供应商可能会指责集群工具，使您陷入中间，没有明确的解决路径。而全合一解决方案提供了单一的责任归属点。
• 维护复杂：碎片化的系统需要针对每个独立组件配备专业技能，使得解决方案更难维护，且随着时间的推移，成本会显著增加。

为了实现自动化恢复并消除停机时间，全合一产品必须同时管理多个技术环节：

• 基于主机的复制：在不依赖共享存储（SAN）的情况下，实现服务器之间关键业务数据的实时同步复制。这确保了零数据丢失（RPO=0），并消除了昂贵的硬件依赖。
• 虚拟 IP 地址 (VIP)：这为用户提供了一个单一的访问入口。当故障发生时，软件会将 VIP 从故障节点转移到健康节点，因此用户无需更改其配置。
• 硬件和软件错误检测器：系统必须持续对物理服务器和特定的软件进程进行“心跳”监测，以便立即识别挂起或崩溃。
• 可定制的启动脚本：并非所有应用程序的启动方式都相同。全合一工具允许使用自定义脚本，以确保复杂的业务服务按正确的顺序启动。
• 自动故障转移：无需人工干预即可协调整个从一台服务器转移到另一台服务器的智能机制。

如果您的故障转移管理器和数据复制是两个不同的产品，它们可能无法保持“同步”。

潜在危险：如果发生了故障转移，但复制尚未完成最新数据的传输，服务器 B 将会使用过时或损坏的数据启动应用程序。

全合一 SANless HA 解决方案可确保故障转移机制能够感知复制状态。它只会在保证数据已更新至最新状态的情况下，才允许应用程序在备用节点上启动，从而防止活跃节点冲突和数据丢失。

自动回切（Failback）在技术指南中经常被忽视，且在传统 HA 解决方案中执行效果不佳，但它仍然是实现真正韧性的最关键要求。一个真正的全合一产品处理“恢复正常”的过程应与处理故障时一样优雅。当故障服务器重新上线时，其数据是滞后的。HA 软件必须：

1. 后台再同步数据：在后台将数据从活动节点同步到恢复后的节点。
2. 保持运行时间：此再同步过程必须在不中断活动节点上当前运行的应用程序的情况下进行。
3. 恢复冗余：一旦数据再次镜像完成，集群会自动恢复到受保护状态，为下一次突发事件做好准备。

基于主机的复制所采用的技术方法，会显著影响您对现有应用程序设置的更改程度。

• 块级复制的挑战：大多数 SANless 解决方案在磁盘/块级别进行复制。这对应用程序而言是非透明的。它要求您完全重新配置应用程序，将其数据迁移到特定的、新创建的“复制磁盘”卷中。这通常涉及复杂的迁移工作，并可能导致应用程序逻辑的更改。
• SafeKit 文件级复制的优势：SafeKit 在文件级别执行基于主机的复制，这对应用程序是完全透明的。您无需将数据移动到特殊磁盘；只需配置 SafeKit 来复制现有的应用程序文件夹即可。这些文件夹甚至可以保留在系统磁盘上，允许您在应用程序的原安装位置直接对其进行保护。

SafeKit Web 控制台提供了一个直观的界面来构建和管理关键应用程序的高可用性。只需几个步骤，您就可以配置 SafeKit 镜像集群以确保业务连续性：

• 应用程序故障转移（Macros 选项卡）：定义在发生故障时需要自动重新启动的具体应用程序服务。
• 心跳网络：集群节点使用的专用通信路径，用于持续监测彼此的健康状况和可用性，并同步故障转移决策。
• 虚拟 IP 管理：设置虚拟 IP (VIP)，以便在故障转移后实现客户端的透明无感重连。
• 实时复制：选择关键目录，进行基于主机的同步字节级复制。
• 检查器（Checkers）：监控应用程序的健康状况，并在检测到进程故障时触发自动恢复。

SafeKit 集群包含一个专用的脑裂检查器（split-brain checker），用于解决网络隔离问题，而不需要第三台见证服务器（witness machine）或额外的心跳网络。了解更多关于集群中的心跳、故障转移和仲裁（quorum）的信息。

SafeKit 管理控制台为您的高可用性基础设施提供了一个统一的视图。它允许管理员实时监控集群的运行状态并跟踪数据同步情况。

对于双节点镜像集群，控制台会清晰地显示每台服务器的角色：

• PRIM (主节点)：当前正在运行应用程序并管理虚拟 IP 的活动节点。它负责写入本地存储，并向备用节点进行实时复制。
• SECOND (备节点)：接收同步字节级更新的备用节点。如果主节点发生故障，它已准备好立即接管服务。
• ALONE (孤立) 状态：当集群仅在单个节点上运行时（例如在维护期间或发生故障后）为您提供直观的警报，提示冗余已暂时丢失。
• 重新同步进度：当故障节点恢复时，在后台数据重新集成期间其状态会变为橙色，确保在“恢复正常”阶段不会出现停机时间。

除了简单的状态图标外，该界面还提供了一键式故障转移调度（one-click failover orchestration），允许您在计划内维护时手动重新分配主节点角色，同时确保用户活动的持续可用性。

场（Farm）模式的 SafeKit 集群专为服务的高可用性和可扩展性而设计。其配置重点在于将传入的流量同时分配到两个节点上：

• 负载均衡服务（Macros 标签页）：定义要在所有节点上保持活动状态的特定应用程序服务（例如 Apache、IIS、Nginx）。
• 心跳网络：用于检测节点是否已离开集群（场）的通信路径，一旦离开将立即触发流量的重新分配。
• 虚拟 IP（场 VIP）：与镜像（Mirror）集群不同，场 VIP 是通过内核过滤算法在节点之间共享的，以此来分发网络流量。
• 负载均衡规则：根据源 IP 地址或端口定义流量分配策略。
• 检查器（Checkers）：监控应用程序的健康状态，并在检测到进程故障时触发自动重启。

监控场模式的集群可以直观地了解其双活（Active-Active）架构的运行状态，在此架构中所有节点都会为应用程序的性能做出贡献（本例中显示为 2 个节点）：

• UP 状态（2 个节点各占 50%）：在健康的场中，两个节点都处于“UP”（50%）状态，这意味着它们都在通过共享的虚拟 IP 主动接收并处理客户端请求。
• 自动重新均衡：如果某一个节点发生故障，控制台会直观地显示剩余节点接管 100% 的流量。这里不存在“故障转移”延迟，因为存活的节点本身就已经处于活动状态（仅需几秒钟的检测时间）。
• 节点并入：当修复后的节点重新启动时，它会从“STOP”状态转换为“UP”状态，并自动开始接收其分担的负载，无需管理员的人工干预。
• 无数据同步：请注意，在场模式集群中，不存在“橙色”的数据重新同步状态，因为各节点通常是无状态的，或者共享同一个后端数据库（该数据库可以在镜像集群中单独受到保护）。

除了简单的状态图标外，该界面还提供了一键式节点 management 功能，允许您在计划维护时手动停止或启动某个节点，而共享的虚拟 IP 会自动重新分配流量，绝不中断用户的业务活动。