WebLogic集群详细方案设计

From here
数据库层：
数据库：oracle 10g 数据库服务器：2台以上F5 设备：2台
部署图：
采用RAID 0+1的
磁盘阵列
部署描述：
1.F5虚拟地址作为对数据用户的唯一地址。

2.F5有主备2台设备，相互之间部署心跳线，在F5的配置中设定其中一台作为主机，配
置心跳的告警设置和数据库服务器的告警设置。

3.ORACLE需要安装F5的管理插件以监控数据库服务器性能参数和状态。

4.数据库采用RAC的方式进行集群，数据库之间有心跳线。

5.服务器Cluster需要一个统一的时间，在整个应用中由统一的服务器提供同步服务。

6.在数据库服务器集群和文件系统之间的交换机需要有主备线路。

访问控制：
1.对F5虚拟地址的访问需要在数据库防火墙中配置白名单
2.数据库的实地址只有DBA等数据库管理角色才能访问
负载均衡：
1.F5设备通过在Oracle服务器上的插件获取各个数据库本身的连接数，内存使用量，CPU
占用率等参数，以及在F5配置中设置负载分发的规则来分发对数据库的真实访问。

2.对于数据库Cluster来说，采用10g以上版本的RAC的方式会有一个公用的缓存区。

数据安全：
1.在文件系统中采用RAID 0+1的方式进行数据存放和备份
2.磁带库作为文件系统的最终容灾备份。

故障处理：
1.在F5主机出现故障时，由F5备用的心跳监控到并做自动切换，同时可以按告警配置进
行对应操作。

2.数据库节点中一台出现问题时，会由别的节点接手，同时F5会监控到数据库的状态出
现异常并按照告警配置进行对应操作，例如【发送告警邮件】等。

3.在数据库集群和文件系统的网络中，当主要线路出现问题，由备用线路接手。

优点：
1.可扩展性好，在性能出现瓶颈的时候不需要修改整体布局，只需要增加服务器并配置
2.可靠性好，所有设备都至少有一个备用节点。

3.访问无缝隙，对于用户来说只有一个访问接口，对于内部所有节点的备用节点都能实现
自动切换或自动故障点剔除。

缺点：
1.采用RAC进行数据库集群需要一个统一的文件存取管理系统，数据和存取基于网络，对
网络性能和稳定性要求非常高。

2.系统网络部署成本会比较高。

3.在出现文件系统故障时，采用RAID 0+1的阵列进行恢复操作比较复杂和缓慢。

取舍：
1.可以采用大量的低端服务器方式来代替多台高端服务器实现数据库集群，但对于服务器
的管理要求很高。

2.数据存取性能要求不高，但是文件安全要求高的系统，应采用RAID1+0的方式。

应用层：
应用服务器：WEBLOGIC 9.2服务器：4台以上F5设备：4台部署图：
部署描述：
1.WEB层中的F5虚拟地址作为对外部用户的唯一访问地址。

2.APP层中的F5虚拟地址作为对内部WEB端的唯一访问地址。

3.F5有主备2台设备，相互之间部署心跳线，在F5的配置中设定其中一台作为主机，配
置心跳的告警设置和数据库服务器的告警设置。

4.F5中需要对应Weblogic集群进行相关配置，转发规则，监控频率，Session识别和转
发，以及设置服务器性能的告警，预防规则等。

访问控制：
1.APP防火墙中设置固定的白名单访问。

2.WEB服务器的实地址只有WEB层的TA维护角色能够访问
3.APP服务器的实地址只有APP层的TA维护角色能够访问
负载均衡：
1.对服务性能和响应速度有要求的应用一般按【服务器能力】的方式进行负载均衡，由F5
对每台服务器定时的监控结果【内存，CPU，连接数】，以及F5中自定义的分发规则决定
采用服务器能力的方式进行负载均衡，在出现系统资源耗尽异常时，有非常多的情况是某个server先出现异常随后伴随整个Cluster的服务器一并发生。

2.性能要求吧不高的应用一般采用【服务器几率访问】或者【服务器轮循访问】的方式进
行均衡，【服务器几率访问】适用于服务器硬件方面存在性能差异或每台服务器上应用不是平均分配的情况，可手工的调整每台服务器的访问比例，【服务器轮循访问】对于每一台服务器来说访问次数是基本平均的。

这两种负载机制由于不同业务的消耗是不同的，容易出现大消耗的请求集中在某台服务器，出现单个服务器挂起的情况，但不容易出现整个服务器Cluster一并挂起的情况。

故障处理：
1.在F5主机出现故障时，由F5备用的心跳监控到并做自动切换，同时可以按告警配置进
行对应操作。

优点：
1.实现网络的物理分割，最大程度上保证系统网络安全
2.WEB和APP对外都只拥有一个访问接口，分离前台业务和后台业务
3.对于集群内部节点是可以自由添加和删除的，因此可以实现系统的分批次部属使得服务
不必中断。

缺点：
1.在APP和WEB之间的网络性能和稳定性要求非常高，网络部署成本高。

Weblogic集群：
结构图：
Weblogic Cluster描述：
1.一个Weblogic Cluster 需要至少1台服务器。

【Cluser对服务器 1对多】
2.每一台服务器中可以有多个应用在一个Cluster中。

【服务器对应用 1对多】
3.在Cluster的配置监控中可以对每个Server的状态，连接数，Jndi连接数进行监控和
配置操作
Session处理
对于F5+Weblogic Cluster每个访问请求来说，F5能识别出weblogic的Session 并生成一个 SessionId，同样sessionId的访问请求都由同一台Server处理。

在F5中所以session会被复制一份副本，并且session的所有变化都会在副本中进行及时更新，这样，当原有Server在响应请求过程中失败时，F5会立即获取session的副本，并由此转发给状态正常的Server继续响应客户端请求，同时保存Session新副本。

Cluster管理：
1.JDBC连接池：和单机配置JDBC连接池类似，在创建连接池时，Cluster会测试每个Server
上JDBC的连通性，对于应用来说可以通过Jndi树获取到连接的DataSource，在发生连接池溢出的情况时，对于每个JDBC可以做单独的重启。

2．监控：可以查看每个Server的状态，Application的状态，
3. 发布Application：对于一个Cluster，只需要上传到其中一台，weblogic会自动分发
到Cluster中所有的服务器上。

在进行UPDATE操作时可以选中Cluster或者Cluster中个别的Server进行操作。

ProxyServer：
1.proxyServer可以作为F5的代替，作为一个对外的唯一访问地址。

2.proxyServer可以是安装有BEA WebLogic Server的Web服务器，或者是安装了 WebLogic
插件的Apache服务器或其他服务器。

3.proxyServer是一个软件方式的负载均衡和硬件层面的负载均衡来说成本低但软件层面
的跳转效率低，性能不能支持巨大的并发访问。

Ehcache集群
结构图：
集群描述：
1.集群配置采用RMI组播的方式进行集群，在Ehcache的集群中不存在主节点和子节
点的关系，所有的节点都是平级的。

通过配置multicastGroupAddress，使得每个节点的Ehcache都会去自动扫描此区段中的地址，每个节点都可以获取到其他节点
的信息。

2.对应不同的业务，配置不同的缓存组，对应不同缓存组按业务要求配置不同的缓存
规则，并配置这个缓存组是属于本地缓存还是集群的缓存。

缓存操作：
1.GET操作：对本地的LocalCache 缓存进行查询
2.PUT,REMOVE,UPDATE等缓存DML操作：将修改结果同步到别的节点上
优点：
1.增加节点基本不需要配置，只需要保证节点处在同一个网段即可，可以避免人为配置
的错漏出现。

2.由于RMI是JAVA自带的，无需引入其他JAR包。

缺点：
1.由于缓存是通过RMI同步分发到各个服务器上的，当缓存的数据量很大时不适用。

2.网络可能会禁用组播功能，若禁用多播则需要对每个节点配置上集群中其他节点的地址。

分布式缓存的Ehcache实现：
部署图：
缓存ClusterA缓存ClusterB
集群描述
1.采用Ehcache Server的方式对缓存进行管理，缓存管理服务器的主要功能维护一张
HashCode表，决定缓存的查询是访问哪组Cluster，同时对Cluster各个服务器进行负载均衡的访问控制。

2.对于每一个缓存Cluster ，采用RMI/JGROUP等方式做2台服务器一组的最基本的缓存
集群，实现缓存数据的同步分发。

优点：
1.可以支持大量数据的缓存
2.有统一的缓存管理
缺点：
1.较直接查内存数据来说，通过网络的形式进程缓存查询性能较低，同时对网络性能要求
非常高
2.。