2. Longhorn架构总览

Longhorn 采用业界领先的控制平面与数据平面分离架构,这是其实现高可用、易扩展与强一致性的基石。控制平面负责管理、编排与状态协调,数据平面负责处理实际的 I/O 请求与数据复制。这种解耦设计使得控制平面的故障不会直接影响正在运行的数据 I/O,反之亦然,极大地提升了系统的整体稳定性与可维护性。

架构核心原则:控制平面故障不影响数据平面 I/O 路径;数据平面组件无状态化,便于快速恢复与扩缩容。
Longhorn 控制平面与数据平面分离架构 Longhorn 控制平面与数据平面分离架构 控制平面 (Control Plane) Longhorn Manager CSI Driver UI / API 职责:卷生命周期管理、调度、故障检测、快照/备份编排、Kubernetes 资源同步 运行方式:以 Kubernetes Deployment / DaemonSet 运行,依赖 etcd 存储状态 数据平面 (Data Plane) Engine Replica Instance Manager 职责:处理前端 iSCSI/NFS 请求、数据复制、快照创建、重建与校验 运行方式:以 Kubernetes Pod 运行,Engine 与 Replica 一一对应,数据不经过控制平面 底层存储层:宿主机磁盘 / 外部存储 / 云盘

2.1 核心组件及其职责

Longhorn 由五个核心组件构成,每个组件在控制平面或数据平面中承担明确的职责。理解这些组件的角色与交互方式是进行故障排查的基础。

组件名称 所属平面 核心职责 运行形态
Longhorn Manager 控制平面 卷生命周期管理、调度、故障检测、与 Kubernetes API Server 交互 Deployment (通常 2 副本)
CSI Driver 控制平面 实现 CSI 标准接口,负责卷的挂载/卸载、快照、扩容等操作 DaemonSet + sidecar
UI / API 控制平面 提供 Web 管理界面与 RESTful API,用于监控与运维 Deployment
Engine 数据平面 处理前端 I/O 请求,将写入同步复制到所有健康的 Replica Pod (每个卷一个 Engine)
Replica 数据平面 存储卷数据副本,负责数据持久化、快照与重建 Pod (每个副本一个 Replica)
Instance Manager 数据平面 管理 Engine 与 Replica 进程的生命周期,提供进程隔离与监控 DaemonSet (每个节点一个)

2.2 控制平面组件详解

2.2.1 Longhorn Manager

Longhorn Manager 是整个系统的大脑。它作为 Kubernetes Controller 运行,监听 Kubernetes 资源的变化(如 Pod、PVC、PV),并据此创建、更新或删除 Longhorn 自定义资源(Volume、Engine、Replica 等)。

  • 卷调度:根据节点资源、磁盘标签、反亲和性策略,决定 Replica 的放置位置。
  • 故障检测与恢复:监控 Engine 与 Replica 的健康状态,在检测到故障时触发重建或重新调度。
  • 快照与备份编排:协调快照创建、备份到远程存储(S3/NFS)以及恢复操作。
  • 与 Kubernetes 同步:确保 Longhorn 内部状态与 Kubernetes PV/PVC/StorageClass 保持一致。
故障排查提示:当卷无法创建或挂载时,首先检查 Longhorn Manager Pod 的日志。使用 kubectl logs -n longhorn-system <manager-pod> 查看调度决策与错误信息。

2.2.2 CSI Driver

CSI Driver 是 Longhorn 与 Kubernetes 存储生态的桥梁。它实现了 Container Storage Interface (CSI) 规范,使得 Kubernetes 组件(如 kubelet、external-provisioner)能够通过标准接口与 Longhorn 交互。

  • Controller Plugin:处理卷的创建、删除、快照、扩容等控制面操作。
  • Node Plugin:运行在每个节点上,负责卷的挂载、格式化、卸载等数据面操作。
  • Identity Plugin:向 Kubernetes 报告 Longhorn 的驱动信息与能力。

2.2.3 UI / API

Longhorn 提供了功能丰富的 Web UI 与 RESTful API,方便运维人员直观地管理存储资源。UI 通过调用 Longhorn Manager 的 API 实现所有功能,包括卷管理、节点管理、备份查看、系统设置等。

2.3 数据平面组件详解

2.3.1 Engine

Engine 是每个 Longhorn 卷的前端入口。它运行在卷被调度的节点上,负责接收来自 Pod 的 I/O 请求,并将写入操作同步复制到所有健康的 Replica。

  • I/O 转发:将读/写请求分发到所有 Replica,确保数据一致性。
  • 写入策略:采用 Quorum 机制,只有大多数 Replica 确认写入成功后,才向客户端返回成功。
  • 快照管理:在 Engine 层面创建快照,快照数据实际存储在 Replica 中。
  • 故障切换:当 Engine 所在节点故障时,Longhorn Manager 会在健康节点上启动新的 Engine,并重新连接到现有 Replica。
关键注意点:Engine 是单点吗?是的,每个卷只有一个活跃的 Engine。但 Engine 本身是无状态的,其故障可通过控制平面快速重建,且重建过程中数据不丢失(因为数据在 Replica 中)。这是控制平面与数据平面分离设计的典型体现。

2.3.2 Replica

Replica 是卷数据的实际存储单元。每个卷通常配置 2-3 个 Replica,分布在不同的节点上,以实现数据冗余与高可用。

  • 数据持久化:将数据以文件形式存储在宿主机的磁盘上(默认路径:/var/lib/longhorn/)。
  • 快照链:Replica 内部维护一个快照链,每个快照是一个只读的差分文件,当前写入指向活跃的读写层。
  • 重建:当某个 Replica 损坏或落后时,Engine 会触发重建流程,从健康的 Replica 同步数据。
  • 校验与修复:定期进行数据校验,确保 Replica 之间数据一致。

2.3.3 Instance Manager

Instance Manager 是数据平面的进程管理器。它作为 DaemonSet 运行在每个节点上,负责启动、监控和停止该节点上的 Engine 与 Replica 进程。

  • 进程隔离:每个 Engine 或 Replica 运行在独立的 Pod 中,由 Instance Manager 管理其生命周期。
  • 资源监控:收集 Engine/Replica 的 CPU、内存、I/O 指标,并上报给 Longhorn Manager。
  • 健康检查:定期检测 Engine/Replica 进程的健康状态,异常时通知控制平面进行恢复。
Engine 与 Replica 数据流交互 Engine 与 Replica 数据流交互 客户端 Pod (应用容器) Engine (I/O 协调者) Replica 1 (节点 A) Replica 2 (节点 B) Replica 3 (节点 C) I/O 请求 同步复制 同步复制 同步复制 写入流程:Pod → Engine → 同步复制到所有 Replica → 多数确认后返回成功

2.4 控制平面与数据平面分离的优势

这种架构设计为 Longhorn 带来了以下关键优势:

维度 传统耦合架构 Longhorn 分离架构
故障隔离 控制平面故障可能导致 I/O 中断 控制平面故障不影响正在运行的 I/O
升级影响 升级控制平面需要暂停数据服务 可独立升级控制平面,数据平面零停机
扩展性 控制平面成为瓶颈 数据平面可独立水平扩展
可观测性 监控数据混杂 控制平面与数据平面可分别监控
总结:Longhorn 通过控制平面与数据平面的清晰分离,实现了高可用、易维护与强扩展性。Engine 与 Replica 构成数据平面的核心,负责高性能 I/O 与数据冗余;Longhorn Manager、CSI Driver 与 UI 构成控制平面,负责智能调度与生命周期管理。理解这一架构是后续故障排查章节的基础。