Apache + Tomcat集群 + 负载均衡

Part I:html

取经处: http://www.ramkitech.com/2012/10/tomcat-clustering-series-simple-load.htmljava

     http://blog.csdn.net/bluishglc/article/details/6867358linux

这部分先弄个简单的Load Balance的例子。web

对Apache Server和Tomcat两者之间的关系有必定了解后,应该能够理解下面盗取的结构图:数据库

在实际生产环境中,不会采起单个Tomcat实例的架构,由于没有任何灾备机制。一旦发生自热灾害,硬件损坏或者内存泄漏等严重错误,都会致使所谓的服务器宕机。apache

为了不这种状况的发生,一定采用灾备机制。典型的作法就是在多台server上部署同一个Application,而后各个server之间相互为backup。编程

但这样,随之而来的问题就是如何分布用户请求。不可能告诉用户全部的Tomcat server IP,而后一会访问这个,过一会又访问另一个,太不人性化了!centos

  这就引出了负载均衡(Load Balance)这个概念。全部用户请求都由Apache Server接收,以后根据内部逻辑分发请求给各个Tomcat。浏览器

简单的Load Balance:tomcat

环境:CentOS7,Tomcat8.5.4,Apache httpd-2.4.23,tomcat-connectors-1.2.41

1. 安装Apache Server(略过)

2. 钱不够,只有一台笔记本,遂安装Tomcat并配置多个实例来模拟多个tomcat server(能够参照以前的blog进行配置)

  假设3个tomcat实例命名为tomcat1,tomcat2,tomcat3

3. 安装并编译mod_jk.so(略过),用于以后Apache Server同Tomcat通讯。

4. 以上准备工做完成后,下面就是Load Balance的配置喽。

  1. 经过mod_jk moudle创建Apache Server同Tomcat的通讯

    1. 在${ApacheServerPath}/conf下建立workers.properties,内容以下:

worker.list=loadbalancer,stat

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat1,tomcat2,tomcat3

worker.tomcat1.type=ajp13
worker.tomcat1.port=8009
worker.tomcat1.host=localhost

worker.tomcat2.type=ajp13
worker.tomcat2.port=8019
worker.tomcat2.host=localhost

worker.tomcat3.type=ajp13
worker.tomcat3.port=8029
worker.tomcat3.host=localhost

worker.stat.type=status

    2. 在${ApacheServerPath}/conf/httpd.conf中添加以下内容:

LoadModule jk_module modules/mod_jk.so

JkWorkersFile conf/workers.properties

JkLogFile logs/mod_jk.log
JkLogLevel emerg
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"

JkMount /status stat
JkMount /* loadbalancer

5. 启动Apache Server,各个tomcat实例进行负载均衡测试。

  测试以前先在各个ROOT下建立index.html文件,用来区分哪一个tomcat server被调用。

  1. 请求localhost,看整个服务是否可用;

  2. 请求localhost/status,看Load Balance状况。

 

Part II:

看到一篇稍好的blog,算是补充吧。http://freeloda.blog.51cto.com/2033581/1301888/

接Part I,虽然实现了简单的负载均衡,可是很明显存在问题。不少blog都拿购物车举例,也很通俗易懂:Part I实现的负载均衡基本会将每次的请求均匀转发到tomcat server上。当咱们在购物车中添加了一项,以后再刷新页面发送新的请求,这时的Apache Server将会分发该请求到新的tomcat server,再一次建立新的session,致使购物车以前的添加项所有丢失,严重影响用户体验。

为解决这个问题,能够经过Sticky Session(粘性会话),实际上就是让Apache Server可以识别正确的Tomcat Server。

从Session的简单原理入手,当用户第一次请求时,Apache Server转发到Tomcat Server,相应建立session(位于tomcat server的内存中)。一个Session能够想象成相似Map的容器,能够CRUD各类属性。对应这个session,有一个Session ID(在Tomcat中,又称为jsessionid)。该Session ID将附到HTTP Response中返回客户端,存储于浏览器中。当用户再次发送相似的请求时,会将Session ID封装到HTTP Request中,经Apache Server转发到Tomcat Server。

因此,对Session ID改进,达到Sticky Session的目的。

因为Session ID是Tomcat Server生成的,因此理所应当修改各个Tomcat的配置文件。

1. 修改每一个tomcat实例的server.xml - 在Engine标签中添加jvmRoute属性(和workers.properties中的balance_workers各项相对应)

OK!

2. 测试,启动Apache Server和Tomcat。

在浏览器发出的HTTP Request中,会发现

Cookie:JSESSIONID=40025608F7B50E42DFA2785329079227.tomcat1

实现Sticky Session。

 

Part III:

实现Sticky Session还不足以解决某个Tomcat宕掉的影响。假设某个Tomcat宕掉,那相应的Session所有失效,严重影响用户体验!

这就又引出Session Replication(复制会话)的概念。也就是相同的Session在其余Server中也存在,当Server宕掉,另外一台能够当即被使用。

实现会话复制的方案有很多:

1. 创建Session服务器,全部Session所有存储于该服务器之上。当某个Tomcat Server宕掉后,其余server能够从该Session服务器中复制一份过来。缺点是一旦Session服务器宕掉,全部Session均失效,代价更大。

2. Tomcat集群方案

  1. 采用多播的方式在Tomcat Server之间通讯来复制Session,一个server的session在其余全部server均存在。缺点是若是参与集群的server数量过多,必然会致使单个server的负载太重。因此不适合大集群环境。

  2. 采用Backup机制,好比两台Tomcat之间通讯以保证各自Session在对方有备份。

 

先来尝试多播方式的Tomcat集群:)

一共3个步骤:

  1. enable多播路由;2. 添加Cluster标签到conf/server.xml中;3. 给app添加<distributable/>

这里面的多播是网络通讯里的概念,正在不断了解过程当中。。。区别于单播与广播,和字面意思相一致。对于Tomcat集群来讲,各个之间必然进行通讯,成为一组,多播是首选吧。

既然是会话复制,就应该涉及到session的管理问题。在Tomcat集群中,SessionManager负责session的管理,分如下4种:

  • Standard Manager
  • Persistent Manager
  • Delta Manager
  • Backup Manager

  Standard Manager

  这个是tomcat默认使用的session管理。但针对stand-alone(单机)tomcat,不能用于tomcat集群环境。

  Persistent Manager

  会将session信息按期存储于文件/数据库中,能够配置以何种方式存储。但因为按期存储和更新,可能致使session更新不够及时。

  Delta Manager

  Tomcat集群默认使用的session管理。每当session发生变化,好比setAttribute(), removeAttribute(),都会及时在其余集群节点上更新。这也就很容易形成集群中的tomcat负载太重,因此不适合大规模的集群环境。

  Backup Manager

  这个能够看做是Persistent Manager和Delta Manager的折中。两套Tomcat server互为Backup。

 

--------------NND,先吐槽下,多播方式的Tomcat集群愣是前先后后耗费了2天的时间才搞定!咱国人的博客水准真是亟待提升,仍是参考了老外的博客最终搞定。。。

环境:根据Part II已经实现Sticky Session,但要说明下个人CentOS7是Win7上的虚拟机。

下面记录我在build多播方式的Tomcat集群过程当中的每步以及遇到的问题:

1. 按照官方文档以及该blog,copy其中Cluster标签的默认配置到各个tomcat实例中的server.xml文件中(位于Enginee标签下),并为各个tomcat实例设置不一样的Receiver端口。

  这里须要注意,tomcat-8.5.4关于Cluster的默认配置里已经没有<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>,并且<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>已经变成<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>

2. route add -net 224.0.0.0 netmask 240.0.0.0 dev your_ethernet接口,添加your_ethernet接口到路由表中。

3. 在各个tomcat实例的app中的web.xml中添加标签<distributable/>

OK,启动httpd和3个tomcat实例(都在CentOS虚拟机上)。

按照该blog的测试方法,查看每一个tomcat实例的manager界面,看是否session之间共享。结果不是。。。

在仔细检查各个配置文件并肯定没问题后,开始天马行空的想,漫无目的的搜索,但大部分的信息都是讲怎么一步步配置还有零散的一些问题解决方案。尝试了几个后(好比给Membership标签添加bind属性,绑定本地IP;修改Receiver的address属性值为本地IP)都没解决,心想解决问题真心不能靠运气啊!

可是从哪下手呢?  -  日志

相比较于Windows,在Linux下启tomcat不会有滚动日志显示,不能实时知道tomcat的状态。

总结一下我所遇到的问题:

  1. java.io.IOException: Network is unreachable

    Unable to join multicast group, make sure your system has multicasting enabled

  很明显,提示多播功能可能没有enable。可是个人确作了这步的,并且经过route -etcpdump -ni your_ethernet接口 host 228.0.0.4也证明了(好blog)。最后有点儿醍醐灌顶的认为应该是防火墙的问题,就把CentOS自带的firewall.service给remove掉了,也防止对Receiver的端口的影响。

  2. SimpleTcpCluster.startInternal Unable to start cluster

    ChannelException: java.net.SocketException: No such device; No faulty members identified.

  这个提示让人无从下手,但根据这篇blog所说,应该是虚拟机的网络设置不当形成的。我最后选择了桥接模式,记得重启后才生效。

  3. skipping state transfer. No members active in cluster group

  这个是耗费我时间最多的一项。仅仅提示你No members active而没有说明可能的缘由!我是各类搜索各类尝试,整的本身晕晕乎乎的,各类郁闷(根上仍是网络通讯/编程这块不懂形成的)。

  在解决这个问题以前,我用公司laptop的Win7环境搭了差很少相同的tomcat集群+httpd。以后顺利实现loadbalance+tomcat集群。在查看log的过程当中,发现第一个启来的tomcat会有skipping state transfer. No members active in cluster group的日志,当时窃喜!说不定我CentOS上的那套集群实际上已经成功了呢?!惋惜仅限于美好的想法。不过Win7下的log却是让我知道了什么样的状况表示tomcat集群成功built起来了:"Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp:"。

  误打误撞搜到这么一篇stackoverflow,大概意思是multicast已经enable,可是tomcat就是没法集群。里面提到了IPv4和IPv6,一脸萌比。。。不过下面的回答却是让我有了些但愿。Tomcat8.5.4默认绑定IPv6,当发现server不工做时,应改绑定IPv4。

  在httpd和3个tomcat实例都启来后,我尝试请求localhost,获得503页面,以后查看mod_jk.log,发现loadbalance没有问题。再尝试http直接访问tomcat,没有问题。因此判定tomcat接收分发的请求出现问题。因为接收请求是经过ajp13协议进行,极可能IPv4和IPv6捣鬼了。

  参考blog,将tomcat运行环境与IPv4绑定。

到此,多播方式的Tomcat集群 + 负载均衡 终于搞定!

PS: 能花半天时间作记录,我也是醉醉的了,估计仅此一次吧:)

相关文章
相关标签/搜索