这次做portal的一些总结(二)

接着前面的写。上文主要写了 ajax portal 中的使用,这篇写集群方面的体会。现在比较流行的架构就是前端 F5 做负载均衡,后面 2 websphere server 做成集群,各自都有 HttpServer ,每个 HttpServer 都向 2 was 做转发。这样每台都能独立完成从 HttpServer was 的流程。一台出现故障, F5 首先进行切换,只向正常 server HttpServer 发起请求,这台 HttpServer 再进行切换只向同一台 server 上的 was 做转发。这次 portal 就是采用的这种架构,不妨称为架构 A

另一种简单点的架构就是只做 F5 负载均衡,不做 was 集群,每台 websphere server 上的 HttpServer 接受 F5 转发的请求,只向本 server was 转发。这样每台 websphere server 保持独立,相互间没有数据交换和转发。不妨称为架构 B

架构 A B 各有优劣,适合不同的需要,下面进行些比较:

Ø         从应用部署上看:

A 使用了 websphere 集群,由一个 DeployManager 进行分发,部署应用,只需部署一次,由 DM 分发到几个节点上。而 B 每个 server 都是独立的,部署应用只能一台台部署,如果 server 较少差别还不明显,如果达到 10 台以上,一台台部署将是一个比较痛苦的事情。

Ø         session 上看:

A 使用了 websphere 集群,可以使用集群提供的 session 复制,对于一些关键应用(某台服务器宕机, session 也必须保持的应用)很有必要。而对于一些能够允许 session 丢失的应用,才可以使用 B 。当然 A 也可以关闭 session 复制,因为 session 复制不管是使用数据库方式还是内存方式,总会消耗一定的性能。具体消耗多少性能,就要看不同的 application server session 复制方案了,想深入了解,可以看集群方面的文档,我也只记得一个比较简单的 round robbin 了。

Ø         从架构复杂性看:

B 更为简单,因为没有 DM 的概念,每台 server 都保持独立。而使用了 DM 有时也会出现莫名奇妙的问题,这当然是由于不了解 DM 的机制所致,但总归也增加了复杂度,这点在后面的教训中进行说明。

Ø         从水平扩展性上看:

B 肯定更胜一筹。只要 F5 能支持,多少台 server 都没关系。而 A 多台 server 做集群,要看 websphere 支持的节点数量,应该不会太大。这个如果哪位同学知道,敬请告知。

当然 A B 在服务器较多的情况下是可以共存的,可以考虑几台机器做集群,然后集群间做负载均衡,这样既可以减少部署的复杂度,又可以带来较好的水平扩展。由于没做过更大型的项目,这个也只是我的假象,请做过的同学斧正。

 

说一说集群中碰到的问题。

Ø         首先是对各节点的同步:

有时为了方便测试,我们只对其中一个节点进行更改,测试通过再放到其它节点。而如果测试周期较长,有时就会造成节点的不同步,出现各种各样莫名其妙的问题。一个经验就是:无论如何,在每天下班前要保证各节点的同步,不同步的现象不要过夜。

Ø         然后是对 DM 的理解:

我现在还只是实践阶段,没有看过相关文档。从意义上看,它控制了相关的配置文件,如果进行节点同步,就会由它把配置文件同步到它管理的节点上。这对配置文件的修改提出了要求。我们开始只修改节点的配置文件而没有修改 DM 的,结果进行节点同步就会覆盖修改的配置文件,带来很多不必要的工作。经验就是:或者修改 DM 的配置文件,然后进行节点同步,或者直接同时修改所有节点和 DM 的。

Ø         还有关于 cache 的:

Cache 是性能优化的一个有效手段。在单机环境下,最简单的就是内存 cache ,使用 static Map 就行。而在集群环境中, cache 就变的比较复杂了。首先还是从应用需求入手,是否要保持每台机器的 cache 同步。如果只是信息展示等要求不高的 cache ,不需保证 cache 的同步,问题也比较简单,自己写内存 cache ,或者使用开源的 cache 组件如 ehcache,oscache 等就可以很好的解决问题。而如果需要 cache 在几个节点保持同步,就需要特殊的机制了, ehcache 等号称支持分布式 cache ,但好像需要 jgroup ,配置比较麻烦,我没有用过,有用过的同学请指教。我本来想使用 session 保存,然后进行 session 同步,后来 IBM 建议使用数据库 cache ,即自己写代码, cache 在数据库中。这样不需要 session 同步,对象不大,性能也能得到保证,现在用下来效果还可以。

 

posted on 2006-12-13 13:39 pesome 阅读(3618) 评论(9)  编辑  收藏 所属分类: 系统架构

评论

# re: 这次做portal的一些总结(二) 2006-12-13 16:43 ilikeJava

集群问题比较高深,有没有系统的介绍的文章  回复  更多评论   

# re: 这次做portal的一些总结(二) 2006-12-13 21:05 lala

was和wps都有部署脚本的,支持jacl和xmlaccess,6.0开始还支持Jython写部署脚本。  回复  更多评论   

# re: 这次做portal的一些总结(二) 2006-12-15 09:39 pesome

就是可以通过脚本一次部署到多台服务器上的?好像不错啊  回复  更多评论   

# re: 这次做portal的一些总结(二) 2007-01-03 10:48 guoyumin

分布式cache 很多开源的cache都支持,本身机制也不复杂。
不过注意在多台机器之间传播cache数据总不是一个好主意,一般建议只传播invalidate事件。

cache在数据库中的机制不太明白,能具体点?

  回复  更多评论   

# re: 这次做portal的一些总结(二) 2007-01-03 22:10 pesome

呵呵,数据库机制就是把数据存入数据库,然后每台机器到数据库去取,这比较适合数据量不是太大且更新不频繁的场合。  回复  更多评论   

# re: 这次做portal的一些总结(二) 2007-01-05 14:56 bai

数据量不大,为什么还要用数据库机制呢,直接用内存cache不就可以吗?难道你的意思是数据量不大,但是比内存还是要大吗?  回复  更多评论   

# re: 这次做portal的一些总结(二) 2007-01-05 17:27 pesome

因为使用集群,而且要保持多台机器的同步。  回复  更多评论   

# re: 这次做portal的一些总结(二) 2007-03-23 16:37 StormSpire

关于cache:
放入数据库有个问题,就是不能很方便的放入JAVA OBJECT,而只是些ID,值什么的。

集群:
不建议更新集群管理下的任何一个服务器,要更新只能更新master,就是ND上的。配置上的东西,很有可能被master上的冲掉,不稳定  回复  更多评论   

# re: 这次做portal的一些总结(二) 2007-03-26 10:31 pesome

@StormSpire
同意,我后来是都改,这样保险,呵呵!  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 
<2006年12月>
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456

导航

统计

公告

主要记录作者在学习java中的每一步足迹。除非特别说明,所有文章均为本blog作者原创,如需转载请注明出处和原作者,如用于商业目的,需跟作者本人联系。
欢迎大家访问:

常用链接

留言簿(16)

随笔分类

随笔档案

文章分类

文章档案

相册

收藏夹

java技术

人间百态

朋友们的blog

搜索

最新评论

阅读排行榜

评论排行榜