☰

Die Tomcat 6-Sitzungsreplikation funktioniert nicht mit HAProxy

tag-icon • tag-icon haproxy tomcat6
Die Tomcat 6-Sitzungsreplikation funktioniert nicht mit HAProxy

Ich habe einen HAProxy-Loadbalancer und zwei Tomcat-Backend-Server. HAProxy ist mit Cookie-basierter Persistenz konfiguriert, Tomcat ist gemäß Dokumentation mit SimpleTcpCluster konfiguriert. Multicast zwischen beiden Tomcat-Backend-Servern ist aktiviert. Allerdings funktioniert die Sitzungsreplikation nicht. Jedes Mal, wenn ich den Server herunterfahre, der die Sitzung hält, werden Benutzer abgemeldet. In catalina.out sehe ich, dass die Server miteinander kommunizieren, zum Beispiel, wenn ich ein Backend herunterfahre:

8. Mai 2014, 11:00:25 Uhr org.apache.catalina.tribes.group.interceptors.TcpFailureDetector performBasicCheck INFO: Verdächtiges Mitglied, bestätigter Tod. [org.apache.catalina.tribes.membership.MemberImpl [tcp://{10, 2, 1, 69}:5000,{10, 2, 1, 69},5000, alive=931801,id={-18 123 59 -88 -95 20 78 -34 -83 31 -43 73 -64 -71 42 -62 }, payload={}, command={}, domain={}, ]]

Außerdem, wenn ich das Backend hochfahre:

WARNUNG: Manager [webservice#], fordert Sitzungsstatus von org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 2, 1, 69}:5000,{10, 2, 1, 69},5000, alive=672675,id={-18 123 59 -88 -95 20 78 -34 -83 31 -43 73 -64 -71 42 -62 }, payload={}, command={}, domain={}, ] an. Dieser Vorgang wird abgebrochen, wenn innerhalb von 60 Sekunden kein Sitzungsstatus empfangen wurde. 8. Mai 2014, 10:54:21 Uhr org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor-Bericht INFO: ThroughputInterceptor-Bericht Tx-Nachricht: 1 Nachricht Gesendet: 0,00 MB (insgesamt) Gesendet: 0,00 MB (Anwendung) Zeit: 0,01 Sekunden Tx-Geschwindigkeit: 0,04 MB/Sek. (insgesamt) Tx-Geschwindigkeit: 0,04 MB/Sek. (Anwendung) Fehlermeldung: 0 Rx-Nachricht: 0 Nachrichten Rx-Geschwindigkeit: 0,00 MB/Sek. (seit 1. Nachricht) Empfangen: 0,00 MB]

8. Mai 2014, 10:54:21 Uhr, org.apache.catalina.ha.session.DeltaManager waitForSendAllSessions INFO: Manager [Webdienstnr.]; ​​Sitzungsstatus gesendet am 8.5.14, 10:54 Uhr, empfangen in 111 ms.

Clustering und Multicast funktionieren also.

Hier ist die HAProxy-Backend-Konfiguration:

backend BE-tomcat_http
mode            http
cookie SERVERID insert indirect nocache
balance         leastconn
timeout connect     30000
timeout server      30000
retries         3
option          httpchk OPTIONS /
option          redispatch
option          http-server-close
option          http-pretend-keepalive
server          node01 10.2.1.69:80 cookie node01 check inter 1000
server          node02 10.2.1.90:80 cookie node02 check inter 1000

Hier ist Tomcat server.xml

    <Engine name="Catalina" defaultHost="localhost" jvmRoute="node01">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>


  <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">
                  <Manager className="org.apache.catalina.ha.session.DeltaManager"
                           expireSessionsOnShutdown="false"
                           notifyListenersOnReplication="true"
                           mapSendOptions="8"/>
                  <Channel className="org.apache.catalina.tribes.group.GroupChannel">
                  <Membership className="org.apache.catalina.tribes.membership.McastService"
                              address="228.0.0.4"
                              port="45564"
                              frequency="500"
                              dropTime="3000"/>
                  <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                            address="auto"
                            port="5000"
                            selectorTimeout="500"
                            minThreads="2"
                            maxThreads="6"/>
                  <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
                  <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
                  </Sender>
                  <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
                  <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
                  <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
                  </Channel>
                  <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                                             filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>
                   <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
                   <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
    <!--           <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                             tempDir="/tmp/war-temp/"
                             deployDir="/tmp/war-deploy/"
                             watchDir="/tmp/war-listen/"
                             watchEnabled="false"/> -->
     </Cluster>

Ich sehe, dass die Cookie-Persistenz funktioniert, denn wenn Benutzer angemeldet sind, bleiben sie bei einem Backend-Server, solange die Sitzung gültig ist. Wenn ich jedoch den Server herunterfahre, der die Sitzung hält, werden Benutzer rausgeschmissen, obwohl ich in der Protokolldatei sehe, dass ein anderer Server dies bemerkt hat.

Auch web.xml verfügt über den verteilbaren Elementsatz.

Irgendwelche Ideen?

Danke

Antwort1

Ich kann kein Problem mit der von Ihnen angegebenen Konfiguration erkennen. Ein paar Vorschläge für Sie.

  1. Sie können bestätigen, dass die Sitzungen auf jeden Knoten im Cluster repliziert werden, indem Sie in den Manager gehen (http://node01:80/manager/html) und zeigen Sie jede Sitzung im Manager des anderen Knotens an.

    Ich vermute, Sie replizieren nicht, da ein Knotenverlust die Sitzung nicht beenden sollte.

  2. Überprüfen Sie Ihre Firewall-Regeln für Port 5000 und für die Multicast-Adresse 228.0.0.4

    Die meisten Probleme sind bei der Firewall-Konfiguration aufgetreten!

verwandte Informationen