Chinaunix

标题: 谈谈我个人对于集群中文件共享的观点 [打印本页]

作者: ecloud 时间: 2005-12-20 17:08
标题: 谈谈我个人对于集群中文件共享的观点
集群技术中，最令人头痛的就是文件的共享，尤其是那些需要读写操作，并且非常频繁的
当前在这方面的技术很多，包括使用NAS/SAN，NFS等传统的网络共享，或者rsync这种非“实时”的方式等等，以及新兴的“网络文件系统”，具有代表性的就是Google

我认为，在普通的网站、电子商务、BS应用软件等领域，过分的研究网络文件共享是有点南辕北辙了
我们为什么那么执著于通过网络共享某个文件，而不从另一个角度改变我们使用这个文件的方式呢？或许我们原本可以不使用这个文件的呢？
因此我认为，我们应该更加从应用层的角度来设计、优化我们的集群而不是过分追求底层的东西。以前我们的一些观点是错误的，“一个为单机运行设计的程序，使可以直接放在一个集群的环境中得到加倍的效果”，这种观点是非常大的误解。网络环境同单机环境有着很大的不同，只有为集群环境量身定做的程序才能够最大限度发挥出效能，同时也便于管理和使用。
幸运的是我们并不需要自己动手来大量的修改我们的程序，现在已经有许多的现成的应用框架，我们可以直接使用。
比如，Websphere ND就是一个非常好的集群应用服务器，标准的ear或者war包可以不需要任何的修改直接部署在Websphere ND环境中，就可以提供集群化的应用服务，所有的session和数据库连接池的处理都由应用服务器来完成，不需要任何人工的干预。
当然这一切的根本是J2EE内建的技术规范提供的良好支持，同样Weblogic和iPlanet等其他的应用服务企业提供类似的功能。
另外一个开源软件的例子就是Zope，Zope也内建了类似的集群功能，同样有Zope服务器来管理session和数据库连接。比如通常的索引功能，在数据吞吐量不是非常巨大的情况下，我们完全可以直接使用Zope的索引服务，而不用再关心传统索引技术中索引文件的网络共享问题了。

所以我认为，一个好的集群应用方案，首先要对应用编程环境进行正确的选型，这样才能做到事半功倍。另外在程序设计过程当中，尽量使用应用服务器的内建功能，或者把那些需要事务处理的逻辑放入数据库中，利用数据库系统现成的事务处理功能。这样就能够大大简化，甚至是彻底消除网络架构上可能带来的各种麻烦。

而对于那些原有的PHP或者cgi编写的应用程序，我觉得最稳妥简便的方法是进行人工分片+url改写，把整个网站分成www1-www10等多个小块儿，这种方法虽然看上去很土，但是的确非常稳定并且有效。只是需要一定量的前期人工操作。一些很大的专业公司的网站，比如ibm,microsoft等曾经长期使用这种技术，这被证明是非常有效的。

[ 本帖最后由 ecloud 于 2005-12-20 17:10 编辑 ]

作者: nntp 时间: 2005-12-20 23:39
你说得到底是HA集群还是负载均衡的集群?

如果是前者，呢么你的观点是完全错误的。恕我直言你并不了解HA.
如果是后者，你的观点是非常有建设性的，我60%的同意你的观点. 剩下的40%不同意的原因也很简单，这个世界是一个高度竞争的世界，无论是Opensource还是商业的系统，竞争带来的表象就是不断的技术同化和不断的创新来打破同化，造成的结果就是产生大量技术本源雷同但又在不同的层次进行创新的开发组织和商业公司。由于这样的现实，所以一种具体的系统不能在自己内部创造出比自身所在的这个领域更大的力量来改变一种技术格局.

好比apache很牛B，也在不断有大的创新，但是在没有可能在这个项目的内部创造出一种力量来改变Web应用的传统技术格局.

你提到的一些软件产品和系统，都是很棒的东西，但是他们所能提供的集群能力，也受制于本身所处的这个集群领域的技术格局限之内，不可能指望通过在某些软件集群功能上的创新来改变集群技术本身的格局。改变和改善是不一样的定义。

不过你提出的想法在理论和纯技术范畴的确值得探讨，如果能够在集群技术格局的层面，打破公司和公司，开发组织和开发组织之间的壁垒和障碍，建立起统一的标准集合，呢么把集群(我说负载均衡集群)的功能由应用本身所充分实现是利大于弊的。

实际上和政治一样，企业级的应用无论是Opensource还是商业产品，都是创新技术在遇到了激烈市场竞争之后妥协的结果。有妥协，就会有不停的无奈。

作者: ecloud 时间: 2005-12-21 10:45

原帖由 nntp 于 2005-12-20 23:39 发表
你说得到底是HA集群还是负载均衡的集群?

如果是前者，呢么你的观点是完全错误的。恕我直言你并不了解HA.
如果是后者，你的观点是非常有建设性的，我60%的同意你的观点. 剩下的40%不同意的原因也很简单，这个世 ...

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

您说的没错，的确很多程度上非技术因素决定了最终的行为的方式。不过我觉得，至少作为技术人员，我们应该在技术路线选择上更具有一定的影响性。其实我说的并不是指某个特定的产品，而是住一种技术。
比如说所有的java程序员都不担心集群的问题，因为J2EE本身就包含这方面的规范，而且几乎所有的Aplication Server都实现了这些规范，无论他们选择什么产品，并不会有什么改变。
但是，类似的比较完善的web技术，流行的也只有java, MS .net 和Zope这3种，并且其中后两者都是单一产品，只有java是一个开放社区，并且有较多的选择。

而对于传统的PHP和cgi，现在还没有一种理想的技术规范和开发框架，可以说在这方面PHP是比较差劲的。我想主要原因并不是PHP缺乏商业支持（基于PHP的商业软件还是很多的），而是PHP技术的实现原理本质上仍然是cgi，依靠apache的module来实现的，每一个程序都是以一个真实的文件而存在。在这种基础之上，是无法实现一种分层次的、面向对象的、模块化的web应用框架的。在这种情况下，集群中的PHP程序之间只能依靠很底层文件共享的方式来进行协作；而java却是在应用层内的RMI技术来交换数据，而且是服务器提供的RMI包装，完全不需要你自己编写什么代码。
比如说Websphere也内嵌了apache，但是只用来解析静态页面，动态页面全部是tomcat来进行解析，只有ejb层和数据库连接池是ibm自己开发的东西。

我的主要意思就是，如果将进行一个集群项目的规划，在尽可能的情况下，最好选择java,Zope或者.net，作为你应用程序的主要技术路线，这样集群的问题基本上就迎刃而解了

作者: jamesb 时间: 2005-12-21 13:30
归根结底你是想保持session了，lvs里的persistent的选项就可以

作者: nntp 时间: 2005-12-21 14:33

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

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

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

很遗憾你把HA集群排除在"集群"之外. 这样一来，IBM HACMP, HP MC/SG, Compaq TruCluster, DEC Cluster for OpenVMS , Oracle RAC ...都被切出去了.

不知道你有没有看我之前在这里贴的一个帖子，回答一个网友关于集群的问题的时候对集群概念做的澄清。如果要严格定义的话，LB也不能算，只有hpc才是真正的"集" 和 "群"了. 我可不想看到自己从事n年的工作在你的一个帖子里面被划分到了其他领域 :")

作者: jamesb 时间: 2005-12-21 15:09
标题: 回复 5楼 nntp 的帖子
rac是负载均衡的集群好不好，呵呵

作者: nntp 时间: 2005-12-21 15:40

原帖由 jamesb 于 2005-12-21 15:09 发表
rac是负载均衡的集群好不好，呵呵

汗. 如果你这样认为的话.

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

作者: nntp 时间: 2005-12-21 16:12

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

如果你的分类方式是正确的话，的确应该如此.

作者: ecloud 时间: 2005-12-22 10:46

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

我跟你的观点比较类似

作者: ecloud 时间: 2005-12-22 10:59

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

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

作者: nntp 时间: 2005-12-22 23:17

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

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

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

作者: joyhappy 时间: 2005-12-23 13:15
标题: 回复 1楼 ecloud 的帖子，补充补充对CFS的一些观点。
能否就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 时间: 2005-12-23 13:35
标题: 你可说错大发了

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

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

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

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

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

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

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

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

作者: joyhappy 时间: 2005-12-23 13:41
标题: 回复 5楼 nntp 的帖子
还有:
Veritas VCS
EMC (Legato) costangdy and aam　
NRC lifekeeper
NEC cluterpro
ROSE roseHA
turbolinux turobha

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

作者: nntp 时间: 2005-12-23 18:23
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 时间: 2005-12-24 12:23
版主可以试试polyserve，在文件系统的性能好GFS太多。ocfs2目前还不太成熟，大io的情况下容易崩溃；afs还可以，但是被ibm阉割了净化。

作者: nntp 时间: 2005-12-24 13:52

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

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

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

作者: 青春狐狸 时间: 2005-12-28 10:49

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

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

作者: fuminglei8 时间: 2005-12-28 11:04
我顶！

作者: fengwy 时间: 2005-12-29 11:59
集群技术中，最令人头痛的就是文件的共享，尤其是那些需要读写操作，并且非常频繁的
-------------------------------------------------------------------------------------------------
大型的集群中，通信开销和同步开销应该是最大的问题

作者: suran007 时间: 2005-12-29 14:17

原帖由 joyhappy 于 2005-12-23 13:15 发表
能否就Google网络文件系统仔细谈一谈。

cluster中的文件系统，我基本了解一些，读过一些源代码，也做过产品和方案。补充一下我的看法：
1。NFS是使用得最普遍的也是最稳定的网络文件系统。在很多HPC中都经常使 ...

小声问一句，你说得gfs由于dlm或gulm的锁机制，导致集群性能的下降，那lustre也有lock机制，会不会也出现由于lock机制导致的性能的问题，能不能解释一下gfs和lustre在lock机制上有何不同？

作者: suran007 时间: 2006-02-15 17:06
问一下版主，您说您有一套lustre集群在infiband上跑，我现在用的集群文件系统是gfs，也一直想在实际环境中用这个lustre集群，不知道这个lustre集群稳定不稳定，会不会出现经常当机的情况

作者: nntp 时间: 2006-02-15 22:43

原帖由 suran007 于 2006-2-15 17:06 发表
问一下版主，您说您有一套lustre集群在infiband上跑，我现在用的集群文件系统是gfs，也一直想在实际环境中用这个lustre集群，不知道这个lustre集群稳定不稳定，会不会出现经常当机的情况

lustre 的双版本制你知道么? production版的稳定性不可怀疑.

lustre 系统比较复杂，特别是前段有一个非常大的hpc cluster时候，不稳定的因素往往来自基本的配置，还有你的storage node传递过来的一些问题.

yahoo用的是lustre.(确切地说是HP修改过的lustre,叫做SFS).

作者: rikerzhang 时间: 2006-12-05 15:34
go on discuessing ! A good subject !

作者: gl00ad 时间: 2008-10-28 02:50
标题: 回复 #26 rikerzhang 的帖子
it is nice you read this.

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)