存档

‘存储集群’ 分类的存档

LightCloud: 从key-value到分布式key-value[转]

2010年9月7日 wenhui 没有评论

来源:http://hi.baidu.com/ah__fu/blog/item/73803107015909c77a89473e.html

最近打算实现一些基于key-value的存储群集,查资料的时候发现了LightCloud这个东东。
LightCloud的中文资料都是千篇一律的对其英文介绍首页的翻译:
《LightCloud — 分布式键-值数据库》:http://www.cnblogs.com/tmfc/archive/2009/03/07/1405669.html
因此我也没必要在此继续扫盲。

还有一篇对其实现原理的翻译:
《LightCloud设计特点》:http://www.cnblogs.com/tmfc/archive/2009/03/08/1406421.html

在此我也谈一些我对LightCloud的肤浅的理解,欢迎拍砖:
1、LightCloud只是一种思想和粘合剂,其核心的存储引擎是ttserver(或曰TokyoTyrant),另一个替代的存储引擎是Redis。
2、LIghtCloud由两部分组成,一个是tyrant manger(或redis manager),用于启动(停止、恢复、备份)更多的存储进程(ttserver or redis);
另一部分是客户端,实现了将数据冗余写入到多个服务器;
tyrant manger(或redis manager)和客户端都是python写成的。
svn服务器的位置是:http://opensource.plurk.com/svn/opensource/tyrant_manager,不过看起来好像被河蟹了,访问不到。
3、实现分布式的关键在于客户端:
·每次写入的时候,客户端根据key的hash值,将同一个节点写入三个服务器;
·这三个服务器中的每一个又有一台备份服务器(这样看来,每个key-value存在六份)
有那么多服务器,数据冗余度那么高,想丢都难啊!

官方网站上应该会讲得更清楚:
LightCloud Homepage: http://opensource.plurk.com/LightCloud/
存储引擎的安装说明:http://opensource.plurk.com/LightCloud/Installation/ (其实就是安装ttserver, redis)
tyrant manager: http://opensource.plurk.com/LightCloud/Tyrant_manager/ (服务进程的管理器)
python客户端的使用例子:http://opensource.plurk.com/LightCloud/Usage_from_Python/
设计说明:http://opensource.plurk.com/LightCloud/Design_spec/ (实现思想)

这朵云,果然够轻!

分布式文件系统比较

2010年8月2日 wenhui 没有评论

发信人: Dieken (风催草低 – 明月何尝不照人), 信区: LinuxDev
标  题: 分布式文件系统比较
发信站: 水木社区 (Mon Mar 22 21:58:25 2010), 站内

简单调查了下开源的东西,一些总结,谬误偏颇遗漏之处请指正。

MooseFS 很不错,已经实用了半月了,易用,稳定,对小文件很高效。
MogileFS 据说对于 Web 2.0 应用存储图片啥的很好。
GlusterFS 感觉广告宣传做的比产品本身好。
OpenAFS/Coda 是很有特色的东西。
Lustre 复杂,高效,适合大型集群。
PVFS2 搭配定制应用会很好,据说曙光的并行文件系统就是基于 PVFS。

适合做通用文件系统的有 MooseFS,GlusterFS,Lustre。
===============================================================
dCache
- 依赖 PostgreSQL

xtreemfs
* 服务端是 Java 实现的
- 性能不高

CloudStore (KosmosFS)
+ 被 Hadoop 作为分布式文件系统后端之一
- 不支持文件元信息
- kfs_fuse 太慢,不可用
- 编译依赖多,文档落后,脚本简陋
- 开发不活跃

MooseFS
+ 支持文件元信息
+ mfsmount 很好用
+ 编译依赖少,文档全,默认配置很好
+ mfshdd.cfg 加 * 的条目会被转移到其它 chunk server,以便此 chunk server 安全退出
+ 不要求 chunk server 使用的文件系统格式以及容量一致
+ 开发很活跃
+ 可以以非 root 用户身份运行
+ 可以在线扩容
+ 支持回收站
+ 支持快照
- master server 存在单点故障
- master server 很耗内存

MogileFS
- 不适合做通用文件系统,适合存储静态只读小文件,比如图片

GlusterFS (http://gluster.com/community/documentation/index.php/GlusterFS_Features)
+ 无单点故障问题
+ 支持回收站
+ 模块化堆叠式架构
- 对文件系统格式有要求,ext3/ext4/zfs 被正式支持,xfs/jfs 可能可以,reiserfs 经测试可以
(http://gluster.com/community/documentation/index.php/Storage_Server_Installation_and_Configuration#Operating_System_Requirements)
- 需要以 root 用户身份运行(用了 trusted xattr,mount 时加 user_xattr 选项是没用的,官方说法是
glusterfsd 需要创建不同属主的文件,所以必需 root 权限)
- 不能在线扩容(不 umount 时增加存储节点),计划在 3.1 里实现
- 分布存储以文件为单位,条带化分布存储不成熟

GFS2

http://sourceware.org/cluster/wiki/DRBD_Cookbook

http://www.smop.co.uk/blog/index.php/2008/02/11/gfs-goodgrief-wheres-the-documentation-file-system/

http://wiki.debian.org/kristian_jerpetjoen

http://longvnit.com/blog/?p=941

http://blog.chinaunix.net/u1/53728/showart_1073271.html (基于红帽RHEL5U2 GFS2+ISCSI+XEN+Cluster 的高可性解决方案)
http://www.yubo.org/blog/?p=27 (iscsi+clvm+gfs2+xen+Cluster)

http://linux.chinaunix.net/bbs/thread-777867-1-1.html

* 并不是 distributed file system, 而是 shared disk cluster file system,需要某种机制在机器
之间共享磁盘,以及加锁机制,因此需要 drbd/iscsi/clvm/ddraid/gnbd 做磁盘共享,以及 dlm 做锁管理)
- 依赖 Red Hat Cluster Suite (Debian: aptitude install redhat-cluster-suite, 图形配置工具包
system-config-cluster, system-config-lvm)
- 适合不超过约 30 个节点左右的小型集群,规模越大,dlm 的开销越大,默认配置 8 个节点

OCFS2
* GFS 的 Oracle 翻版,据说性能比 GFS2 好 (Debian: aptitude install ocfs2-tools, 图形配置工具包 ocfs2console)
- 不支持 ACL、flock,只是为了 Oracle database 设计

OpenAFS
+ 成熟稳定
+ 开发活跃,支持 Unix/Linux/MacOS X/Windows
- 性能不够好

Coda
* 从服务器复制文件到本地,文件读写是本地操作因此很高效
* 文件关闭后发送到服务器
+ 支持离线操作,连线后再同步到服务器上
- 缓存基于文件,不是基于数据块,打开文件时需要等待从服务器缓存到本地完毕
- 并发写有版本冲突问题
- 并发读有极大的延迟,需要等某个 client 关闭文件,比如不适合 tail -f some.log
- 研究项目,不够成熟,使用不广

PVFS2

http://blog.csdn.net/yfw418/archive/2007/07/06/1680930.aspx

* 高性能
- 没有锁机制,不符合 POSIX 语意,需要应用的配合,不适合做通用文件系统
(See pvfs2-guide chaper 5:  PVFS2 User APIs and Semantics)
- 静态配置,不能动态扩展

Lustre
* 适合大型集群
+ 很高性能
+ 支持动态扩展
- 需要对内核打补丁,深度依赖 Linux 内核和 ext3 文件系统

Hadoop HDFS
* 本地写缓存,够一定大小 (64 MB) 时传给服务器
- 不适合通用文件系统

FastDFS
- 只能通过 API 使用,不支持 fuse

NFSv4 Referrals
+ 简单
- 没有负载均衡,容错

NFSv4.1 pNFS
- 没有普及

spNFS
* pNFS 在 Linux 上的一个实现

Ceph (http://ceph.newdream.net/)
- 开发初期,不稳定
- 依赖 btrfs

GFarm (http://datafarm.apgrid.org/software/)
OBFS

分类: 存储集群 标签: