2. Longhorn 架构深度解析：核心组件与数据/控制平面分离设计
Longhorn 采用微服务架构，将存储系统拆分为多个独立、可替换的组件。其核心设计哲学是数据平面与控制平面严格分离：控制平面负责编排、调度与状态管理，数据平面负责实际的数据读写与传输。这种分离带来了高可用性、水平扩展能力和故障隔离性。
2.1 核心组件总览
Longhorn 由三个核心组件构成：Engine（引擎）、Replica（副本）和 Manager（管理器）。它们各自承担不同职责，协同工作。
| 组件 | 所属平面 | 核心职责 | 部署形态 |
|---|---|---|---|
| Engine | 数据平面 | 处理前端 iSCSI/NFS 请求，执行数据读写、去重、快照、备份 | 每个卷对应一个 Engine 实例（Pod） |
| Replica | 数据平面 | 持久化存储数据块，维护数据副本，参与重建与修复 | 每个卷对应多个 Replica 实例（Pod），通常为 3 个 |
| Manager | 控制平面 | 管理卷生命周期、调度 Replica、监控健康、执行故障转移 | DaemonSet 形式运行在每个节点上 |
关键理解：Engine 是“大脑”与“执行器”的结合体，负责将来自 Pod 的读写请求分发到多个 Replica；Replica 是“存储介质”，只负责保存数据块；Manager 是“调度中心”，不参与数据路径。
2.2 数据平面与控制平面分离设计
这种分离设计是 Longhorn 高可用与可扩展性的基石。下面通过架构图直观展示两者的边界与交互。
2.3 组件职责详解
2.3.1 Engine（引擎）
- 前端协议处理：对外暴露 iSCSI 或 NFS 接口，使 Kubernetes Pod 能够像使用本地磁盘一样访问 Longhorn 卷。
- 数据分发与一致性：将每个写入请求同步发送到所有健康的 Replica，并等待多数（Quorum）确认后才返回写入成功，保证数据强一致性。
- 快照与备份：支持创建卷的快照（Snapshot），并可将快照备份到远程存储（如 S3、NFS）。
- 去重与压缩：在数据写入时进行块级去重和压缩，降低存储成本。
2.3.2 Replica（副本）
- 数据持久化：将 Engine 分发过来的数据块以文件形式存储在宿主机的磁盘上（通常为 ext4/xfs 文件系统中的稀疏文件）。
- 副本维护：每个卷默认有 3 个 Replica，分布在不同的节点上，防止单点故障。
- 重建与修复：当某个 Replica 所在的节点宕机或磁盘损坏时，Manager 会调度一个新的 Replica，Engine 会自动从其他健康 Replica 同步数据完成重建。
2.3.3 Manager（管理器）
- 卷生命周期管理：创建、删除、挂载、卸载卷，以及调整卷大小。
- Replica 调度：根据节点资源、磁盘容量、故障域等策略，决定 Replica 的放置位置。
- 健康监控与故障转移：持续监控 Engine 和 Replica 的健康状态，当检测到故障时，自动触发重建或切换。
- API 与 UI 服务：提供 RESTful API 和 Web UI，供管理员操作和监控。
2.4 数据读写流程示例
以下是一个典型的写入流程，展示了数据平面与控制平面的协作：
- Pod 发起写入请求：Pod 通过 iSCSI 发起块设备写入。
- Engine 接收请求：Engine 实例接收请求，将数据块拆分为固定大小的块（默认 2MB）。
- 并行分发：Engine 将数据块并行发送到所有健康的 Replica。
- Replica 写入：每个 Replica 将数据块写入本地磁盘，并返回确认。
- Quorum 确认：Engine 等待多数 Replica（例如 3 个中至少 2 个）返回成功，然后向 Pod 返回写入成功。
- 控制平面监控：Manager 持续监控整个过程的健康状态，如果发现某个 Replica 响应超时，会标记其为故障并触发重建。
高可用保障：由于 Engine 等待多数确认，即使一个 Replica 故障，写入仍然成功。后续 Manager 会自动调度新 Replica 并触发数据重建，整个过程对 Pod 透明。
2.5 组件交互关系图
下面用另一张图展示组件之间的交互关系，重点突出 Manager 如何通过 Kubernetes API 与 Engine/Replica 通信。
2.6 设计优势总结
| 特性 | 控制平面（Manager） | 数据平面（Engine + Replica） |
|---|---|---|
| 故障影响范围 | Manager 故障不影响已有卷的读写，仅影响新卷创建和调度 | Engine 故障导致卷不可用，但 Replica 数据不丢失 |
| 扩展性 | 通过增加 Manager 副本实现高可用 | 通过增加 Replica 数量提升数据冗余和读取性能 |
| 升级策略 | 可滚动升级，不影响数据路径 | Engine 升级需短暂中断 I/O，但可通过多副本实现零停机 |
| 资源消耗 | 低，主要消耗 CPU 和内存用于调度和监控 | 高，主要消耗磁盘 I/O 和网络带宽 |
注意：虽然控制平面故障不影响已有卷的读写，但会影响故障恢复和新卷创建。在生产环境中，建议为 Manager 配置 Pod 反亲和性和资源限制，确保其高可用。