免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: yftty
打印 上一主题 下一主题

浩存 - 面向数据库,虚拟机等海量数据可同时提供NFS/iSCSI访问的集群存储系统 [复制链接]

论坛徽章:
0
111 [报告]
发表于 2005-07-02 22:35 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

小弟对该项目很有兴趣,希望能加入。我做的是GFS中Master的部分,即meta data server,请版主告知具体步骤。另外有些问题也请有兴趣的兄弟讨论:
1、google文件系统的确实现了一些创新,但它主要是为google自己的Application服务,所以对此在设计时作了许多优化,但拿来作为通用的未必有利(例如用户接口设计和文件分块方式)。
2、GFs采用的是单metadata server,对此各方有很多批评,pvfs第一版采用的也是单metadata server,第二版中改成了分布式的多metadata server,但这样也带来了许多问题,就此不知大家有何高见。
3、集群(并行)文件系统现在大多一中间件的方式出现,下一步能不能制定标准集成到os中?

论坛徽章:
0
112 [报告]
发表于 2005-07-02 22:53 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

[quote]原帖由 "Randome"]小弟正在根据goole的相关资料开发基于linux的GFS原型,用c++实现,有2万多行源代码,基本能跑起来了,但没找到根多相关的资料,也没有很详细的同类文件系统的资料,如果哪位有还望能赐教,有兴趣可以共同开发,非商

论坛徽章:
0
113 [报告]
发表于 2005-07-02 22:58 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

这篇文章已经有了,多谢了
楼主原来在线啊,能不能聊聊,小弟qq:382502660

论坛徽章:
0
114 [报告]
发表于 2005-07-02 23:09 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

>;小弟对该项目很有兴趣,希望能加入。我做的是GFS中Master的部分,即meta data

给你发站内信息了,请看.

>;server,请版主告知具体步骤。另外有些问题也请有兴趣的兄弟讨论:
>;1、google文件系统的确实现了一些创新,但它主要是为google自己的Application服
>;务,所以对此在设计时作了许多优化,

是的,它本身可以说是针对某个应用的一个数据管理库函数,是应用了成熟的业界技术,达到了Performance/Cost的最优方案.

>;但拿来作为通用的未必有利(例如用户接口设计和文件分块方式)。

它是不能作为通用集群文件系统的,它并不支持POSIX标准.

>;2、GFs采用的是单metadata server,对此各方有很多批评,pvfs第一版采用的也是单

因为存在可能的系统瓶颈,但从工程上来说是可取的,同时它可以通过控制MDS的检索粒度平衡MDS的负载.

>;metadata server,第二版中改成了分布式的多metadata server,但这样也带来了许多问
>;题,就此不知大家有何高见。

MDS的数据同步问题.

>;3、集群(并行)文件系统现在大多一中间件的方式出现,下一步能不能制定标准集
>;成到os中?

这个可以看看ReiserFS v4, Lustre试图进入Mainline的努力

论坛徽章:
0
115 [报告]
发表于 2005-07-03 17:17 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

我不是搞开发的
但对这个也还是比较感兴趣,弄过GFS,OGFS,PVFS之类的
而且从事的也还是HA相关的工作,不知道能做些什么呢?~

论坛徽章:
0
116 [报告]
发表于 2005-07-05 12:46 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

原帖由 "beyondsky" 发表:
我不是搞开发的
但对这个也还是比较感兴趣,弄过GFS,OGFS,PVFS之类的
而且从事的也还是HA相关的工作,不知道能做些什么呢?~


那你是否有兴趣整理下需求呢? 例如作为一个存储系统的管理方案,如何利于使用和管理等,或者不需要人的管理介入. 以及你所提的几个FS对于用户来说的体验区别

例如这个需求文档 < Tri-Labs/DOD SGS File System RFP>;  http://www.lustre.org/docs/SGSRFP.pdf

论坛徽章:
0
117 [报告]
发表于 2005-07-07 09:50 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

Here is my suggestion
A client connects to the cluster through an Access Point (AP)

File Data Servers (each one called a node)
- files/copyes are identified by an uniquie ID and DELTA (version of the copy)
- node stores only whole files (no idea how to implement striping yet)
- don`t bother with any directory structure

Database Servers
- Implement directories and directory tree, hold information for file
ID and DELTA

Meta data server
- gather node`s traffic/freespace/resource load
- hold nodes` file list (node, file ID, file DELTA, popularity), so we
know where each copy is and it`s version
- all read/write requests go through them

Unit - MDS with all nodes that belong to it

Control servers (CS)
- move/replicate/delete copies accross the cluster, implement
traffic/freespace/load balancing accross the cluster
- takes care for the number of copies present and delta. if a file is
very popular then make more copies and spread them accross less
traffic loaded nodes. if not much popular remove some copies from
heavy traffic loaded nodes
- make sure that there are N copies on different units (we do not want
to have several copies over one Unit because when unit`s mds crashes
we may encounter a situation when there is no available copy present
in the cluster)
- holds list of MDS and their load
- takes care wich MDS a node will use (node may change MDS on the fly?)

On client write:
1) AP asks DBS for the file ID and DELTA
2) AP puts a request to MDS for writing
3) MDS looks where copies of the file (ID and DELTA) are and returns
the address of the node with appropriate load (also mark that copy
with write flag)
4) client (or AP - don`t know now which one is appropriate) connects
to the node and performs the write
5) after the write the node informs MDS of the successful write
6) MDS removes the write flag of the copy, MDS updates the DELTA, MDS
informs DBS of the DELTA change
7) inform CS for the event (CS initiates copies update to the new DELTA)

On client read:
1) AP asks DBS of the file ID and DELTA
2) AP puts read request to MDS
3) MDS looks where copies of the file (ID&DELTA) are and returns the
address of the node with appropriate load
4) client (or AP) connects to the node and performs read

On client read/write dir:
1) AP informs DBS
2) if file removal: DBS puts removal request ot CS

Copies update:
1) CS puts request to MDS for writing
2) MDS looks where copies of the file (ID and DELTA) are and returns
the address of the node with appropriate load (also mark that copy
with write flag)
3) CS informs the node to update the file (gives file ID and the
address of the node form which ot update)

Each node is connected to one MDS (on MDS crash go to another MDS).
on new node/MDS down
1) the node puts a broadcast
2) CS tells which MDS to use

MDS are interconnected (maybe some sort of a tree, don`t have an idea yet)
DBS - no idea for the connection yet
CS - some sort of communication, so we can avoid:
* several CS initiate same action on one node

MDS checks child node`s availability
on node down, mark his file list as inaccessible. after N minutes of
an unavailability remove file list
on new node/node up, node sends file list ot the MDS


Well that is all from me, thank you for reading all this. I hope you
will find something useful in my idea.

Best regards
Momchil

论坛徽章:
0
118 [报告]
发表于 2005-07-07 10:09 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

上次谈的关于把名字空间分布于不同的MDS上可以解决单点瓶颈问题,但是却破坏了namespace的单一性并产生了更新后的一致性问题,对于每个Client看到的还是应该是一致的namespace,我觉得不管怎么分布还应该有一个统一的名字空间,虽然不一定在一台机器上,不知老兄有何高见。

论坛徽章:
0
119 [报告]
发表于 2005-07-07 14:39 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

I suggest that create a group of QQ for communion!
okay?~

论坛徽章:
0
120 [报告]
发表于 2005-07-07 14:59 |只看该作者

Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目

原帖由 "beyondsky" 发表:
I suggest that create a group of QQ for communion!
okay?~


I consider a Forum is better, which can be devided into many channels as client, fds, mds,  namespace, datapath, log, recovery, networking, migration/replication, utilities, etc.
which is about 4 hundreds pages book.
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP