More Related Content Similar to Sheepdog内部实现机制 (20) Sheepdog内部实现机制2. 提纲
●
Sheepdog 介绍
●
整体架构
●
节点管理
●
数据管理
●
本地存储(持久化)
3. Sheepdog 介绍
●
开源的分布式块存储
●
专为虚拟机提供块存储
●
无单点
●
低运维开销
– “ 零”配置
– 对内核文件系统无特性假设
– 节点变化无须人工参与即可恢复
– 数据动态均衡负载
– 支持虚拟机的热迁移、镜像快照、模板 & 克隆(快速安装部署)、集群快照
– 计算节点和数据节点混合模式
●
线性扩展,支持上千级别节点
5. 整体架构
Sheep Sheep Sheep
Gateway Gateway Gateway
VM VM VM
Sheep Sheep Sheep
store
Store store
Store Store
节点 A 节点 B 节点 C
6. 节点内部
Sheepdog 存储
以太网
QEMU
虚拟机地址空间
块设备模拟
VCPU VCPU
eventfd VM_ENTRY
内核
KVM VM_EXIT
读写请求 PCPU PCPU
7. Sheepdog 线程模型
●
两种上下文
– 主线程上下文
●
接收请求,唤醒处理函数
– group_handler() ,处理节点变化和广播消息
– client_handler() ,处理 IO 和数据恢复、迁移等
请求
– 工作线程上下文
●
12 个,其中 4 个专门处理 IO 请求, 4 个专门
处理 Gateway 请求
8. 逻辑处理模型
●
两种上下文,主线程同工作线程无竞争的全局变量
●
将请求处理逻辑中需要串行化的逻辑放到主线程中,可以
并行的逻辑放到工作线程中
– 多线程、无锁的节点变化处理逻辑、数据恢复、迁
移逻辑
– 复杂的分布式算法简单化,根除死锁的可能性
– 容易验证算法的正确性
9. 节点管理
●
Sheepdog 只提供节点变化后的处理机制
– 节点变化的检测依赖外部实现
– 消息机制依赖外部实现
●
节点变化消息
●
节点广播消息
●
支持两种模型
– 全对称 (依赖 Corosync ,运行于 Sheepdog 的地址空间)
●
缺点:规模小 [<100]
●
优点:无需配置
– 单独的控制集群 (依赖 Accord* 或者 Zookeeper ,运行于独立地
址空间)
●
缺点:需要配置控制集群
●
优点:规模大 [>1000]
*Accord 为 Sheepdog 项目的一个子项目
10. 节点变化的处理
●
节点加入时,内部逻辑需要一个特殊的 master 节点来处理新节
点是否可以加入
– 集群主动或被动关闭后,重新启动集群,也是节点变化
的处理过程
●
每一个节点都有一致的成员视图
●
目前可以处理多个节点同时离开或者加入的事件(比如同时有 A , B
加入, C 离开)
11. 节点加入
●
节点加入
– 分为两个阶段
●
1 新加入节点发送加入请求
●
2 master 节点检查系统状态,核查能否加入,如果能,则
广播一个新的视图,各个节点更新视图和状态
join(C)
A C A
new_view(A,B,C)
B B C
1. 2.
– 新节点加入时,在节点 1 和 2 之间 master 节点离
开, mastership 自动转移,不会影响系统运行
●
新的 master 节点继续检查状态以及广播视图
12. 节点离开
●
节点离开
– 外部的节点检测机制发送成员变化视图
– 各个节点更新视图和状态
●
当多个节点变化事件发生时,外部检测机制确保离开和加入的消息的
顺序一致
– 剩下的节点和新加入的节点看见一致的视图
●
比如集群有 (A,B,C,D) 四个节点, E 在加入的同时
D 因事故离开,那么 (A,B,C,E) 四个节点都将看
到最终如下的视图
– {member(A,B,C,E), join(E), left(D)}
– 产生一个还是多个视图变化消息跟外部检测机制相关
13. 虚拟节点与一致性哈希
●
Sheepdog 采用虚拟节点和一致性哈希存储块对象
– 节点和数据都放到哈希环上
– 一个物理节点分散成多个节点均匀到环上
图片来自 http://www.paperplanes.de/
14. 节点变化的影响
●
节点加入,数据需要重新均衡
– 虚拟节点和一致性哈希算法保证
●
数据均匀分布在各个物理节点
●
很大程度上减少数据迁移
●
节点离开,数据拷贝需要恢复,保证数据冗
余度
– 通过节点变化的历史信息恢复数据
15. 数据管理
●
虚拟机镜像被切分为 4M 大小的对象
– 对象稀疏存储
– 每个对象由唯一的 64 位数字索引
– 每个对象有多个拷贝复制到节点上
图片来自 http://www.osrg.net/sheepdog/
16. 数据的读写
●
由于一个镜像只有一个虚拟机操作,所以更
新拷贝时可以并行执行写操作
●
读一个对象,可以从任何一个拷贝中返回
17. 拷贝修复
●
分布式系统中,拷贝的修复通常有两种
– 急修复:收到节点离开消息,立刻进行修复
●
优点:实现简单
●
缺点:当离开的节点回来之后,造成带宽的浪费
– 懒修复:
●
优点:能区分节点的临时错误和永久错误,减少
带宽的浪费
●
缺点 : 增加算法逻辑复杂度
– 如何处理关于临时离开节点的数据请求
Sheepdog 目前采用的方法
18. 拷贝修复逻辑
●
对象的时间轨迹
– 用 epoch 来记录每一次发生节点变化后的新视图
– 通过 epoch 来区分不同时间的数据对象
– 每一个对象都有一个以 epoch 为点的时间轨迹
Init: (A,B,C), 3 份拷贝
A B C D F
E1 D join
E2 F join
时间
E3 Latest!
C left
E4
19. 本地存储 - 农场
●
设计类似 GIT ,将数据对象分为普通对象和快照对象
– 普通对象存于当前活动目录,平时的读写操作将操作普通对
象
●
拷贝恢复或迁移到当前活动目录
– 当系统发生节点变化时,将普通对象存入仓库,类似快照操
作,各个数据拷贝都需要根据一致性哈希重新计算位置
●
恢复逻辑保证节点变化时,上层逻辑保证只存取恢复后的对象
●
节点变化时,集群仍能响应虚拟机的读写请求
●
快照对象去冗余,相同内容的对象指向同一个仓库文件
20. 农场架构
节点变化或者用
户集群快照请求
读写
当前活动 Sheep
仓库 Gateway
目录
21. 新特性开发列表
●
区分临时错误结点和永久错误节点
●
加强网裂 (network partition) 处理能力
●
本地 Cache 和 镜像预读到本地节点
●
高性能动态内部 Trace 机制
●
集群合并操作
●
实现子集群概念
●
增加更多后端 ( 如 LevelDB) 支持
●
高性能异步日志机制
●
更多需求驱动
表示在开发中