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

ecloud

集群技术中，最令人头痛的就是文件的共享，尤其是那些需要读写操作，并且非常频繁的
当前在这方面的技术很多，包括使用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 编辑 ]

fffy2366

九年后僵尸贴被扒出来，新手刚了解了两个概念：集群(cluster)和高可用性(HA)，两者的关系之对于HAproxy和Keepalive ，不知是否可以这样理解。

nntp

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

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

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

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

suran007

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

suran007

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

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

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

fengwy

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

青春狐狸

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

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

ecloud

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

nntp

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

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

jamesb

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