![节点管理
●
Sheepdog 只提供节点变化后的处理机制
– 节点变化的检测依赖外部实现
– 消息机制依赖外部实现
●
节点变化消息
●
节点广播消息
●
支持两种模型
– 全对称 （依赖 Corosync ，运行于 Sheepdog 的地址空间）
●
缺点：规模小 [<100]
●
优点：无需配置
– 单独的控制集群 （依赖 Accord* 或者 Zookeeper ，运行于独立地
址空间）
●
缺点：需要配置控制集群
●
优点：规模大 [>1000]
*Accord 为 Sheepdog 项目的一个子项目](https://image.slidesharecdn.com/sheepdog-120110025905-phpapp02/85/Sheepdog-9-320.jpg)
Sheepdog内部实现机制
- 1. 开源分布式块存储 Sheepdog 内部实现机制 泰来 ( 刘源 ) 核心系统部 2012 年 1 月 10 日
- 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) 支持 ● 高性能异步日志机制 ● 更多需求驱动 表示在开发中
- 22. 问答