Clustering overview

This article describes the available clustering features for the Orion Application Server

Introduction
State replication
HTTP State replication
Application context state replication
EJB State replication
Load distribution
User management
Cluster deployment

1 Introduction

Clustering is the common term for distributing a service over a number of servers in order to increase falt tolerance and to support loads larger than a single server is able to handle. It is often used for large scale and mission critical applications where there can be no downtime. A cluster contains servers who share state at some level, such as HTTP state, EJB state or Application context state. Client access to these Servers is normally managed by load balancers.

Figure 1: The cluster services offered with the Orion Application Server includes load balancing, Application context state replication, HTTP state replication and EJB state replication.

2 State replication

Originally, HTTP was designed as a stateless protocol. Every request had all the info the server needed to perform a certain task. Providing clustering for a stateless system is trivial and only requires that a request can be handled by more than one server that share the same document hierarchy. In today's world however the picture is not as simple. The need for client sessions with data stored on the server about a specific client resulted in the invention of the HTTP cookie. A cookie is a way for a web server to store data in the web browser. This cookie is passed back to the server on later requests. This is often used to associate some data on the server (state) with a specific client. A typical example is that of a webshop shopping cart. The client adds the goods he wishes to purchase to the cart and the server associates the client's cookie with a certain cart stored on the server.

This means that clustering gets somewhat more complex. It is no longer enough that the document hierarchy is shared between the web servers, now the state stored on a server will mean that requests sent to different servers will result in different results. There are two obvious solutions to the problem:

When a client has any state on the server associated with him, make sure that he always get directed to the server which holds his state. If the server can no longer respond, for any reason, let him log in again to a new server.
Replicate all state on a server to at least one other server. Make sure the client gets to a server that holds "his" state. If his original server goes down, he will transparently be redirected to a server that has the backup of his state.

What we see is that option 1 does not provide maybe the most important reason for clustering, fault tolerance. When a server fails the client will have to start over, which might result in him giving up and leaving the site. For this reason, option 2 state replication is often required.

Client interaction often leads to that Server-side data is manipulated in some way. As this is normally managed by the use of EJBs in a J2EE application, there must be a way to replicate EJB state over a cluster.

The same goes for Application state. Earlier developers often chooe to store application state in the Servlet Context. But then the Servlet specification mandated that the Servlet Context is local to the VM and thus not suitable for replication. Instead the applications local JNDI context should be used for managing Application state, introducing a need for means to replicate the Applications context state over a cluster.

In order to meet these demands, the Orion Application Server has HTTP state replication services, EJB state replication services and Application Context replication services, as well as a load balancer service. Each of these services will be described in their own article, together with the steps needed to set them up.

To simplify Application management in a cluster, the Orion Application Server comes with the tools neccessary to deploy and redeploy an Application to all nodes of a cluster, as described in the Cluster-deployment article.

3 HTTP State replication

HTTP state is managed by replicating http sessions over a cluster.

HTTP state replication is handled by the HTTP-clustering service as described here.

4 Application context state replication

Application state is managed by replicating the Application Context over a cluster.

The Application Context is the writable (and readable) part of the global JNDI Context that the Application has access to. This context is used to store Application wide state.

Applicaton context state replication is handled by the RMI-clustering service as described here.

5 EJB State replication

EJB state is managed by replicating EJB entities and/or distributing EJB sessions over a cluster.

EJB state replication is handled by the EJB-clustering service as described here.

6 Load distribution

Load distribution or load balancing (these terms will be used to mean the same thing in this document) means that some process (front-end) acts as a distributor of HTTP/HTTPS requests and send different requests off to different servers, or backends.

Detailed information about setting up load-distribution can be found here.

7 User management

In order to to make sure that the same Users and Groups are available on all cluster nodes, a UserManager that uses replicable persistance should be used, such as the EJBUserManager.

8 Cluster deployment