实现Tomcat 8 Clustering/Session Replication环境

YY-LIN

　　目录
　　1、环境概述
　　2、时间同步
　　3、实现过程
　　4、测试
　　5、讨论及总结
　　1、环境概述
　　测试环境拓扑如下：
　　clients
　　|
　　httpd
　　/       \
　　tomcat1     tomcat2
　　tomcat、httpd的安装已不再重复，但版本在这里说明：
　　httpd服务器（以负载均衡方式工作）
[root@lb conf.d]# cat /etc/issue
CentOS release 6.4 (Final)
Kernel \r on an \m
[root@lb conf.d]# uname -r
2.6.32-358.el6.x86_64
[root@lb conf.d]# ifconfig | grep Bcast:
          inet addr:192.168.0.200  Bcast:192.168.0.255  Mask:255.255.255.0
[root@lb conf.d]# rpm -q httpd
httpd-2.2.15-39.el6.centos.x86_64　　后端tomcat服务器环境，操作系统版本与httpd服务器相同
[root@master ~]# catalina.sh version
Using CATALINA_BASE:   /usr/local/tomcat
Using CATALINA_HOME:   /usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JRE_HOME:        /usr/java/latest
Using CLASSPATH:       /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar
Server version: Apache Tomcat/8.0.21
Server built:   Mar 23 2015 14:11:21 UTC
Server number:  8.0.21.0
OS Name:        Linux
OS Version:     2.6.32-358.el6.x86_64
Architecture:   amd64
JVM Version:    1.8.0_45-b14
JVM Vendor:     Oracle Corporation　　2、时间同步
　　请参照此博文的相关部份配置http://zhaochj.blog.运维网.com/368705/1635982
　　3、实现过程
　　在之前的博文中已实现了apache以mod_jk和mod_proxy两种类型实现对后端tomcat进行负载均衡的部署，但都有一个缺陷，在不启用sticky session时，客户端访问前端apache后被调度到后端的tomcat节点，当访问节点发生改变时此负载均衡系统不能保证用户session信息不变；如果启用sticky session，在一定程度上解决了用户session信息的丢失问题，但是当用户所访问的节点宕机时，用户的session信息依然会丢失，那是否有方法解决这个问题？
　　当然，常用有两种方案，方案一：采用节点间session复制技术，当用户被调度到一tomcat节点时，用户的session信息会被同步到其他节点，一般采用组播的方式传递session信息，只要在同一个组播里的成员都会有一份session复制器，这样不管是哪个tomcat节点宕机，其他节点上也有一份接近（如果session信息变化又没来得及同步就宕机，那其他节点的session就不完整）完整的session信息，对用户来说是透明的；方案二就是单独部署session服务器，利用google的MSM（Memcached Session Manager）项目来实现，这个此博文不讨论，将在后边博文中来呈现。
　　

　　前提：此次环境是在上次博文“apache以mod_proxy实现负载均衡集群”的基础上来实现集群的session复制机制。
　　因tomcat的版本不同，在实现集群session复制时有些细微的区别，所以根据官方文档来配置，我的环境是tomcat是8.0.21的版本，官方文档这里http://tomcat.apache.org/tomcat-8.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node
　　

　　配置tomcat，实现集群的session复制：
[root@tomcat1 ~]# vim /usr/local/tomcat/conf/server.xml
#以下代码加入到Engine容器中

               
               
                        
                        
                        
                                
                        
                        
                        
               
               
               
               
               
        　　

　　注：以上内容定义在Engine容器中，则表示对所有主机均启动用集群功能。如果定义在某Host容器中，则表示仅对此主机启用集群功能。此外，需要注意的是，Receiver中的address="auto"一项的值最好改为当前主机集群服务所对应的网络接口的IP地址。
　　接下来更改web应用程序根目录下“WEB-INF”目录下的web.xml文件，必须添加这个元素，如果web应用程序没有这个目录及文件，则可复制默认站点的web.xml文件。
[root@tomcat1 ~]# vim /tomcat/webapps/test/WEB-INF/web.xml

  Welcome to Tomcat
  
     Welcome to Tomcat
  


#在web-app容器中加入元素即可。　　到此，tomcat1配置完成，在tomcat2上也作上边的这些修改后重新启动tomcat服务，重启后注意观察服务器的监听端口，会有server.xml配置文件中配置的端口出现，如下：
[root@master ~]# netstat -tnlup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name  
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      1100/sshd         
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      1184/master        
tcp        0      0 :::8080                     :::*                        LISTEN      3422/java         
tcp        0      0 :::22                       :::*                        LISTEN      1100/sshd         
tcp        0      0 ::1:25                      :::*                        LISTEN      1184/master        
tcp        0      0 ::ffff:192.168.0.201:4000   :::*                        LISTEN      3422/java         
tcp        0      0 ::ffff:127.0.0.1:8005       :::*                        LISTEN      3422/java         
tcp        0      0 :::8009                     :::*                        LISTEN      3422/java         
udp        0      0 192.168.0.201:123           0.0.0.0:*                               1108/ntpd         
udp        0      0 127.0.0.1:123               0.0.0.0:*                               1108/ntpd         
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               1108/ntpd         
udp        0      0 fe80::20c:29ff:fec6:f77a:123 :::*                                    1108/ntpd         
udp        0      0 ::1:123                     :::*                                    1108/ntpd         
udp        0      0 :::123                      :::*                                    1108/ntpd         
udp        0      0 :::45564                    :::*                                    3422/java　　4、测试
　　打开浏览器访问前端的httpd监听的地址，得到的结果如下图：

http://s3.运维网.com/wyfs02/M01/6C/C9/wKiom1VRzEjQmPz7AAC5Y8TiYTk721.jpg

http://s3.运维网.com/wyfs02/M02/6C/C3/wKioL1VRzeGBkC_pAADCn2Z6Uaw781.jpg

　　看两次访问到的页面，第一次访问到了tomcat1节点上的测试页面，第二访问到了tomcat2上的测试页面，但两次访问的session信息是保持不变的。测试说明两个节点间的session已完成了复制。
　　5、讨论及总结
　　官方建议此Clustering/Session Replication技术只能用在小规模的集群环境中，有网友做过测试，当后端的tomcat节点数大于5个时，整个集群的性能不会再上升。
　　这里还有一个问题值得讨论，在生产环境下实现了session在各节点间的复制，在httpd上的配置中是否要启用session粘性或绑定呢，即使不启用绑定session，mod_proxy或mod_jk会根据配置的调度算法来把客户端的请求分发到后端的tomcat节点上，如果启用session的绑定功能，那客户端在一段时间内会被分发到同一个tomcat节点上，如果是以mod_proxy方式实现负载集群时要记得启用故障转移选项（nofailover=Off），不然，客户端之前问题的tomcat节点发生故障，那客户端将无法实现故障转移，不过这好像是默认选项。
　　在集群session复制的负载均衡环境中是否启用session粘性功能我个人认为需要不断的监控调度节点、后端的tomcat各节点的负载情况来再做调整。


附件：http://down.运维网.com/data/2365674