Tomcat Web Hosting Blog - Java, JSP, EJB, Hibernate

Chapter 17: Clustering Setting Up Multiple Tomcat Instances on One Machine To enable multiple instances of Tomcat 6 to run on the same physical machine, each instance must have at least the following: . Its own configuration directory . Its own tempdirectory . Its own webappsdirectory . Its own temporary workdirectory . Its own logsdirectory . TCP ports (for the AJP Connector) that do not conflict with other instances . Optionally, other private TCP or JDBC resources, depending on the backend session-sharing mechanism being deployed Three batch files, called start1.bat, start2.bat, and start3.bat, are created and placed into the /bindirectory. These batch files set the CATALINA_BASE environment variable and then call the startup.batTomcat startup script. Tomcat 6 checks for the existence of the CATALINA_BASE environment variable and uses it to locate the base directory for startup. Each of the start1.bat, start2.bat, and start3.batfiles sets the CATALINA_BASE variable to a different directory, allowing for variation in configuration. For example, start1.batcontains the following: set CATALINA_BASE=c:clustermachine1 call startup On Linux systems with a Bourne shell, it contains the following: export CATALINA_BASE=/cluster/machine1 sh startup.sh This tells Tomcat 6 to look for configuration information and Web application in the c:cluster machine1 directory. Figure 17-8 shows the directory hierarchy used here in subsequent cluster testing. Note in Figure 17-8 that each machine1, machine2, and machine3 directory houses the configuration files for the respective Tomcat 6 instances to be started. Shutting Down the Tomcat Cluster Similar to the startn.bat files, three stopn.batfiles exist for shutting down the individual server instances. These batch files set the CATALINA_BASE environment variable and then call the shutdown script for the server. For example, following is the content of stop3.bat: set CATALINA_BASE=c:clustermachine3 call shutdown Configuring Minimal Web Applications Only the examples application (the servlet and JSP examples from Tomcat distribution) is loaded for each of the three machine instances. In general, when setting up a cluster, you should try to minimize the

If you looking for unlimited one inclusive web hosting plan please check cheap web hosting website.

Chapter 17: Clustering coat, which the establishment holds on your behalf. The browser client holds the cookie, and returns the cookie each time in a connection to the server. Using the cookie, the server is able to locate the session on which the browser client is working. For browsers that do not support cookies, it is possible to use URL rewrite to achieve a similar effect. In URL rewrite, any URL that is being supplied by the application is decorated with the session ID being used. This enables the Web application to extract the session ID from the incoming URL during runtime. The Role of Cookies and Modern Browsers All popular modern-day browsers (Firefox, Internet Explorer, Opera, Mozilla, and so on) support the use of cookies. Cookies are managed on the browser s host PC, and indexed by the Web site s host name. In addition, all modern-day browsers support multiple concurrent connections to the same server. For example, you can start as many instances of Internet Explorer as you want (subject to machine resource constraints) and have them all connect to the www.wrox.comURL. www.wrox.com/ Each instance you start manages its own client-side session. This is not to be confused with server-side sessions. In essence, when you start multiple instances of a browser pointing to the same server, it appears to the server as if different users are accessing it (each instance manages its own copy of a cookie from the server). In other words, each client-side browser instance will have its own independent, associated server-side session. Note that if a load-balancing mechanism redirects an incoming request to a different host, the cookie supplied will be different (because cookies are indexed by host names) and the session information will not be maintained. Configuring a Tomcat 6 Cluster This section describes the configuration of an actual Tomcat 6 cluster. The cluster consists of three independent Tomcat 6 instances, and makes use of the following: . mod_jk load-balancing frontend . In-memory session replication backend This configuration is similar to the one featured in the AJP Connector load-balancing example presented in Chapter 11 . The main difference is in the use of multiple %CATALINA_BASE%settings ($CATALINA_ BASE on Unix/Linux) for each Tomcat instance, and the cluster naming of the server instances. Ideally, the following configuration experiments should be performed on an actual cluster of physical machines running Tomcat 6 on a network. However, not everyone has access to such extensive hardware. To provide all readers with a hands-on configuration experience, the example utilizes multiple instances of Tomcat 6 running on the same machine. If you do configure multiple machines, make sure that their clocks are synchronized. This can be done by synchronizing the machines clocks with an NTP/Internet time server. Read the manual of your operating system for the specifics.

For high quality java hosting services please check java web hosting website.

Chapter 17: Clustering The second item is the major benefit delivered by the in-memory session replication scheme. The other schemes examined thus far cannot deliver this benefit. However, with the benefit comes substantial cost. Here are the items of concern for this approach: . The traffic on the interconnection (usually a LAN) can quickly become very heavy, especially when you are using DeltaManager, where changes to all sessions are sent to all members of the group. . Sessions are not persistent. This means that this model assumes that the overall system operates continuously (sometimes called 24/7 or nonstop operation). All sessions are lost if the entire cluster is shut down. This is not the case with persistent session management. . Configuration, tuning, and maintenance can be quite complex. The remaining sections in this chapter cover each of the clustering mechanisms in more depth, and provide hands-on configuration with working examples. Working with Tomcat 6 Clustering As discussed earlier, a Tomcat 6 clustering implementation depends on a load-balancing frontend and a session-sharing backend. The load-balancing frontend may implement sticky sessions (using Apache mod_proxyor mod_jk), which ensure that the same clustered Tomcat 6 instance will always handle the same session. Taking a peek under the hood reveals why this is very important in several clustering configurations. Session Management in Tomcat 6 Sessions are created and managed by the Tomcat 6 container during application execution, and are made available to JSP and servlets via the application context. In a single-server instance, Tomcat 6 sessions are objects (which can contain and reference other objects) that are kept on behalf of a client. Because the HTTP protocol is stateless, there is no simple way to maintain application state using the protocol alone. For example, consider a shopping cart application. Each product page accessed by a user comes into the server as a separate and distinct HTTP request. There is no way for the server to match up independent incoming requests that represent an application flow. However, most Web applications need to maintain state information associated with a user (for example, the items in the user s shopping cart). A server-side session is the main mechanism used to maintain state. It works as follows: 1. The server writes a cookie to the user s browser instance. The cookie contains a token to retrieve the server-side session (data structure). 2. The cookie is supplied by the browser instance every time it accesses a page on the site. 3. The server reads the token in the cookie to extract the corresponding session. An analogy to a session is the coat check tag that one may obtain prior to entering a theatre or concert. In this case, the cookie is the tag (smaller and simpler to carry) and the session is the coat (larger, but important data that is kept on the server side). You, the client, hold the tag and return the tag for the

For reliable and cheap web hosting services please check tomcat web hosting website.

Chapter 17: Clustering In-memory replication (SimpleTcpCluster) Tomcat 6 instance In-memory replication (SimpleTcpCluster) Tomcat 6 instance Local area network In-memory replication (SimpleTcpCluster) Tomcat 6 instance Replicated session information Guaranteed messaging (Apache Tribes) Communication groups membership (Apache Tribes) Figure 17-7: Tomcat 6 in-memory session replication In Figure 17-7 , the Tomcat 6 server instances running in the cluster are implemented as a communications group. At the Tomcat instance level, the cluster implementation is an instance of the Simple TcpClusterclass. Depending on your needs, and the replication pattern you want, you can configure SimpleTcpCluster with one of two managers. The two available managers with Tomcat 6 are: . DeltaManager to replicate sessions across all Tomcat instances . BackupManager to replicate sessions from a master to a backup instance (see the master-backup topological discussion earlier in this chapter) Under the hood, SimpleTcpCluster uses Apache Tribes to maintain and communicate with the communications group. Apache Tribes is a reusable API library for implementation of communications groups over TCP networks. Group membership is established and maintained by Apache Tribes. If a server crashes, it is automatically removed from the group. A recovered server is automatically made a member of the group again. Apache Tribes also offer several levels of guaranteed message delivery between group members. This capability is utilized by the SimpleTcpCluster to provide a configurable level of service. Any session-creation and modification activities on Tomcat 6 instances are sent to one or all instances within the communications group (depending on the manager implementation configured). The receiving group member(s) then update its (their) own session image in memory to reflect the change. In this way, sessions and changes are replicated immediately in memory, and between members of the group. The main benefits of this approach are as follows: . Full round-robin load balancing enables an even distribution of requests (subject to prefigured lbfactorload factor on mod_jk). Any server can handle any request. . With full HA support, any server can crash and fail-over with no session loss.

If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.

Chapter 17: Clustering persisted session at fail-over time can be immediately handled by any one of the remaining servers in the cluster. Note that sticky sessions must still be configured in the mod_jkwith this scheme. This means that most of the time, a session will be serviced throughout its lifetime by the same Tomcat instance. The only exception occurs when the original server crashed during the session s lifetime. Sticky sessions also increase the probability that the session will be persisted to the store. This is because the longer the session lingers around, the greater the probability of it being persisted. The advantages of this session-sharing scheme include the following: . Application scalability through round-robin load balancing (new sessions are always created on the next worker in the round-robin queue). . Relatively easy setup and maintenance. The mod_jk lb(load balance) worker will detect crashed servers and reinstate recovered ones. . It provides a measure of HA in most situations because any persisted session is shared and can be handled by another server in the cluster. The disadvantages of this session-sharing scheme include the following: . Some sessions may still be lost during fail-over. . Access traffic on the network supporting the shared file system can be heavy in a highly loaded server cluster. Sticky Sessions with a Persistent Session Manager and a JDBC -Based Store Note in Figure 17-6 that there is no conceptual difference between this session-sharing scheme and the previous one. In fact, they both use the same Persistent Session Manager component. In this case, JDBC is used to persist session information onto an RDBMS. The set of benefits and weaknesses remains identical to the previous scheme. The only additional benefit of going to a JDBC-based scheme is the potential performance improvement on systems persisting a large number of sessions. If the applications running on the cluster are using the same RDBMS as the Persistent Session Manager, however, this slight performance edge may disappear (because of increased contention). In-Memory Session Replication Unlike the other two session-sharing schemes, this session-sharing mechanism is not built on top of a shared persistent storage. With in-memory session replication, session information is maintained in synchronization within the memory, across the clustered server instances. Two replication patterns are supported by Tomcat 6. In the first replication pattern, all sessions are replicated between all server instances. In the second pattern, sessions are replicated between only a server and its backup instance, regardless of how many servers are on the connected network cluster. Because two or more instances share the same session information, these session replication mechanisms have the potential to provide the full benefits associated with clustering. Figure 17-7 illustrates how this is accomplished.

If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.

Chapter 17: Clustering The major disadvantage is the lack of HA features. A crashed server means lost sessions. In situations in which server crashes are rare occurrences, and when session losses during these rare occasions are acceptable, this should be the clustering solution deployed. Sticky Sessions with a Persistence Manager and a Shared File Store Tomcat 6 is packaged with a Persistence Manager component that can be configured into any application context. Chapter 6 covers the configuration of this component. The main purpose of persistence management is to provide continuity to sessions when a server shuts down and is restarted. Because the sessions are persisted to either the disk or an RDBMS (via a File Store or a JDBC Store component), they can have a lifecycle that is longer than the server s. In addition, because sessions can be configured to be swapped out to the store after a specified idle time, the Persistence Manager also provides a form of protection against system crashes. (That is, any persistent session can be recovered when the system restarts after a crash.) Note that the Persistence Manager in Tomcat 6 is designed with no consideration for clustering. It deals only with the lifecycle and session of one single Tomcat instance. However, by sharing the store between multiple Tomcat 6 server instances (via either a shared file system or an RDBMS), a certain level of session sharing can be accomplished. Figure 17-6 illustrates the Persistence Manager with a shared file store. In this case, all the Tomcat server instances use the same directory to store their sessions. This directory is accessible from all the servers via the OS s shared file mechanism (NFS, SMB, and so on). Now, any sessions created by any Tomcat instance will eventually be visible to the other instances. Any modifications made by any instance will also be eventually visible to the other instances. It is important to reiterate the importance of the word eventually here because the Persistent Session Manager does not guarantee exactly when a session will be persisted to the store (either after creation or modification). Until a session (or a change in the session) is persisted to the store, that information is not available to the other instances. Shared file system Persistence Manager and File Store Tomcat 6 instance Persistence Manager and File Store Tomcat 6 instance Persistence Manager and File Store Tomcat 6 instance Persisting and accessing session information Figure 17-6: Tomcat 6 s Persistence Manager with a shared file store At this point, you may be wondering what good a clustering system is that eventually shares its session information. There is actually a very good and pragmatic answer. It is slightly better than the sticky session with no session sharing solution previously discussed. In clustering situations where server crashes happen very infrequently, using this scheme can further minimize the loss of sessions during the moment of system crash and fail-over. This is because any

For high quality java hosting services please check java web hosting website.

Chapter 17: Clustering In Figure 17-5 , incoming request A is routed to tomcat1 because session X is created and maintained on the tomcat1 instance. Meanwhile, request B is routed to tomcat3 because session Y is created and maintained on the tomcat3 instance. Request C has no session, so it is routed to the next server in the round- robin distribution, which is tomcat2. This is a highly functional clustering configuration that is relatively easy to configure, and it can be used to scale a Web application across a cluster of Tomcat 6 servers. The only disadvantage of this configuration is that sessions are Tomcat instance specific. If a Tomcat instance is lost, all its sessions are lost. For example, in Figure 17-5 , if the tomcat1 instance crashes, session X is lost forever. Request A will not be handled by the system, and the user will lose the session (and whatever was being done at the time the failure occurred). However, if there is some way to help the clustered Tomcat instances to share session information, then one of the other Tomcat instances still up and running can take over and service incoming requests with sessions created by the crashed server. Session Sharing As with the load-balancing frontend, you have numerous session-sharing backends from which to choose. Each provides a different level of functionality, as well as implementation complexity. Session sharing is the secret behind most implementations of an application server fail-over mechanism. It ensures transparent transfer of the sessions that were being handled by the crashed server. In the following discussion, we assume that the mod_proxyor mod_jk load balancing frontend is used. These are the most popular production configurations for clustered Tomcat 6 instances. The available session-sharing configuration options include the following: . Sticky sessions with no session sharing . Sticky sessions with a Persistent Session Manager and a shared file store . Sticky sessions with a Persistent Session Manager and a JDBC store to RDBMS . In-memory session replication Sticky Sessions with No Clustered Session Sharing This is the scenario that was tested in Chapter 11 , when mod_jk and an AJP Connector were used to round-robin requests amongst a cluster of Tomcat 6 server instances. In this scenario, the mod_jk lb (load balance) worker ensures that requests destined for the same session are always handled by the same Tomcat worker instance. The session ID is encoded with the route name of the server instance that created it, assisting in the routing of the request. While this setup may sound contrived, it is extremely practical and pragmatic in many production scenarios. The advantages of this simple clustering setup include the following: . Application scalability through round-robin load balancing (new sessions are always created on the next worker in the round-robin queue) . Simplicity in setup and maintenance (the mod_jk lbworker will detect crashed servers and reinstate recovered ones) . No additional configuration or resource overhead (as no session sharing is occurring)

For reliable and cheap web hosting services please check javaweb hosting website.

Chapter 17: Clustering Of course, when the master server has crashed, it is too late to query it for information about what it was doing. In all likelihood, the crashed master server is not in any condition to respond. Therefore, almost all fail-over solutions rely on maintaining and sharing state information between the master and backup servers before any crashes occur. Keeping this information current is the only way to ensure that the backup server can take over from where the master server left off during a fail-over. This state sharing is much tougher to implement than it sounds. State information on a system refers to any changes to the system. On a hardware level, this could mean any memory or register write. Imagine having to let all servers in a cluster know about every register and memory write on the master system! Thankfully, in a Java EE compliant Servlet/JSP container, a well-accepted convention for tracking state information within Web applications is available. It involves the use of server-side sessions. Tomcat 6 s cluster implementation takes advantage of this to provide fail-over capability. Now it s time to see how Tomcat 6 incorporates the load-balancing, master-backup, and fail-over patterns in its clustering implementation to provide scalable HA features for end users. Tomcat 6 Clustering Model This section explores the specific clustering implementation supported by Tomcat 6. Based on the discussion thus far, the implementation can be divided into two layers and various components. Figure 17-4 illustrates this. Incoming requests STATE/SESSIONS SHARING Back-End (many choices of technology) LOAD BALANCING Front-End (many choices of technology) Tomcat Server Instances Figure 17-4: Tomcat 6 clustering-implementation architectural model The two layers that enable clustering are the load-balancing frontend and the state-sharing/synchronization backend. In particular, Tomcat s load-balancing frontend distributes incoming requests to the Tomcat instances, while the backend is concerned with ensuring that shared session data is available to the different instances.

For reliable and cheap web hosting services please check javaweb hosting website.

Chapter 17: Clustering Load Balancing There are many options for implementing the load-balancing frontend. What you should choose depends on your specific application. These alternatives include (but are not restricted to) the following: . Round-robin DNS, whereby a domain name resolution results in a set of IP addresses. . A hardware-based load balancer. . A software-based load balancer. See PLB (Pure Load Balancer), a popular open-source TCP-based load balancer available from http://plb.sunsite.dk/. Another one is mod_backhand , from backhand.org/mod_backhand/. Yet another software-based load balancer is balance , available from inlab.de/balance.html. . Apache mod_proxyor mod_jk as load balancer. A discussion and detailed comparison of all of these options is beyond the scope of this blog. However, the last option is covered in this chapter because it is the most popular and least expensive option with Tomcat 6 deployments. mod_proxy/mod_ jk Load Balancing and Sticky Sessions The mod_proxyor mod_jk load balancer distributes incoming requests in a round-robin manner among the available Tomcat workers, but will also respect a load factor that you can specify. In addition, these load balancers support sticky sessions. Understanding Sticky Sessions When sticky sessions (or session affinity) is enabled on mod_proxyor mod_jk, it ensures that all incoming requests with the same session are routed to the same Tomcat 6 worker. Figure 17-5 illustrates this concept. Request C No existing session AJP tomcat2 AJP tomcat3 AJP tomcat1 Session YSession X Request B Session Y Request A Session X mod_proxy or mod_jk Apache Figure 17-5: mod_jk2 load balancing with session affinity

For high quality java hosting services please check tomcat web hosting website.

Chapter 17: Clustering identically configured in hardware and OS, and they both host the same software. Interconnection exists between the machines (for example, over a LAN). One machine is designated as the master server and processes incoming requests. The rest of the machines are backup servers. The health of the master server is monitored constantly, either by the backup servers or by an independent hardware/software component. Whenever the master server crashes, one of the backup servers is made the master and request processing continues as if no crash has occurred. This action of the backup server taking over operation after a crash of the master is an instance of the fail-over behavioral pattern, covered in the next section. Master-backup combined with fail-over form the basis of most HA implementations. BACKUP Server1 BACKUP Server2 MASTER Server Request processing on MASTER only Local area network Figure 17-2: The master-backup topological pattern Fail-Over Behavioral Pattern Figure 17-3 illustrates the fail-over behavioral pattern. Fail-over occurs when a server crashes in a master- backup system. It refers to the way and means by which the master server is taken over by the former backup server. While in a hardware implementation, this may involve sophisticated switching and communications link isolation; in a software scenario, a state transfer and synchronization mechanism must be in place. New MASTER Server (formerly BACKUP Server1) BACKUP Server2 MASTER Server Request processing fail-over from MASTER to BACKUP Local area network CRASHED! Figure 17-3: The fail-over behavioral pattern In other words, simply having identically configured hardware, OS, and software applications (as in the master-backup pattern) is not enough to guarantee a logically transparent fail-over. The backup server taking over the duties of the master server must know what the master server is up to, and continue from where it left off. This requires the synchronization and sharing of dynamic state information, as shown in Figure 17-3 .

For reliable and cheap web hosting services please check javaweb hosting website.