引 言
星际文件系统(InterPlanetary File System,缩写IPFS)是一个旨在创建持久且分布式存储和共享文件的网络传输协议。西部世界根据官方说明了解到,它是一种内容可寻址的点对点超媒体分发协议。在IPFS网络中的节点将构成一个分布式文件系统。
西部世界了解到,在IPFS网络中,文件是拆分后存储在不同节点的,每个节点存储的内容并不相同,当我们使用IPFS私有网络来作为系统的文件系统时就存在存储一致性问题,如单个节点的故障导致存储的文件不可用。
IPFS-Cluster项目很好地解决了私有IPFS网络数据可用性问题,IPFS-Cluster 通过给IPFS网络添加一层分布式共识协议,从而保证IPFS集群节点存储内容的一致性。IPFS-Cluster 也是分布式的系统,附加在IPFS节点之上,通过维护全局一致Pinset并和IPFS交互来构建一致性存储。IPFS优质矿机家Mariobtc。
图1 IPFS-Cluster示意图
IPFS-Cluster 架构介绍
IPFS-Cluste是由各功能组件构成的,所以首先需要对组件化及各组件功能进行简单介绍;然后介绍使用IPFS-Cluster进行文件Pin操作的工作流程,与IPFS Pin文件工作流程进行对比;Consensus组件是IPFS-Cluster能够完成分布式一致性存储的核心,最后会介绍基于“Raft”的强一致性分布式共识组件,和基于“Merkle-CRDT”的最终一致性共识组件。
图2 IPFS组件结构示意图
▲ 组件化设计
IPFS-Cluster基于组件化设计,同节点的各组件之间通过内部RPC进行通信,此方案很容易把各组件部署到不同的机器,是一种极其容易扩展的架构设计。
IPFS-Cluster 由以下8个组件组成:
Consensus共识组件: 负责在集群节点之间实现一致性,使所有节点的Pinset保持一致,并且管理节点的加入及退出。目前支持两种共识算法“Merkle-CRDT”和“Raft”。
Pin Tracker组件: Pin Tracker处于共识组件和IPFS中间层,Pin Tracker接收并维护Consensus组件发送的Pin操作,通过RPC组件将Pin操作发送到IPFS。
Peer Monitor组件: 负责维护集群节点的状态,Peer Monitor周期性的检查节点存活状态。
State组件:存储Pin操作的数据库,便于对Pin操作进行增、删、查等操作。
RestApi组件:该组件提供了基于HTTP的Cluster Peer功能的访问服务器。
IPFS Proxy组件:是一个代理endpoint,可以用来调用IPFS-Cluster连接的IPFS。某些请求比如Pin/Unpin等会被拦截并触发IPFS-Cluster集群操作,从而操作会在集群所有节点执行。未被拦截的请求都直接转发Cluster所连接的IPFS Deamon。
Allocator/Informer组件: Informer组件用于监控系统的硬盘使用情况、Pin操作的数量。Allocator组件用来选择文件Pin到的具体节点,系统可以根据硬盘使用情况来选择文件存储到的节点,把文件存储到特定的节点。
RPC组件: 系统使用内部RPC在同节点各组件间进行通信,外部RPC在不同节点各组件间进行通信,提高了系统的可扩展性。
▲ Pin处理流程
当使用IPFS-Cluster添加内容时和IPFS add命令添加内容命令的选项基本相同。但是IPFS add命令仅将内容添加到本地IPFS,IPFS-Cluster同时添加到多个集群节点连接的IPFS,具体添加到多少个节点依靠Replication Factors参数控制。
Pin和Unpin是集群操作的核心,涉及多个内部组件,但有两个主要阶段:
Cluster Pin阶段:持久化Pin操作,并通过共识组件广播给其他集群节点。
(1)首先接收到一个Pin请求,请求包括特定参数。
(2)根据参数会选择Pin到哪个节点,Replication Factors决定多少副本,磁盘空间决定选择哪个节点来进行存储。
(3)共识组件负责将Pin请求广播到集群其它节点。
IPFS Pin阶段:被指定的IPFS负责将文件内容成功Pin到本地。当Cluster-Pinning阶段完成,每个节点会被通知有个新的Pin工作,如果节点在配置列表中,会调用IPFS来进行Pin操作。
(1)Pin Tracker组件开始追踪CID。
(2)如果分配到节点,IPFS Pin add操作被执行。
(3)Pin Tracker会等待IPFS Pin add操作完成,如果Pin出现错误则会进行上报处理。
这两个阶段是异步处理的,Cluster Pin阶段处理后就会给用户返回应答,IPFS-Pinning阶段处理比较慢,由Pin Tracker对Pin过程进行管理。如果IPFS Pin失败, 或Pin超时失败,Cluster会接收异常情况,并定期运行Recover功能来进行异常处理。
▲ Consensus共识组件
共识组件主要职责:
(1)管理全局Pinset集合,包括从其它节点获取或者向其它节点发送Pin操作命令。
(2)管理Pinset相关的文件在IPFS中的持久化存储。
(3)在所有的节点间实现分布式一致,所有的节点需要收敛相同的Pinset。
(4)管理集群节点,包括节点加入离开,设置节点间的管理机制。
(5)设置节点信任机制,定义哪些节点可以访问本地RPC服务。
IPFS-Cluster共识组件目前有两种具体实现,基于“Raft”的强一致性分布式共识,和基于“Merkle-CRDT”的最终一致性共识。基于“Raft”的强一致性共识,对任何一个节点发起请求都会得到相同的回复,但将产生相对高的延迟;基于“Merkle-CRDT”的最终一致性共识具有更低的响应延迟,但可能会回复过期的数据,最终一致性即是经过一段时间后终会到达一致的弱一致性。
▲ 基于Raft共识算法实现
(1)通过将更新直接发送到连接的每个节点来发布更新。
(2)在本地BoltDB保存所有的持久化数据。
(3)使用Raft共识来获得强一致性。集群选出一个Leader负责提交每个请求的日志,必须群集中超过一半的节点确认才能使操作有效。可以仅将追加日志合并并压缩为快照,然后将其发送给新的节点方。
(4)相信所有节点,所有节点都可以申请加入Raft集群,并且所有节点可以和其它节点进行网络通信,前提是他们都知道私有网络的Cluster Secret。
▲ 基于Merkle-CRDT 实现
CRDT是Conflict-Free Replicated Data Types的缩写,即“无冲突可复制数据类型”。Merkle-CRDT是IPFS-Cluster默认的共识组件实现。
(1)通过libp2p的pubsub组件来广播Pinset更新,通过DHT+Bitswap来定位并交换数据。
(2)在本地BoltDB保存所有的持久化数据。
(3)使用Merkle-CRDTs来达成最终一致性。Merkle-CRDTs是CRDT一种改进,使用Merkle-DAG作为共识的逻辑时钟,Merkle-DAG中每个Node代表一个操作,前一个操作Node作为后一个操作Node的Parent。这样不同节点间只需要对比并同步Merkle-DAG数据结构即可维持操作的一致性。Merkle-DAGs作为逻辑时钟是只增的,不能修改的。当新的节点加入时需要从Root Node开始遍历整个Merkle-DAG,当Merkle-DAG深度比较大时,这可能导致新节点加入处理流程过慢。
(4)不需要执行任何Peerset管理。通过pubsub收到“Ping”的每个对等方都被视为集群的成员。
IPFS-Cluster 总结
IPFS-Cluster作为IPFS网络的附加层,通过添加分布式共识算法达到了IPFS集群存储的一致性。此方案可以将IPFS私有网络打造成高可用存储系统,也可以用来提高IPFS的稳定性。基于内部RPC的组件化设计非常适合分布式系统,整个系统可以很方便的扩展并部署到不同的节点。家Mariobtc了解Filecoin集群项目。
当然,目前IPFS-Cluster还不支持基于文件系统的一致性存储操作,以集群形式添加的文件在IPFS中存储为Block格式,并不支持整个文件系统状态的分布式一致性维护。