- 简介
- 单节点自动化的问题
- 什么是 Semaphore UI 中的主动-主动 HA？
- 高层架构
- HA 集群中的作业执行方式
- 使用多个运行器进行水平扩展
- 主动-主动 Semaphore 部署的优势
- 典型使用场景
- 结论
- FAQ
简介
许多自动化平台从单节点架构开始。一个进程提供 UI 服务、执行作业、管理调度并处理实时更新。虽然这种设置很简单，但它也创建了单点故障。如果该进程停止，自动化也会随之停止。
对于运行大规模基础设施自动化的组织——尤其是在 DevOps 或平台工程环境中——自动化系统的停机可能成为严重的运营风险。
这就是主动-主动高可用性（HA）发挥作用的地方。Semaphore UI 支持多个实例同时运行并共享工作负载的架构。这确保即使个别节点发生故障，自动化仍会继续，同时还能实现水平扩展。
单节点自动化的问题
在标准部署中，一个 Semaphore UI 进程执行所有核心职责：
- 提供 Web UI 服务
- 处理 API 请求
- 执行计划作业
- 运行自动化任务
- 向浏览器发送实时更新
这种架构适用于小型团队或测试环境。然而，它引入了一个关键限制。如果单个进程宕机，整个系统将变得不可用。 对于拥有众多用户和自动化工作流的生产环境，这会带来以下风险：
- 部署中断
- 计划作业失败
- 运营可见性丧失
- 维护期间的停机
为了消除这个瓶颈，Semaphore UI 支持主动-主动高可用性部署。
什么是 Semaphore UI 中的主动-主动 HA？
在主动-主动 HA 架构中，多个相同的 Semaphore UI 实例同时在负载均衡器后面运行。与传统的故障转移系统不同，没有主节点或备用节点。每个实例都完全能够处理 UI 请求、API 调用、计划作业和任务执行。
流量分布在整个集群中，如果一个实例发生故障，其他实例会继续服务请求而不会中断。这种架构同时改善了系统可靠性和执行可扩展性。
高层架构
典型的主动-主动部署由几个关键组件组成。
-
负载均衡器。 用户通过 NGINX、HAProxy 和云负载均衡器等负载均衡器连接。负载均衡器在可用的 Semaphore 节点之间分配 HTTP 和 WebSocket 流量。
-
Semaphore 节点。 每个节点运行一个相同的 Semaphore UI 实例。任何节点都可以接收用户请求、启动自动化作业、处理计划任务并发送实时更新。由于所有节点都是平等的，系统在应用层没有单点故障。
-
共享数据库。 所有实例连接到共享数据库，如 PostgreSQL 或 MySQL。数据库作为持久数据的唯一事实来源，包括：项目、模板、清单、调度、任务历史、用户账户和 RBAC 配置。
-
Redis 协调层。 Redis 提供协调层，使多个节点能够作为单一系统运行。它提供三个重要功能。
- 分布式锁确保一次只有一个实例执行作业或步骤。没有分布式锁定，多个节点可能会尝试同时运行相同的任务。
- 共享任务队列状态。 Redis 维护任务队列，使作业恰好被一个 worker 接收。所有节点看到相同的队列并协调任务执行。
- Pub/Sub 消息传递允许节点广播事件，如：任务更新、集群通知、缓存失效、UI 状态更新。这使所有节点保持实时同步。
HA 集群中的作业执行方式
在多节点 Semaphore 部署中，任务执行遵循协调流程。
- 用户触发任务。用户通过 UI 或 API 启动作业。请求可以落在任何 Semaphore 实例上。
- 任务元数据被存储。接收节点将任务元数据写入数据库，并通过 Redis 发出工作信号。
- 节点接收任务。可用节点之一从 Redis 检索任务，获取分布式锁，并在数据库中将任务标记为正在运行。
- 任务执行。节点在本地或通过分布式运行器/代理执行任务。进度和日志持续写回数据库。
- 结果被广播。任务更新通过 Redis Pub/Sub 传播，使所有节点和 UI 客户端保持同步。
使用多个运行器进行水平扩展
高可用性还支持任务执行的水平扩展。与其仅在 Semaphore 节点本身上运行作业，不如将执行委托给多个运行器或代理。对于大型 DevOps 团队，这种架构支持企业级自动化工作负载：
- 在基础设施中分配工作负载
- 扩展自动化容量
- 隔离执行环境以限制爆炸半径
- 并行运行数千个节点
主动-主动 Semaphore 部署的优势
提高可靠性。 如果一个实例发生故障，其他实例继续服务流量和执行作业。
零停机维护。 无需停止系统即可更新或重启节点。
水平可扩展性。 可以在负载均衡器后面添加额外的 Semaphore 节点以增加容量。
无主节点依赖。 所有节点平等，消除了复杂的故障转移机制。 整个集群的一致状态。共享数据库存储和 Redis 协调使所有实例保持同步。
典型使用场景
主动-主动 Semaphore 部署常见于需要持续自动化可用性的环境中，例如：
- 大型 DevOps 团队。 在许多工程师全天触发自动化任务的组织中，多个 Semaphore 实例允许并行处理作业和请求，防止单个节点成为瓶颈。
- 企业基础设施。 管理大量服务器、虚拟机或容器群的公司严重依赖自动化进行配置和维护。高可用性有助于确保关键自动化工作流保持运行。
- CI/CD 自动化。 当 Semaphore 作为 CI/CD 管道的一部分使用时，中断可能会延迟部署和发布。主动-主动部署有助于保持管道可靠运行，即使个别节点重启或发生故障。
- 平台工程。 平台团队经常将 Semaphore 作为提供自助自动化的内部开发者平台的一部分使用。高可用性确保这些内部服务对开发团队保持稳定和响应。
结论
主动-主动高可用性使 Semaphore UI 从单一自动化服务器演变为弹性分布式系统。多个 Semaphore 实例在负载均衡器后面协同工作，通过数据库和 Redis 共享状态，而不是依赖一个进程来处理 UI、调度和任务执行。结果是一个即使个别节点发生故障仍然可用、并能随工作负载增长而水平扩展的自动化平台。
主动-主动 HA 支持在 Semaphore Enterprise 版本中提供。除了高可用性外，Enterprise 版本还包括为更大团队和生产环境设计的功能——如高级 RBAC（基于角色的访问控制），允许组织在项目、团队和环境中定义细粒度权限。
如果您正在评估适用于您基础设施的高可用性自动化平台，可以申请 Enterprise 版本的试用，测试 HA 架构并了解它如何融入您的 DevOps 工作流。
FAQ
什么是主动-主动高可用性？
主动-主动高可用性意味着多个应用实例同时运行，所有实例都可以处理请求。没有主节点——任何实例都可以处理流量和执行作业。
为什么 Semaphore 在 HA 模式下使用 Redis？
Redis 充当实例之间的协调层。它提供分布式锁、共享任务队列状态和 Pub/Sub 消息传递，以确保节点不会同时执行相同的作业。
Semaphore 支持哪些数据库用于 HA 部署？
Semaphore 支持 PostgreSQL 和 MySQL 作为存储持久系统数据的共享数据库。
如果一个 Semaphore 节点发生故障会怎样？
负载均衡器会简单地将流量路由到其余节点。正在运行的作业会继续执行，新作业由其他实例接收。
Semaphore 可以水平扩展吗？
可以。可以添加额外的 Semaphore 节点和运行器来增加执行容量并处理更大的自动化工作负载。