Understanding WebLogic Clustering

This post is intended to help WebLogic beginners to understand and then set up a cluster.

If you're an advanced user, no need to longer read ! :)

What's a cluster ?

A cluster is an abstract representation of a group of a application servers also known as instances. It mainly allows :

• failover, which provides, in case of crash of an instance, the ability to have a continued quality of service (QoS)
• load-balancing, which, as it names says, allows a strong load to be balanced between the different instances
• session-replication which combined to the failover mechanism, ensures that the user does not lose his/her session when an instance goes down

How does it work ?

From a WLS point of view, it's only a logical component you design and then, you affect the desired services to that cluster.

When I first worked with clustering, I thought I could make an HTTP call directly to the cluster, but it's not the case.

To do so, you will have to contact what's called a frontend.

That frontend is responsible for taking all the incoming requests and then dispatch them to the servers composing the cluster.

Concerning the inside communication, it lies on two mechanisms :

• IP Sockets (communication between two instances, for replication ...)
• IP Unicast or Multicast (used to know whether an instance is up or not ...)

More information

Note that BEA encourages the use of Unicast for a newly created cluster and Multicast when mixing WLS versions.

How to create it ?

Using the console or WLST, it's really easy.

1. Create the cluster ( Environnement > Cluster) by first locking an edit session and click "New".
2. Determine the kind of communication used for Heartbeat (Unicast recommended)
3. Enroll all the managed servers
4. Configure the "Cluster Address" (useful for EJBs, see below) and the frontend host & port (useful for webservices)

You're done !

Choosing your HTTP Frontend

Well, you've got the choice between :

• an HTTP server (Apache, IIS, SunOne ...) + the WebLogic plugin
• a DNS server
• a hardware load-balancer (Alteon, BigIP ...)
• another WLS instance, with the HttpClusteredServlet (available when you create a domain, for instance)

The choice depends on your will and on what your society allows :)

Failover : easy to configure !

The failover mechanism takes place when an instance goes down in a cluster. The users accessing the website should not be aware of that problem.

That's where the frontend plays an important role : it's responsible for routing all the new requests to the other available servers.

How does the frontend know which server is available and which is not ? Well, it depends of the nature of the frontend !

For instance, for an Apache WebServer configured with the WebLogic DSO module,

the initial server list is initially composed of a comma-separated succession of IP addresses and ports like the following :

<IfModule mod_weblogic.c>
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001

[...]
</IfModule>

After the first call, the cluster maintains what's called the DSL or Dynamic Server List, thanks to the heartbeat.

When a server fails to respond to a heartbeat request, it is flagged as "failed" and is automatically removed from the DSL.

This list is supplied for each request to the frontend which uses it to dispatch requests.

For a phyical load-balancer, like an Alteon or BigIP, it performs the heartbeat itself.

If a server fails to answer, then the load-balancer removes this server from the list of potential ready servers.

Session replication

This mechanism is linked to the failover mechanism. When an instance goes down, new users must not only be routed to the fallen instance,

but users who were working on that instance (that is to say who were having an active session) must be able to keep doing what they were doing.

In other words, all the session initiated on that instance continue to live on another server.

The principle is simple, each session started on a server (aka primary server) is replicated on another server (aka secondary server).

The update only takes place at each set() method invocation.

Usually, it is recommended to have a session whose size is not over 40k, mainly for performance reasons.

Taken from the documentation, the format of a session cookie is:

sessionid!primary_server_id!secondary_server_id

where:

• sessionid is a randomly generated identifier of the HTTP session. The length of the
  value is configured by the IDLength parameter in the <session-descriptor> element in
  the weblogic.xml file for an application. By default, the sessionid length is 52 bytes.
  
• primary_server_id and secondary_server_id are 10 character identifiers of the
  primary and secondary hosts for the session.
  

Note: For sessions using non-replicated memory, cookie, JDBC, or file-based session persistence, the secondary_server_id is not present.

For sessions that use in-memory replication, if the secondary session does not exist, the secondary_server_id is “NONE”.

 

For increased performance, BEA strongly recommends to use Native IO versus pure Java socket readers. See my post about muxers to know more.

I strongly encourage you to go there : http://edocs.beasys.com/wls/docs100/cluster/failover.html#wp1039991 to read about "replication groups".

I wanted to make a sum up, but it's really well explained there + you will have pictures to make your understanding quicker.

Load-balancing ? Not harder to configure than failover ...

Well, it depends on what you want to load-balance. Because, according to the components you want to balance, the mechanisms are not the same.

Dealing with servlets, jsp and everything that lies on HTTP for the communication,

you have 4 solutions (see "Choosing your HTTP Frontend) but I'm going to list only the two which are WLS-related :

=> HttpClusterServlet, which is a simple servlet whose role is to provide a route, based on the round-robin algorithm.

It is often created while setting up your domain with the Config Manager. http://edocs.beasys.com/wls/docs100/cluster/setup.html#wp759939

=> a typical HttpServer such as Apache, IIS, SunOne, on which you will have to deploy a WLS plugin.

The configuration is the same than the one required for Failover (see above)

 

For EJBs, the load-balacing is made thanks to the cluster address configuration.

To make it easier to understand, you've got to understand that when you have a reference to an EJB,

it's a stub supplied by WebLogic Server which encapsulates/wraps the "real" EJB stub. The WLS stub is "replica-aware" :

that means that it is aware of all the EJBs deployed on other managed servers.

That's this mechanism which is used to perform load-balancing for EJBs.

 

Taken from the documentation : in WebLogic Server cluster, the cluster address is used in entity and stateless beans to construct the host name portion of request URLs.

You can explicitly define the cluster address when you configure the a cluster; otherwise, WebLogic Server dynamically generates the cluster address for each new request.

Allowing WebLogic Server to dynamically generate the cluster address is simplest, in terms of system administration, and is suitable for both development and production environments.

What about JNDI across the cluster ?

I won't say what's already well explained in the official documentation !

 

http://edocs.bea.com/wls/docs100/cluster/features.html#wp1007508

 

Mots clés Technorati : WebLogic Server,Cluster,Clustering,load-balancing,failover,session replication,replication group