In this release of session replication, Tomcat performs an all-to-all
replication of session state.
This is an algorithm that is only efficient when the clusters are
small. For large clusters, the next
release will support a primary-secondary session replication where
the session will only be stored at one
or maybe two backup servers.
Currently you can use the domain worker attribute (mod_jk > 1.2.8)
to build cluster partitions
with the potential of very scaleable cluster solution.
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:
What is important to mention here, is that session replication is
only the beginning of clustering.
Another popular concept used to implement clusters is farming, ie,
you deploy your apps only to one
server, and the cluster will distribute the deployments across the
entire cluster.
This is all capabilities that can go into with the FarmWarDeployer
(s. cluster example at server.xml
)
下一章将深入讨论session复制是怎样实现的，以及怎样配置它。
TomcatA
启动
Tomcat 标准方式启动. 当 Host 对象被创建之后, 一个 cluster 对象与它关联.
当上下文被解析完, 如果 web.xml中有distributable元素，
Tomcat 通过 Cluster class (in this case SimpleTcpCluster
)
为支持复制的上下文创建一个管理器.
因此通过设置web.xml中的distributable来启用集群。
Tomcat 将为上下文创建 DeltaManager
莱取代 StandardManager
.
cluster class 将启动 a membership service (multicast) 和 a
replication service (tcp unicast).
More on the architecture further down in this document.
One of the most important performance considerations is the
synchronous (pooled or not pooled) 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.
The parameter "replicationMode" has four different settings:
"pooled", "synchronous", "asynchronous" and "fastasyncqueue"
The default mode configuration setup a fastasyncqueue
mode
cluster configuration with following
parameters:
Open Membership receiver at 228.0.0.4
and send to
multicast udp port 8012
Send membership every 1 sec and drop member after 30sec.
Open message receiver at default ip interface at first free port
between 8015
and 8019
.
Receiver message with SocketReplicationListener
Configure a ReplicationTransmitter
with fastasyncqueue
sender mode.
Add ClusterSessionListener
and ReplicationValve
.
NOTE
: Use this configuration when you need very quick a test
cluster with
at your developer machine. You can change the default attributes from
cluster sub elements.
Use following cluster attribute prefixes sender.
, receiver.
, service.
, manager.
, valve.
and listener.
.
Example
configure cluster at windows laptop with network
connection and
change receiver port range
WARNING
: When you add you sub elements, there overwrite the
defaults complete.
Example
configure cluster with cluster failover jsessionid
support. In this
case you need also the defaultmode Cluster listener ClusterSessionListener
and ReplicationValve
.
See default mode configuration description as simple host cluster
example before.
Complex Cluster
Configuration
Example
Configure cluster with complete sub elements.
Activate this node
as master farm delopyer. Message receiver is NIO based ReplicationListener
with six parallel
worker threads.
replication mode (synchronous
, pooled
, asynchronous
or fastasyncqueue
)
pooled
processSenderFrequency
Control the sender keepalive status and drop sender socket
connection after timeout is reached.
Check every processSenderFrequency value engine background ticks.
2
compress
compress bytes before sending (consume memory, but reduce
network traffic - GZIP)
false
ackTimeout
acknowledge timeout and only usefull it waitForAck is true
15000 msec
waitForAck
Wait for ack after data send
false
autoConnect
is sender disabled, fork a new socket
false
doTransmitterProcessingStats
create processing time stats
false
Example to get statistic information, wait for ack at every message send
and transfer at compressed mode
Cluster Configuration for ReplicationTransmitter ( pooled
- mode)
List of Attributes
属性
描述
Default value
keepAliveTimeout
active socket keep alive timeout
60000 msec
keepAliveMaxRequestCount
max request over this socket
-1
maxPoolSocketLimit
max pooled sockets (Sender Sockets)
25
resend
resend message after failure, can overwrite at message
false
Example to get a no processing statistic information, wait for ACK,
after 10000 request renew socket, only 10 SockerSender available and
autoconnect before first request is send.
Cluster Configuration for ReplicationTransmitter (
DeltaManager Attribute)
List of Attributes
属性
描述
Default value
expireSessionsOnShutdown
When server stopped, expire all sessions also at backup nodes
(only for testing)
false
maxActiveSessions
Number of active sessions. (Default is no limit)
-1
notifyListenersOnReplication
Notify application session listener to session creation
and expiring events at backup nodes
true
notifySessionListenersOnReplication
Notify application session listener to attribute changes at
backup nodes
true
stateTransferTimeout
Timeout that session state transfer is complete. Is attribute stateTransferTimeout
== -1
then application wait that other node send the complete session
state
60 sec
sendAllSessions
Flag to send sessions as splited blocks
true
sendAllSessionsSize
Number of serialize sessions inside a send block session
message. Only useful when sendAllSessions==false
1000
sendAllSessionsWaitTime
wait time between two session send blocks.
2000 msec
sendClusterDomainOnly
Send all session messages only to member inside same cluster
domain
(value od Membership attribute mcastClusterDomain). Also don't
handle
session messages from other domains.
true
stateTimestampDrop
DeltaManager queued Sessions messages when send GET_ALL_SESSION
to other node.
with stateTimestampDrop all messages before state transfer message
creation date (find session) are dropped.
Only other GET_ALL_SESSION events are handle with date before state
transfer message.
true
Example send all sessions at separate blocks. Serialize and send 100
session inside one block.
Wait maximale two minutes before the complete backup sessions are loaded
inside tomcat boot process.
Between send blocks wait 5 secs to transfers the session block to other
node. This save memory
when you use the async modes with queues.
As Cluster.defaultMode=true
you can configure the manager
attributes with prefix manager.
.
注意
With Cluster.setProperty(<String>,<String>)
you can
modify
attributes for all register managers. The method exists as MBeans
operation.
Bind session
after crash to failover node
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.
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.
通
过 JMX 监控集群
Monitoring is a very important question when you use a cluster. Some
of the cluster objects are JMX MBeans
Add the following parameter to your startup script with Java 5:
QQ群⑧：
窥视卡
雷达卡
发表于 2017-1-13 09:50:59
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡