!C99Shell v. 1.0 pre-release build #13!

Software: Apache. PHP/5.5.15 

uname -a: Windows NT SVR-DMZ 6.1 build 7600 (Windows Server 2008 R2 Enterprise Edition) i586 

SYSTEM 

Safe-mode: OFF (not secure)

E:\nuevo\tomcat\webapps\docs\   drwxrwxrwx
Free 10.09 GB of 239.26 GB (4.22%)
Detected drives: [ a ] [ c ] [ d ] [ e ] [ f ]
Home    Back    Forward    UPDIR    Refresh    Search    Buffer    Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    


Viewing file:     cluster-howto.html (65.43 KB)      -rw-rw-rw-
Select action/file-type:
(+) | (+) | (+) | Code (+) | Session (+) | (+) | SDB (+) | (+) | (+) | (+) | (+) | (+) |
Apache Tomcat 7 (7.0.42) - Clustering/Session Replication HOW-TO

      The Apache Tomcat Servlet/JSP Container
    
Apache Tomcat 7
Version 7.0.42, Jul 2 2013		Apache Logo
Links
User Guide
Reference
Apache Tomcat Development
Clustering/Session Replication HOW-TO
Important Note


You can also check the configuration reference documentation.



Table of Contents



For the impatient

  

    Simply add 
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>

    to your <Engine> or your <Host> element to enable clustering.
  

  

    Using the above configuration will enable all-to-all session replication
    using the DeltaManager to replicate session deltas. By all-to-all we mean that the session gets replicated to all the other
    nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of Tomcat nodes).
    Also when using the delta manager it will replicate to all nodes, even nodes that don't have the application deployed.

    To get around this problem, you'll want to use the BackupManager. This manager only replicates the session data to one backup
    node, and only to nodes that have the application deployed. Downside of the BackupManager: not quite as battle tested as the delta manager.
    

    Here are some of the important default values:

    1. Multicast address is 228.0.0.4

    2. Multicast port is 45564 (the port and the address together determine cluster membership.

    3. The IP broadcasted is java.net.InetAddress.getLocalHost().getHostAddress() (make sure you don't broadcast 127.0.0.1, this is a common error)

    4. The TCP port listening for replication messages is the first available server socket in range 4000-4100

    5. Two listeners are configured ClusterSessionListener and JvmRouteSessionIDBinderListener

    6. Two interceptors are configured TcpFailureDetector and MessageDispatch15Interceptor

    The following is the default cluster configuration:

    
        <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.tribes.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.NioReceiver"
                      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.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"/>

          <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

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

  

  
Will cover this section in more detail later in this document.


Cluster Basics



To run session replication in your Tomcat 7.0 container, the following steps
should be completed:


    
  
  • All your session attributes must implement java.io.Serializable
    • 
  
  • Uncomment the Cluster element in server.xml
    • 
  
  • If you have defined custom cluster valves, make sure you have the ReplicationValve  defined as well under the Cluster element in server.xml
    • 
  
  • If your Tomcat instances are running on the same machine, make sure the tcpListenPort
      attribute is unique for each instance, in most cases Tomcat is smart enough to resolve this on it's own by autodetecting available ports in the range 4000-4100
    • 
  
  • Make sure your web.xml has the
      <distributable/> element
    • 
  
  • If you are using mod_jk, make sure that jvmRoute attribute is set at your Engine <Engine name="Catalina" jvmRoute="node01" >
      and that the jvmRoute attribute value matches your worker name in workers.properties
    • 
  
  • Make sure that all nodes have the same time and sync with NTP service!
    • 
  
  • Make sure that your loadbalancer is configured for sticky session mode.
    • 



Load balancing can be achieved through many techniques, as seen in the
Load Balancing chapter.


Note: Remember that your session state is tracked by a cookie, so your URL must look the same from the out
   side otherwise, a new session will be created.


Note: Clustering support currently requires the JDK version 1.5 or later.


The Cluster module uses the Tomcat JULI logging framework, so you can configure logging
   through the regular logging.properties file. To track messages, you can enable logging on the key:org.apache.catalina.tribes.MESSAGES


Overview



To enable session replication in Tomcat, three different paths can be followed to achieve the exact same thing:


    
  
  1. Using session persistence, and saving the session to a shared file system (PersistenceManager + FileStore)
    2. 
  
  2. Using session persistence, and saving the session to a shared database (PersistenceManager + JDBCStore)
    3. 
  
  3. Using in-memory-replication, using the SimpleTcpCluster that ships with Tomcat (lib/catalina-tribes.jar + lib/catalina-ha.jar)
    4. 




In this release of session replication, Tomcat can perform an all-to-all replication of session state using the DeltaManager or
   perform backup replication to only one node using the BackupManager.
   The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters,  to use
   a primary-secondary session replication where the session will only be stored at one backup server simply setup the BackupManager. 

   Currently you can use the domain worker attribute (mod_jk > 1.2.8) to build cluster partitions
   with the potential of having a more scalable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this).
   In order to keep the network traffic down in an all-to-all environment, you can split your cluster
   into smaller groups. This can be easily achieved by using different multicast addresses for the different groups.
   A very simple setup would look like this: