谈谈我个人对于集群中文件共享的观点

ecloud

原帖由 jamesb 于 2005-12-21 13:30 发表
归根结底你是想保持session了，lvs里的persistent的选项就可以

不是session那么简单的问题
比如你有一些文档，对这些文档建立索引，那么你的索引是什么格式的？如何进行更新？你必须解决“锁”和“冲突”。另外还有数据库连接的问题。
如果你的文档和索引全部都是实体文件存在的，那么你就会遇到非常棘手的文件共享问题。
那么你可以把所有的文档和索引都放到数据库中，这种做法也比较常见，但是如果这些文档都是邮件或者其他一些不便放入数据库中的文件的话，就难办了。更何况一般的SQL数据库并不适合进行文档管理，效率是很低的。
因此才有了google的bigfile
而如果你使用Zope内建的索引功能的话，那么你根本就不用考虑这个问题，因为他是对一个集群整体的对象建立的索引，而且是Zope自行维护的。zope内建的全文检索功能的速度是perl+sql编程模式的10倍以上，是跟用存储过程编程一个数量级的，但是它不需要你编写一行代码，而且自动解决集群问题

nntp

原帖由 ecloud 于 2005-12-22 10:59 发表

不是session那么简单的问题
比如你有一些文档，对这些文档建立索引，那么你的索引是什么格式的？如何进行更新？你必须解决“锁”和“冲突”。另外还有数据库连接的问题。
如果你的文档和索引全部都是实体文件 ...

说的有一定的道理，不过用事实说话，目前这样的实现方法并不适合实际应用.

joyhappy

能否就Google网络文件系统仔细谈一谈。

cluster中的文件系统，我基本了解一些，读过一些源代码，也做过产品和方案。补充一下我的看法：
1。NFS是使用得最普遍的也是最稳定的网络文件系统。在很多HPC中都经常使用，因为做并行计算mpi时，往往需要共享中间过程产生的大量数据，或者是输入的采集数据非常大（几十GB甚至上TB）（在top500中，一些中低端的配置也用得不少吧）。但由于NFS是那种单server的模式，所以由此产生了NFS server的入口I／O带宽的瓶颈。解决这个问题的途径是，首先了解数据流的各个阶段，有将千兆网卡做bonding的，有将业务数据分组的，有使用FC的高性能raid的。。。
2。从文件系统的角度解决NFS的并行性能的是使用并行文件系统，如PVFS，Lustre，我不知道将Lustre归于并行文件系统一类是否妥当。（Lustre号称在top500中被广泛使用）不过Lustre的牛人之一peter，我倒是见过，并且一眼看上去就是个搞研究的牛人。PVFS我看过早期的源码，实现原理简介明快，对于大文件I／O的聚集带宽性能应该是比NFS强，但metadata的HA，以及I/O server的HA，好像并没有冗余的设计，PVFS采用数据的网络分片方式并发处理I／O流，所以类似与网络的RAID0，但是一旦有一个I／Oserver宕机或者干脆metadata宕机会很麻烦，不知道这些在PVFS2中得到改进没有（我有好久没有看PVFS了，不过我想PVFS2最好支持一下网络RAID5的数据分片，以提高数据的高可靠性。当然，这些都只是性能和可靠性之间的折衷了）。似乎lustre比PVFS在HA方面做得好一些。PVFS和Lustre，个人认为对小文件的支持肯定没有大文件好，这是由他们的原理来决定的。另外，向coda，似乎也是metadata和I／O server的架构，具体没有去研究。
3。还有一个牛文件系统不得不提，这就是GFS。在sourceforge上有opengfs，后来sistina被RH拿了之后，sistina的看家技术GFS顺利成章的成为RH的solution了。GFS不同于PVFS等CFS，GFS应该来说是严格的分布式日志文件系统，不同于PVFS系统的关键在于，GFS的metadat和I／O real data都分布在一个逻辑的存储池上（这个存储池，可以是共享的SCSI盘阵或者光线盘阵，还可以上是iSCSI或者gnbd和lvm组合形成的虚拟可扩展存储块），和传统的本地文件系统类似，不同的是GFS的makefs工具和内核模块都是分布式的。当然GFS的性能，通过实际的使用，我觉得并不是很乐观，它使用dlm锁／gulm锁，似乎带来了性能的不少损失。不过，GFS似乎更通用一些，不向PVFS／Lustre对hpc支持得更好。GFS常常用于LB和HA的并行数据库应用当中。商业的这类FS，象Veritas的CFS好像也不错，和Oracle的rac配合的很好。
4。DAFS，搞存储的人都知道有个netapp，dafs号称可以改善数据通过网络的性能消耗，在对ＮＡＳ这类设备的改进有帮助。有netapp有用ＮＡＳ来支持oracle的系统的测试报告，性能好像不错，这个dafs应该发挥了作用。
5。其他CFS，象IBM的GPFS，或者storageTANK之类的东东，没有实际用过，所以不敢妄言。


从楼主的贴，看得出楼主对一些应用的架构还是比较了解的。但对于cluter，fs，storage的理解还没有成系统（不好意思，恕直言）嘻嘻。。。

其实cluster方式也好，并行方式也好，数据的共享和并发存取是个老生长谈的话题，学CS archit的人都知道。只是现在cluster架构的应用和solution越来越多，使得更多的人开始关注。
试问，从CPU，mem，net，fs，disk等，这些层次，有哪个层次没有考虑到数据的共享和并非存取呢？

以上仅是个人一家之言，简陋生僻，望大家不要　乱p我呀。呵呵　^-^

joyhappy

原帖由 ecloud 于 2005-12-21 10:45 发表

呵呵，我当然说的是LB集群，我一般不大把HA归入“集群”的范畴之内，同时，HA当中也不存在实时的文件共享问题

您说的没错，的确很多程度上非技术因素决定了最终的行为的方式。不过我觉得，至少作为技术人员， ...

就我参与的cluster的研发来看，还没有一个人说ＨＡ不算是“集群”的范畴，也没有一个大牛这样说过，若你指的“集群”是“cluster”这个词的话。

ＨＡ应该来说是cluster最早、最简单、最流行的一种应用，尤其是双机ＨＡ软件。
一般圈子里的人都将cluster分成３种：
１。ＨＡ
２。ＬＢ
３。ＨＰＣ

个人认为这种划分是有道理的。不知道你用过老章的ＬＶＳ没有，现在好像ＲＨ在卖这个东东（cluster　suite）。里头的director　server不也要用ＨＡ吗？否则director　server宕机了，ＬＢ不也是个没用的东东吗？

多节点的ＨＡ，以及ＨＡ的active-active的并发应用也是需要文件系统共享的并发控制的。（只不过多节点的ＨＡ在国内的实际应用案例的确不多，往往不被人了解。）

看来楼主真的是不懂ＨＡ啊。更是小看了ＨＡ。呵呵！？！？

joyhappy

还有:
Veritas VCS
EMC (Legato) costangdy and aam　
NRC lifekeeper
NEC cluterpro
ROSE roseHA
turbolinux turobha

......
这些都是在国内有不少应用案例的ＨＡ，在银行、电信、政府行业应用比较多。

nntp

joyhappy 看得出是闲下来的， 你说的都是正解. 我就废话了. 分享一些我熟悉的东西:

1. lustre 的HA特性的确如你所说比PVFS好，而且是好得多。所以lustre 现在的license mode让独立研究人员深恶痛绝。(kick kick)，不过也从另外一个角度表达了这样一种意思，就是lustre可以更好的复合企业环境的应用，而不仅仅是hpc 的后端.

2. lustre/pvfs之类的分布式文件系统(包括GFS) 对于小文件的表现，仍旧如同传统文件系统那样，没有给我在具体项目中带来任何的希望. (实际上一度把我逼死).  我在这个论坛的另外一个帖子中详细写过关于小文件的在分布式fs上的性能问题. 就不重复了.

庆幸的是, infiniband 价格的一再降低给分布式fs带来了希望. 也许我们今天苦恼的问题，将来会随着底层硬件基础的发展被轻而易举地克服掉. (好像历史上很多情况都是如此). 我们有一套lustre 在infiniband上跑，当然小文件表现比之前的GbE好很多，但是仍旧不够好.

3.在评估过GFS之后，我还是觉得lustre更加有希望领先于其他分布式fs进入商业应用的主流市场. 所以空闲下来后，我会花比较多的精力来琢磨.

其它也没什么好说得了，都被joyhappy说掉了.  :\">


另外开贴讨论 gogole fs :\">

[ 本帖最后由 nntp 于 2005-12-23 18:33 编辑 ]

jamesb

版主可以试试polyserve，在文件系统的性能好GFS太多。ocfs2目前还不太成熟，大io的情况下容易崩溃；afs还可以，但是被ibm阉割了净化。

nntp

原帖由 jamesb 于 2005-12-24 12:23 发表
版主可以试试polyserve，在文件系统的性能好GFS太多。ocfs2目前还不太成熟，大io的情况下容易崩溃；afs还可以，但是被ibm阉割了净化。

polyserve 比较贵.不过性能的确不错.

ecloud

我的倾向是尽量避免使用网络文件系统（也是发这贴的意义）
能够靠应用层解决的靠应用层解决，能够扔进数据库的靠数据库解决
最理想的境界就是，一个统一的应用程序包+数据库，除了配置文件不在FS（无论是本地还是网络的）上存在任何别的东西！

青春狐狸

原帖由 jamesb 于 2005-12-21 15:56 发表
我对ha和loading balance的分类就是，HA里的一个服务一般只运行在一个节点上，而loading balance的一个服务一般运行在多个节点上，从这个角度来说,rac当然算负载均衡的集群

同意。rac怎么不算是负载均衡？按流量和按连接不同而已。rac很容易就做到按照连接的负责均衡
RAC－－－真正的应用集群，oracle吹了n年的东东