venus-cluster开源简述

[Fatman13]

原文 by @dtynn

简述

我们的不少合作伙伴曾大量、深度使用过 lotus 的封装组件，也不乏自行定制的经历。

使用过程中，他们遇到不少痛点，也总结出许多经验。我们将这些思考汇总起来，尝试提供一套与 lotus 封装组件思路不完全相同、以简洁、效率和灵活为最优先考虑，但同样具备竞争力的集群方案，供广大的 SP （Storage Provider，存储供应商）选择。

设计思路

venus-cluster 主要包含 venus-sector-manager 和 venus-worker 两个组件，其功能大致与 lotus-minr 和 lotus-seal-worker 的组合相当。

venus-cluster 着眼于实现一套满足：

• 面向大量同质化计算设备，降低硬件需求类型、实例数量和部署复杂度
• 尽可能针对不同环节、不同类型的异常，安全地完成“自愈”，减少人工介入、提供生产效率
• 依托云服务、外包服务及其他可共享的基础设施，降低门槛，削减不必要的成本

等目标的高效封装集群方案。

当然，明确且针对性强的设计意图可能导致这套方案并不普适于所有用户。例如，如果使用者已经拥有大量针对封装的不同阶段单独配置、形成搭配的设备，那么 venus-cluster 方案可能并不能有效地提升。具体情形，可以在阅读完后续文档后，由用户自行判断。

lotus 封装组件的模式

在介绍 venus-cluster 的具体设计思路之前，我们有必要回顾一下 louts 相关组件的工作模式。

lotus 的封装组件是一套标准的中心化调度集群：

• lotus-miner 是中心调度服务，对任务进行分配、管理；
• lotus-seal-worker 是封装执行体，负责完成分配到其之上的具体任务，并反馈给 lotus-miner；
• lotus-miner 作为发起方，与 lotus-seal-worker 之间通过 RPC 交互。

这套设计优点十分明显：

• lotus-seal-worker 是几乎无状态的工作进程，理论上很方便进行横向扩容；
• lotus-miner 可以灵活地将任务在 lotus-worker 之间进行调度。

但是这套机制也存在另一面：

1. lotus-miner 作为调度核心：

   • 承担着繁重的、不同类型的逻辑，如任务调度和管理，与链进行交互等
   • 保留着需要同时兼容本地模式和远程模式的历史负担

   导致内部逻辑（状态机）复杂、异常处理难以细化。

2. lotus-seal-worker 被完全设计为无状态的模式。

继而产生了一些问题，例如：

1. 由于各个阶段之间对硬件资源的要求迥异，为了保证资源的合理分配，通常会将 lotus-seal-worker 设置成每个实例支持一个阶段任务的模式，在同一机器上部署多个不同的实例，通过操作系统级别的资源控制（cgroup、docker、numa 等）进行隔离。

   这导致在大规模集群中， lotus-seal-worker 数量众多，编排和管理都较为复杂。

2. 任何中心化任务调度机制都很有可能需要考虑计算和存储资源的匹配、亲和性等。

   我们说 lotus-seal-worker 几乎无状态，但是事实上，扇区封装过程中存在着 临时文件 这样一种特殊的“上下文”。对于这类 “上下文”，lotus-miner 长期以来简单地对其进行整体搬移。这导致了巨大的网络带宽开销，以及一系列随之产生的网络、存储异常的可能性。

   直到 PR 7453 提出 “存储分组”概念之后，亲和性问题才初步解决，但这一方案给 worker 的编排又增加了额外的复杂度。

3. 大规模集群中存在着大量可能导致任务异常的因素，包括但不限于：计算错误、存储失效、网络抖动。而 lotus-miner 内部缺乏有效感知异常根因的手段，使得其难以根据具体原因选择不同的异常恢复机制，只能统一粗粒度地处理或等待人工介入。

venus-cluster 的设计思路

基于我们的目标和过去的经验，venus-cluster 在设计之初就确立了几点思路：

• 简化逻辑
• 优化流程
• 隔离异常
• 降低部署复杂度
• 灵活替换功能组件

下面我们会具体进行阐述。

简化逻辑

我们重新规划了上下游组件之间的责任划分：

• venus-sector-manager 负责：
  • 扇区封装过程中与链进行交互的部分，如 Ticket 和 Seed 的获取，消息的独立或聚合提交等
  • 扇区封装任务的状态记录，如当前阶段、异常及原因等
  • 已完成扇区的管理和维持，如响应 WindowPoST 等
• venus-worker 负责：
  • 管理各个阶段计算资源的分配
  • 使用预先规划好的本地存储空间完成扇区封装的完整过程

通过这样的划分，使得 venus-sector-manager 只需被动地接收必须传递的信息，不必实现一套复杂的感知和调度系统；同时 venus-worker 直接管理各类本地异常，便于执行不同的处理策略。

这样，两者的业务逻辑都不会频繁出现分支，相对便于理解及修改。

优化流程

在 lotus 的封装流程中，最大的问题就是上文提到的，对封装过程中的临时文件的处理。此外还存在一些不尽如人意的点，例如：

• 订单的等待逻辑可能会使计算资源闲置
• 存储资源和计算资源的强制一对一匹配
• 部分阶段，内部多个环节对资源的需求度不一致
• 将与链的交互和扇区封装计算捆绑，带来的存储空间释放不及时等

等。这些都会到封装的整体效率产生影响。

隔离异常

一方面，主要的异常处理被移动到了 venus-worker 一层，且在与 venus-sector-manager 交互的接口设计中，就尽早考虑了区分网络异常和逻辑异常，从而使得 venus-worker 比较容易感知到异常的具体原因。

另一方面，我们将封装过程中可能产生的错误类型归为四个级别，并设定了不同的处理方式：

• temp(orary)，临时:
  这个级别的错误通常明确属于临时性的，或者我们知道重试不会带来负面影响的。
  对于这类错误，worker 会自动尝试重试（以 recover_interval 为间隔，最多 max_retries 次）。
  当重试次数超过设定的上限时，会自动升级到 perm 级别。
  RPC 错误是比较典型的临时错误类型。

• perm(anent)，持续:
  这个级别的错误通常出现在 sealing 的过程中，无法简单判断是否可以安全重试，或一旦修复会有较大的收益（如不必重新完成 pre commit phase1）。
  这类错误会阻塞 worker 线程，直到人工介入完成处理。

• crit(tical)，严重:
  严重级别的错误在各个方面都与持续级别的错误比较相似。
  比较显著的区别是，严重级别的错误通常明确来自运行的环境而非 sealing 的过程。
  如可甄别的本地文件系统异常、本地持久化数据库异常等都归入此类。
  严重级别的错误同样也会阻塞 worker 线程直到人工介入。

• abort，终止:
  遇到这个级别的错误，worker 会直接放弃当前的 sealing 进度，尝试重新开始一个新的流程。

这使得 venus-worker 能够在更多不需要人工介入的异常场景下自行恢复，同时也给予将来用户定制异常处理策略提供了空间。

降低部署复杂度

venus-worker 降低部署复杂度的努力主要体现在三个方面：

• 降低实例数
• 减少差异化的配置
• 降低硬件失效，尤其是存储失效影响的范围

venus-worker 是以一台设备一个实例的部署方式为目标设计的，同时内部融入了精简但足够的资源控制和隔离方式。使用者可以根据实际情况决定资源的分配策略以期达到最高的使用效率。同时，扇区粒度的任务隔离也可以做到确保部分硬件的失效不会蔓延影响到其他扇区任务。

venus-sector-manager 被设计为一个实例可以为多个不同的 SP 服务，同时得益于 venus 系列链服务组件的设计，可以达成一些不太常见的运行模式：

• SP 联合体
• 使用云厂商设备的多算力集群协同
• 多 SP 共享算力设备下的动态调配

灵活替换功能组件

venus-cluster 内的大量功能组件都是按照先抽象接口，再具体实现的路径设计的。这样做可以确保我们仅对必要的部分进行约束，保留不同实现并存的可能性，从而能够更容易地提供对诸如：

• 定制化或闭源的封装算法执行器

• 共享的订单数据存储

• 部分阶段外包服务

等功能的支持。

总结

我们并不将 venus-cluster 定义为一套全能的封装集群方案，我们希望它是在特定的场景下，满足对简洁、高效、灵活有需求的使用者的一种选择。

同时我们期待有更多的参与者为其引入更丰富的功能组件实现。

我们认为扩大 “特定场景” 的覆盖范围有助于扩大 venus-cluster 的受众，但也不会贸然允诺对于 venus-cluster 的全部功能需求，尤其是那些对其自身特质有影响的部分。

[Fatman13]

原文 by @dtynn

概念和基础设施

venus-cluster 包含了一系列的抽象、功能组件、基础设施。了解这些内容有助于我们理解 venus-cluster 的运转。

公共部分

ActorID

ActorID 是在 venus-cluster 组件中使用的、SP 的标识格式，为数字类型。其与 SP 的地址是一一对应的关系。

例如：

• 在测试网络中，t01234 这样一个 SP 地址与 1234 这样一个 ActorID 一一对应
• 在主网中，f02468 这样一个 SP 地址与 2468 这样一个 ActorID 一一对应

之所以统一使用 ActorID 这样的标识格式，是为了：

• 方便辨识和书写

• 避免地址中的网络标识(t，f) 和类型标识 (t0 中的 0) 可能带来的混淆

objstore

objstore 是基于对象存储模式的存储基础设施抽象。

我们知道，在 Filecoin 中，与数据交互的各个环节广泛使用了基于文件系统的存储设施抽象。但在实践过程中，我们发现，除了一些相对基础的数据访问模式外，文件系统提供的大量特性并未被使用。

经过分析，我们认为：

1. 在许多场景下，基本的对象存储抽象已经能够满足 Filecoin 的需求
2. 无论是搭建本地的大规模高可用分布式存储集群，还是使用已有的商业化存储方案，对象存储都有大量选项
3. 存量的、基于文件系统的存储可以经由简单的代理层完成向对象存储接口的转换

当然，由于在算法层面，一些关键的环节还不支持基于对象存储的抽象（例如 MerkleStore），我们目前仅仅是将文件系统转换为对象存储的形式。希望在将来，通过社区推动Filecoin 算法层面对于对象存储的原生支持落地，令使用者能够按照自己的需求使用适合的存储方案，甚至混合方案。

piece store

piece store 是在存储订单封装场景中使用的，用于访问订单 piece 数据的存储抽象。

这里的 piece 数据，是指用户发出的、未经过填充 (padding) 和 FR32 转换的原始数据内容。

由于 venus-cluster 并不会涉及 piece 数据的写入，因此只提供了数据读取的接口。

venus-worker 部分

sealing store

sealing store 是位于 venus-worker 所在宿主机的存储设施，用于临时存放扇区封装过程中产生的数据文件。通常由高速本地存储设备（如 nvme）构成。

sealing store的使用遵循：

• 一个扇区唯一对应一个 sealing store
• 一个 sealing store 在同一时间只会存在一个扇区

每个 sealing store 中都会包含 meta 和 data 两个子目录，分别存放正在进行中的扇区的状态和封装数据。这样，在sealing store 之间，状态数据不会相互影响。即使部分sealing store的底层存储设备损坏，影响面也会局限在它所容纳的 sealing store 范围内。

通常来说，sealing store 会根据当前宿主机上存储资源数量来进行规划。

remote store

remote store 是扇区数据的永久存储设施，通常是一个存储集群。

目前在 venus-worker 中，remote store 实现为一套在文件系统之上的对象存储接口封装。

完成封装、等待上链的扇区数据会从 sealing store 移动到 remote store。

实际上， remote store 更多相对 sealing store 的本地而言。对于 venus-sector-manager 和 venus-worker 来说，都需要能够访问这一存储设施。

processor

processor 是扇区封装步骤的执行器。通常来说，每一个独立的步骤会对应一类 processor，如 pc1 processor, c2 processor 等。使用者可以针对每一类 processor 设置其并行数量。

通常来说，processor 会根据当前宿主机上的计算资源数量来进行规划。

external processor

external processor 是一类特殊的 processor，它们以子进程的形式存在，通过确定的协议，与主进程完成任务上下文的交互，并具体执行某一特定的封装步骤。

external processor 这一设定的存在，使得venus-cluster 可以依托操作系统提供的接口，针对子进程进行计算资源的配置和隔离，例如

• 通过 cgroup选项为 pc1 processor 指定 cpu sets，以避免 pc1 阶段的扇区相互抢占 cpu资源
• 通过 numa 选项为 pc1 processor 指定内存分配的倾向性，以降低 pc1 阶段内存的访问延迟，提高 multicore_sdr 模式下的缓存预取效率
• 通过英伟达默认的 GPU 相关环境变量，为多个 c2 prcessor 各自绑定唯一的可用 GPU，并将锁文件的位置分隔开

等极其灵活的搭配方式。

除了方便计算资源的配置和隔离之外，external processor 还使得 非通用或非公开的执行器实现 变得可能。任何满足上下文交互协议要求的可执行程序都可以作为 external processor的具体实现被集成进封装流程，这使得诸如：

• 高度定制化的 c2 processor
• 基于 GPU 外包的 pc2 processor 或 c2 processor

等选项变得易于集成。使用者可以任意选择多种定制化的 external processor 进行组合，且这种选择不会受限于具体的 external processor 的开发和维护者是谁。

sealing store 、 processor 和 sector 的关系

在之前的段落中我们提到，sealing store 和 processor 分别根据存储资源和计算资源进行规划，那么是否意味着他们之间并不需要 维持 1:1 的配比？

答案是肯定的，原因如下：

在任何一个特定阶段，一个 sector 所占用的资源是其所占用的计算资源（processor）和存储资源（sealing store）的组合。

在 venus-worker 的封装流程中，sector 从一个阶段进入下一个阶段时，会释放之前占用的计算资源，并尝试申请下一阶段所需要的计算资源。被释放的计算资源完全可以被分配给其他等待中的sector。

举例来说：

通常，基于成本和硬件规格考虑，可规划的 sealing store 数量往往多于可规划的 p1 processor 数量。在 venus-worker 的封装中，如果一个 sector 完成了 p1 阶段的计算，那么释放出来的 p1 processor 就可以被用于等待中的其他 sealing store 上的 sector。

这使得硬件资源的高密度利用变得可行。

venus-sector-manager 部分

基础服务API

这是 venus-cluster 依托的服务及其接口定义。

这些服务和接口为 venus-cluster 提供基础的、与链和其他参与者交互的能力。

chain.API

这是一组定义在 venus/venus-shared 中的，链相关的接口定义。主要是向 venus-cluster 提供基础的链服务接口。

messager.API

这是一组定义在 venus/venus-shared 中的，消息相关的接口定义。主要是向 venus-cluster 提供发送消息、确认上链和执行结果方面的基础能力。

market.API

这是一组定义在 venus/venus-shared 中的，订单相关的接口定义。主要是向 venus-cluster 提供订单分配、订单数据获取方面的基础能力。

RandomnessAPI

这是对 chain.API 的一层简单封装，主要用于提供扇区封装、维持过程中所需的随机数信息。

这一层封装使得 venus-worker 及其他模块仅需要根据用途获取相应的结果，而不必在意具体的请求对象（Drand or Filecoin）或请求格式。

MinerInfoAPI

这是对 chain.API 的一层封装，主要提供 SP 粒度的信息。

SectorManager

这是管理扇区分配的模块。主要负责根据 venus-worker 提交的参进行扇区编号的分配。

可以为多个 SP 、不同的扇区大小提供支持。

DealManager

这是管理订单的模块，主要负责为空白的扇区分配可容纳的订单 piece，以及对失败的扇区中的订单进行释放。

CommitmentManager

这是管理扇区消息上链的模块。主要负责按照预先指定的策略对 PreCommit 和 ProveCommit 消息进行单条或聚合式的提交，并观察上链结果。

SectorStateManager

这是管理进行中的扇区的状态的模块。主要负责接收来自 venus-worker的状态和异常信息上报。

SectorIndexer

这是管理已完成的扇区位置的模块。主要负责定位指定的扇区，常用在 PoSt 的计算过程中。