分布式卷
卷，以及为什么有两种
Section titled “卷，以及为什么有两种”侧边栏在主要部分中并排显示卷和分布式卷，它们不是同一事物的两个视图。
卷是一个普通的 Docker 卷：driver: local，一个节点，没有复制。它存在于使用它的容器所在的节点上，如果该节点消失，它也会消失。用于任何不需要在节点离开后继续存在的内容。
分布式卷是一个独立的子系统，它跨节点复制卷的数据，可以随着文件老化自动在存储层之间移动卷的文件，可以在您不进行任何操作的情况下将部署的存储故障转移到健康节点，可以在使用它的部署保持运行的同时将卷移动到另一个节点，并且可以指出看起来大小或类别错误的卷。将其用于任何必须能够承受节点故障的内容。
四种存储类，而非单一行为
Section titled “四种存储类，而非单一行为”分布式卷通过存储类创建，该类决定了上述哪些特性实际适用于它：
- 临时 — 仅限本地，无复制。与普通卷保证相同，但通过分布式卷工具管理。
- 复制 — 异步复制到其他节点。此类允许您选择副本数并提供自动故障转移（如下所述）。
- 共享 — 由 SeaweedFS 支持，同步，可从多个节点同时读写。
- 对象 — 通过 MinIO 提供 S3 兼容存储。
副本数和接下来描述的自动故障转移行为适用于复制类。创建为临时的卷没有可故障转移的内容，因为没有其他副本存在。
节点故障时会发生什么
Section titled “节点故障时会发生什么”一个复制卷有一个节点持有当前的主副本，一个或多个节点持有副本。故障转移控制器监视主副本；如果它变得不可访问，控制器会选择最健康的副本并将其提升为主副本——但只有当该副本是经过验证的、刚刚同步的副本时，才会在没有人员干预的情况下进行提升。一个仅仅标记为同步但未证明其为最新状态或已过时的副本，无论卷的策略如何，都会回退到等待批准，因此永远不会为了更快的故障转移而牺牲数据丢失。提升是否需要批准完全是每个卷的设置——自动策略在副本通过新鲜度标准后自行提升，手动策略则始终等待人员操作，即使副本是新鲜的。
等待中的提升不会停止部署的容器。它们继续使用已有的存储运行；平台所做的只是记录请求并将卷标记为失败，这会阻止任何新内容挂载它，直到提升得到解决。等待中的请求在仪表板中该卷自己的页面上可见，操作员可以在那里批准它——你无需在日志中费力寻找。当提升自动发生时，你会看到一个事件，其中命名了旧的和新的主节点，而不是停机。
将卷移动到另一个节点，而不停止部署
Section titled “将卷移动到另一个节点，而不停止部署”一个复制卷的主副本可以在使用它的部署保持运行的同时移动到不同的节点。这是一次迁移，并且是一个有意的操作：操作员打开卷，选择迁移，挑选一个目标节点并启动它。
随后发生的是，目标节点被添加为副本并开始接收卷的数据，迁移控制器监视该副本而非时钟。只有当目标报告自身已同步并且与主副本相差几秒时，它才会切换：写入在切换的瞬间被暂停，目标成为主副本，而原来的主节点作为副本保留。直到那一刻，部署都没有任何变化，这就是为什么迁移可以在切换前的任何时刻被放弃——取消迁移会丢弃目标并让原始主副本保持原样。
如果目标节点未发送心跳，或者没有卷的完整大小加上其十分之一的空闲空间，迁移将在开始前被拒绝。当迁移正在进行时，卷自身的页面会显示其进度以及预计完成时间。
这并非侧边栏中的 KV 迁移 条目。那是一个不相关的平台管理员工具，用于将部署记录移动到更新的键布局，与卷无关。
分布式卷可以携带一个可选的分层策略——除非您启用它，否则它是关闭的。当启用时，一段时间未被读取的文件会从热存储（本地，在节点上）移动到温存储（SeaweedFS），然后根据自上次访问以来的天数和文件大小，从温存储移动到冷存储（MinIO）。这作为定期后台扫描运行，并且它永远不会改变容器通过哪个节点访问卷——只改变给定文件实际存储在哪个底层存储上。
承载字节的组件是 数据移动器。它记录即将发送的文件的校验和，发送它，并且仅在传输被接受后才删除它移动的副本——因此中断的移动会导致重试而不是丢失文件。它双向工作：需要再次使用的文件会从温存储拉回到读取它的节点上。
Odysseus 会检查一个租户的分布式卷，并指出值得更改的地方。它不是一个持续监控并记录发现的后台服务：整个列表是在被请求时根据卷的当前状态即时计算出来的。除了你对建议所做的操作（已确认、已应用或已忽略）之外，不会存储任何关于建议的信息。
它读取卷实际报告的三项内容：你设定的声明大小和副本计数；每个节点记录在其自身副本记录中的实际存储字节数；以及快照数量。任何建议都可以追溯到这三项之一。
有四种类型。
- 容量。 如果卷使用了其声明大小的 85% 或更多，就会被标记；达到 95% 或更多则被标记为紧急。建议的大小为其提供了大约翻倍的空间。
- 副本计数。 如果复制卷的副本数低于其存储类定义的最低值，就会被标记以提高副本数。你标记为
criticality: critical的卷的最低副本数被设定为三份。超过三份副本时，额外的副本会被标记为成本，且平台无法为其调度容错能力。 - 存储类。 超过 100 GB 的复制卷会被标记为对象存储的候选，并附带成本模型给出的月度差价。另外，你标记为关键的数据如果位于临时存储类（单副本、单节点、无复制）上，会被标记为可靠性问题。
- 成本。 超过 10 GB 但实际存储量不足其声明大小三分之一的卷会被标记为过度配置，并附带一个更小的建议大小，该大小在实际存储量之上保留 50% 的余量。单个卷上的快照超过十个会被标记以供审查。当识别出的节省超过租户模型化存储支出的十分之一时，列表顶部会显示一个摘要。
其中一些可以为你应用，另一些则不能，每条建议都会说明是哪种情况。 容量或过度配置建议会更改卷的声明大小；副本计数建议会更改计数并选择节点，同时保留已持有同步副本的节点，以避免强制进行不必要的全量重新同步。存储类建议无法应用——在存储类之间移动卷属于层级迁移，Odysseus 目前不提供此功能——快照清理也不会为你执行，因为删除快照是不可逆的，只有你才知道哪些快照仍然需要。在这两种情况下，建议都会用通俗语言说明原因，仪表板也不会提供明知会被拒绝的按钮。
读者可能期望的两件事被刻意省略了。没有“此卷数月未被访问”的建议，也没有“此卷被频繁读取，请将其移至更快位置”的建议，因为目前不收集每个卷的访问统计信息——提供这些信息的文件级跟踪属于分层引擎，而该引擎当前未运行。一条无法触发的规则比缺失的规则更糟糕，因为它在你的列表中的缺失会被解读为好消息。
确认一条建议会将其保留在屏幕上并标记。忽略一条建议会将其从列表中移除，直到它所描述的情况发生变化——建议的标识源自发现内容，因此一个再次填满的卷会产生一条新建议，而不是恢复你之前忽略的那条。
Odysseus 不会对分布式卷的数据进行时间点快照，API 也如实说明，而非假装可以。两个快照创建端点——POST /api/v1/tenants/{tenant}/volumes/{id}/snapshots 和 POST /api/v1/dvm/volumes/{id}/snapshots——均返回 501 Not Implemented，并且拒绝信息会说明哪些功能可以覆盖附近的需求。它们过去会返回 202 Accepted 和一个快照标识符，但对应的工作从未启动，也无法获取。机器可读的代码和确切措辞在拒绝参考中。
列出、获取和删除快照仍然有效。它们读取一个设计上为空（而非错误导致为空）的存储，因此获取操作会解释该记录永远不会存在，而不是看起来像是一个丢失的标识符。
Not this
分布式卷屏幕列出了每个分布式卷、其存储类和副本健康状况，也是你创建卷的地方。打开一个卷会显示其完整规格、副本状态和标签，并包含上述的迁移、故障转移和审批控制。同一个屏幕参考涵盖了从它进入的两个视图：网格状态，显示节点间 WireGuard 网格复制传输所经过的路径，以及使用它们的存储类背后的共享和对象存储的健康状况；建议，即上述四种建议显示的地方，每条建议都附带其可以代表你执行的操作或无法执行的原因。要创建一个卷并将其附加到部署，请参阅分布式卷任务指南。
