Author: fhanik
Date: Mon Oct 16 12:56:30 2006
New Revision: 464645
URL: http://svn.apache.org/viewvc?view=rev&rev=464645
Log:
more updates, restructure a little bit
Modified:
tomcat/tc6.0.x/trunk/webapps/docs/cluster-howto.xml
Modified: tomcat/tc6.0.x/trunk/webapps/docs/cluster-howto.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/cluster-howto.xml?view=diff&rev=464645&r1=464644&r2=464645
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/cluster-howto.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/cluster-howto.xml Mon Oct 16 12:56:30 2006
@@ -92,7 +92,8 @@
attribute is unique for each instance.</li>
<li>Make sure your <code>web.xml</code> has the
<code><distributable/></code> element
or set at your <code><Context distributable="true" /></code></li>
-<li>Make sure that jvmRoute attribute is set at your Engine <code><Engine
name="Catalina" jvmRoute="node01" ></code></li>
+<li>If you are using mod_jk, make sure that jvmRoute attribute is set at your
Engine <code><Engine name="Catalina" jvmRoute="node01" ></code>
+ and that the jvmRoute attribute value matches your worker name in
workers.properties</li>
<li>Make sure that all nodes have the same time and sync with NTP service!</li>
<li>Make sure that your loadbalancer is configured for sticky session
mode.</li>
</ul>
@@ -143,6 +144,128 @@
</section>
+<section name="Cluster Information">
+<p>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
<code><Membership></code> element.
+</p>
+<p>
+ 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.
+</p>
+<p>
+ The <code>ReplicationValve</code> 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).
+</p>
+<p>
+ 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
<code>channelSendOptions</code>
+ flag and is an integer value. The default value for the
<code>SimpleTcpCluster/DeltaManager</code> combo is
+ 8, which is asynchronous. You can read more on the <a
href="#pointer-to-Tribes-Channel-Javadoc-here">send flag</a>.
+ 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.
+</p>
+
+
+<section name="Bind session after crash to failover node">
+<p>
+ 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.
+</p>
+<p>
+ 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!<br/>
+ As jsessionid was created by cookie, the change JSESSIONID cookie resend
with next response.
+</p>
+<p>
+ 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.
+
+<source>
+<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>
+</source>
+</p>
+<p>
+ <b>Hint:</b><br/>
+ With attribute <i>sessionIdAttribute</i> you can change the request
attribute name that included the old session id.
+ Default attribuite name is
<i>org.apache.catalina.cluster.session.JvmRouteOrignalSessionID</i>.
+</p>
+<p>
+ <b>Trick:</b><br/>
+ 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.
+</p>
+
+</section>
+
+</section>
+
+<section name="Cluster Architecture">
+
+<p><b>Component Levels:</b>
+<source>
+ Server
+ |
+ Service
+ |
+ Engine
+ | \
+ | --- Cluster --*
+ |
+ Host
+ |
+ ------
+ / \
+ Cluster Context(1-N)
+ | \
+ | -- Manager
+ | \
+ | -- DeltaManager
+ |
+ ---------------------------
+ | \
+ Channel \
+ ----------------------------- \
+ | | | \
+ Receiver Sender Membership \
+ -- Valve
+ | \
+ | -- ReplicationValve
+ | -- JvmRouteBinderValve
+ |
+ -- LifecycleListener
+ |
+ -- ClusterListener
+ | \
+ | -- ClusterSessionListener
+ | -- JvmRouteSessionIDBinderListener
+ |
+ -- Deployer
+ \
+ -- FarmWarDeployer
+
+
+</source>
+</p>
+
+</section>
<section name="How it Works">
<p>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
<code>TomcatA</code> and <code>TomcatB</code>.
@@ -275,137 +398,9 @@
</section>
-<section name="Cluster Architecture">
-
-<p><b>Component Levels:</b>
-<source>
- Server
- |
- Service
- |
- Engine
- | \
- | --- Cluster --*
- |
- Host
- |
- ------
- / \
- Cluster Context(1-N)
- | \
- | -- Manager
- | \
- | -- DeltaManager
- |
- ---------------------------
- | \
- Channel \
- ----------------------------- \
- | | | \
- Receiver Sender Membership \
- -- Valve
- | \
- | -- ReplicationValve
- | -- JvmRouteBinderValve
- |
- -- LifecycleListener
- |
- -- ClusterListener
- | \
- | -- ClusterSessionListener
- | -- JvmRouteSessionIDBinderListener
- |
- -- Deployer
- \
- -- FarmWarDeployer
-
-
-</source>
-</p>
-
-</section>
-
-<section name="Cluster Configuration">
-<p>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.
-</p>
-<p>
- 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.
-</p>
-<p>
- The replication valve is used to find out when the request has been
completed and initiate the
- replication.
-</p>
-<p>
- 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.
-</p>
-<section name="Bind session after crash to failover node">
-<p>
-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.
-</p>
-<p>
-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!<br/>
-As jsessionid was created by cookie, the change JSESSIONID cookie resend with
next response.
-</p>
-<p>
-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.
-<source>
-<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>
-</source>
-</p>
-<p>
-<b>Hint:</b><br/>
-With attribute <i>sessionIdAttribute</i> you can change the request attribute
name that included the old session id.
-Default attribuite name is
<i>org.apache.catalina.cluster.session.JvmRouteOrignalSessionID</i>.
-</p>
-<p>
-<b>Trick:</b><br/>
-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.
-</p>
-
-</section>
-
-</section>
<section name="Monitoring your Cluster with JMX">
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
