Linux高可用HA集群Corosync+Pacemaker作用、核心架构以及工作流程（二）

Linux 高可用（HA）集群 Corosync + Pacemaker 的作用、核心架构与工作流程

---

一、作用

Corosync 和 Pacemaker 组合为 Linux 集群提供了一套完整的高可用解决方案，核心作用如下：

组件	核心作用
Corosync	1. 节点通信：管理集群节点间的心跳检测和状态同步。 2. 仲裁（Quorum）：防止脑裂（Split-Brain），确保集群决策合法性。 3. 事件通知：将节点故障、网络分区等事件传递给上层（Pacemaker）。
Pacemaker	1. 资源管理：定义、监控和迁移集群资源（如 IP、服务、存储）。 2. 故障恢复：自动触发资源故障转移（Failover）。 3. 策略执行：根据约束（优先级、依赖关系）分配资源。

---

二、核心架构

1. 分层架构

+------------------------+     +------------------------+
|    **Pacemaker**       |     |      **Corosync**       |
|  - 资源管理器          |<----|  - 通信层（心跳、消息）  |
|  - 策略引擎            |     |  - 仲裁（Quorum）       |
|  - 资源代理接口        |     +------------------------+
+------------------------+
        | 管理资源
        v
+------------------------+
| **资源（VIP, 服务, 存储）** |
+------------------------+

2. 关键组件详解

• Corosync 层：
  • Totem 协议：通过多播/单播实现节点间心跳和消息传递。
  • Quorum 机制：集群存活节点需超过半数（可配置），否则拒绝操作（防脑裂）。
  • QDevice（可选）：外部仲裁设备（如独立服务器）辅助决策 Quorum。
• Pacemaker 层：
  • 资源代理（Resource Agents）：控制资源生命周期的脚本（如启动/停止服务）。
    • 类型：OCF（推荐）、LSB、Systemd。
  • CIB（集群信息库）：XML 格式的集群配置和状态数据库，所有节点同步。
  • CRM（集群资源管理）：决策引擎，根据约束和事件生成资源分配计划。
  • STONITH：强制隔离故障节点（如远程电源控制），防止数据冲突。

3. 物理架构示例

            +------------------+
            |   **QDevice**    |
            | （仲裁设备）       |
            +------------------+
                     |
      +---------------+---------------+
      |                               |
+------------+                 +------------+
| **Node 1** |<---Corosync--->| **Node 2** |
| - VIP      |    （心跳）      | - VIP (备)  |
| - Apache   |                 | - Apache   |
+------------+                 +------------+
      |                               |
      +---------> 计算节点/客户端 <-----+

---

三、工作流程

1. 集群初始化流程

1. 节点发现：
   • Corosync 启动后，通过配置的通信协议（多播或单播）发现其他节点。
   • 节点交换信息，形成集群成员列表。
2. Quorum 计算：
   • 集群根据存活节点数判断是否达到仲裁（如 3 节点集群需至少 2 节点存活）。
3. Pacemaker 启动：
   • Pacemaker 读取 CIB 配置，加载资源代理。
   • 根据约束规则分配资源到节点。

2. 正常运行监控流程

循环执行：
1. Corosync 持续发送心跳包，检测节点存活。
2. Pacemaker 监控资源状态（如进程是否运行、IP 是否绑定）。
3. 若资源异常，标记为故障并触发恢复策略。

3. 故障切换流程

场景：节点 A（运行资源）宕机。

1. **故障检测**：
   - Corosync 检测到节点 A 心跳丢失，通知 Pacemaker。
2. **Quorum 重计算**：
   - 剩余节点判断是否仍满足 Quorum（如 2/3 节点存活）。
3. **资源迁移决策**：
   - Pacemaker 根据资源约束（如优先级、位置偏好）选择新节点（节点 B）。
4. **隔离故障节点**：
   - 触发 STONITH 强制关闭节点 A（防止脑裂）。
5. **资源接管**：
   - 节点 B 启动资源（如 VIP、Apache），更新 CIB 状态。
6. **状态同步**：
   - 新资源分配策略通过 Corosync 广播到所有存活节点。

4. 脑裂处理流程

1. **网络分区**：集群分裂为两组节点（如 Node1 和 Node2 无法通信）。
2. **Quorum 判断**：
   - 每组节点检查是否拥有多数节点（如 2/3 集群中，单节点组失去 Quorum）。
3. **资源冻结**：
   - 失去 Quorum 的节点组停止资源操作，防止数据冲突。
4. **恢复合并**：
   - 网络恢复后，节点重新协商 Quorum，同步 CIB 状态。

---

四、关键配置与约束类型

1. 资源约束类型

约束类型	作用	示例命令
位置约束	指定资源倾向在哪些节点运行。	pcs constraint location WebVIP prefers node1
顺序约束	控制资源启动/停止顺序。	pcs constraint order start WebVIP then start WebServer
共置约束	强制资源在同一节点运行。	pcs constraint colocation add WebVIP with WebServer

2. 典型配置示例

# 创建集群
pcs cluster auth node1 node2
pcs cluster setup --name my_cluster node1 node2
pcs cluster start --all

# 配置资源
pcs resource create WebVIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24
pcs resource create WebServer systemd:httpd

# 设置约束
pcs constraint colocation add WebVIP with WebServer
pcs constraint order WebVIP then WebServer

# 启用 STONITH
pcs stonith create ipmi-fence fence_ipmilan pcmk_host_list="node1 node2" ipaddr=192.168.1.50 login=admin passwd=secret

---

五、最佳实践

1. 专用心跳网络：使用独立物理网络传输 Corosync 心跳，避免业务流量干扰。
2. 资源代理选择：优先使用 OCF 资源代理（更灵活）。
3. STONITH 必配：避免脑裂导致数据损坏。
4. 监控与日志：集成 Prometheus + Grafana 监控集群状态，日志集中收集（如 ELK）。

---

总结

• Corosync 是集群的“神经系统”，负责通信和仲裁。
• Pacemaker 是集群的“大脑”，负责资源调度和故障恢复。
• 二者协同实现自动化高可用，适用于 Web 服务、数据库、存储等关键场景。
• 合理配置约束、STONITH 和 Quorum 是保障集群可靠性的关键。