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

Question

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

Answer 1

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

我跟你的观点比较类似

Answer 2

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

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

Answer 3

我对ha和loading balance的分类就是，HA里的一个服务一般只运行在一个节点上，而loading balance的一个服务一般运行在多个节点上，从这个角度来说,rac当然算负载均衡的集群

Answer 4

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

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

Answer 5

rac是负载均衡的集群好不好，呵呵

Answer 6

原帖由 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年的工作在你的一个帖子里面被划分到了其他领域 :")

Answer 7

归根结底你是想保持session了，lvs里的persistent的选项就可以

Answer 8

原帖由 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，作为你应用程序的主要技术路线，这样集群的问题基本上就迎刃而解了

Answer 9

你说得到底是HA集群还是负载均衡的集群?

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

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

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

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

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