Longhorn 分布式块存储

答案：

Longhorn 由五个核心组件构成分层架构：Longhorn Manager（控制平面）、Longhorn Engine（存储控制器/数据平面）、Replica（数据副本）、Instance Manager（进程生命周期管理）和 CSI Driver（Kubernetes 存储接口实现）。

组件职责与关系

架构数据流

graph TD
    subgraph K8s["Kubernetes"]
        CSI["PVC → StorageClass → Longhorn CSI Driver"]
    end
    K8s -->|"gRPC"| Manager
    subgraph Manager["Longhorn Manager (DaemonSet)"]
        Scheduler["Scheduler"]
        CRD["CRD Watch"]
        Webhook["Webhook"]
    end
    Manager -->|"进程管理"| InstanceMgr
    subgraph InstanceMgr["Instance Manager (DaemonSet)"]
        Engine["Engine Process"]
        Replica["Replica Process(s)"]
    end

核心职责分界

• Longhorn Manager：不做数据 I/O，只做控制和编排。监听 Volume / Engine / Replica 等 CRD，通过 Instance Manager API 下发创建/删除进程的指令。
• Instance Manager：不包含业务逻辑，仅负责 Engine/Replica 进程的 fork、健康检查和重启。Engine 和 Replica 进程通过 gRPC 与 Instance Manager 通信。
• Engine：承担所有数据路径职责，包括 read/write I/O、副本间数据同步、snapshot 管理、与外部备份目标通信。
• Replica：仅负责本地数据存储和响应 Engine 的读写请求，不参与 I/O 路由决策。

答案：

Longhorn Volume 的 I/O 路径采用 iSCSI 块设备协议实现从 Pod 所在节点到 Engine 所在节点的远程挂载，Engine 再通过内部 TCP 协议将写操作同步到所有 Replica。

完整读写路径

graph TD
    Pod["Pod（应用程序）"]
    BlockDev["/dev/longhorn/<volume-name>（块设备）"]
    Initiator["iSCSI Initiator（open-iscsi）<br/>在 Pod 所在节点上"]
    Target["iSCSI Target（tgt / LIO）<br/>在 Engine 进程中<br/>（iSCSI 协议，TCP 3260）"]
    Engine["Longhorn Engine（存储控制器）"]
    Replica["Replica 1, Replica 2, Replica 3<br/>各节点上的 Sparse File"]

    Pod --> BlockDev
    BlockDev --> Initiator
    Initiator -->|"iSCSI 协议，TCP 3260"| Target
    Target --> Engine
    Engine -->|"写操作：并行写入所有 Replica"| Replica

iSCSI 协议的作用

Longhorn Engine 内置 iSCSI Target 实现（基于 tgt 或 LIO），对外暴露为 iSCSI 设备。Pod 所在节点的 iSCSI Initiator（open-iscsi）通过 TCP 3260 端口连接 Engine，将远端块设备映射为本地 /dev/longhorn/<volume-name> 设备。

iSCSI 在此处的核心价值：

• 跨节点块设备挂载：Pod 和 Engine 可以位于不同节点，iSCSI 作为标准 SAN 协议实现远程块设备访问。
• 标准内核支持：Linux 内核原生支持 iSCSI Initiator，无需额外内核模块。
• 与 Kubernetes 兼容：CSI Node Plugin 调用 iscsiadm 完成登录和挂载，完全符合 Kubernetes 卷挂载生命周期。

写入路径细节

1. 应用向 /dev/longhorn/pvc-xxx 写入数据。
2. iSCSI Initiator 将写请求封装为 iSCSI PDU，通过 TCP 发送给 Engine 的 iSCSI Target。
3. Engine 收到写入后，将数据写入自身的 Frontend I/O buffer，然后并行向所有健康 Replica 发送写入请求。
4. 根据 Write Tolerance 策略（默认 Quorum），Engine 等待足够数量 Replica 确认后返回写入成功。
5. Replica 将数据写入本地 Sparse File（链式快照结构），并更新 Metadata。

读取路径细节

1. 应用从块设备读取数据。
2. iSCSI Initiator 将读请求转发给 Engine。
3. Engine 从任意一个健康的 Replica 读取（默认轮询），直接返回，无 Quorum 判断。

答案：

Longhorn 采用多副本同步写入机制，通过 Quorum（法定人数） 保证数据一致性和可用性。每个 Volume 可配置多个 Replica（默认 3），Engine 负责在写入时将数据同步分发给所有 Replica。

副本数量与容错能力

Quorum 机制

Longhorn 使用多数派写入确认策略：

• 默认写入 Quorum = floor(n/2) + 1（n 为 Replica 数量）。
• Engine 发送写入请求到所有 Replica，等待至少 Quorum 数量的 Replica 确认成功后才向上层返回写入成功。
• 未确认成功的 Replica 标记为 Out-of-Sync，触发 Rebuild 过程。
• 读取只需 1 个 Replica 响应即可，无需 Quorum。

副本状态转换

副本同步模式

• 同步写入：Engine 等待全部 Quorum 确认，保证写入一致性。
• Rebuild 同步：当副本失联后重新加入时，Engine 自动触发增量 Rebuild，仅同步差异快照链。Rebuild 期间 Volume 仍可正常读写，性能可能受影响。
• 快照链一致性：每个 Replica 独立维护快照链（Snapshot Chain），Engine 通过比较快照 ID 确定差量范围。

答案：

Longhorn Engine 作为每个 Volume 的存储控制器，其高可用依赖 进程级自动故障转移 机制。当 Engine 进程所在节点故障时，Longhorn Manager 自动将 Engine 迁移到健康节点并重新挂载，整个恢复过程对 Pod I/O 透明。

Engine 故障转移流程

1. 故障检测：Longhorn Manager 监测 Engine 进程状态，节点宕机或 Engine 崩溃后，Manager 在设定的超时（默认 10s）内确认 Engine 不可用。
2. 选择新节点：Scheduler 根据 Replica 分布选择最佳节点启动新 Engine。优先选择已有健康 Replica 的节点以减少网络跳数。
3. 启动新 Engine：通过 Instance Manager 在新节点上启动 Engine 进程，Engine 重新连接所有健康 Replica。
4. iSCSI 重连：CSI Node Plugin 通过 iSCSI 重新连接新 Engine，应用 I/O 恢复（短暂阻塞后恢复）。

Engine 高可用的关键参数

设计特点

• Engine 本身是无状态的（状态在 Replica 中），故障转移无数据迁移开销。
• Engine 进程轻量，恢复快速（秒级）。
• 与 Replica 连接恢复后自动校验快照链一致性，确定是否需要 Rebuild。

答案：

Longhorn 使用 链式快照（Snapshot Chain） 模型，基于 Copy-on-Write（CoW）策略实现。每个 Volume 的快照组成一个链，每个快照仅存储自上一个快照以来的增量数据。

快照存储结构

graph TD
    Head["Volume-Head（当前写入）"]
    Snap3["Snapshot-003（Δ3）"]
    Snap2["Snapshot-002（Δ2）"]
    Snap1["Snapshot-001（Δ1）"]
    Empty["Volume-Head 初始状态（空）"]

    Head --> Snap3
    Snap3 --> Snap2
    Snap2 --> Snap1
    Snap1 --> Empty

链式快照工作原理

1. 初始状态：Volume 创建时生成一个空的 Volume-Head 文件，所有写入进入此文件。
2. 创建快照：创建 Snapshot 时，当前 Volume-Head 被冻结并转化为快照文件（如 volume-snap-001.img），同时新建一个空的 Volume-Head 承接后续写入。
3. 继续写入：新的写入进入新的 Volume-Head。旧快照文件中的块如果被修改，新数据写入 Volume-Head 而不修改快照文件（CoW 语义）。
4. 读取数据：读取时从 Volume-Head 开始逐层向下查找，找到第一个包含该块数据的快照层返回。

增量快照特性

• 空间效率：每个快照仅包含差异数据，不复制完整 Volume。
• 即时创建：快照创建是 O(1) 操作，仅冻结 Head 和创建新 Head。
• 即时删除：删除快照时将其数据块合并到下一层。
• Purge 操作：删除最后一个快照时需要将快照数据合并回 Volume-Head，此为后台异步操作。

Replica 快照一致性

Engine 保证所有 Replica 在同一快照点的一致性。创建快照时，Engine 暂停 I/O，向所有 Replica 发送快照创建指令，所有 Replica 成功后在 Engine 侧记录快照完成。若某个 Replica 创建失败，Engine 标记该 Replica 为 Out-of-Sync 并触发 Rebuild。

答案：

Longhorn 支持将 Volume 快照备份到外部对象存储，实现异地容灾。Backup 由 Engine 进程驱动，直接从 Replica 读取数据并通过 Backupstore Driver 写入远程存储。

支持的外部备份目标

Backup 工作流程

1. 创建 Snapshot：用户或 Recurring Job 创建 Volume Snapshot。
2. 创建 Backup CRD：Longhorn Manager 创建 Backup CR 对象。
3. Engine 执行备份：Engine 读取指定 Snapshot 的数据块（跨所有 Replica 的 Snapshot Chain 差异数据）。
4. 去重与压缩：Engine 将数据块（默认 2MB block size）去重后压缩，上传至 Backupstore。
5. 更新元数据：备份完成后，将 Volume 元数据（Volume 大小、快照链信息等）写入 Backupstore 的 volume.cfg 文件。

Backupstore 存储结构

backupstore/
├── backups/
│   └── backup_<backup-id>.cfg
├── volumes/
│   └── <volume-name>/
│       ├── volume.cfg
│       └── blocks/
│           └── <block-id>.blk
└── locks/

备份增量机制

• 全量备份：首次备份上传 Volume 全部数据块。
• 增量备份：后续备份仅上传自上次备份以来的新增/变更数据块（通过比较旧 Snapshot Chain 和新 Snapshot Chain 的差异）。
• 块级去重：Engine 对每个 2MB 数据块计算哈希，已存在的块不再上传。

答案：

Disaster Recovery Volume（DR Volume）是 Longhorn 实现跨集群灾备的核心机制。DR Volume 在主集群故障时激活为正常 Volume，数据从 Backupstore 中增量同步恢复。

DR Volume 工作原理

1. 在主集群：创建 Backup（Snapshot → Backup），数据存储到共享的 Backupstore（如 S3/MinIO）。
2. 在灾备集群：创建 DR Volume，指向同一 Backupstore 和 Backup 记录。
3. 增量同步：DR Volume 持续从 Backupstore 拉取最新的增量备份数据，保持快照链与主集群同步。
4. 故障切换：主集群不可用时，执行 Activate 操作将 DR Volume 转为正常 Volume，创建 Engine 和 Replica，挂载到 Pod。

DR Volume 状态机

激活过程

1. Manager 停止增量同步。
2. 从最新的 Backup 创建 Replica。
3. 创建 Engine 并关联 Replica。
4. 挂载 Volume 到请求的 Pod。
5. 应用数据恢复到最新备份点。

关键限制

• DR Volume 不实时同步数据，RPO 等于最近一次 Backup 间隔。
• 激活操作为单向不可逆，激活后无法回退到 Standby 状态。
• 建议结合 Recurring Job 设置合理的备份间隔以达到目标 RPO。

答案：

Longhorn CSI Driver 实现 Kubernetes CSI 规范 v1.x，负责 PVC → PV 的完整生命周期管理。架构分为 CSI Controller（控制面）和 CSI Node Plugin（数据面）两部分。

CSI 组件架构

PVC 创建完整流程

graph TD
    S1["1. PVC 提交 → external-provisioner 调用 CSI Controller CreateVolume"]
    S2["2. CSI Controller → Longhorn Manager API 创建 Volume CRD"]
    S3["3. Longhorn Manager Scheduler 选择节点 → 创建 Replica CRD"]
    S4["4. Instance Manager 启动 Replica 进程"]
    S5["5. Longhorn Manager 创建 Engine CRD → Instance Manager 启动 Engine"]
    S6["6. Engine 连接 Replica → Volume 状态变为 Healthy"]
    S7["7. Pod 调度到某节点 → kubelet 发起 NodeStageVolume / NodePublishVolume"]
    S8["8. CSI Node Plugin 执行 iscsiadm 登录 → 挂载块设备 → bind mount 到 Pod"]
    S9["9. Pod 启动，读写 /dev/longhorn/<volume-name>"]

    S1 --> S2
    S2 --> S3
    S3 --> S4
    S4 --> S5
    S5 --> S6
    S6 --> S7
    S7 --> S8
    S8 --> S9

CSI 关键操作说明

• CreateVolume：通过 Longhorn Manager gRPC API 创建 Volume 及关联的 Engine/Replica 资源。
• NodeStageVolume：触发 iSCSI 登录，将块设备映射到节点全局设备路径（/dev/longhorn/<volume-name>）。
• NodePublishVolume：将全局设备路径 bind mount 到 Pod 的 volume mount 路径。
• NodeUnpublishVolume：解绑 bind mount。
• NodeUnstageVolume：执行 iSCSI 登出。
• DeleteVolume：删除 Volume 及相关联的 Engine、Replica 资源。

答案：

Instance Manager 是 Longhorn v1.0.0 引入的进程生命周期管理组件，以 DaemonSet 形式在每个节点上运行，负责 Engine 和 Replica 进程的创建、健康监控和重启。

架构背景

在引入 Instance Manager 之前，Engine 和 Replica 进程由 Longhorn Manager 的 longhorn-engine 和 longhorn-replica 容器直接管理。该方式存在以下问题：

• Manager Pod 重启会级联重启所有 Engine 和 Replica 进程。
• Manager 升级期间 Engine 进程受影响。
• 进程管理职责与编排逻辑耦合。

Instance Manager 的两个实例

每个节点运行两种 Instance Manager：

进程生命周期管理

1. 进程创建：Longhorn Manager 通过 gRPC 调用 Instance Manager 的 ProcessCreate 接口，传入进程二进制路径和参数。Instance Manager fork 子进程。
2. 健康检查：Instance Manager 定期对子进程进行 gRPC 健康探测（ProcessGet 接口），并将状态上报给 Longhorn Manager。
3. 进程重启：子进程崩溃后，Instance Manager 可配置自动重启策略，重启失败则上报异常状态。
4. 进程删除：Longhorn Manager 调用 ProcessDelete 接口，Instance Manager 发送 SIGTERM 后等待退出，超时发送 SIGKILL。

进程管理优势

• 隔离性：Manager 升级/重启不影响已运行的 Engine/Replica 进程。
• 统一接口：通过 gRPC 标准接口管理进程，屏蔽底层 PID namespace 差异。
• 资源控制：Instance Manager 可对子进程施加 cgroup 限制，控制 CPU 和内存使用。

答案：

Longhorn 将 Kubernetes 节点映射为 Node CRD，每个 Node 可配置多个 Disk（物理存储路径），通过调度器和标签机制控制 Replica 的放置策略。

Node CRD 核心字段

Disk 管理

每个 Disk 对应节点上的一个挂载路径：

Node: worker-1
├── Disk: default (/var/lib/longhorn/)
│   ├── storageReserved: 30%   ← 预留空间不用于调度
│   ├── storageMaximum: 200Gi  ← 调度上限
│   └── tags: ["ssd", "fast"]
└── Disk: archive (/mnt/archive/)
    ├── storageReserved: 10%
    ├── storageMaximum: 1Ti
    └── tags: ["hdd", "archive"]

Disk 调度策略

Longhorn Scheduler 在为 Replica 选择位置时考虑以下因素：

1. Disk 空间充足：排除空间不足（考虑 storageReserved 和 storageMaximum）的磁盘。
2. Disk 标签匹配：匹配 Volume 的 Disk Selector 标签。
3. Node 标签匹配：匹配 Volume 的 Node Selector 标签。
4. 反亲和性：同一 Volume 的多个 Replica 默认不调度到同一节点。
5. Data Locality：根据 Data Locality 策略决定是否将 Replica 调度到 Engine 所在节点。

磁盘状态监控

Longhorn Manager 持续监控每个 Disk 的状态：

答案：

Longhorn 实现了一套多维度 Replica 调度策略，包括自动均衡（Replica Auto Balance）、数据本地性（Data Locality）和反亲和性调度，确保数据分布合理且性能最优。

调度策略分类

Replica Auto Balance 三种模式

Data Locality 数据本地性

调度优先级

1. Node/Disk 标签匹配（Selector）
2. 反亲和性检查（Replica Soft/Hard Anti-Affinity）
3. Data Locality 策略
4. 磁盘空间充足性
5. Replica Auto Balance 策略
6. 负载排序（选空闲空间最大/负载最小的节点）

标签选择器示例

apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: demo-volume
spec:
  numberOfReplicas: 3
  dataLocality: best-effort
  replicaAutoBalance: best-effort
  nodeSelector:
    - zone: "zone-a"
  diskSelector:
    - ssd

答案：

Recurring Job 是 Longhorn 内置的定时任务机制，支持按 Cron 表达式定时执行 Snapshot、Backup、Snapshot Cleanup 和 Filesystem Trim 等操作。Recurring Job 通过 CRD 定义，可关联到单个 Volume 或 Volume Group。

支持的 Job 类型

Recurring Job CRD 示例

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: daily-backup
spec:
  cron: "0 2 * * *"
  task: "backup"
  groups: []
  labels: {}
  retain: 7                # 保留最近 7 个备份
  concurrency: 1           # 同一 Volume 最多同时执行 1 个此类型的 Job
  parameters:
    fullBackupInterval: 7  # 每 7 次增量备份后做一次全量备份

Volume 关联 Recurring Job

apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: demo-volume
spec:
  recurringJobSelector:
    matchLabels:
      backup-policy: daily

保留策略

• retain 字段控制保留的快照/备份数量。
• 超出数量的旧快照自动删除（先删除最旧的）。
• 快照清理按 Volume 粒度执行，不跨 Volume 计算。

并发控制

• concurrency 控制同一 Volume 上同一类型 Job 的最大并发数。
• 设置为 1 时，如果前一个 Job 仍在执行，新触发的 Job 被跳过。
• 不同 Volume 之间的 Job 并发不受此限制。

答案：

Longhorn 支持对已挂载的 Volume 进行在线扩容（Online Expansion），无需停止 Pod 或卸载 Volume。扩容涉及两层：Longhorn Volume 块设备层和文件系统层。

扩容流程

1. 修改 PVC Spec：用户或控制器修改 PVC 的 spec.resources.requests.storage 增大容量。
2. CSI Controller 响应：external-resizer 检测到 PVC 变更，调用 CSI Controller 的 ControllerExpandVolume。
3. Longhorn Manager 扩容 Volume：Manager 更新 Volume CRD 的 spec.size，并通知 Engine 进程调整块设备大小。
4. Engine 更新 iSCSI Target：Engine 更新 iSCSI Target 的 LUN 大小。
5. CSI Node Plugin 扩容块设备：Node Plugin 重新扫描 iSCSI 设备并更新块设备大小。
6. 文件系统扩容：Node Plugin 调用文件系统特定工具（resize2fs / xfs_growfs）扩展文件系统到新大小。

扩容约束

StorageClass 配置

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  fromBackup: ""
  fsType: "ext4"

扩容注意事项

• 扩容过程对上层 I/O 透明，不影响 Pod 正常运行。
• Volume 扩容后，Replica 对应 Sparse File 的大小会自动扩容。
• 扩容不会自动触发快照或备份，建议扩容后立即创建快照。

答案：

Longhorn 支持从现有 Volume 的 Snapshot 创建克隆（Clone），克隆操作在 Snapshot 层面执行，生成一个独立的 Volume，与源 Volume 共享底层数据块。

Clone 工作流程

1. 选择源 Snapshot：指定源 Volume 的某个 Snapshot 作为克隆源。
2. 创建 Clone Volume：Longhorn Manager 创建新的 Volume CRD，其 Snapshot Chain 指向源 Snapshot 作为基础层。
3. 创建 Replica：新 Replica 的 Sparse File 链基址指向源 Snapshot 的数据文件。
4. 共享数据：Clone Volume 和源 Volume 的旧 Snapshot 共享底层数据块，新写入分别进入各自的 Volume-Head。
5. 独立性：Clone 创建后可独立写入、创建快照、备份，与源 Volume 完全解耦。

Clone 特性

Clone CRD 示例

apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: clone-volume
spec:
  fromBackup: ""
  numberOfReplicas: 3
  dataSource: |
    kind: Volume
    name: source-volume
    snapshot: snapshot-001    

典型应用场景

• 开发/测试环境：从生产数据快照克隆出测试数据。
• 数据恢复验证：克隆备份数据以验证可恢复性。
• 数据分析：为分析任务提供生产数据的只读副本。

答案：

Longhorn 通过内置的 Share Manager 组件实现 RWX（ReadWriteMany）访问模式。Share Manager 在每个 Volume 的 Engine 所在节点运行一个 NFS Ganesha 服务器，将块设备通过 NFSv4 协议导出为可多节点同时挂载的文件系统。

RWX 访问模式的架构差异

Share Manager 架构

graph TD
    PodA["Pod-A (Node-1)<br/>NFS Client"]
    PodB["Pod-B (Node-2)<br/>NFS Client"]
    PodC["Pod-C (Node-3)<br/>NFS Client"]
    PodA --> Ganesha["NFS Ganesha Server<br/>(Share Manager Pod)"]
    PodB --> Ganesha
    PodC --> Ganesha
    Ganesha --> BlockDev["/dev/longhorn/&lt;volume-name&gt;"]
    BlockDev --> Engine["Longhorn Engine (iSCSI)"]
    Engine --> Replica1["Replica"]
    Engine --> Replica2["Replica"]
    Engine --> Replica3["Replica"]

Share Manager 工作原理

1. Volume 创建：Volume 按正常流程创建（Engine + Replica）。
2. Share Manager 启动：当 Volume 被以 RWX 模式请求时，Longhorn Manager 创建 Share Manager Pod。
3. NFS 导出：Share Manager 内的 NFS Ganesha 服务器将块设备格式化为文件系统（如 ext4/xfs）并通过 NFSv4 导出。
4. Pod 挂载：CSI Node Plugin 在 Pod 所在节点执行 NFS mount 而非 iSCSI 登录。
5. 数据路径：Pod → NFS Client → NFS Ganesha → 块设备 → Engine → Replica。

RWX Volume 配置示例

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: shared-data
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: longhorn
  resources:
    requests:
      storage: 10Gi

限制与权衡

答案：

Longhorn 支持 Storage Network 功能，将 Engine 与 Replica 之间的数据流量隔离到专用网络接口，与 Kubernetes 管理流量和 iSCSI 前端流量分离，避免存储 I/O 争抢应用网络带宽。

存储网络架构

graph TD
    Net1["Kubernetes 管理网络<br/>(API Server, CSI 通信, Manager 管控)"]
    Net2["iSCSI 前端网络<br/>(Pod ↔ Engine iSCSI Target)"]
    Net3["Storage 专用网络 (data engine)<br/>(Engine ↔ Replica 数据同步)"]
    Net1 --- Net2 --- Net3

配置方式

通过 Setting CRD 配置 Storage Network：

apiVersion: longhorn.io/v1beta2
kind: Setting
metadata:
  name: storage-network
value: |
  {
    "multusNicName": "storage-net",
    "ipRanges": ["10.10.0.0/24"],
    "excludeSubnets": [],
    "nfsOptions": ""
  }  

实现原理

1. Multus CNI 集成：Longhorn 依赖 Multus CNI 为 Instance Manager Pod 分配额外的网络接口。
2. Instance Manager 双栈：Instance Manager Pod 拥有管理网络 IP 和存储网络 IP 两个地址。
3. Engine/Replica 绑定：Engine 和 Replica 进程启动时绑定到存储网络 IP，内部同步流量走存储网络。
4. iSCSI 不变：iSCSI 前端流量仍走默认网络，保证 Pod 连接兼容。

关键参数

答案：

Longhorn 内置 Prometheus 指标暴露端点，通过 ServiceMonitor 或 PodMonitor 与 Prometheus Operator 集成，提供 Volume、Node、Disk、Engine、Replica 等维度的全方位监控指标。

指标暴露来源

关键 Prometheus 指标

ServiceMonitor 配置

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: longhorn-prometheus-servicemonitor
  namespace: longhorn-system
  labels:
    name: longhorn-prometheus-servicemonitor
spec:
  selector:
    matchLabels:
      app: longhorn-manager
  endpoints:
    - port: manager
      path: /metrics
      interval: 30s

Grafana Dashboard

Longhorn 提供预置的 Grafana Dashboard：

• Longhorn Overview：集群级概览（总容量、Volume 数量、节点状态）。
• Longhorn Volume：单 Volume 详细指标（IOPS、延迟、吞吐、副本状态）。
• Longhorn Node：节点级存储资源使用。

告警规则建议

答案：

Longhorn 支持多层次的故障恢复机制，核心包括 Replica Rebuild（副本重建）和 Volume Degraded Recovery（卷降级恢复），实现从节点故障、磁盘故障、Replica 数据不一致等场景自动恢复。

Replica Rebuild（副本重建）

当 Replica 因节点宕机、网络故障或磁盘故障变为不可用时，Engine 检测到 Replica 数量低于配置值后触发 Rebuild：

1. 故障检测：Engine 定期向所有 Replica 发送心跳，超时未响应标记为 Failed。
2. 调度新 Replica：Longhorn Manager Scheduler 选择健康节点，创建新 Replica。
3. 数据同步：Engine 从健康 Replica 读取数据块，写入新 Replica。同步过程中新 Replica 状态为 Rebuilding。
4. 完成同步：所有数据块同步完成后，新 Replica 转为 Healthy，Volume 恢复正常。

Rebuild 特性

Degraded 状态处理

Volume 处于 Degraded 状态时（至少 1 个 Replica 不健康）：

• 读操作：Engine 从健康 Replica 读取。
• 写操作：Engine 仅写入健康 Replica，容忍剩余健康副本数 >= Quorum。
• 自动恢复：Manager 自动调度新的 Replica 启动 Rebuild。

手动恢复场景

故障恢复参数

答案：

Longhorn 提供 Node Drain（节点驱逐）和 Disk Eviction（磁盘驱逐）功能，支持有计划地将存储工作负载从节点或磁盘迁移走，实现节点维护或磁盘退役。

Node Drain 流程

# 1. 标记节点不可调度
kubectl cordon <node-name>

# 2. 设置 Longhorn Node 驱逐
kubectl -n longhorn-system patch node <node-name> \
  --type='merge' \
  -p '{"spec":{"allowScheduling": false, "evictionRequested": true}}'

1. 禁止新调度：allowScheduling: false 禁止新 Replica 调度到此节点。
2. 标记驱逐：evictionRequested: true 触发驱逐流程。
3. Replica 迁移：Longhorn Manager 为节点上的每个 Replica 在其他节点创建新副本，数据同步完成后删除旧副本。
4. Engine 迁移：如果 Engine 在此节点，Manager 自动将 Engine 迁移到其他节点。
5. 完成确认：所有 Replica 和 Engine 迁出后，节点可安全维护。

Disk Eviction 流程

kubectl -n longhorn-system edit node <node-name>
# 删除对应 disk 配置或设置 allowScheduling: false

磁盘级别的驱逐：

• 删除 Disk 配置后，Manager 自动将磁盘上的 Replica 迁移到同节点其他磁盘或不同节点。
• 仅影响被驱逐磁盘上的 Replica，同节点其他磁盘不受影响。

Kubernetes Node Drain 集成

Longhorn 支持 Kubernetes 原生的 kubectl drain 命令：

• Longhorn Manager 监听节点 Eviction API，自动执行 Replica 迁移。
• 节点上所有 Replica 迁移完成后，Pod 驱逐才继续执行。

维护完成后恢复

kubectl -n longhorn-system patch node <node-name> \
  --type='merge' \
  -p '{"spec":{"allowScheduling": true, "evictionRequested": false}}'

kubectl uncordon <node-name>

维护操作建议

答案：

Longhorn v2（v1.5.x 开始逐步引入，v1.6.x/v1.7.x 逐步完善）引入了 SPDK（Storage Performance Development Kit）存储引擎和 Instance Manager 重构，在性能和架构上实现了显著飞跃。

v1 vs v2 架构对比

SPDK 存储引擎

SPDK 是 Intel 开源的用户态高性能存储开发套件，核心优势：

• 用户态 I/O：绕过 Linux 内核 I/O 栈，使用用户态轮询驱动（UIO/VFIO），消除内核上下文切换开销。
• NVMe-oF：支持 NVMe over Fabrics（NVMe-oF/TCP），替代 iSCSI 协议，提供更高带宽和更低延迟。
• 无锁设计：基于线程本地存储和无锁数据结构，最大化 CPU 亲和性。

Instance Manager v2 重构

• 统一进程模型：不再区分 Engine Instance Manager 和 Replica Instance Manager，统一为一个 SPDK Application。
• 内存管理优化：使用 HugePages（大页内存）减少 TLB miss。
• CPU 亲和性：可将 Engine/Replica 绑定到特定 CPU 核心。

升级路径

Longhorn 设计为 v1 和 v2 共存：

• 已有 v1 Volume 继续使用 v1 Engine。
• 新建 Volume 可选择 v2 Data Engine。
• 支持在线将 Volume 从 v1 Engine 迁移到 v2 Engine。

v2 Data Engine 配置

apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: spdk-volume
spec:
  dataEngine: "v2"          # 指定使用 v2 引擎
  numberOfReplicas: 3
  backendStoreDriver: "v2"

答案：

Longhorn 的性能优化涉及副本配置、数据本地性、存储网络隔离、底层磁盘选择和内核参数调优等多个维度。

Replica Count 策略

• 每次写入需要等待 Quorum 数量 Replica 确认，Replica 越多写入延迟越高。
• 读取只需 1 个 Replica 响应，Replica 数量不影响读性能。

Data Locality 优化

Storage Network 隔离

启用 Storage Network 后，Engine 和 Replica 之间的同步流量走专用网络接口：

• 消除存储流量对应用网络带宽的争抢。
• 建议使用 10Gbps 或更高带宽的专用网卡。
• 配合 Jumbo Frame（MTU 9000）进一步提升吞吐。

磁盘和文件系统选择

内核参数调优

# I/O Scheduler 设置为 none（NVMe）或 noop
echo none > /sys/block/nvme0n1/queue/scheduler

# 增大内核网络缓冲区
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728

# 增大 TCP 缓冲区（影响 iSCSI 和 Replica 同步）
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"

性能测试参考数据

答案：

Longhorn 通过 Helm Chart 部署在 longhorn-system 命名空间下，安装过程包括 CRD 注册、Manager / Instance Manager / CSI Driver 等组件部署以及 StorageClass 创建。

安装命令

helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultDataPath="/var/lib/longhorn" \
  --set defaultSettings.backupTarget="s3://mybucket@us-east-1/"

核心配置参数

安装前置条件

安装后验证

# 检查所有 Pod 运行状态
kubectl -n longhorn-system get pods

# 访问 Longhorn UI
kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80

# 确认 StorageClass
kubectl get storageclass longhorn

答案：

Longhorn 支持在线滚动升级（Live Upgrade），升级过程不中断 Volume I/O。升级引擎（Engine）和 Manager 分别独立执行，版本兼容性由 Longhorn 内部版本协议保证。

升级顺序

graph TD
    S1["1. Longhorn Manager（DaemonSet）"]
    S2["2. Longhorn CRD 版本迁移"]
    S3["3. Longhorn Instance Manager（v1）/ SPDK Instance Manager（v2）"]
    S4["4. Longhorn Engine（每个 Volume 独立升级）"]
    S5["5. Longhorn CSI Driver（Deployment + DaemonSet）"]
    S6["6. Longhorn UI"]

    S1 --> S2
    S2 --> S3
    S3 --> S4
    S4 --> S5
    S5 --> S6

Engine 在线升级流程

1. Manager 升级完成：新版本 Manager 运行后，检测到 Engine 版本低于目标版本。
2. 创建新 Engine：Manager 自动创建新版本 Engine 进程（使用新二进制）。
3. 切换连接：新 Engine 连接所有 Replica，通过快照链校验一致性。
4. iSCSI 切换：iSCSI Target 从旧 Engine 切换到新 Engine。切换过程短暂 I/O 阻塞（毫秒级），应用层可感知为短暂磁盘延迟波动。
5. 清理旧 Engine：确认新 Engine 正常工作后，删除旧 Engine 进程。

升级关键参数

升级注意事项

Helm 升级命令

helm repo update
helm upgrade longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --version <target-version> \
  --reuse-values

答案：

Longhorn 和 Ceph RBD 均为 Kubernetes 生态中的分布式块存储方案，但在架构复杂度、运维门槛、性能特征和应用场景上有显著差异。

核心对比

选型建议

答案：

Longhorn 与 OpenEBS 同为 CNCF 项目中的容器原生存储（Container Native Storage，CNS）方案，均以轻量、Kubernetes 原生为设计目标，但在存储引擎、快照机制和运维模型上存在差异。

核心对比

引擎选型对比

选型建议

答案：

Longhorn 和 Rook Ceph 两种对比实质上是"轻量容器原生存储 vs. Kubernetes Operator 管理的传统分布式存储"的对比。Rook 是 Ceph 的 Kubernetes Operator，让 Ceph 以云原生方式在 Kubernetes 中运行。

核心对比

存储类型覆盖

选型建议

答案：

Longhorn 通过 Kubernetes 命名空间隔离、RBAC 权限控制、Backup Target 租户隔离和 Longhorn UI 多命名空间支持，实现多租户环境下的存储资源隔离。

隔离维度

物理存储隔离

通过 Node/Disk 标签将不同租户的 Volume 调度到不同物理存储：

# 租户 A 的 PVC 只使用 tenant-a 标签的磁盘
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tenant-a-data
spec:
  storageClassName: longhorn-tenant-a
  resources:
    requests:
      storage: 10Gi
# 对应 StorageClass 配置 Disk Selector
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-tenant-a
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  diskSelector: "tenant-a"

备份目标隔离

每个租户配置独立的 Backup Target，数据物理隔离：

# 租户 A 的备份目标
apiVersion: longhorn.io/v1beta2
kind: Setting
metadata:
  name: backup-target
value: "s3://tenant-a-backup@region/"
# 租户 A 的凭据
apiVersion: v1
kind: Secret
metadata:
  name: tenant-a-backup-secret
  namespace: tenant-a
data:
  AWS_ACCESS_KEY_ID: <base64>
  AWS_SECRET_ACCESS_KEY: <base64>

RBAC 权限模型

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: longhorn-tenant-a
  namespace: tenant-a
rules:
  - apiGroups: ["longhorn.io"]
    resources: ["volumes", "engines", "replicas"]
    verbs: ["get", "list", "create", "delete"]
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: longhorn-tenant-a-binding
  namespace: tenant-a
subjects:
  - kind: Group
    name: tenant-a-users
roleRef:
  kind: Role
  name: longhorn-tenant-a
  apiGroup: rbac.authorization.k8s.io

限制说明

答案：

Longhorn 支持对备份数据进行 AES-256-GCM 加密，加密在 Engine 层执行，备份存储中保存的为密文数据块，解密密钥通过 Kubernetes Secret 管理。

加密工作流程

1. 创建加密密钥 Secret：配置 CRYPTO_KEY_VALUE 为加密密钥。
2. 配置 Backup Target Credential：在 Backup Target Secret 中引用加密密钥。
3. Engine 加密：执行 Backup 时，Engine 使用密钥对每个 2MB 数据块进行 AES-256-GCM 加密，生成密文块上传。
4. Engine 解密：执行 Restore 时，Engine 使用同一密钥解密数据块，还原为明文后写入 Replica。

加密密钥 Secret 配置

apiVersion: v1
kind: Secret
metadata:
  name: backup-secret
  namespace: longhorn-system
data:
  AWS_ACCESS_KEY_ID: <base64-encoded>
  AWS_SECRET_ACCESS_KEY: <base64-encoded>
  # 以下为加密专用字段
  CRYPTO_KEY_VALUE: <base64-encoded-encryption-key>    # 加密密钥（32 字节 Base64 编码）
  CRYPTO_KEY_PROVIDER: "secret"                         # 密钥来源（当前仅支持 "secret"）
  CRYPTO_KEY_CIPHER: "AES-256-GCM"                      # 加密算法（当前仅支持 AES-256-GCM）

加密密钥生成

# 生成 32 字节随机密钥
openssl rand -base64 32

# 或使用 hex 密钥
openssl rand -hex 32

Backup Target 配置

apiVersion: longhorn.io/v1beta2
kind: Setting
metadata:
  name: backup-target
value: "s3://my-secure-bucket@us-east-1/"
apiVersion: longhorn.io/v1beta2
kind: Setting
metadata:
  name: backup-target-credential-secret
value: "backup-secret"

加密特性

密钥安全建议

答案：

Longhorn 故障排查遵循组件分层原则，从 Volume 状态到 Engine、Replica、Instance Manager、Node 逐层下钻定位根因。

常见故障速查表

标准排查流程

步骤 1：检查整体集群状态

kubectl -n longhorn-system get nodes.longhorn.io
kubectl -n longhorn-system get volumes.longhorn.io
kubectl -n longhorn-system get pods

步骤 2：检查故障 Volume 详情

# 查看 Volume 状态和关联资源
kubectl -n longhorn-system describe volume <volume-name>

# 查看 Replica 分布和状态
kubectl -n longhorn-system get replicas -l longhornvolume=<volume-name> -o wide

步骤 3：检查 Engine 日志

# 获取 Engine Instance Manager Pod
ENGINE_IM=$(kubectl -n longhorn-system get pod \
  -l longhorn.io/instance-manager-type=engine \
  -o jsonpath='{.items[0].metadata.name}')

# 查看 Engine 进程日志
kubectl -n longhorn-system logs $ENGINE_IM --tail=200

步骤 4：检查 iSCSI 连接状态

# 在 Pod 所在节点执行
iscsiadm -m session
lsblk | grep longhorn

常见问题修复

日志收集命令

# 收集 Longhorn 全部组件日志
kubectl -n longhorn-system logs -l app=longhorn-manager --tail=500 > manager.log
kubectl -n longhorn-system logs -l longhorn.io/component=instance-manager --tail=500 > instance-manager.log
kubectl -n longhorn-system logs -l longhorn.io/component=csi-plugin --tail=500 > csi.log

# 收集 Support Bundle（推荐）
kubectl -n longhorn-system exec -it deploy/longhorn-driver-deployer -- \
  longhornctl install-manager \
  && longhornctl export-support-bundle --output support-bundle.zip

答案：

部署规划

副本配置

备份策略

性能调优

安全配置

监控与告警

升级与维护

容量规划

灾难恢复演练