As user grows, performance of tomcat and web-server decreases. Tomcat is worked fine with few user and open application very fast. This means, if we want to increase the performance of web application, need to increase number of tomcat servers.
- Load balancing(high traffic, share load)
- High performance(always)
- Fail over or high availability(one down another work)
Load balancing is technique to distribute load to different servers. Traffic is redirect to other servers when it comes to main entry server. When one user A request to server, load balancer send this user to first TomcatA server for processing, Next user B request, load balancer send this request to TomcatB server, user’s C request will be sent to TomcatC server, and so on. Load balancer is work as single server and all request first come to this server and this load balancer distribute all request to other servers.
Load balancers are available in two types:-
- Software
- Hardware device.
Software load balancer is easy to configure, and easy to use. Software load balancers are
- Round Robin
- Weight base
- Random (Pick anyone)
- Redirect
Round Robin
Round Robin algorithm is work in circular loop. First request come to load balancer, redirect to TomcatA Server, Second request come to load balancer, send to TomcatB, Third request come to Load balancer, send to TomcatC and again forth come to TomcatA. All three tomcat server have different IP address. These requests go to next tomcat server which server has the turn. Round Robin DNS is easy to implement and easier to use. Round Robin DNS has one disadvantage, if any one server failed between the cluster, it will be continuously sending request to that failed server, until not remove from the DNS server
Weight-Based Load Balancing
Sometimes all servers’ CPU has not same processing power. Weight-Based load balancing is worked fine with this condition. Weight-based load balancing is improved version of Round Robin load balancing. Weight-based load balancing works with number of load define by you for particular server. This numeric figure represents weight. Weight is pre-defined for particular server; if numeric weight 50 is assign TomcatA. TomcatB and TomcatC are assigning 100. TomcatA will take 50 times less then requests to TomcatB and TomcatC.
Random Load Balancing
Random load Balancing does not care of server’s CPU processing power. Random Load balancing redirects request to any server machine. If TomcatA is less processing power CPU, Random Load Balancer gives more and more request to this server. And more powerful CPU processor may not get more request, it depends on the random request.
This is disadvantage of Random Load balancer that anyone can be overloaded or anyone may be fewer requests.
Specific Load Balancing
This load balancing is fully customized or self programmed. This means request will be redirected to specify server which defined for redirect.
Hardware Load Balancer
Hardware load balancer is much superior to software load balancer. Performance comes much better than software load balancer. Today in market, many hardware load balancer is available, which gives you faster and good performance, Hardware load balancer is difficult to configure. It needs technical person to configure and needs little change in network. Problem is with maintenance of Session and cookies. Hardware Load balancer is also network Load Balancer and use NAT network address translation
Failover is technique to keep the servers up and always available for users. This can be achieved by putting more than two servers in cluster. One server fail, Load will be taken by another adjacent server, without interrupting the work. User will not know that server is break down. Failover clustering implementation can see more with examples
Tomcat clustering handle two type of session maintenance.
- Sticky session
- Session Replication
Sticky session
Sticky session is work on individual session. No session is shared with other tomcat servers. Server generated the session will keep that information of session, else no one know about that information. This can be done by Load balancer and mod_jk connectors.
This method has advantages and also disadvantages.
No network or communication take place among the servers, therefore Load is less and speed is high. This results in better performance in clustering. It is easy to implement and easy to use. It is not allow failover, because no session is sharing among the tomcat servers. So no one knows others session in cluster. If any tomcat cluster server crushed then user’s all information will be lost. User has to re login again application to store data to database.
Session Replication
Sticky session is easy to implement and easy to use, but it doesn’t support for failover. If one server is crushed then users have no choice to re –login again. Session Replication is improved methodology over sticky session. Session replication is process of sharing session to other tomcat servers in clusters, and new copy is generated. All nodes know the session in cluster. This is done by sharing session in cluster. If one node creates session, this session is send to all nodes in cluster. All nodes get that session through TCP/IP or any session sharing methods. If any server is crushed in cluster, users don’t need to re-login again to server. Crushed server is removed from the cluster, and work load is shared among other working servers. All tomcat servers have separate copy of session in cluster, so session doesn’t get expired.
These are four types of session sharing in clustering.
- No session shared
- Single file or Single server for persistent session sharing
- JDBC RDBMS persistent session sharing
- In-memory session Sharing
No session sharing clustering
When using simple load balancing algorithms. Apache or any DNS server redirect incoming request to any tomcat’s server. All requests create new session every time. Tomcat servers don’t communicate with each others and don’t know to other session. It is easy to use and easy to implement.
This cannot handle failover and provide high availability. If one server gets crashed others cannot take his session, because there is no communication among them. All work is done by mod_jk2 or mod_jk apache connector with lb property (load balancing).In this case, no session is sharing.
File persistent session sharing
Tomcat shipped now with persistent session component org.apache.catalina.session.PersistentManager. File shared persistent session use the class org.apache.catalina.session.FileStore in catalina.jar reside in C:\tomcat\server\lib. This is implemented by the persistence session manager. Persistence uses for swapping session between storage. Persistence session is used for uninterrupted flow of session when tomcat servers crashed or restart properly
In file session sharing, all sessions stored in a common file or storage. When new session is created, that goes to this storage and saved. All tomcat servers communicate to this file or storage, through file system of an operating system. If one tomcat creates session, all servers can view that session and know to each others. It works immediately.
Disadvantage
It is not full flag solution of failover
JDBC persistent session sharing in clustering
JDBC session sharing method is improved version of file shared session. JDBC session sharing uses RDBMS for storing the session. JDBC persistent session uses class org.apache.catalina.session.JDBCStore in Catalina.jar reside in C:\tomcat\server\lib. It is almost same as file shared session expect that storage medium. All session is stored in database and retrieved by the tomcat servers, if failover occurs. But it also not full flag solution of failover.
This session replication is different from persistent session sharing. It doesn’t save or store any kind of session in physical device. Session is replicated in memory rather than in storing. All session information sends to other tomcat server through communication channels. This is bunch of tomcat servers which make a cluster or group. All nodes have the same information of session, therefore all session work in JVM and use different JVM identification or different JVM route. This in-memory session replication is more advantageous than other method of session sharing. In-memory session replication fully supports failover. And keeps all session of servers until all are not shutdown.
All tomcat nodes have membership and have to register themselves. It is like attendance in office where each and every employee has to sign-in in sign-in register. This registration tells daily information about their employees. All know their presence in office through sign-in entry. Others node of Tomcat, know the nodes presence by registration. If any node crushed other nodes unregistered their presence in cluster or group.
Session replication provides fully failover feature, and no session loss in failover. User will work continuously in environment without any interruption.
This comes with little limitation. Traffic on network will increase by using In-memory session replication. In particular time of interval, tomcat broadcast message to all tomcat nodes for checking presence in network through TCP/IP. This is little difficult to configure and to use than other previous methods.
Download pre build load balancing, tomcat clustering code.
|
HTML TagsNew