群集配置在样品server.xml 文件里有描述。需要指出的是以mcastXXX开头的是关于会员成分multicast ping的属性,以tcpXXX开头的是关于TCP replication的属性。
会员成分是通过在相同的multicast IP 和 port上的所有tomcat实例建立的。TCP listen port是从其他会员那里来的会话复制在这它里被接收到的端口。
复制阀被用来发现请求什么时候被完成,并启动复制。
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"
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.
| | | | <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.
|
|