To support the above-said functionality, the cluster uses a messaging model for members of the cluster to exchange the information required to keep the cluster in sync. WebLogic Server supports two cluster messaging protocols:[1,2]
Note that, in our configuration, we have both servers installed on the same machine. But, the best practice is to install them on different machines in case that one of them crashes.
CustomerCluster mentioned here is configured in the CRM Domain of CRM Fusion Application. There are two members in the cluster. To sync up each other, unicast cluster messaging mode was chosen as shown below:
It is important to note that although unicast is the default protocol, Oracle fully supports both protocols equally. As stated in [1], parts of the WLS documentation suggest or imply that multicast is only supported for backwards compatibility (see [4]). This suggestion or implication is incorrect. For example, if you are using WebLogic Server 12c, the choice of protocols should not be influenced by this wording in the WLS documentation. Read [1] for a good comparison for clusters using either unicast or multicast protocols.
Unicast protocol relies on point-to-point TCP/IP sockets. So, WebLogic Server’s unicast implementation uses a group leader strategy to limit the growth in the number of sockets required as the cluster size grows. The cluster is split into one or more groups; each group has a group leader. Group members communicate with the group leader; group leaders also communicate with other group leaders in the cluster. If a group leader dies, the group elects another group leader. In the example CustomerCluster, CustomerServer_1 is the group leader (see Figure).
When configuring WebLogic Server clusters for unicast communications, if the servers are running on different machines, you must explicitly specify their listen addresses or DNS names.
To find out more information, read the following articles:
- Multicast – This protocol, which relies on UDP Multicast, has been around since WebLogic Server introduced clustering back in WebLogic Server version 4.0.
- Unicast – This protocol, which relies on point-to-point TCP/IP sockets, was added in WebLogic Server 10.0.
- CustomerServer_1
- CustomerServer_2
CustomerCluster
CustomerCluster mentioned here is configured in the CRM Domain of CRM Fusion Application. There are two members in the cluster. To sync up each other, unicast cluster messaging mode was chosen as shown below:
It is important to note that although unicast is the default protocol, Oracle fully supports both protocols equally. As stated in [1], parts of the WLS documentation suggest or imply that multicast is only supported for backwards compatibility (see [4]). This suggestion or implication is incorrect. For example, if you are using WebLogic Server 12c, the choice of protocols should not be influenced by this wording in the WLS documentation. Read [1] for a good comparison for clusters using either unicast or multicast protocols.
Group Leader Strategy
Unicast protocol relies on point-to-point TCP/IP sockets. So, WebLogic Server’s unicast implementation uses a group leader strategy to limit the growth in the number of sockets required as the cluster size grows. The cluster is split into one or more groups; each group has a group leader. Group members communicate with the group leader; group leaders also communicate with other group leaders in the cluster. If a group leader dies, the group elects another group leader. In the example CustomerCluster, CustomerServer_1 is the group leader (see Figure).
Final Words
When configuring WebLogic Server clusters for unicast communications, if the servers are running on different machines, you must explicitly specify their listen addresses or DNS names.
To find out more information, read the following articles:
- WebLogic Server Cluster Messaging Protocols
- How to persist session across Weblogic?
- Communications In a Cluster
No comments:
Post a Comment