How to Implement cluster/session replication-doc (cluster-howto.html) __html

Source Document Link: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

Translation Date: March 19, 2014

Translation staff: Anchor

feel : Tomcat has a lot of problems with this cluster, so if you need to do a distributed cluster, it's best to use a stateless application, plus a caching system. If the old system is reformed, then perhaps can refer to.

Translated as follows:

Apache Tomcat 6.0 how to Realize cluster/session replication

Important Tips

You can also consult the cluster configuration reference documentation.

Content List

Quick Settings Cluster Foundation Overview Cluster Information bind session to failover node after crash Configuration Example Cluster Architecture operating mechanism FAQ

Quick Settings

Clustering can be supported as long as the following code is added to the <Engine> node or <Host> node: <cluster classname= "Org.apache.catalina.ha.tcp.SimpleTcpCluster"/> The configuration above will turn on All-to-all session replication, and the session increment is replicated through  DeltaManager . Using All-to-all means session will be replicated to all other nodes in this cluster. This is true for small clusters, but we do not recommend using them in larger clusters (there are many Tomcat nodes: for example, dozens of nodes and above ...). Also, when using Delta Delta Manager, the session is replicated to all nodes even if some of the nodes do not have an application deployed. &NBSP To perform session replication on a larger cluster, you need to use Backupmanager. This manager replicates only Session data to a backup node and replicate only to those nodes where the corresponding application is deployed. Backupmanager disadvantage: After testing, performance is not as good as Delta manager.  Below are some important defaults:   1. The default multicast (multicast) address is: 228.0.0.4  2. The default multicast (multicast) port is: 45564 (after the port number and address combination determines the cluster relationship and is considered to be the same cluster). &NBSP 3. ip  of the default broadcast Java.net.InetAddress.getLocalHost (). Gethostaddress ()   (make sure you are not broadcasting to 127.0.0.1, which is a common error)   4. The default listener for replication messages The TCP port is the first available server socket in the  4000-4100  scope. &NBSP 5. Configured with two listeners: clustersessionlistener  and  jvmroutesessionidbinderlistener  6. Configured with two interceptors: tcpfailuredetector  and  messagedispatch15interceptor  The following is a complete list of default cluster configuration information ( The effect is the same as configuring only one line above:   <cluster classname= "Org.apache.catalina.ha.tcp.SimpleTcpCluster" channelsendoptions= "8" > <manager classname= "Org.apache.catalina.ha.session.DeltaManager" expiresessionsonshutdown= " False "notifylistenersonreplication=" true "/> <channel classname=" org.apache.catalina.t Ribes.group.GroupChannel "> <membership classname=" Org.apache.catalina.tribes.membership.McastService " address= "228.0.0.4" port= "45564" frequency= "500" Droptime= "3000"/> <receiver classname= "Org.apache.catalina.tribes.transport.nio.Nio" Receiver "address=" Auto "port=" 4000 "autobind=" 100 " selectortimeout= "5000" maxthreads= "6"/> <sender classname= "org. apache.catalina.tribes.tRansport. Replicationtransmitter "> <transport classname=" org.apache.catalina.tribes.transport.nio.PooledParallel Sender "/> </Sender> <interceptor classname=" org.apache.catalina.tribes.group.intercept Ors. Tcpfailuredetector "/> <interceptor classname=" Org.apache.catalina.tribes.group.interceptors.MessageDispa Tch15interceptor "/> </Channel> <valve classname=" Org.apache.catalina.ha.tcp.ReplicationVa Lve "filter=" "/> <valve classname=" Org.apache.catalina.ha.session.JvmRouteBinderValve "/&G" T <deployer classname= "Org.apache.catalina.ha.deploy.FarmWarDeployer" tempdir= "/tmp/war-temp/" Deploydir= "/tmp/war-deploy/" watchdir= "/tmp/war-listen/" watchenable D= "false"/> <clusterlistener classname= "Org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/> <clusterlistener classname=" Org.apache.catalina.ha.session.ClusterSessionListener "/> </c Luster> The information in this section will be covered in more detail later in this article.

Cluster Foundation

To perform session replication in the Tomcat 6.0 container, you need to complete the following steps: All objects stored in the session attributes must implement the Java.io.Serializable interface to Server.xml Cluste R element Uncomment (or add this element) If you are have defined custom cluster valves, make sure your have the replicationvalve defined as well under The Cluster element in Server.xml If multiple Tomcat instances are running on the same machine, make sure that the Tcplistenport property is unique to each instance, and in most cases Tomcat resolves the problem itself (if you don't specify ), by automatically detecting the available port number in the range 4000-4100. Make sure to web-app the root node in the project's Web.xml file with the <distributable/> element if you use MOD_JK, make sure Jvmroute properties < Engine name= are set on the Engine node Catalina "jvmroute=" node01 ">, and Jvmroute attribute values to the worker name in workers.properties ensure that all nodes have the same time and are synchronized using NTP service! Ensure that the LoadBalancer load balancer is configured with sticky session mode. Load Balancing can be implemented in a variety of ways, referring to the load balancing documentation. Note: Remember that in Java the session state is tracked through a cookie, so the URL that the client sees must be consistent (Host,port), or a new one will be created. Note: JDK version number 1.5 or higher is currently required to support clustering. The Cluster module uses the Tomcat Juli log framework, so you can configure it with a regular logging.properties file. To print log trace information, you can enable logging by Key:org.apache.catalina.tribes.MESSAGES.

Overview

To enable session replication in Tomcat, the following 3 different approaches can achieve the same goal: Use session persistence and save session to a shared file system (PersistenceManager + filestore) using SE Ssion is persisted and the session is saved to a shared database (PersistenceManager + jdbcstore) using memory Replication (in-memory-replication), shipped with Tomcat 6 simpletcp Cluster (Lib/catalina-tribes.jar + Lib/catalina-ha.jar) In this version of Session replication, Tomcat can use Deltamanager for All-to-all session replication, or it can replicate session backups to a single node through Backupmanager. All-to-all replication algorithms are efficient only in clusters that are very small. For larger clusters, you can use primary standby session replication (Primary-secondary sessions replication) to replicate session information to backup nodes simply by configuring Backupmanager. Now you can use the Domain worker attribute (required mod_jk > 1.2.8) to build a scalable cluster solution for the cluster partition by Deltamanager (Configure the Domain name Interceptor [domain Interceptor]). To reduce the amount of network traffic that replication consumes in a all-to-all environment, you can cut the cluster into smaller groups. This can be easily achieved by using different multicast addresses for different groups (multicast addresses). A very simple cluster configuration looks like this: DNS Polling | Load balancer / \ Cluster1 Cluster2 / \ / \ Tomcat1 Tomcat2 TOMCAT3 Tomcat4 It is necessary to solemnly point out that session replication is only the beginning of clustering. Another popular concept for implementing a cluster is farming, for example, if you only need to deploy the app to a single server, the cluster will automatically distribute the deployment to the entire cluster. This is all the functionality that can be used with Farmwardeployer (see the cluster example in Server.xml ) The next section will delve into the workings of session replication and how to configure it.

Cluster information

Cluster relationships are created by broadcasting a heartbeat packet. Therefore, if you want to subdivide a cluster, you can do so by changing the multicast IP address or the port number in the <Membership> element. The heartbeat includes the IP address of the Tomcat node and the TCP port number of Tomcat listening for replication traffic. All data interchange is used in the TCP protocol. The parameter replicationvalve is used to determine when the request completes, when the replication is initialized, and if the session changes (by calling the session's SetAttribute or RemoveAttribute method) to replicate that part of the data. One of the most important considerations is the performance comparison of synchronous and asynchronous replication. In synchronous replication mode, requests do not return immediately, and the session that waits for replication is sent to all other nodes in the cluster, and the processing is completed before it is returned. Synchronous (synchronous) vs. asynchronous (asynchronous) is configured by the Channelsendoptions flag and is of type Integer. The default value for Simpletcpcluster/deltamanager is 8, which is asynchronous (asynchronous). Please refer to send flag (overview) or send flag (Javadoc) for more information. During asynchronous replication, the client request is returned before the data is replicated. Asynchronous replication has a shorter response time, while synchronous replication ensures that session information is replicated before the request returns.

Bind session to failover node after crash

If you use MOD_JK but do not use sticky sessions or for some reason sticky session is not effective, or simply failover, the session ID needs to be modified because it contains the original Tomcat worker ID (defined by Jvmroute in the engine element). To solve this problem, you will use the jvmroutebindervalve. The Jvmroutebindervalve overrides the session ID to ensure that the next request is still sticky after a failover (and will not be rolled back to another random node because the worker is not available). The valve (valve) will rewrite the Jsessionid value in the cookie, of course, using the same name. If the valve is not set correctly, it will make the MOD_JK module difficult to maintain the session adhesion after the failure. If you do not configure a valve (valves), the default jvmroutebindervalve is added, and a clustered message listener named Jvmroutesessionidbinderlistener (listener) is added. To perform the rewrite session ID to other nodes in the cluster when a failover occurs. Remember, if you add custom valves and listeners to the Server.xml, the default settings are no longer in effect, make sure you add all the valves and listeners that are compatible with the default settings. Tip: Property Sessionidattribute allows you to change the name of a request property that includes the old session ID. The default property name is Org.apache.catalina.cluster.session.JvmRouteOrignalSessionID. Tips: You can also enable MOD_JK transfer mode to all backup nodes through JMX before deleting a node! On the backup node, set the Enable to true on all Jvmroutebindervalve backup nodes, disable MOD_JK worker, and then delete the node and reboot! Then enable MOD_JK worker again and disable jvmroutebindervalves. This usage means that only the request session is migrated.

Configuration Example

<cluster classname= "Org.apache.catalina.ha.tcp.SimpleTcpCluster" channelsendoptions= "6" > <manager classname= "Org.apache.catalina.ha.session.BackupManager" expiresessionsonshutdown= "False" notifylistenersonreplication= "true" mapsendoptions= "6"/> <!- -<manager classname= "Org.apache.catalina.ha.session.DeltaManager" Expiresessionsonshutdow N= "false" notifylistenersonreplication= "true"/>--> <channel class Name= "Org.apache.catalina.tribes.group.GroupChannel" > <membership classname= "Org.apache.catalina.tribes. Membership. Mcastservice "address=" 228.0.0.4 "port=" 45564 "Fre" quency= "droptime=" 3000 "/> <receiver classname=" org.apache.catalina.tribes.t Ransport.nio.Nioreceiver "address=" "Auto" port= "5000" selectortimeout= "maxthreads=" 6 "/> <sender classname=" org.apache.catalina.tribes.transport.Re Plicationtransmitter "> <transport classname=" org.apache.catalina.tribes.transport.nio.PooledParallelSe NDEr "/> </Sender> <interceptor classname=" Org.apache.catalina.tribes.group.interceptor S.tcpfailuredetector "/> <interceptor classname=" Org.apache.catalina.tribes.group.interceptors.MessageDis Patch15interceptor "/> <interceptor classname=" org.apache.catalina.tribes.group.interceptors.ThroughputIn Terceptor "/> </Channel> <valve classname=" Org.apache.catalina.ha.tcp.ReplicationValve " Filter= ". *\.gif; *\.js;. *\.jpg;. *\.png;. *\.htm;. *\.html;. *\.css;. *\.txt; " /> <deployer classname= "Org.apache.cataliNa.ha.deploy.FarmWarDeployer "tempdir="/tmp/war-temp/"deploydir="/tmp/war-deploy/ "Watchdir="/tmp/war-listen/"watchenabled=" false/> <clusterlist Ener classname= "Org.apache.catalina.ha.session.ClusterSessionListener"/> </Cluster> We have an item to interpret!! <cluster classname= "Org.apache.catalina.ha.tcp.SimpleTcpCluster" channelsendoptions= "6" > Cluster is the primary element, and all cluster-related detailed configurations are contained within the element. Each message sent by the Simpletcpcluster class, or by calling the Simpletcpcluster.send method, is appended with a flag such as channelsendoptions. A detailed description of the send flags can be referred to Tomcat official Javadoc. Deltamanager calls the Simpletcpcluster.send method to send the message, while backup Manager sends it by itself directly through the channel. To learn more, visit the cluster configuration reference documentation <