副本与存储策略

本章节介绍 WANOS 中与「数据副本」和「存储策略」相关的核心概念，帮助你理解系统如何在多个后端之间分布、保护和迁移数据，并给出一些典型配置思路。

为什么需要副本与策略

在接入多个存储后端（本地磁盘、云对象存储、WebDAV、OneDrive 等）之后，你通常会有这样的诉求：

• 某些重要数据希望有多份副本，提高可靠性；
• 热数据优先放在本地或低延迟后端，冷数据迁移到便宜的大容量后端；
• 某些后端只用于过渡迁移或即将下线，希望逐步搬空；
• 不同业务的桶（Bucket）需要不同的可靠性和成本策略。

WANOS 通过「副本数配置」和「存储策略」来协调这些需求，在保证可靠性的前提下，让数据尽可能自动地放在合适的位置。

副本相关的几个概念

在使用本章节内容前，先区分好几个容易混淆的概念：

• Bucket 默认副本数

  • 针对某个 Bucket，配置它在系统中期望拥有多少份跨后端的逻辑副本。
  • 例如设置为 2，表示写入该 Bucket 的对象，系统会尽量在不同后端上各保留一份，达到至少 2 份副本。

• 后端自身的冗余能力（副本数）

  • 在「存储后端」页面中，每个后端都有一个「副本数」字段，代表该后端自身的冗余能力预估（例如内部多副本、RAID 等）。
  • 这个数字主要用于容量和可靠性评估，不等同于跨后端的逻辑副本数。

• 最小副本数 / 策略中的副本约束

  • 在更细粒度的存储策略中，可以为某些对象类型或路径设置「至少多少份副本」的约束，用于覆盖 Bucket 的默认值。
  • 例如：日志类数据默认 1 份，关键业务配置文件至少 3 份。

理解了这三层含义之后，再去看 Bucket 设置和策略规则会更清晰。

Bucket 默认副本数（基础配置）

对于每个 Bucket，系统会维护一个默认副本数配置，用于指导写入时的基础可靠性目标：

• 当你创建或编辑 Bucket 时，可以根据该业务的重要程度设置默认副本数（例如 1、2 或 3）。
• 在没有额外策略干预的情况下，系统会尽量为该 Bucket 的对象选择足够的后端，达到这个副本数目标。

一般建议：

• 测试环境、非关键数据：可以设置为 1，节省空间；
• 重要业务数据：建议从 2 起步，根据业务要求再决定是否提升；
• 对读写性能要求更高时，可以通过结合「本地 + 云」多个后端，让副本同时分布在就近和远端后端上。

存储策略（按规则选择后端）

在默认副本数的基础上，系统还支持更精细的「存储策略」，用于根据对象的特征选择更合适的后端集合，并对副本数进行进一步约束。典型的策略维度包括：

• Bucket 名称；
• 对象 Key 前缀（例如某个目录或业务前缀）；
• 对象大小（大文件 / 小文件）；
• 存储类别（如 "standard" / "archive" 等自定义标签）。

通过策略，你可以表达类似的需求：

• 「小文件优先放在本地 SSD 后端，大文件放在云对象存储」；
• 「某个 Bucket 下的 backup/ 前缀数据至少 2 份副本，且必须包含一个云端后端」；
• 「日志类数据只写入便宜的大容量后端」。

当有多条策略生效时，系统会在内部按配置的优先级与规则进行匹配，并在满足容量与副本约束的前提下，选择一组合适的后端来写入数据。

不同版本中，具体的策略配置方式（管理界面 / 配置文件 / 管理 API）可能略有差异，但核心思想都是：基于对象属性，选择后端集合并设定最小副本数。

后端数据策略（Data Policy）

除了针对对象和 Bucket 的策略外，每个后端本身还可以设置一个「数据策略」，用于控制系统是否继续向其写入、是否逐步迁出存量数据等。这部分配置通常可以在「存储后端」列表中直接看到和调整。

常见的数据策略包括（实际界面文案可能略有不同）：

• 正常使用

  • 后端处于健康状态，继续接收新数据，也允许读取和迁出。

• 停止接收新数据

  • 对已有数据仍然可以读取和迁出，但系统不再将新的对象或新副本调度到此后端。
  • 适合用于「逐步弃用」某个后端：先不再写入新数据，等存量数据慢慢减少或被迁出。

• 驱逐 / 迁出数据

  • 结合后台迁移任务，系统会逐步将此后端上的数据搬迁到其他后端，目标是最终将其清空。
  • 适用于下线磁盘阵列、回收某个云存储账号等场景。

• 离线 / 禁用

  • 临时或长期将后端标记为不可用，不再对其进行读写操作。
  • 适用于后端发生严重故障，需要人工介入修复的情况。

合理地使用这些数据策略，可以在不中断业务的前提下，完成后端的扩容、缩容与迁移。

副本修复与数据健康（概览）

当某些后端发生故障、容量不足或被标记为不可用时，系统会通过后台任务尽量维持对象的副本数和整体健康状态：

• 自动化修复任务 (Replication Repair)：

  • 系统会根据「副本修复计划」（可在设置中配置 Cron 表达式）定时扫描数据库。
  • 发现实际副本数低于 Bucket 设定的 Replication Factor 时，自动生成补全任务。
  • 任务会选择健康的、剩余空间充足的后端作为目标，从现有副本进行拉取并补全。

• 一致性校验机制 (Verification)：

  • 后端校验 (Verify Backend)：主动发起，遍历特定后端的所有分片，检查物理文件是否存在且大小正确。
  • 异常校验 (Verify Anomalies)：针对已被记录为失败（Failed）或异常的对象进行的二次确认任务。

• 监控与干预建议：

  • 在「管理后台 -> 监控 -> 副本维护队列」中观察修复任务的实时进度。
  • 当发现副本修复任务持续大量运行时，及时评估是否有后端长期不稳定。
  • 为关键业务的 Bucket 配置合适的默认副本数（建议至少 2 份）。

典型使用场景示例

下面给出几个基于副本与策略的典型设计思路，你可以根据自己的资源和需求做适当调整：

• 本地 + 云的双副本方案

  • 为关键 Bucket 设置默认副本数为 2；
  • 接入一个本地高速后端和一个云对象存储后端；
  • 通过策略（或后端权重配置）让一份副本优先落在本地，另一份落在云端，实现就近访问与异地容灾兼顾。

• 冷热分层存储

  • 热数据 Bucket：默认副本数稍高（如 2），并优先使用性能更好的后端；
  • 冷数据 Bucket：默认副本数可以为 1 或 2，主要使用便宜的大容量后端；
  • 配合生命周期策略或后台迁移任务，将一段时间未访问的数据从热后端迁移到冷后端。

• 后端下线与数据迁移

  • 将即将下线的后端数据策略调整为「停止接收新数据」，避免新数据继续写入；
  • 启动迁移任务或使用驱逐策略，将存量数据逐步搬迁到新的后端；
  • 当确认数据已经迁出且不会再访问时，再将该后端标记为「离线」并从实际基础设施中移除。

通过合理组合 Bucket 副本数、对象级存储策略以及后端数据策略，你可以在 WANOS 内部完成相对复杂的存储编排，而不需要在业务侧单独处理多后端细节。