04-Harvester 存储管理

1. 为什么 Harvester 的存储要单独成篇

前三篇已经完成了 Harvester 的定位、部署和虚拟机生命周期管理。到了第四篇，重点转向平台能不能长期稳定承载业务数据。虚拟机是否能创建成功，只说明控制平面、镜像、网络和调度大体可用；虚拟机是否能在节点维护、磁盘故障、容量增长、快照恢复和备份演练中保持可控，主要取决于存储管理。

Harvester 默认使用 Longhorn 为虚拟机和集群工作负载提供分布式块存储。对运维人员来说，这既是优势，也是新的复杂度来源。优势在于：不需要先采购独立 SAN，就能在普通 x86 节点上获得多副本、快照、备份、在线扩容和节点级容错能力。复杂度在于：每个虚拟机磁盘背后不再是一块传统 LUN，而是 Kubernetes PVC、Longhorn Volume、Replica、Engine、Instance Manager、节点磁盘、StorageClass、网络和调度策略共同作用的结果。

本文按生产运维视角展开，目标不是复述 UI 菜单，而是建立一套可落地的存储管理方法。读完之后，你应该能够回答五个问题：

1. Harvester 虚拟机磁盘从创建到挂载，背后经过哪些对象。
2. StorageClass、磁盘标签、副本数、数据本地性和迁移能力如何影响设计。
3. 什么时候应该使用默认 Longhorn，什么时候要拆分 SSD/HDD/NVMe 或引入第三方 CSI。
4. 快照、备份、恢复和卷扩容应该怎样验证，哪些操作不能随意做。
5. 当卷 Degraded、Replica 重建失败、VM Not-Ready 或存储网络异常时，应该按什么顺序排查。

本文的事实基础参考 Harvester v1.5/v1.7 官方文档、Longhorn 当前文档和 SUSE Harvester Support Matrix。Harvester 文档版本更新较快，生产集群仍应以目标版本官方文档、SUSE 标记的 Stable 版本和现场测试结果为准。

2. Harvester 存储对象的心智模型

在 Harvester UI 里，存储入口大致分为 Volumes、StorageClasses、VM Backups、VM Snapshots、Host Storage 和 Longhorn 相关页面。真正排障时，不要把这些入口当成互不相关的功能模块。它们都围绕同一个核心问题：某个工作负载需要一块持久化块设备，Harvester 如何把这个请求变成可调度、可复制、可迁移、可恢复的卷。

图中把 Harvester 存储对象整理成可复盘的心智模型，下面的内容会沿着这些边界继续展开。 这张图可以作为后续所有排障的入口。虚拟机看到的是磁盘，Kubernetes 看到的是 PVC，Longhorn 看到的是 Volume、Engine 和 Replica，物理层看到的是节点上的具体磁盘和网络路径。任何一层出问题，最终都可能表现为虚拟机启动慢、迁移失败、磁盘只读、备份失败或卷处于 Degraded。

2.1 从虚拟机磁盘到 PVC

创建虚拟机时，Harvester 会根据根盘、数据盘和镜像选择生成相应的 PVC。对于从 VM Image 创建的磁盘，官方文档特别提醒：卷大小必须大于或等于底层镜像的虚拟大小，尤其是 qcow2 镜像，因为它的虚拟大小往往大于物理文件大小。如果根盘小于镜像虚拟大小，卷可能损坏。这个规则应该写入模板规范，而不是靠创建者临场判断。

常见卷来源可以分成三类：

创建卷后，Harvester 的对象状态并不等于来宾系统内部已经可用。对于数据盘，还要在虚拟机内部完成分区、文件系统、挂载、应用配置和监控采集。平台侧只负责把块设备稳定交付给 VM；应用侧如何使用这块盘，仍然要按操作系统和业务规范管理。

2.2 Longhorn Volume、Engine 与 Replica

Longhorn 把一个 Volume 拆成 Engine 和多个 Replica。Engine 负责对接工作负载读写，Replica 分布在不同节点或磁盘上承载副本数据。默认高可用场景下，Harvester 的 harvester-longhorn StorageClass 副本数为 3。官方文档也明确说明，单节点集群如果继续使用 3 副本默认 StorageClass，Longhorn 无法创建足够副本，卷会在 UI 中显示 Degraded。

这意味着单节点实验环境与生产三节点环境不能复用同一套存储判断标准：

不要把 Degraded 简单理解为“平台坏了”。在单节点集群上，3 副本卷 Degraded 是设计与现实不匹配；在三节点集群上，Degraded 可能意味着某个节点、磁盘、Replica、网络或调度条件出现问题。判断前先确认副本策略和节点数量。

3. StorageClass 是存储策略，不只是下拉选项

Harvester 官方文档把 StorageClass 描述为 Longhorn 如何供给卷的策略描述。它可以映射副本策略、节点调度策略、磁盘调度策略等。在传统虚拟化里，类似概念可能叫“存储配置文件”或“存储策略”。如果团队只保留一个默认 StorageClass，短期最省事，长期会把性能、容量、保护等级和调度约束混在一起。

3.1 默认 StorageClass 的边界

harvester-longhorn 适合作为通用生产默认值，但不应该承担所有场景。官方文档列出的关键参数包括：

官方文档还说明，StorageClass 创建后除描述外其他设置固定。因此，命名和参数设计要在创建前想清楚。不要用 fast、prod 这种含义过宽的名字，应把副本、介质、用途或调度条件写进名称。

3.2 建议的 StorageClass 分层

一个实用的中小型 Harvester 集群可以从下面几类开始：

这里的重点不是照抄名称，而是把策略外显。创建 VM 或数据盘时，使用者应能从 StorageClass 名称看出“它大致适合什么，不适合什么”。

图中把 StorageClass 分层思路整理为容量、性能、保护策略和适用工作负载之间的关系。 这张决策图适合做成运维规范的一部分。它提醒创建者先判断业务重要性、性能特征和删除保护，再选择 StorageClass，而不是先看哪个下拉选项排在第一。

3.3 数据本地性与迁移能力

Harvester 文档列出数据本地性选项：disabled 是默认值，Longhorn 可以但不保证在工作负载所在节点放置本地副本；best-effort 会尽量在使用卷的 Pod 所在节点放置一个副本。Longhorn 还有 strict-local，但 Harvester 不支持该选项，因为它会影响 VM Live Migration 等操作。

这点非常重要。很多人会自然地认为“数据越贴近计算越好”，但在虚拟化平台中，迁移、维护和故障接管同样重要。对于数据库、低延迟服务或边缘单节点环境，可以评估 best-effort；对于需要频繁迁移或跨节点维护的通用 VM，默认策略通常更稳。不要为了追求局部性能，让卷变成只能在少数节点上工作的资源。

4. 节点磁盘、标签与容量规划

Harvester 存储管理不能只看 StorageClass，还要看节点上的实际磁盘。Longhorn 的副本最终落在节点磁盘路径上。一个三节点集群即使每个节点都显示 Ready，也可能因为磁盘大小不一致、剩余容量不足、磁盘标签不完整或某个节点 I/O 异常，导致卷调度和重建出现问题。

4.1 节点磁盘接入原则

建议把系统盘和数据盘分开规划。系统盘承载 Harvester OS、Kubernetes 组件和平台运行时；数据盘承载 Longhorn 副本。虽然实验环境可以使用有限磁盘完成部署，但生产环境应尽量避免把所有东西混在同一块盘上。

磁盘接入时要确认：

1. 设备是否稳定识别，重启后路径不会漂移。
2. 文件系统、挂载点和权限是否符合 Harvester/Longhorn 要求。
3. 每个节点是否有足够相近的容量和性能。
4. 是否需要给磁盘打标签，例如 SSD、NVMe、HDD、ColdStorage。
5. 是否需要把不同业务的卷限制在特定节点或磁盘池。

Harvester 官方文档在 HDD 场景中建议先在 Host 页面添加 HDD 并指定磁盘标签，再创建使用这些标签的新 StorageClass。这个顺序不能反过来。先创建了引用标签的 StorageClass，但节点磁盘没有对应标签，后续 PVC 就可能因为找不到可调度磁盘而一直 Pending。

4.2 容量放大不是简单乘以副本数

最直观的容量计算是“业务数据量 × 副本数”。例如 2 TiB 数据，3 副本至少需要 6 TiB 原始容量。但生产规划还要考虑更多因素：

建议采用下面的粗略方法做初始规划：

可用业务容量 = 原始磁盘容量 / 副本数 × 可用水位

其中可用水位不建议按 100% 计算。对于生产集群，保守起点可以按 60%-70% 估算，再根据业务变更率、快照保留周期、备份窗口和节点扩容节奏调整。容量规划的目标不是把磁盘用满，而是在单节点故障、Replica 重建和业务增长同时发生时仍然有操作空间。

4.3 磁盘标签的治理

磁盘标签很容易从“治理工具”变成“隐形故障源”。如果标签命名随意，StorageClass 就会出现不可解释的调度失败。建议使用固定标签表：

如果 Harvester UI 的标签能力不足以表达复杂故障域，至少在 CMDB 或运维文档中维护节点、磁盘、标签和 StorageClass 的对应关系。否则排障时只能逐个点开页面猜测。

5. 存储网络：什么时候需要单独配置

Longhorn 副本复制会产生节点间存储流量。小型实验环境可以让它走默认管理网络，但生产集群中，管理流量、虚拟机业务流量、镜像导入流量、监控流量和 Longhorn 复制流量混在一起，会让故障边界变得模糊。当某个网络拥塞时，你很难判断是业务流量把存储拖慢，还是存储重建把业务网络打满。

Harvester 官方文档说明，可以使用专用 storage network 隔离 Longhorn replication traffic，以获得更好的带宽和性能；同时也提醒不要直接修改 Longhorn 设置，否则可能造成非预期行为。文档还说明，storage network 目前只适用于 Longhorn V1 Data Engine，不支持 V2 Data Engine。

5.1 配置前置条件

配置 storage network 前，需要先确认：

1. 交换机 VLAN 已正确配置，所有相关节点可达。
2. Harvester cluster network 和 VLAN network 已覆盖所有节点。
3. IP 地址池不与 Kubernetes 集群网络冲突。
4. IP 地址池足够覆盖节点、磁盘和镜像上传下载需求。
5. Whereabouts CNI 正常。
6. 所有 VM 已停止，所有挂载 Longhorn 卷的 Pod 已停止。
7. 镜像上传、下载和重要存储操作已完成。

官方文档给出 IP 数量估算公式：

Required number of IPs = (Number of nodes * 2) + (Number of disks * 2) + Number of images to be downloaded or uploaded

这个公式很适合做变更前检查。很多 storage network 故障并不是 VLAN 不通，而是 IP 池太小。后续新增节点、添加磁盘或并发导入镜像时，Longhorn 相关 Pod 可能因为拿不到地址而无法启动。

图中把存储网络配置前置条件拆成节点、接口、交换机、MTU 和 Longhorn 组件几条检查线。 这张流程图强调了一个容易忽略的事实：storage network 不是一个无感开关。启用或变更时会影响 Longhorn 组件和工作负载，需要按变更流程执行。

5.2 验证 storage network 是否真正生效

配置完成后，不要只看 UI 显示 Enabled。至少要做四类检查：

kubectl get settings.harvesterhci.io storage-network -o yaml
kubectl get pods -n longhorn-system -l longhorn.io/component=instance-manager -o wide
kubectl get pods -n longhorn-system -l longhorn.io/component=instance-manager -o yaml | grep -A20 'k8s.v1.cni.cncf.io/network-status'
kubectl -n longhorn-system describe pod <instance-manager-pod>

重点看 storage-network setting 的 condition 是否为 configured，Longhorn instance-manager 和 backing-image-manager 是否 Ready，网络注解中是否出现类似 lhnet1 的接口，接口地址是否来自规划 IP 池。官方文档还建议进入不同 Longhorn Pod，通过绑定 storage network IP 的简单 HTTP 服务测试跨节点连通性。

如果出现 VM 卡在 Not-Ready、Longhorn manager 日志出现 replica rebuild 失败、Multus 分配 IP 失败或 no route to host，应优先检查 VLAN、节点网卡、IP 池、MTU 和 storage network 的网络注解，而不是先重启整个平台。

6. 创建、扩容与挂载数据卷

Harvester 的 Volume Management 支持创建空白卷、从镜像创建卷、编辑卷、克隆卷、导出为镜像和管理卷快照。日常生产中最常见的是给已有 VM 添加数据盘、扩容数据盘，以及在来宾系统内完成文件系统扩容。

6.1 创建空白数据卷

创建数据卷时建议先确认四个字段：

示例 PVC 结构可以作为理解对象关系使用：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data-01
  namespace: prod-app
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 200Gi
  storageClassName: harvester-longhorn
  volumeMode: Block

具体 YAML 以 Harvester 当前版本生成结果为准。对于 VM 磁盘，volumeMode: Block 很常见，因为虚拟机需要的是块设备，而不是直接挂载给 Pod 的文件系统目录。

6.2 给 VM 添加数据盘后的来宾系统操作

平台侧添加磁盘后，Linux 来宾系统中还要完成识别、分区、格式化和挂载。示例流程：

lsblk
sudo parted /dev/vdb --script mklabel gpt
sudo parted /dev/vdb --script mkpart primary xfs 0% 100%
sudo mkfs.xfs -f /dev/vdb1
sudo mkdir -p /data
sudo blkid /dev/vdb1
echo 'UUID=<replace-with-real-uuid> /data xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -a
df -hT /data

生产环境不要直接把 /dev/vdb1 写入 /etc/fstab，应使用 UUID 或稳定设备标识。添加 nofail 可以避免非关键数据盘异常导致系统启动卡死，但关键业务盘是否允许 nofail 要结合业务启动顺序判断。

6.3 扩容卷与文件系统

Harvester StorageClass 默认允许 Volume Expansion，但官方文档也说明扩容只能增加容量，不能缩小。扩容通常分成两段：

1. 平台侧编辑 PVC 或 Volume，把块设备容量增大。
2. 来宾系统内扩展分区和文件系统。

Linux 示例：

lsblk
sudo growpart /dev/vdb 1
sudo xfs_growfs /data
# ext4 文件系统则通常使用 resize2fs
df -hT /data

如果卷是根盘，操作前要确认发行版、分区布局、LVM 使用情况和备份状态。不要把“Harvester 支持扩容”理解成“所有来宾系统都会自动扩容文件系统”。平台提供更大的块设备，来宾系统内部仍然要完成自己的扩容步骤。

平台容量、来宾磁盘、分区或 LVM、文件系统和挂载点必须逐层验证，任一层没有扩展，业务看到的可用空间都不会真正增加。 扩容完成后应同时检查平台侧 Volume 状态和来宾系统文件系统。只检查其中一边都不完整。

7. 快照、备份与恢复：不要混用概念

快照和备份都能帮助恢复，但它们不是同一个东西。快照通常是集群内的短期回滚点，依赖当前存储系统；备份应写入外部备份目标，用于节点级、集群级或误删除场景下恢复。Harvester 支持 VM backup、VM snapshot、restore new VM、replace existing VM 等能力，但每种能力都有边界。

7.1 快照适合短期变更回滚

快照适合：

1. 系统补丁前短期保护。
2. 应用升级前短期保护。
3. 配置变更前快速回退。
4. 非数据库类小型 VM 的短期状态保存。

快照不适合：

1. 长期保留。
2. 替代离线备份或异地备份。
3. 高变更数据库的唯一保护手段。
4. 在不了解应用一致性的情况下频繁创建。

Harvester 文档提醒，创建备份或快照会让卷在集群中消耗额外空间，并且可以在 namespace 或 VM 级配置空间使用限制。这个限制不是装饰项。没有限制时，某些频繁快照或备份操作可能悄悄吞掉大量容量，最终影响正常卷写入和 Replica 重建。

7.2 备份适合跨故障域恢复

备份要先配置 backup target。生产环境至少要满足：

Harvester 官方文档说明，备份支持目前限制在 Longhorn volumes，Harvester 不能为外部存储中的卷创建备份。第三方 CSI 或外部存储场景下，必须确认它自己的快照、备份和恢复能力，不要默认 Harvester 原生 VM Backup 会覆盖所有卷。

7.3 Ubuntu DHCP 与 machine-id 风险

前一篇虚拟机管理已经提到，Harvester 文档特别提醒：恢复后的 VM 会保留原 VM 的 machine ID。如果 Ubuntu 没有设置 dhcp-identifier: mac，netplan 默认可能使用 machine ID 作为 DHCP client identifier，恢复后的 VM 可能拿到和原 VM 相同的 IP，造成网络冲突。

这条经验应该写入备份前检查：

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true
      dhcp-identifier: mac

如果是静态 IP，则恢复新 VM 前要修改地址、主机名、DNS 记录、监控对象和配置管理身份。不要把恢复演练做成“能启动就算成功”，真正的成功是恢复对象不会和原业务对象冲突。

7.4 Longhorn V2 与已知限制

Harvester v1.7 文档提示，从 v1.7.0 开始支持 Longhorn V2 volumes 的备份和快照，但也明确警告：删除最新备份或快照可能阻塞相关卷后续操作，影响 volume snapshots、backups 和 live migration，解决 blocked 状态可能需要删除受影响 volume。这个限制非常严肃，生产环境不能把 Longhorn V2 当成“完全等价但更快”的默认选择。

对运维规范来说，至少要加三条：

1. 使用 Longhorn V2 前先核对目标 Harvester 版本文档和已知问题。
2. 快照、备份、删除最新恢复点等操作必须先在测试集群演练。
3. 对关键业务，不要在没有替代备份和恢复路径时依赖单一实验性能力。

删除最新恢复点可能影响后续快照、备份和热迁移，因此 Longhorn V2 上生产前必须先核对版本边界，并完成删除、恢复和迁移演练。

8. 第三方 CSI 与外部存储

Harvester 从 v1.5.0 起支持使用外部 CSI driver 供给 root volumes 和 data volumes。官方文档列出 Harvester 工程团队验证过的 CSI，包括 Longhorn V2 Data Engine、LVM、NFS 和 Rook RBD，并给出不同能力矩阵。这个能力对已有存储体系的企业很有价值，但也会显著提高治理复杂度。

8.1 什么时候考虑第三方 CSI

可以考虑外部 CSI 的典型场景：

1. 企业已有成熟 SAN/NAS/Ceph，容量和运维流程已经标准化。
2. 某些业务需要比默认 Longhorn 更高的 I/O 或特定数据服务。
3. 需要把 Harvester 纳入统一存储计费、配额和审计。
4. 数据中心已有明确的存储故障域和备份体系。
5. 某些 VM 磁盘需要放在外部受控存储上。

不建议一开始就引入第三方 CSI 的场景：

1. 团队还没有掌握 Harvester 默认 Longhorn 运维。
2. 只是为了“看起来更企业级”而引入外部存储。
3. 外部 CSI 的快照、克隆、扩容和 RWX 能力没有验证。
4. 升级、故障和支持责任边界没有明确。

官方文档对第三方 CSI 的前置能力要求包括：在线扩容、快照、克隆、以及用于 live migration 的 RWX volumes。换句话说，能 provision PVC 不代表适合承载 Harvester VM。虚拟机平台需要的是完整生命周期能力。

8.2 外部 CSI 的支持边界

第三方 CSI 最大的问题不是“能不能接入”，而是“出了问题谁负责哪一段”。SUSE Support Matrix 说明 Harvester 支持权益覆盖 Harvester appliance 绑定组件，包括 Longhorn、Harvester cloud provider、storage interface 等；来宾 Kubernetes、Rancher Manager 或外部组件可能需要单独权益。外部存储还涉及存储厂商、CSI driver、Harvester、Kubernetes 和业务系统多方。

建议在生产接入前完成一份能力矩阵：

不要在未验证的外部 CSI 上承载生产根盘。至少先从非关键数据盘、测试 VM、恢复演练和节点维护演练开始。

9. 存储日常巡检

Harvester 存储巡检要覆盖四层：Harvester UI、Kubernetes 对象、Longhorn 状态和物理节点。只看 UI 容易漏掉底层事件，只看 kubectl 又容易忽略业务归属和保护策略。

9.1 每日检查

每日检查适合快速发现明显异常：

kubectl get nodes -o wide
kubectl get pods -n longhorn-system
kubectl get pvc -A
kubectl get pv
kubectl get events -A --sort-by=.lastTimestamp | tail -n 50

关注点：

1. 是否有 Longhorn Pod CrashLoopBackOff、Pending 或频繁重启。
2. 是否有 PVC Pending、Lost、Terminating 卡住。
3. 是否有卷 Degraded、Faulted 或重建长期不完成。
4. 是否有节点 NotReady、磁盘压力或网络异常事件。
5. 是否有异常增长的快照、备份或镜像导入任务。

9.2 每周检查

每周检查要看容量和趋势：

9.3 每月检查

每月检查更像治理复盘：

1. 复核 StorageClass 命名和参数是否仍符合业务需求。
2. 复核磁盘标签、节点池、机架分布和故障域。
3. 检查 Harvester/Longhorn 版本是否处于 SUSE 建议的支持阶段。
4. 检查是否有外部 CSI、备份目标或网络配置需要升级。
5. 复盘过去一个月的存储告警、容量增长和恢复演练。

每日状态、每周容量和月度治理需要形成连续闭环，才能识别系统仍可运行但冗余和恢复能力已经下降的隐患。 巡检不是为了生成表格，而是为了尽早发现“还能跑但恢复能力下降”的状态。例如副本长期 Degraded、备份连续失败、容量水位过高，都可能在真正故障发生时放大影响。

10. 常见故障与排查顺序

存储故障最忌讳一上来就重启节点或删除卷。正确做法是先判断影响范围：是单个 VM、单个 PVC、单个节点、某个 StorageClass，还是整个 Longhorn 系统。

10.1 卷 Degraded

卷 Degraded 表示副本数量或副本健康状态不符合期望。排查顺序：

1. 确认集群节点数量是否满足副本数。
2. 查看目标 Volume 的 Replica 分布和错误信息。
3. 检查节点 Ready 状态、磁盘容量和磁盘标签。
4. 检查 Longhorn manager、instance-manager 日志。
5. 检查 storage network 或默认网络是否有跨节点连通问题。
6. 等待或触发副本重建前，确认容量和网络都足够。

单节点实验环境使用 3 副本 StorageClass 导致 Degraded，应通过 1 副本 StorageClass 解决，而不是反复重建副本。

10.2 PVC Pending

PVC Pending 常见原因：

Longhorn 文档说明，StorageClass 参数只影响新建卷；修改 StorageClass 后，既有卷不会自动继承新参数。因此遇到 PVC Pending 时，要看创建时实际引用的 StorageClass，而不是事后修改过的同名策略。

10.3 VM Not-Ready 或启动慢

如果 VM 因存储问题 Not-Ready，常见证据包括：

kubectl get -A vmi
kubectl describe vmi -n <namespace> <vm-name>
kubectl get pvc -n <namespace>
kubectl describe pvc -n <namespace> <pvc-name>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

然后回到 Longhorn 看对应 Volume。重点判断是卷 attach 失败、Replica 不足、engine 异常、节点不可达，还是 storage network 配置错误。不要只在 VM 控制台里等待，因为来宾系统还没启动时，控制台可能没有任何有效线索。

10.4 快照或备份失败

快照或备份失败要区分平台错误、来宾文件系统冻结错误、备份目标错误和容量错误。Harvester 文档提到运行中的 RHEL9 guest VM 可能遇到 filesystem freeze failed，需要按对应故障文档处理。数据库类业务还要看应用一致性，不应只依赖平台冻结。

排查时建议：

1. 查看 VM Snapshot 或 VM Backup 对象状态。
2. 查看 namespace 和 VM 级快照空间限制。
3. 查看 guest agent 是否安装、运行并可通信。
4. 查看备份目标网络、凭据和容量。
5. 查看 Longhorn Volume 和 Snapshot 状态。
6. 对 Longhorn V2 volume，核对目标版本已知问题。

10.5 storage network 异常

storage network 异常可能表现为 Longhorn Pod 起不来、Replica 重建失败、镜像上传下载异常、VM Not-Ready。排查顺序：

这条排障链先按影响范围分流，再沿虚拟机、Longhorn 对象、节点网络和物理交换机逐层取证；影响越广，越应优先检查共享层。

11. 生产存储基线

下面是一份可以直接放进 Harvester 运维规范的存储基线。

11.1 设计基线

• 生产集群至少三节点，默认生产卷使用 3 副本。
• 单节点实验集群必须使用单独的 1 副本 StorageClass，并在文档中标注无节点级高可用。
• StorageClass 命名必须体现介质、副本数、用途或删除策略。
• 关键业务卷不使用未验证的外部 CSI，不使用临时或实验 StorageClass。
• 系统盘和 Longhorn 数据盘尽量分离，生产节点使用稳定 SSD/NVMe。
• 磁盘标签必须统一命名并记录在 CMDB 或运维文档。

11.2 容量基线

• 按副本数、快照、备份、Replica 重建和业务增长预留容量。
• 节点磁盘长期使用率不应逼近满载，超过水位线要触发扩容或迁移计划。
• 快照和备份必须设置保留策略，避免无期限增长。
• 镜像导入、备份窗口和 Replica 重建不能集中在同一高峰期。
• 新增节点或磁盘后，要验证 storage network IP 池和 Longhorn Pod 状态。

11.3 变更基线

• 创建或修改 StorageClass 前先评审参数，创建后不要指望再改核心字段。
• 启用 storage network 必须按变更流程停止相关工作负载，并在完成后手动验证。
• 扩容卷前确认备份、文件系统类型、来宾系统操作步骤和回退方案。
• 删除 PVC、Volume、快照、备份前确认业务归属和恢复点价值。
• Longhorn V2、第三方 CSI 和外部存储接入必须先在测试环境演练。

11.4 恢复基线

• 快照用于短期变更回滚，备份用于跨故障域恢复。
• 关键 VM 必须定期恢复到测试环境，验证启动、网络、应用和监控。
• Ubuntu DHCP VM 必须处理 dhcp-identifier: mac 或恢复后 IP 冲突风险。
• 数据库 VM 要结合应用层备份、停写、日志归档或一致性工具。
• 恢复演练结果要记录恢复点、耗时、失败项和修复动作。

12. 一个落地案例：从默认存储走向分层治理

假设一个三节点 Harvester 集群最初只有默认 harvester-longhorn，上面运行了监控、工单、测试数据库和几个内部应用。运行三个月后出现三个问题：监控 VM 磁盘增长快，测试数据库 I/O 波动影响其他 VM，快照保留没有规则导致容量接近水位线。

治理前还要统一命名和归属。StorageClass、Volume、VM、namespace 和备份目标都应能看出环境、业务和负责人，至少要在标签或注解中保留这些信息。多团队共用集群时，存储问题经常不是技术能力不足，而是没人能判断某个卷属于谁、能不能扩容、能不能删除、恢复点需要保留多久。把归属和生命周期写清楚，后续容量告警才有处理对象。

对生产环境，还应区分平台管理员和业务管理员的边界。平台管理员负责节点磁盘、StorageClass、Longhorn、storage network 和备份基础设施；业务管理员负责 VM 内文件系统、应用一致性、恢复演练和数据保留策略。边界不清时，平台侧看到卷空间不足，业务侧以为平台会自动扩容，最终问题会在故障时集中暴露。

可按四步治理：

第一步，盘点所有 VM 磁盘。导出 namespace、VM、PVC、StorageClass、容量、备份策略、业务负责人和最近增长趋势。先知道谁在用、用多少、重要性如何。

第二步，拆分 StorageClass。保留默认 3 副本作为通用策略，新增 longhorn-nvme-repl-3 给高 I/O 测试数据库，新增 longhorn-hdd-repl-2-cold 给低频归档盘，新增 longhorn-retain-prod 给误删除风险较高的关键数据卷。

第三步，建立快照和备份策略。应用升级前允许短期快照，保留 1-3 天；生产 VM 按业务重要性配置 scheduled VM backup；每月抽样恢复到测试 namespace。

第四步，做容量和告警治理。设置节点磁盘水位告警、Longhorn Volume Degraded 告警、备份失败告警和快照空间使用告警。新增节点或磁盘时同步检查 storage network IP 池。

这条治理路线从资产盘点开始，通过 StorageClass 分层、恢复点治理和容量告警，把单一默认策略逐步改造成可解释、可审计、可恢复的体系。 这个案例的关键不是一次性追求完美架构，而是把默认存储逐步治理成可解释、可审计、可恢复的体系。

13. 总结

Harvester 的存储管理不能只停留在“会创建卷、会扩容、会点快照”。它真正要解决的是生产虚拟机的数据生命周期：从镜像创建根盘，到数据盘分层；从 StorageClass 策略，到 Longhorn 副本调度；从容量规划，到 storage network；从短期快照，到外部备份和恢复演练；从单个卷故障，到整个平台的巡检和告警。

本文给出的核心原则可以压缩成四句话：

1. StorageClass 是策略，不是普通下拉选项。
2. Longhorn 副本带来高可用，也带来容量、网络和重建成本。
3. 快照用于短期回滚，备份用于跨故障域恢复，二者不能混用。
4. 任何外部 CSI、Longhorn V2 或 storage network 变更，都必须先验证支持边界和恢复路径。

下一篇将进入 Harvester 的《网络配置》，重点分析管理网络、VLAN 网络、Cluster Network、VM Network、路由、DHCP、双网卡和网络故障排查。

参考资料

• Harvester v1.5 - StorageClass
• Harvester v1.5 - Storage Network
• Harvester v1.5 - Create a Volume
• Harvester v1.7 - VM Backup, Snapshot & Restore
• Harvester v1.5 - Third-Party Storage Support
• Longhorn - StorageClass Parameters
• SUSE Harvester Support Matrix