Jelastic PaaS was specially designed for huge clustered application hosting. As we already demonstrated in our previous posts, Jelastic provides session replication between pairs of server nodes with a the help of multicast and load balancer, which redirects requests to each server. Such an approach guarantees session exchange between the nodes through the local net and eliminates the need to use additional software or Memcached. As a result, session data is copied between servers providing high reliability, scalability and perfect fail-over capabilities.

Today we will show you how to take a deeper look into clustering technology used in Jelastic by the example of the Tomcat application server.

On the above scheme you can see a Tomcat cluster which consists of two servers and one load balancer, which handles all requests and distributes them to various nodes, according to availability and server load.

In case when one of the servers fails, the users, who were on that node get automatically switched to the other instance of this Tomcat cluster. Thanks to the replication, the other instance already has all the sessions of the failed node, so end-users never notice any change. Also you can create multiple Tomcat clusters in Jelastic, so that in the highly unlikely event of whole cluster failing, users get redirected to another cluster.

To get a highly available Tomcat cluster in Jelastic, all you need is just click the Create environment button, select Tomcat 6 or 7 as the application server you want to use and switch on High Availability for it.

Note: Don’t confuse horizontal scaling and HA mode in Jelastic. In the first case you have multiple servers and the load is distributed evenly between the chosen number of instances with the help of load balancer. Switching on of High Availability mode sets replication between pair or few pairs of servers using multicast membership.

Now let’s dive into the technology to see what happens when you switch on the HA button and how the Tomcat cluster works on Jelastic.

When you click HA a special Tomcat config file is generated for each node by our system, which is called jelastic-ha.xml. Here is an example:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
       channelSendOptions="4">
 
 <Manager className="org.apache.catalina.ha.session.DeltaManager"
       expireSessionsOnShutdown="false"
       notifyListenersOnReplication="true"/>
 
 <Channel className="org.apache.catalina.tribes.group.GroupChannel">
 
  <Membership className="org.apache.catalina.tribes.membership.McastService"
        address="228.0.0.4"
        port="${MagicPort}"
        frequency="500"
        dropTime="3000"/>
 
  <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
        address="${ReceiverIp}"
        port="4000"
        autoBind="100"
        selectorTimeout="5000"
        maxThreads="6"/>
 
  <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
  <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
  </Sender>
 
  <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
  <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
 </Channel>
 
  <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
      filter=""/>
  <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
 
  <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
  <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

Let’s look at the details of this file:

1. Here is the major element, inside which all the other cluster elements are configured.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
        channelSendOptions="4">

The channelSendOptions flag is attached to every message sent by SimpleTcpCluster class or any objects that are calling the SimpleTcpCluster.send method.

2. The DeltaManager uses the SimpleTcpCluster.send method to send information though the channel.

<Manager className="org.apache.catalina.ha.session.DeltaManager"
      expireSessionsOnShutdown="false"
      notifyListenersOnReplication="true"/>

3. The group communication framework used inside Tomcat called  Tribes, is used as the channel element here. It encapsulates everything that has to do with membership, logic and communication.

<Channel className="org.apache.catalina.tribes.group.GroupChannel">

4. Membership is made using multicast. Tomcat cluster separation consists of a multicast address and port number. Communication between nodes is realized over TCP.

<Membership className="org.apache.catalina.tribes.membership.McastService"
     address="228.0.0.4"
     port="${MagicPort}"
     frequency="500"
     dropTime="3000"/>

{MagicPort}is a unique port number for the cluster, which is generatedon the fly from the Java arguments.

5. Tribes’ logic of sending and receiving data includes two components: sender and receiver. The Receiver is responsible for data receiving. There is a thread pool in this element which has a maxThreads andminThreads setting. The address attribute is the host address that will be broadcasted by the membership component to the other nodes.

<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
     address="${ReceiverIp}"
     port="4000"
     autoBind="100"
     selectorTimeout="5000"
     maxThreads="6"/>

6. The Sender component is responsible for sending messages to other nodes. The Sender includes the ReplicationTransmitter, a special shell component, and Transport sub component. Messages can be sent concurrently with the NIO sender and parallel with pool of senders.

<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
 <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>

7. The elements of the Tribes stack interceptors are:

• TcpFailureDetector – verifies crashed members via TCP
• MessageDispatch15Interceptor – dispatches messages to a thread pool to send message asynchronously

<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
 <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>

8. The cluster uses valves to track requests to web applications:

• ReplicationValve finds out when the request has been completed and initiates the replication
• JvmRouteBinderValve is responsible for backing up your data

<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
      filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

9. The SimpleTcpCluster is a sender and receiver of the Channel object, so components are registered as listeners to this cluster.

<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>

As you can see, setting up high availability manually is possible, but is quite involved and needs additional research and knowledge. We automated the configuration for you and now you can set up High Availability for every Java application server that we support. From every one here at Jelastic – enjoy!