WebSphere和Portal的部署方案的选择

      客户又买了2台IBM X366的PC Server，4个CPU，8G内存，据说性能比IBM以前的低端小型机要好很多。因为客户买了多套正版的Windows 2003的企业版，所以想在这2台机器上安装Windows2003的Cluster。

      只有Windows2003的企业版及Data Center的版本才可以做Cluster，企业版据说可以支持4台机器，而数据中心版本的可以支持8台，而Windows2000的Cluster只能支持一半的机器，据说MS在全国一直在维护2台数据中心的Windows集群，每年巡检，其他时间不用重启，也不会蓝屏，据说是MS现在最牛的系统了，当然这是听来安装的工程师所说的，而他是从台湾的IBM的培训讲师那里听来的。

      Windows2003的Cluster首先要共享存储，如果不共享存储的话，那么就要安装Veritas之类的软件，而这类软件非常的贵，所以，还是共享存储划算。首先在存储上划出专用的区做心跳用，还要在每台机器上安装2块光纤通道卡，因为用的是IBM的目前比较牛的DS4800，可以支持4Gbit/s,据说可以管理56TB的存储，我们的系统目前使用了14块146G(转速15000转)的存储。所以，速度很快，一块光纤卡用于心跳通讯，一块用于网络通讯。把存储划分给Windows2003的组，这样才能找到共享存储，然后在一台上创建Cluster，创建成功后，在另一台上加入就可以了。在安装过程中如果使用本机的管理员帐号，需要写成“administrator@本机IP”，否则用的是域的管理员帐号。

      另外Windows2003的Cluster支持主-主模式的，但大部分的应用要求主－从模式的，比如如果安装DB2的集群，如果没有买IBM的“并行分区”组件的话，那么只能主-从运行。如果DB2选择主－从运行的话，那么在2台机器上都安装DB2，只是在一台上create database 到共享存储上，另一台catalog就可以了。另外Windows的Cluster支持故障转移，如果一台有故障，则另一台回接管。而2台机器对外有一个“虚拟IP”或者叫“漂移IP”，如果访问DB2集群的数据库，需要使用的就是这个“漂移IP”。实际一个集群有3个IP，A机一个，B机一个，两台机器对外表现为第三个IP，也就是“漂移IP”，在安装Cluster的时候，需要手工指定。开始的时候，“漂移IP”是绑定到“主”机的，如果“主”机发生故障了，则Cluster会检测到这个故障，然后把这个“漂移IP”绑定到B机，这样再来的请求就被转发到B机器了。

最近在做系统部署方案，一共有3个：
      1:Portal和WebSphere安装在Windows2003的Cluster上，由Cluster负责failover和load banlance。
      2:做WebSphere和Portal的Cluster，由IHS转发，但存在单点故障，需要购买ND版本的WebSphere，如果要消除的话，需要增加服务器和购买Edge Server。部署复杂，维护困难。但这是最常规的做法。
      3:WebSphere一台机器，Portal一台机器，同时加2台Server，一台安装WebSphere，一台安装Portal，作为备用服务器，如果出现故障，立刻换掉IP，这样的方案非常简单，而且维护容易，但限制是，需要人工来发现故障和替换。

      经过和IBM的几个工程师沟通，最终定下了第三种方案，理由：
      IBM工程师强烈不建议部署到Windows的集群上，根本不愿意讨论第一种方案，所以排除。
      第二种方案的好处是可以做到自动的故障转移和负载均衡，而且即使一台瘫掉了，用户的Session的信息依然在另一台机器上。Session的复制可以在内存中或者数据库中。而且可以2台机器都同时服务。缺点是架构复杂，维护困难，需要更多的硬件，还需要购买做集群的ND版本的WebSphere，即使做了WAS和Portal的Cluster，也不能消除单点故障，如果要消除单点故障，那么还要购买Edge Server，而且还要增加机器，而且Edge Server建议安装2套，即使这样，也还是不能消除单点故障，我的一个IBM的朋友告诉我，如果ND版本的Deploy Manager死掉了，那么还是不能服务了。所以，这种昂贵的方案也排除了。
      第三种方案的好处是简单容易维护，硬件要求也不高，目前在试运行环境稳定的运行了半年多了。采用这种方案只需要找2台性能差不多的服务器，一台作为Portal Server的备份机器，另一个作为WebSphere的备份机器，这2台机器的性能可以比真正的Server的性能差些，平时可以运行其他的不重要的应用，在Portal或者WebSphere出现故障的时候，立刻将IP替换掉，可以尽快的继续提供服务。然后腾出时间来查找Portal或者WebSphere的故障原因。当然，如果Portal或者WebSphere的主服务器只需要重启一下就可以解决问题的话，那么还是不用动用备用的服务器的。