Azure中的Tomcat负载平衡

时间:2013-07-08 11:45:48

标签: tomcat authentication azure load-balancing

我们正在Azure中的两个切片上安装一个Tomcat的小型服务器场(2个节点),并将Azure负载均衡器放在前面。这基本上是一个循环的非粘性会话平衡器。

webapp使用Tomcat的容器管理安全性(表单身份验证,目前通过DataSourceRealm。

当用户循环访问节点时,他们没有像我们预期的那样进行身份验证,他们会收到身份验证错误。

我已经完成了相当多的研究,并且似乎没有一种规定的处理方式......有人建议我们将节点放在Apache服务器后面并使用mod_jk;我们重新设计身份验证过程以使用cookie来确认身份验证;我们使用Tomcat集群。

我们实现这一目标的最简单方法是什么?我们的应用程序不会使用任何会话(除了Tomcat的CMS)。我们宁愿不离开Tomcat的CMS,但我们并不反对在必要时构建JAAS实现。但实际上,我们唯一需要支持的是跨节点身份验证。

任何帮助表示赞赏!

编辑:我们尝试在Azure上进行memcached,得到以下内容:

2013-07-08 21:50:55.463 INFO net.spy.memcached.MemcachedConnection:  Connection state changed for sun.nio.ch.SelectionKeyImpl@dcd4755
2013-07-08 21:50:55.463 INFO net.spy.memcached.MemcachedConnection:  Reconnecting due to failure to connect to {QA sa=srvr.cloud.com/1XX.1XX.1XX.1XX:11XXX, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
java.net.ConnectException: Connection timed out: no further information
                at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
                at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
                at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:399)
                at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
                at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)

我们的context.xml:

<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:srvr.cloud.com:11XXX"
    sticky="false"
    sessionBackupAsync="false"
    lockingMode="uriPattern:/path1|/path2"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    transcoderFactoryClass="de.javakaffee.web.msm.JavaSerializationTranscoderFactory"
    />

1 个答案:

答案 0 :(得分:3)

一种方法是在服务器上托管memcached,或Windows Azure Caching,并利用memcached-session-manager在Tomcat服务器之间共享会话数据。

“memcached-session-manager是一个tomcat会话管理器,用于保存memcached中的会话,用于高可用性,可伸缩和容错的Web应用程序。它支持粘性和非粘性配置,目前正在使用tomcat 6.x对于粘性会话,支持会话故障转移(tomcat崩溃),对于非粘性会话,这是默认设置(默认情况下,会话由不同的tomcats为不同的请求提供服务)。还支持memcashed故障转移(memcached crash)通过迁移会话。也不会出现单点故障,所以当memcached失败时,会话不会丢失(但要么在tomcat或其他memcached中可用)。“

请参阅this answer稍稍过时的讨论。