Apache tomcat负载均衡详解.docx

Apache tomcat负载均衡详解.docx

《Apache tomcat负载均衡详解.docx》由会员分享，可在线阅读，更多相关《Apache tomcat负载均衡详解.docx（15页珍藏版）》请在冰点文库上搜索。

Apachetomcat负载均衡详解

Apache tomcat负载均衡详解1

一、简介：

每个Tomcatworker是一个服务于webserver、等待执行servlet的Tomcat实例。

例如我们经常使用像Apache之类的webserver转发sevlet请求给位于其后面的一个Tomcat进程（也就是前面所说的worker）。

本文详细介绍了如何配置各种类型worker和loadbalance，并说明了各种类型worker的特性和loadbalance配置的原理。

二、为什么使用Tomcatworkers：

上文描述了一个非常简单的结构，事实上能够配置多个Tomcatworkers来处理webserver转发的servlet请求。

而这样配置的理由不外乎以下几种假想环境：

*我们在开发环境中发布不同的Tomcatworkers为各自不同的应用服务。

当然在开发环境中的开发者共享同一个webserver，但是每个Tomcatworke服务于拥有它的开发者。

*我们在不同的Tomcat进程上定义各自的虚拟主机，这样不同的公司可以使用各自的website，从而使他们的website得到了合理的分割。

*我们提供负载平衡的website，也就意味着同时使用多个Tomcatworkers，而每个Tomcatworker具有独立的主机并且在workers之间要分配通过webserver转发来的请求。

当然，这些假想情况也许并不能涵盖使用多个workers的所有状况。

三、workers.properties配置说明：

定义Tomcatworkers的方法是在apache的conf目录下编写一个名为“workers.properties”的属性文件。

本文将详细解释如何进行配置的：

1.定义Workers列表：

定义workers的方法就是在apache的conf目录下编写一个workers.properties文件，使其作为apache的插件来发挥作用。

定义workers列表的格式：

worker.list=<使用“,”分割的worker名字列表>

例如：

worker.list=worker1,worker2

当apache启动时，workers.properties作为插件将初始化出现在worker.list列表中的workers。

2.定义Workers的类型：

每个被命名的worker都应有一些关于其自身的附加信息。

这些信息包括了worker的类型和其它相关信息。

这里讨论的是JK1.2.5中定义的workers类型。

定义worker类型的格式：

worker.worker名字.type=

worker名字的命名最好遵循java的命名规范。

worker类型取值于下面的表格：

定义一个名为“local”的worker，其使用ajpv12协议与Tomcat进程通讯：

worker.local.type=ajp12

定义一个名为“remote”的worker，其使用ajpv13协议与Tomcat进程通讯：

worker.remote.type=ajp13

定义一个名为“fast”的worker，其使用JNI的方式与Tomcat进程通讯：

worker.fast.type=jni

定义一个名为“loadbalancer”的worker，其作为对多个Tomcat进程的负载平衡使用：

worker.loadbalancer.type=lb

各个类型具有不同的行为，我们在下文中会详细解释。

3.设置Worker属性：

在定义worker之后，还需要提供各个worker的属性，这些属性的定义使用下面的方式：

worker..<属性>=<属性值>

3-1ajp12类型的Worker属性：

.

ajp12类型的worker工作时使用基于TCP/IPsocket的ajpv12协议转发请求给“进程外”Tomcatworker。

ajp12worker属性如下：

host：

侦听ajp12请求的Tomcatworker主机。

port：

Tomcatworker主机的侦听端口。

lbfactor：

当此Tomcatworker被用于一个负载平衡worker使用时，此属性将被使用。

它定义了此worker的负载平衡权值。

例如：

下面的“worker1”定义了一个位于主机上的Tomcat，它使用8007端口侦听apache发来的请求，并具有2.5的负载权值

worker.worker1.host=

worker.worker1.port=8007

worker.worker1.lbfactor=2.5

注意：

在ajpv12协议中，针对每个请求都要一个连接建立、使用、关闭。

其默认侦听端口为8007。

3-2ajp13类型的Worker属性：

ajp13类型的worker工作时使用基于TCP/IPsocket的ajpv13协议转发请求给“进程外”Tomcatworker。

ajpv13协议与ajpv12协议的主要不同：

*ajpv13具有更丰富的二进制协议，它使用将频繁使用的字符串编码为小整数的方式对请求数据进行压缩。

*ajpv13重用打开的socket并保留这些打开的socket以处理将来的请求。

这在apache与Tomcat之间具有防火墙的网络环境下是必要的。

*ajpv13具有对SSL信息的处理能力，以致容器能够实现SSL的相关方法（如isSecure（））。

注意：

ajp13当前只能用于支持“进程外”协议的Tomcat4.0.x,4.1.xand5。

下表描述了ajp13worker接受的属性：

host：

侦听ajp13请求的Tomcatworker主机。

port：

Tomcatworker主机的侦听端口。

lbfactor：

当此Tomcatworker被用于一个负载平衡worker使用时，此属性将被使用。

它定义了此worker的负载平衡权值。

cachesize：

当在多线程的webserver（例如apache2.0、IIS、Netscape）中使用JK时，此属性是有效的。

如果将cachesize的值设置为较高的值，这些支持多线程的webserver将获得很好的处理能力。

如果此属性不被设置，则连接cache特性将失效。

cache_timeout：

本属性用于声明JK在cache中保留一个打开的socket的时间，它对减少webserer的线程数有所帮助。

使用cache_timeout的原因：

周所周知，一个身背重负的webserver（例如apache）建立childs/threads来处理负载，而当负载减少时它将销毁无用的childs/threads。

每个child在转发请求给Tomcat时要打开一个ajp13连接，而在Tomcat那一端也将建立一个ajp13线程与之通讯。

但是问题出现在一个ajp13连接建立完成后，child没有及时的释放那个ajp13连接，由于webserver1将保持它的childs/threads运行已处理高负载，即使childs/threads处理快速的静态内容，在Tomcat端也将积累很多的无用ajp13线程。

socket_keepalive：

当防火墙位于webserver与Tomcat之间时，防火墙将尝试断开未激活的网络连接。

此属性将告诉操作系统在未激活的连接中发送KEEP_ALIVE信息（发送间隔时间依赖于操作系统的设置，一般为120秒），这样将防止防火墙切断未激活的网络连接。

但此设置并不是万能钥匙，它对于某些防火墙也无能为力。

socket_timeout：

此属性说明连接在未激活的状况下持续多久，webserver将主动切断之。

这是一个使Tomcat端的陈旧线程不致过多的好方法，但是也带来了在下一次请求到来时需要重新打开socket的开销。

此属性与cache_timeout有类似的功效，但是它工作在non-cache模式。

connect_timeout：

webserver在连接建立后将一个PING请求发送到ajp13协议的连接上。

此属性说明了webserver等待PONG回应的时间（以ms为单位）。

此属性在jk1.2.6版本被增加进来，以求避免Tomcat的死机，Tomcat3.3.2+,4.1.28+and5.0.13+实现了对使用ajp13的ping/pong的支持。

此属性默认为失效的。

prepost_timeout：

webserver在转发一个请求后将一个PING请求发送到ajp13协议的连接上。

此属性说明了webserver等待PONG回应的时间（以ms为单位）。

此属性在jk1.2.6版本被增加进来，以求避免Tomcat的死机，Tomcat3.3.2+,4.1.28+and5.0.13+实现了对使用ajp13的ping/pong的支持。

此属性默认为失效的。

reply_timeout：

此属性告诉webserver在接到远端的Tomcat已死并实时的切换到集群中的另外一个Tomcat的回应之前等待一段时间。

默认情况下webserver将永远等待。

属性值为webserver要等待回应的时间（以ms为单位），所以如果具有运行时间较长的servlet时设置其值要小心。

此属性在jk1.2.6版本被增加进来，以求避免Tomcat的死机和在支持ajp13的servlet引擎上发生的问题。

此属性默认为失效的。

recovery_options：

此属性说明了webserver在检测到Tomcat失败后如何进行恢复工作。

默认情况下，webserver将转发请求给处于负载平衡模式中的另一个Tomcat。

属性值为0，说明全部恢复；属性值为1，说明如果在Tomcat接到请求后出现失败状况，则不进行恢复；属性值为2，说明如果在Tomcat发送http头给客户端后出现失败状况，则不进行恢复；属性值为3，说明如果在Tomcat接到请求后出现失败状况或者在Tomcat发送http头给客户端后出现失败状况，则不进行恢复。

此属性在jk1.2.6版本被增加进来，以求避免Tomcat的死机和在支持ajp13的servlet引擎上发生的问题。

此属性默认为全部恢复。

例如：

一个名为“worker2”的worker的配置：

worker.worker2.host=

worker.worker2.port=8009

worker.worker2.lbfactor=3.5

worker.worker2.cachesize=10

worker.worker2.cache_timeout=600

worker.worker2.socket_keepalive=1

worker"worker2"wantajp13connectiontobedroppedafter5mn（timeout）

worker.worker2.socket_timeout=300

说明：

上例中的worker要求操作系统在连接上发送KEEP-ALIVE信号。

注意：

在ajpv13协议中默认端口为8009。

4.设置lbWorker属性：

负载平衡类型的worker并不与Tomcatworker通讯，它负责管理这些Tomcatworker。

其管理范围如下：

*初始化在webserver的worker列表中定义的worker。

*使用worker的负载平衡权值，执行基于权值的负载平衡，将数量多的请求发送到负载平衡权值高（在webserver看来就是更加健壮的）的worker。

*维护在同一个Tomcatworker上的同一个session的请求，使其发送到同一个Tomcatworker上。

以达到Tomcatworker上的session一致性、持续性。

*标识已经失败的Tomcatworkers，悬空发向它们的请求，在被lbworker管理的其它workers上寻找可以失败恢复的worker。

被同一个lbworker管理多个worker之间的负载平衡的（基于它们的lbfactor和当前用户session），也可以尽量避免由于单一的Tomcat进程死掉而造成这个网站被“杀”的不良反应。

下表说明了lbworker接受的属性：

*balanced_workers：

一个由“，”分割的worker列表，用来声明lbworker需要被管理的workers。

这些workers不应出现在worker.list属性中。

*sticky_session：

表述是否将对SESSIONID的请求路由回到相同的Tomcatworker。

如果属性值不为0，它将被设置为JK_TRUE，session将是粘性的，即SESSIONID的请求路由回到相同的Tomcatworker；当Tomcat正使用能够跨越多个Tomcat实例持久化session数据的SessionManager时，它将被设置为JK_FALSE。

属性默认值为JK_TRUE。

例如：

workerbalance1管理着两个workers：

worker1、worker2：

worker.balance1.balanced_workers=worker1,worker2

5.高级lbWorker属性：

JK1.2.x版本通过增加两个新的属性：

local_worker_only和local_worker为lbworker增添了新的负载平衡和容错支持。

下面让我们举一个实际的环境作为example：

一个集群具有两个节点（worker1+worker2），一个webserver与tomcatworkers一前一后，一个负载平衡器（lbWorker）位于节点的前面、webserver的后面。

配置如下：

worker.list=router

#Definea'local_worker'workerusingajp13

worker.worker1.port=8009

worker.worker1.host=node1.domain.org

worker.worker1.type=ajp13

worker.worker1.lbfactor=1

worker.worker1.local_worker=1

#Defineanother'local_worker'workerusingajp13

worker.worker2.port=8009

worker.worker2.host=node2.domain.org

worker.worker2.type=ajp13

worker.worker2.lbfactor=1

worker.worker2.local_worker=0

#DefinetheLBworker

worker.router.type=lb

worker.router.balanced_workers=worker1,worker2

worker.router.local_worker_only=1

在worker1和worker2上的local_worker标志告诉lb_worker哪个连接属于本地worker。

如果local_worker值为非0，则它将被设置为JK_TRUE，用来标记“localworker”，而JK_FALSE的情况则相反。

如果至少一个worker被标记为localworker，则lb_worker将工作于localworker模式。

这种模式下，所有的localworkers将被移到在lb_worker中的内部worker列表的头部。

这意味着一个带有sessionid的请求到达lb_worker时，相应的worker（根据权值排序，权值最大的那个worker）将被确定作为此请求的接受/处理者。

如果这个worker死掉/当机，请求将被发送到处于非错误状态的第一个localworker；如果一个没有sessionid的请求到达lb_worker时，此请求将被路由到第一个localworker。

如果所有的localworker均处于错误状态，则这时“local_worker_only”标志显得尤其重要。

如果local_worker_only的属性值为非0，则它被设置为JK_TRUE，否则被设置为JK_FALSE。

当它被设置为JK_TRUE时，这个没有sessionid的请求将得到一个错误作为回应，否则lb_worker将尝试将请求路由到其它的被管理的worker上。

如果其中的一个worker处于错误状态，并且恢复会话的工作并没有任何改变，localworker将查找这个没有sessionid的请求（因为在localworker中保存有这个请求的session），而其它的worker只能查找带有sessionid的请求。

注意：

local_worker默认值是0，local_worker_only默认值也是0。

6.为什么需要这么复杂的过程吗？

因为我们对于一个关闭的节点需要一个具有灵性的维护。

在节点前面的平衡器周期性的对每个节点的特定端口进行查询。

如果我们从集群中移走一个节点，我们就会隐性的关闭掉这个特定的端口。

由于负载平衡器不能连接它，这个节点将被标记为down。

但是我们没有移动在那个关闭的节点上的session到其它的节点上。

在这个环境下，如果平衡器发送一个没有sessionid的请求到一个端口被关掉的节点，那么一个错误将发生。

如果平衡器测试到一个节点被标记为down的状态，而没有其它的节点允许发送没有sessionid的请求。

这样这些陈旧的session请求就只有路由到那个被关闭的节点才能被接受。

在一段时间后，这些陈旧的session将超时。

由于所有的陈旧的session过期，那个不可达（被关闭）的节点将失去这个请求。

同时也会导致我们的servlet系统发送一个没有sessionid的重定向回应给浏览器。

但是可能被关闭的节点将会up，重新加入到集群中来，在它上面仍将保留着陈旧的session。

所以在最后一个session超时后，更新节点能够为陈旧的session的恢复带来希望，而不是杀掉sessions或者把它们移到其它节点上。

而且有时如果那些陈旧的session中有许多big的对象，那么移动它们也将花费许多时间。

7.jni类型的Worker属性：

jniworker会在webserver进程中打开一个JVM，并在其中执行Tomcat，这叫做“进程内”worker。

来往于JVM的消息将通过调用JNI方法被传递，这使jniworker比那些需要使用ajp消息通讯的“进程外”worker执行的更快。

注意：

由于JVM是多线程的，jniworker应该只被用于在支持对线程的webserver（AOLServer,IIS,NetscapeandApache2.0）上。

同时还应该确认在webserver上使用的线程方案是否与被使用的JKwebserver插件相匹配。

由于jniworker打开了一个JVM，它将接受一些属性（例如classpath等）并将其传递给JVM：

worker.worker名.class_path：

“进程内”的JVM要使用的classpath。

它将包括所有的Tomcat的jar文件和class、配置文件等。

为了获得JSP编译器的支持，我们需要将Javac添加到classpath中。

当然对于Java2需要添加tools.jar到classpath，而对于JDK1.xx则要添加classes.zip到classpath。

worker.worker名.class_path：

用于以多行的形式声明多个classpath。

JK环境将用“：

”或者“；”把这些classpath；连接起来。

例如：

给名为“wrkjni”的worker设置classpath。

worker.wrkjni.class_path=/var/tomcat3/lib/tomcat.jar

worker.wrkjni.class_path=/opt/IBMJava2-131/lib/tools.jar

worker.worker名.bridge：

用于标识将通过JNI方式被使用的Tomcat的类型。

此属性目前有两个属性值：

tomcat32ortomcat33。

Tomcat3.2.x虽然已经过时，但是被提供用于发布在一些类似iSeries系统上。

此属性的默认值为tomcat33。

例如：

给“wrkjni”设置bridge类型为tomcat3.3。

worker.wrkjni.bridge=tomcat33

worker.worker名.cmd_line：

此属性提供了在Tomcat启动代码执行的命令行。

使用时将命令行的命令、参数分解为多个cmd_line属性。

JK环境通过在各个cmd_line属性值之间添加空格将这些cmd_line连接在一起。

例如：

设置“wrkjni”的cmd_line属性。

worker.wrkjni.cmd_line=-config

worker.wrkjni.cmd_line=/etc/tomcat3/conf/alt-server.xml

worker.wrkjni.cmd_line=-home

worker.wrkjni.cmd_line=/var/tomcat3

上面例子中的第一行声明了-config参数名，而第二行声明了与之对应的参数值。

第三行与第四行同理。

worker.worker名.jvm_lib：

用于声明JVM的实现库的完整路径。

Jniworker使用这个路径动态装载JVM。

例如：

设置“wrkjni”的JVMsharedlib（IBMSDKonLinux）。

worker.wrkjni.jvm_lib=/opt/IBMJava2-131/jre/bin/classic/libjvm.so

例如：

设置“wrkjni”的JVMsharedlib（SunSDKonWindows）。

worker.wrkjni.jvm_lib=c:

\JDK\1.3.1\jre\bin\classic

worker.worker名.stdout：

设置JVM写它的System.out的完整路径位置。

例如：

将“wrkjni”的JVM系统输出路径设置为/var/log/http/jk-jvm-out.log。

worker.wrkjni.stdout=/var/log/http/jk-jvm-out.log

worker.worker名.stderr：

设置JVM写它的System.err的完整路径位置。

例如：

将“wrkjni”的JVM系统错误输出路径设置为/var/log/http/jk-jvm-err.log

worker.wrkjni.stderr=/var/log/http/jk-jvm-out.log

worker.worker名.ms：

设置JVM的初始堆大小。

例如：

设置“wrkjni”的JVM的初始堆为64M。

worker.wrkjni.ms=64

worker.worker名.mx：

设置JVM的最大的堆大小。

例如：

设置“wrkjni”的JVM堆最大为128M