|
|
Weblogic server |
端口号 |
内存分配 |
Weblogic Server执行线程数 |
| Server1 |
AdminServer |
7001 |
500M |
|
|
|
App1 |
7002 |
初始=2.4G 最大=4G
|
Thread Count: 30 Threads Increase:5 |
|
|
App2 |
7004 |
初始=2.4G 最大=4G
|
Thread Count: 30 Threads Increase:5 |
|
|
App3 |
7006 |
初始=2.4G 最大=4G
|
Thread Count: 30 Threads Increase:5 |
| Server2 |
App4 |
7002 |
初始=2.4G 最大=4G
|
Thread Count: 30 Threads Increase:5 |
|
|
App5 |
7004 |
初始=2.4G 最大=4G
|
Thread Count: 30 Threads Increase:5 |
|
|
App6 |
7006 |
初始=2.4G 最大=4G |
Thread Count: 30 Threads Increase:5 |
集群开始：(第一张图，为集群策略图)
选择创建新域配置，按顺序分别配置做如下配置： 管理服务器、被管理服务器、CLUSTER、MACHINE、JDBC POOL、JNDI。
1.Cluster，管理服务器与被管理服务器的配置不在这里赘述，注意将配各服务器拖入cluster，设置正确的ip/port等。
2.上面的列表是DomainA的配置设置情况，注意内存分配和线程分配，需要根据自身的应用情况，进行合理设置。这里是各个server共享weblogic server的内存设置
初始=2.4G 最大=4G。对jvm参数设置进行优化，也可以起到间接优化weblogic server的作用。jvm的优化可以参考java相关文档。至于执行线程数，需要结合自身业务情况，具体分析设置。
3.JDBC POOL 设置，初始=10，增长=5，最大=50(一般性的应用，应该够了)。 如果使用Oracle RAC数据库，建议使用mutipool,需要注意选择池的机制： load_banlance还是High availability。
这两种算法的区别如下：
假设有两个poolA和poolB
load_banlance机制会将压力均衡分布在两个池上。由于负载均衡，双双宕机的几率相对降低。
High availability机制,正常的情况下,只有一个PoolA起作用,其poolB是stand-by,当起作用的那个poolA出现故障,则会被 WLS标记为disable,并将请求转发到另外一个poolB上,并且定时测试被标记为disable的poolA,如果重新连接成功后,则将请求再切 换回PoolA上,PoolB继续stand-by.
相对于load_banlance，High availability对单机的负担较大，但当有一个节点A宕机后，weblogic会将数据连接切换到节点B上。
至于如何选择，根据自身业务特点来选择。
案例：如果RAC 是2个节点，也就是2个数据库实例，并且每个实例上有不用业务单元的表。假设有2个应用，将A应用的master库设为节点A的DB,slave为节点B 的DB；应用B的设置正好相反。此时选择High availability机制比较好。原因是：RAC 以Cache 同步为代价实现Cluster。在Cache Fusion 中，最大的消耗有两处：
－ 锁通知。这是无论如何我们也控制不了的，好在它的消耗不是最大的；
－ Cache 内的数据同步。如果RAC 实例间不访问同样的数据块，这一消耗是可以回避的。这一点我们能做到，而且，它是 Cache Fusion 的最大消耗者。回避的办法就是像现在
这样：让不同的实例支撑不同的业务单元，前提是这两个业务单元的表几乎没有交叉。
4. 可以在weblogic server之上加入一层代理服务器(apache)，用于处理静态文件如图片、js文件等。至于动态应用当然全权交给weblogic。