From bcc5c5c5bd0cb80ef4054bf116ca3e97c417f74f Mon Sep 17 00:00:00 2001 From: fhanik Date: Mon, 16 Oct 2006 19:56:30 +0000 Subject: [PATCH] more updates, restructure a little bit git-svn-id: https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk@464645 13f79535-47bb-0310-9956-ffa450edef68 --- webapps/docs/cluster-howto.xml | 253 ++++++++++++++++++++--------------------- 1 file changed, 124 insertions(+), 129 deletions(-) diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml index a59192117..fb40a0438 100644 --- a/webapps/docs/cluster-howto.xml +++ b/webapps/docs/cluster-howto.xml @@ -92,7 +92,8 @@ should be completed:

attribute is unique for each instance.
  • Make sure your web.xml has the <distributable/> element or set at your <Context distributable="true" />
    • -
  • Make sure that jvmRoute attribute is set at your Engine <Engine name="Catalina" jvmRoute="node01" >
    • +
  • 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.
    • @@ -143,6 +144,128 @@ should be completed:

    +
    +

    Membership is established using multicast heartbeats. + Hence, if you wish to subdivide your clusters, you can do this by + changing the multicast IP address or port in the <Membership> element. +

    +

    + The heartbeat contains the IP address of the Tomcat node and the TCP port that + Tomcat listens to for replication traffic. All data communication happens over TCP. +

    +

    + The ReplicationValve is used to find out when the request has been completed and initiate the + replication, if any. Data is only replicated if the session has changed (by calling setAttribute or removeAttribute + on the session). +

    +

    + One of the most important performance considerations is the synchronous versus asynchronous replication. + In a synchronous replication mode the request doesn't return until the replicated session has been + sent over the wire and reinstantiated on all the other cluster nodes. + Synchronous vs asynchronous is configured using the channelSendOptions + flag and is an integer value. The default value for the SimpleTcpCluster/DeltaManager combo is + 8, which is asynchronous. You can read more on the send flag. + During async replication, the request is returned before the data has been replicated. async replication yields shorter + request times, and synchronous replication guarantees the session to be replicated before the request returns. +

    + + +
    +

    + As you configure more then two nodes at same cluster for backup, most loadbalancer + send don't all your requests after failover to the same node. +

    +

    + The JvmRouteBinderValve handle tomcat jvmRoute takeover using mod_jk module after node + failure. After a node crashed the next request going to other cluster node. The JvmRouteBinderValve + now detect the takeover and rewrite the jsessionid + information to the backup cluster node. After the next response all client + request goes direct to the backup node. The change sessionid send also to all + other cluster nodes. Well, now the session stickyness work directly to the + backup node, but traffic don't go back too restarted cluster nodes!
    + As jsessionid was created by cookie, the change JSESSIONID cookie resend with next response. +

    +

    + You must add JvmRouteBinderValve and the corresponding cluster message listener JvmRouteSessionIDBinderListener. + As you add the new listener you must also add the default ClusterSessionListener that receiver the normal cluster messages. + + +<Cluster className="org.apache.catalina.tcp.SimpleTcpCluster" > +... + <Valve className="org.apache.catalina.cluster.session.JvmRouteBinderValve" + enabled="true" sessionIdAttribute="takeoverSessionid"/> + <ClusterListener className="org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener" /> + <ClusterListener className="org.apache.catalina.cluster.session.ClusterSessionListener" /> +... +<Cluster> + +

    +

    + Hint:
    + With attribute sessionIdAttribute you can change the request attribute name that included the old session id. + Default attribuite name is org.apache.catalina.cluster.session.JvmRouteOrignalSessionID. +

    +

    + Trick:
    + You can enable this mod_jk turnover mode via JMX before you drop a node to all backup nodes! + Set enable true on all JvmRouteBinderValve backups, disable worker at mod_jk + and then drop node and restart it! Then enable mod_jk Worker and disable JvmRouteBinderValves again. + This use case means that only requested session are migrated. +

    + +
    + +
    + +
    + +

    Component Levels: + + Server + | + Service + | + Engine + | \ + | --- Cluster --* + | + Host + | + ------ + / \ + Cluster Context(1-N) + | \ + | -- Manager + | \ + | -- DeltaManager + | + --------------------------- + | \ + Channel \ + ----------------------------- \ + | | | \ + Receiver Sender Membership \ + -- Valve + | \ + | -- ReplicationValve + | -- JvmRouteBinderValve + | + -- LifecycleListener + | + -- ClusterListener + | \ + | -- ClusterSessionListener + | -- JvmRouteSessionIDBinderListener + | + -- Deployer + \ + -- FarmWarDeployer + + + +

    + +

    To make it easy to understand how clustering works, We are gonna take you through a series of scenarios. In the scenario we only plan to use two tomcat instances TomcatA and TomcatB. @@ -275,137 +398,9 @@ should be completed:

    -
    - -

    Component Levels: - - Server - | - Service - | - Engine - | \ - | --- Cluster --* - | - Host - | - ------ - / \ - Cluster Context(1-N) - | \ - | -- Manager - | \ - | -- DeltaManager - | - --------------------------- - | \ - Channel \ - ----------------------------- \ - | | | \ - Receiver Sender Membership \ - -- Valve - | \ - | -- ReplicationValve - | -- JvmRouteBinderValve - | - -- LifecycleListener - | - -- ClusterListener - | \ - | -- ClusterSessionListener - | -- JvmRouteSessionIDBinderListener - | - -- Deployer - \ - -- FarmWarDeployer - - - -

    - -
    - -
    -

    The cluster configuration is described in the sample server.xml file. -What is worth to mention is that the attributes starting with mcastXXX -are for the membership multicast ping, and the attributes starting with tcpXXX -are for the actual TCP replication. -

    -

    - The membership is established by all the tomcat instances are sending broadcast messages - on the same multicast IP and port. - The TCP listen port, is the port where the session replication is received from other members. -

    -

    - The replication valve is used to find out when the request has been completed and initiate the - replication. -

    -

    - One of the most important performance considerations is the synchronous versus asynchronous replication - mode. In a synchronous replication mode the request doesn't return until the replicated session has been - sent over the wire and reinstantiated on all the other cluster nodes. - There are two settings for synchronous replication. Pooled or not pooled. - Not pooled (ie replicationMode="fastasnycqueue" or "synchronous") means that all the replication request are sent over a single - socket. - Using synchronous mode can potentially becomes a bottleneck when a lot of messages generated, - You can overcome this bottleneck by setting replicationMode="pooled" but then you worker threads blocks with replication . - What is recommended here is to increase the number of threads that handle - incoming replication request. This is the tcpThreadCount property in the cluster - section of server.xml. The pooled setting means that we are using multiple sockets, hence increases the performance. - Asynchronous replication, should be used if you have sticky sessions until fail over, then - your replicated data is not time crucial, but the request time is, at this time leave the tcpThreadCount to - be number-of-nodes-1. - During async replication, the request is returned before the data has been replicated. async replication yields shorter - request times, and synchronous replication guarantees the session to be replicated before the request returns. -

    -
    -

    -As you configure more then two nodes at same cluster for backup, most loadbalancer -send don't all your requests after failover to the same node. -

    -

    -The JvmRouteBinderValve handle tomcat jvmRoute takeover using mod_jk module after node -failure. After a node crashed the next request going to other cluster node. The JvmRouteBinderValve -now detect the takeover and rewrite the jsessionid -information to the backup cluster node. After the next response all client -request goes direct to the backup node. The change sessionid send also to all -other cluster nodes. Well, now the session stickyness work directly to the -backup node, but traffic don't go back too restarted cluster nodes!
    -As jsessionid was created by cookie, the change JSESSIONID cookie resend with next response. -

    -

    -You must add JvmRouteBinderValve and the corresponding cluster message listener JvmRouteSessionIDBinderListener. -As you add the new listener you must also add the default ClusterSessionListener that receiver the normal cluster messages. - -<Cluster className="org.apache.catalina.tcp.SimpleTcpCluster" > -... - <Valve className="org.apache.catalina.cluster.session.JvmRouteBinderValve" - enabled="true" sessionIdAttribute="takeoverSessionid"/> - <ClusterListener className="org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener" /> - <ClusterListener className="org.apache.catalina.cluster.session.ClusterSessionListener" /> -... -<Cluster> - -

    -

    -Hint:
    -With attribute sessionIdAttribute you can change the request attribute name that included the old session id. -Default attribuite name is org.apache.catalina.cluster.session.JvmRouteOrignalSessionID. -

    -

    -Trick:
    -You can enable this mod_jk turnover mode via JMX before you drop a node to all backup nodes! -Set enable true on all JvmRouteBinderValve backups, disable worker at mod_jk -and then drop node and restart it! Then enable mod_jk Worker and disable JvmRouteBinderValves again. -This use case means that only requested session are migrated. -

    - -
    - -
    -- 2.11.0