分布式存储系统 VeSpace 的策略子系统介绍(一)

元数据


1、元数据组织示意

 

 

为了实现在策略子系统中对整个 VeSpace Server SAN 系统进行资源调度策略控制、 状态监控等核心功能,从物理角度和逻辑角度设计和组织了如上图所示的元数据层次结构。

 

从物理角度来看,为了使不同的存储主机和存储资源散落到不同物理区域,不同的物理 区域相互隔离,在出现意外或灾害时能够有效的保证存储数据是可用的,策略子系统定义了 保护域 Domain 这个元数据类型,在 Domain 下可包含多个存储主机 Host,在存储主机下 又包含多个存储逻辑资源 component,这样就从物理角度把整个存储系统通过 Domain、 Host、component 的元数据结构有效的组织了起来,方便了策略子系统对存储系统的管理 和调度。

 

从逻辑角度来看,为了使得各个用户对存储资源的使用相互隔离、互不影响,策略子系 统定义了命名空间这个元数据类型,在命名空间下可包含多个存储资源池 Pool,在存储资 源池 Pool 下又包含多个存储卷 Volume,而为了保证存储卷 Volume 的数据高可用,在 Volume 下又设计了数据副本 Replica 这个元数据类型,每个 Volume 都可包含一个或多个 Replica,最后每个 Replica 下就对应一个或多个存储资源 component。至此,整个系统的元数据组织结构就如上图所示,正是有了这个树形的元数据组织结构,才能在策略子系统方便、灵活、高效地管理和调度整个存储系统的资源。下面针对每个元数据类型做简要说明。

 

 

2、基于 Raft 算法实现的分布式 KV 模块 RStore


从上述整个系统设计的元数据组织结构来看,使用 Key/Value 键值对的方式进行元数 据的存储是非常高效的,同时为了保证元数据的一致性和可靠性,我们开发了一个基于 Raft 算法的分布式 KV 模块 RStore 来管理和存储我们整个系统的元数据。同时针对我们系统具 体的使用场景对 Raft 算法处理流程进行了一定的适配优化。

 

2.1、元数据一致性

 

分布式 KV 模块 RStore 是 Raft 算法在策略子系统中的实现和应用,并且保障在实际分 布式存储场景中数据的一致性和异常数据恢复。RStore 模块目前设计实现的基本目标有以 下几点:

(1) 具有容错性,保证异常情况下系统元数据的一致性

(2) 支持自动增删节点

(3) 支持增删查改操作

(4) 支持适配多种后端存储引擎

(5) 支持日志快照重建功能

(6) 支持节点异常宕机系统元数据自动恢复

 

在 RStore 模块中我们主要实现了 Raft 一致性模块、日志状态机模块(FSM)、快照 对象模块(Snapshot)和后端存储模块(Backend Store)。如下图所示:

 

 

从上图中可以看出,元数据分布式 KV 存储模块 RStore 主要包括 FSM、Snapshot、 Raft 和 Backend Store 四个主要部分,其中 FSM 是 RStore 模块中日志的状态机,Snapshot 是元数据的快照对象,Raft 就是 RStore 模块中 Raft 一致性算法的实现(策略子系统元数 据的一致性主要由 Raft 模块来保证),Backend Store 为元数据的索引和存储模块(负责 元数据从内存到磁盘的实际落地)。下面就 RStore 模块如何保证元数据一致性、故障恢复、 快照和存储落地做简要的说明。

 

首先 Raft 一致性算法在确保分布式存储系统数据一致性方面已经非常成熟和可靠,也 在业界得到了广泛的应用和验证,因此 RStore 模块选择实现 Raft 算法来确保策略子系统 元数据多副本的一致性。在系统正常运行过程中,RStore 中的 Raft 模块会进行如下处理流 程来保证元数据的一致性。

 

 

(1) 在某一时刻策略系统集群子节点成为一个候选者(Candidate),它会在一个 TERM内向其他 Follower 发出选举投票请求,请求 Follower 选择自己成为 Leader。

 

(2) 其他 Follower 的 Raft 模块会向发起投票的节点进行回应,若同意则回应 YES,不 同意则回应 NO,在整个投票过程中,由于各个节点可能会故障或者宕机,也有可 能有其他的 Candidate 发起投票,但只要 Candidate 的最后选举票数达到 N/2 + 1(N 为策略子系统的节点数),那么该 Candidate 就可以成为 Leader。

 

(3) 选举投票结束后,成为 Leader 的节点就可以向其他节点发出日志复制的等操作并 会与其他节点之间维持一个心跳来感知节点之间的状态。这时对于系统元数据的修 改都先经过 Leader 节点,每个节点都会写一条日志记录,Leader 会复制该条日 志记录到所有 Follower 上,等到大部分 Follower 都响应时才提交日志,并通知 Follower 日志已提交,所有的 Follower 收到通知之后也在各自节点上提交该条日 志,然后每个节点根据日志记录将元数据的修改实际存储落地。这样就保证了系统 元数据是一致的。

 

(4) 若在系统运行过程中,Leader 节点故障或者宕机,导致整个系统没有存活着的 Leader 节点,那么系统以后的修改操作就将没有 Leader 节点来带领其他节点进 行元数据修改操作。发生这种情况后,RStore 中的 Raft 模块由于在一定时间内没 有收到 Leader 节点的心跳,此时其他节点就会认为 Leader 已经失效,会有新的 节点成为 Candidate 发起新一轮投票,具体的投票处理流程和前面的投票流程完 全一样,直至选出新的 Leader 继续带领其他节点进行系统元数据的修改操作。因 此,系统在运行过程中,规定数量范围内的节点宕机,元数据一样可以保证一致并 不会影响整个策略子系统的正常处理。

 

(5) 脑裂情况。选举过程是有一定的时间限制,如果恰巧有两个节点同时成为 Candidate,同时向其他节点中的 Raft 模块发起投票请求,这时就会出现脑裂投 票的情况,两个节点都可能拉到一样多的选票,本轮选举失败,没有选举出 Leader, 那么此时 Raft 模块中会内置一个计时器,最先超时的 Follower 会马上再次成为 Candidate,并发起新一轮的投票,由于 Raft 模块中超时时间是一个随机数,同 时超时的概率会非常小,因此系统总能保证在多轮投票之后选举出新的 Leader, 从而带领其他节点进行元数据修改操作,保证系统元数据的一致性。

 

(6) 若发生网络分区,在网络分区消失后,系统同样可以达成整个系统数据是一致的。 假设策略子系统有 A-E 五个节点,B 是 Leader,如果发生网络分区,A,B 成为一 个网络子分区,C、D、E 成为一个网络子分区,此时 C、D、E 节点 RStore 中的 Raft 模块之间会发起新的选举,假设选举出 C 作为新的 TERM 的 Leader,这样在 两个网络子分区内就有了不同 TERM 的两个 Leader,这是如果有客户端写入 A 时, 因为 B 无法复制到大部分 Follower 中,所以日志一直会处于未提交的状态,同时另一客户端对 C 节点的写操作能够正常完成,因为 C 是新的 Leader,此时知道 D、E 节点。那么当网络恢复时,B 节点能够发送心跳的给 C、D 和 E 了,发现 C 节点 的 TERM 值更大,这时 B 节点就会自动降级为 Follower,然后 A 和 B 节点都会回 滚未提交的日志,并从新的 Leader 也就是 C 节点那里复制最新的日志记录并进行 相应操作,因此通过各个节点 RStore 中 Raft 模块之间的交互保证了在出现网络分 区时系统元数据的一致性。

 

 

 

 

分享:分布式存储系统 VeSpace 的策略子系统介绍(一)

有容云-构筑企业容器云 www.youruncloud.com

温馨提示

对Docker容器技术或容器生产实施感兴趣的朋友欢迎加群讨论。我们汇集了Docker容器技术落地实施团队精英及业内技术派高人,在线为您分享Docker技术干货。我们的宗旨是为了大家拥有更专业的平台交流Docker实战技术,我们将定期邀请嘉宾做各类话题分享及回顾,共同实践研究Docker容器生态圈。

加微信群方法:

1.关注【有容云】公众号

2.留言”我要加群”

QQ群号:454565480

有容云微信二维码