glusterfs 文件系统
TRANSCRIPT
你的需求是什么 ?
我知道你需要一个分布式文件系统，但你的需求究竟是什么？• 文件储存与提取
只需要支持文件的存储，提取，删除，比如 flickr 这类的网站。那么 mogilefs 能够满足你的需求 , 甚至你可以自行设计系统。
你的需求是什么 ?
我知道你需要一个分布式文件系统，但你的需求究竟是什么？• 文件储存与提取
只需要支持文件的存储，提取，删除，比如 flickr 这类的网站。那么 mogilefs 能够满足你的需求 , 甚至你可以自行设计系统。
• 一个通用的文件系统你需要你的程序无须做任何更改就可以运行在新的文件系统，那么 glusterfs 可以满足你的需求 , 当然 NAS 也不错，不过他比较贵。
你的需求是什么 ?
我知道你需要一个分布式文件系统，但你的需求究竟是什么？• 文件储存与提取
只需要支持文件的存储，提取，删除，比如 flickr 这类的网站。那么 mogilefs 能够满足你的需求 , 甚至你可以自行设计系统。
• 一个通用的文件系统你需要你的程序无须做任何更改就可以运行在新的文件系统，那么 glusterfs 可以满足你的需求 , 当然 NAS 也不错，不过他比较贵。
• 一个通用的块设备我玩过 LVM, 他很酷，但是不能跨网络， SAN 应该能满足你的需求 , 不过也许你想了解一下 iSCSI
我还应当关心写什么？• 解决方案是否廉价 : 找几台破机器，装一堆硬盘，软件装上
就可以用，还是从 IBM 买一个黑盒子 ? • 是否能防止单点故障 : 一台机器坏了，没关系，系统不受影
响。• 是否支持在线扩容 ? • 小文件 / 大文件 : 系统优化的目标 • 文件切割 : 是否需要支持文件切割 (stripe) • 数据冗余 : • 容错还是容灾 : 容错 ( 版本关系系统，延后删除 ) ，容灾 ( 异
地备份 ) • 同步 / 备份距离 : 为了预防火灾，地震，暴乱，嗯，我在月
球弄了一个镜像服务器。 • 技术是否稳定 : 平均故障时间
我还应当关心写什么？ (glusterfs 的表现 )• 解决方案是否廉价 : 找几台破机器，装一堆硬盘，软件装上
就可以用，还是从 IBM 买一个黑盒子 ? ( 是 )• 是否能防止单点故障 : 一台机器坏了，没关系，系统不受影
响。 ( 是 )• 是否支持在线扩容 ? ( 否 )• 小文件 / 大文件 : 系统优化的目标 ( 大文件较好 )• 文件切割 : 是否需要支持文件切割 (stripe) ( 是 )• 支持数据冗余 : ( 是 ) • 容错 : 容错 ( 版本管理系统，延后删除 ) ( 否 )• 容灾 : 容灾 ( 异地备份 ) ( 是 )• 同步 / 备份距离 : 为了预防火灾，地震，暴乱，嗯，我在月
球弄了一个镜像服务器。 ( 否 )• 技术是否稳定 : 平均故障时间 ( 否 )
大规模文件存储的几种实现
• 硬件 o DAS o NASo SAN
• 软件
o glusterfs (Z Research, GPL)o MogileFS(DANGA, GPL/Artistic)o lustre (SUN, GPL)o GFS (Google,Proprietary)o Hadoop (Apache Software Fundation, Apache License)
结构图
glusterfs 的设计
• 设计的目标o 通用的文件系统，支持 POSIX 几乎全部操作 ( 大约 40
个 , mmap 除外 )o 无单点故障 ( 无中心设计 )o 支持冗余，支持自动修复，支持多客户端同时操作o 非平面化储存
glusterfs 的设计
• 设计 / 特性o 基于 fuse ，整个程序位于用户态o 层状的设计，新功能的引入只需要在系统加入一个新的层
即可o 服务器可以叠加，即一个服务器可依赖于其他的多个服务
器 ( 类似与负载均衡的结构 )o 多个客户端可以从服务器树中的任意结点引入
glusterfs 文件系统
优点• 程序无须做任何更改即可运行在 glusterfs 上• 支持多个客户端同时使用 • 扩展性好 ( 支持上千台主机的集群，甚至更多 )• 自动修复 • 网络利用率高
glusterfs 文件系统
优点• 程序无须做任何更改即可运行在 glusterfs 上• 支持多个客户端同时使用 • 扩展性好 ( 支持上千台主机的集群，甚至更多 )• 自动修复 • 网络利用率高
缺点• 众多 BUG• 小文件时效率不高
设计上的难点
• 冗余系统的自动修复问题o 自动修复意味着存在一个正确的参照o 维护一份正确的参照的代价过于昂贵，比如创建一个文
件，在第 3 份上失败了，那么前面两份的创建操作需要回滚，如果回滚失败，那么系统就处于不一致状态，这种错误在网络异常繁忙时出现频率较高，错误的积累导致系统不稳定。
o 自动修复由文件系统操作触发，而不是由后台进程维护，在文件系统修复完成之前，系统操作无法返回，客户端强行杀死 glusterfs进程导致系统处于不一致状态。
设计上的难点
• 多客户端，竞态，一致性o 如果多台电脑同时打开同一个文件，读写过程中会造成系
统不一致。o 没有稳定的文件锁 API 实现 (?) 。
• 该死的 Cacheo 你伪装成一个本地文件系统，系统就信以为真了。o 你向系统写一个文件，完成后通知另外一个客户端读文
件，结果文件还在系统的缓存里。o 情况更糟糕，即是同一个客户端的另外一个进程也会出
错。
设计上的难点
• 效率与稳定性o linux 系统缺省单次 write 的大小过小 (512byte) o 没有稳定的 cache 系统
经验与教训
• 无中心 VS 有中心o 无中心
无单点故障，扩展性好，存在一致性问题 (glusterfs)o 有中心
有单点故障，扩展性受制于中心的处理能力，中心可以解决一致性问题 (lustre)
经验与教训
• 平面化储存o 每个文件根据他的内容的 hash 值发往储存集群o 文件系统结构保存于数据库o 后台进程负责保证冗余o 支持远距离冗余 (glusterfs 的远距离冗余是噩梦 )o 仅能支持少量的文件操作 ( 不是通用文件系统 )
经验与教训
• 我们需要一个通用的分布式存储系统么？ glusterfs 系统的替代方案。o 对于小软件，不存在磁盘空间不足的问题o 如果你有大量的小文件需要储存，可以考虑 mogilefso 如果你真的需要通用的分布式存储系统，可以考虑 lustre,
不过 lustre 对冗余支持不好，同时系统规模不能过大，不过比 glusterfs 稳定
o 如果有钱，请优先考虑向 IBM, HP 等公司咨询解决方案，这儿没有银弹
总结
• glusterfs 想做一个通用的，高扩展性的分布式文件系统• glusterfs 不足之处在于不够稳定• 不够稳定的原因在于挑选了有难度的技术方案• 挑选有难度的技术方案的原因在于想实现的功能太多，野心太大。
Quote
Nobody should start to undertake a large project. You start with a small _trivial_ project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way _useful_ first, and then others will say "hey, that _almost_ works for me", and they'll get involved in the project.
Linus Travalds, Linux Times (2004-10-25)
Q&A?
Thanks for your attention!