Weblogic cluster -II

EJBs and RMI Objects

Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. Replica-aware stubs are created for EJBs and RMI objects as a result of the object compilation process. EJBs and RMI objects are deployed homogeneously—to all the server instances in the cluster.

Failover for EJBs and RMI objects is accomplished using the object’s replica-aware stub. When a client makes a call through a replica-aware stub to a service that fails, the stub detects the failure and retries the call on another replica.

Consider a shopping cart service call addItem method that adds an item to a shopping cart. Suppose client C invokes this call on a replica on Server S1. After S1 receives the call, but before it successfully returns to C, S1 crashes. At this point the item has been added to the shopping cart, but the replica-aware stub has received an exception. If the stub were to retry the method on Server S2, the item would be added a second time to the shopping cart. Because of this, replica-aware stubs will not, by default, attempt to retry a method that fails after the request is sent but before it returns.

Basic cluster architecture:

The basic recommended cluster architecture combines all Web application tiers and puts the related services (static HTTP, presentation logic, and objects) into one cluster.

The basic architecture has the following advantages:

•Easy administration: Because one cluster hosts static HTTP pages, servlets, and EJBs, you can configure the entire Web application and deploy or undeploy objects using one Administration Console. You do not need to maintain a separate bank of Web servers (and configure Oracle WebLogic Server proxy plug-ins) to benefit from clustered servlets.

•Flexible load balancing: Using load-balancing hardware directly, in front of the Oracle WebLogic Server cluster, enables you to use advanced load-balancing policies for access to both HTML and servlet content.

•Robust security: Putting a firewall in front of your load-balancing hardware enables you to set up a demilitarized zone (DMZ) for your Web application using minimal firewall policies.

•Optimal performance: The combined-tier architecture offers the best performance for applications in which most or all the servlets or JSPs in the presentation tier typically access objects in the object tier, such as EJBs or JDBC objects. 

Advantages:

Easy administration
Flexible load balancing
Robust security

 

Disadvantages:

It cannot load-balance EJB method calls.

                     Load-balancing across the tiers may become unbalanced

Multi Cluster Architecture:

In the architecture illustrated in the slide, two separate Oracle WebLogic Server clusters are configured:

•Cluster A to serve static HTTP content and clustered servlets

•Cluster B to serve clustered EJBs

Multitier architecture is recommended for applications that require:

•Load balancing for method calls to clustered EJBs

•Flexibility for load balancing between servers that provide HTTP content and servers that provide clustered objects

•Higher availability (fewer single points of failure)

•More flexible security

Advantages:

Improved load balancing

Load balancing of EJB methods

Higher availability

Improved security options

Disadvantages:

Can create a bottleneck when the presentation tier makes frequent calls to the business logic

Can lead to increased licensing cost

Can lead to added firewall configuration complexity

Communication In a cluster:

WebLogic Server instances in a cluster communicate with one another using two basic network technologies:

• IP unicast or multicast (one to many), which server instances use to broadcast availability of services and heartbeats that indicate continued availability.
• IP sockets, which are the conduits for peer-to-peer communication between clustered server instances.

Multicast:

Multicast is a simple broadcast technology that enables multiple applications to "subscribe" to a given IP address and port number and listen for messages.

There is no cluster master each server has to ping each other to inform everyone that I am alive.
So MS-1 would send the ping to MS-2 & MS-3 same way MS-2 would send the ping to MS-1 & MS-3 and MS-3 would ping MS-1 & MS-3.
Thus if you see in multicast the congestion in sending the pings are more compared to unicast which makes multicast much heavier, thus WLS recommends using Unicast of less congestion in the network.

note: A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255. The default multicast value used by WebLogic Server is 239.192.0.0

Unicast: 

The WebLogic Server unicast protocol uses standard TCP/IP sockets to send messages between cluster members. Since all networks and network devices support TCP/IP sockets, unicast simplifies out-of-the-box-cluster configuration. It typically requires no additional configuration, regardless of the network topology between cluster members. Additionally, unicast reduces potential network errors that can occur from multicast address conflicts. WebLogic Server uses unicast as its default cluster protocol.

If we have three servers (MS-1,MS-2,MS-3) in a cluster now if they have to communicate with each other they have to ping (i.e. heartbeats ) the cluster master for informing him that he is alive.

If MS-1 is the master then MS-2 and MS-3 would send the ping to MS-1.

Peer-to-Peer Communications

Proper socket configuration is crucial to the performance of an Oracle WebLogic Server cluster. Two factors determine the efficiency of socket communications in Oracle WebLogic Server:

•Whether the server’s host system uses a native or a pure-Java socket reader implementation

•For systems that use pure-Java socket readers, whether or not the server is configured to use enough socket reader threads

IP sockets provide a simple, high-performance mechanism for transferring messages and data between two applications. Clustered Oracle WebLogic Server instances use IP sockets for the following:

•Accessing nonclustered objects that are deployed to another clustered server instance on a different machine

•Replicating HTTP session states and stateful session EJB states between a primary and secondary server instance