Re: Server affinity instead of session affinity
On 23/11/2010 23:34, André Warnier wrote: Andrew Hole wrote: I'm reading about domain directive in worker properties. I can setup different workers to be in the same domain (p.e. a machine) and have domain affinity. Do you have some idea how it really works? No, but it kind of sounds like what you want to achieve, doesn't it ? You could try it, and see how it goes. It sounds like you would need to add one directive to each worker, like worker.tomcatA.domain=machine1 worker.tomcatB.domain=machine1 worker.tomcatC.domain=machine2 worker.tomcatD.domain=machine2 and it would then balance between machine1 and machine2, instead of between the workers themselves. But it also sounds like tomcatA and tomcatB would have to be configured as a cluster, and have some provision to share and replicate sessions between them. That may be more work than you're aiming for. (I'm not sure, just guessing). That isn't going to help keep sessions for app1 and sessions for app2 on the same machine since httpd/IIS treats each application independently. What it will do is require you to have clustering using the delta manager (all sessions replicated to all nodes) working across all of the nodes on a machine. That adds a lot of overhead for little benefit and requires all applications are installed on every node. Again, you'll need to look at an alternative LB approach. I've already mentioned the client IP based approach. The other approach is adding your own cookie (with path =/ so it applies to all apps) that you use to make the LB sticky to a machine. You'll need to do a little config in httpd.conf but it is quite simple. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
On 23/11/2010 00:06, Andrew Hole wrote: There is a middleware-to-middleware connection between Tomcat A and Tomcat B using RMI (point-to-point protocol) and Tomcat A has in-memory data useful to App3. The same aproach in the second server: applications in tomcat d have RMI communication to tomcat c. I don't think there is a way to do this in mod_jk configuration. One way to do this would be base affinity on client IP address. You should be able to do something like the following in httpd: - get client IP address - if last octet is odd, redirect to machine 1 - else, redirect to machine 2 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 11/23/2010 5:12 AM, Mark Thomas wrote: On 23/11/2010 00:06, Andrew Hole wrote: There is a middleware-to-middleware connection between Tomcat A and Tomcat B using RMI (point-to-point protocol) and Tomcat A has in-memory data useful to App3. The same aproach in the second server: applications in tomcat d have RMI communication to tomcat c. I don't think there is a way to do this in mod_jk configuration. One way to do this would be base affinity on client IP address. You should be able to do something like the following in httpd: - get client IP address - if last octet is odd, redirect to machine 1 - else, redirect to machine 2 What about Chuck's suggestion of having multiple JVMs with the same jvmRoute? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzr0pgACgkQ9CaO5/Lv0PCiUQCgmPrNHGz1bfUF0qmSfAOVfziA RUEAn1s2Fa5LoFa/CB9YOAdovXtSLIrX =zcqz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
On 23/11/2010 14:41, Christopher Schultz wrote: Mark, On 11/23/2010 5:12 AM, Mark Thomas wrote: On 23/11/2010 00:06, Andrew Hole wrote: There is a middleware-to-middleware connection between Tomcat A and Tomcat B using RMI (point-to-point protocol) and Tomcat A has in-memory data useful to App3. The same aproach in the second server: applications in tomcat d have RMI communication to tomcat c. I don't think there is a way to do this in mod_jk configuration. One way to do this would be base affinity on client IP address. You should be able to do something like the following in httpd: - get client IP address - if last octet is odd, redirect to machine 1 - else, redirect to machine 2 What about Chuck's suggestion of having multiple JVMs with the same jvmRoute? It won't work. Apps are routed independently. If every Tomcat instance was running every app then the session ID can be shared between the apps and you get more options. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
With the configuration below and your explanations, I suppose that there is some kind of load-balancing going on between the two machines. What is used at the front-end to load-balance ? An idea (for the moment vague) would be to use some intelligent front-end, which would decide (maybe as Mark wrote, in function of the client IP address) to start chanelling one client to either machine 1 or machine 2 - and within it to Tomcat A,B,C or D - , set a cookie, and use this cookie later to keep sending the same client to the same back-end machine. Kind of a session on top of a session.. There is also the question of why App1-4 have to be split between different Tomcats. Why can you not run all apps within one single JVM/Tomcat ? Andrew Hole wrote: There is a middleware-to-middleware connection between Tomcat A and Tomcat B using RMI (point-to-point protocol) and Tomcat A has in-memory data useful to App3. The same aproach in the second server: applications in tomcat d have RMI communication to tomcat c. thanks On Mon, Nov 22, 2010 at 11:58 PM, André Warnier a...@ice-sa.com wrote: Andrew Hole wrote: Sorry for the inconvenience. I sent the email with wrong content. An example: Machine 1: Tomcat A App1 App2 Tomcat B App3 App4 Machine 2: Tomcat C App1 App2 Tomcat D App3 App4 Using session affinity, if I make a request to App1 and the Tomcat A in Machine 1 is selected. All the sequent requests will be redirected (within the same session) to the same Tomcat (tomcat A). However, if i make a request to App3, Tomcat B (machine 1) or Tomcat D (machine 2) could be selected. What I really want is that the request to App3 could be done to Tomcat B in machine 1 (the request was done using the same browser client). Ok, now I get it. My next question is : why ? Why is it important that, having started on Tomcat A with App1, the same client would get App3 on Tomcat B, rather than on Tomcat D ? What do Tomcat A and Tomcat B have in common, that Tomcat C and D don't ? And vice-versa. And , should your scheme still work if in the future, Tomcat A and Tomcat B were split onto two separate machines ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/23/2010 10:27 AM, André Warnier wrote: With the configuration below and your explanations, I suppose that there is some kind of load-balancing going on between the two machines. What is used at the front-end to load-balance ? An idea (for the moment vague) would be to use some intelligent front-end, which would decide (maybe as Mark wrote, in function of the client IP address) to start chanelling one client to either machine 1 or machine 2 - and within it to Tomcat A,B,C or D - , set a cookie, and use this cookie later to keep sending the same client to the same back-end machine. Kind of a session on top of a session.. I believe there was a presentation at ApacheCon where someone presented something like this. I didn't attend, but I heard that a relatively simply use of httpd's mod_headers was used to essentially synthesize sticky sessions. The same technique could be applied to do a sort of server stickiness: 1. Check the request for a SERVER_AFFINITY cookie 2. If none exists, choose a server however you like and set SERVER_AFFINITY=A/B or D/C 3. Given a server affinity, send the request to a specific back-end server. Note that #3 can be achieved by simply choosing an AJP worker that is not a load-balancer. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzsK6kACgkQ9CaO5/Lv0PCZWACgwBnHTtm61U3tRM1QXP1w+Tdp EOQAn0YPzA8SVbO589e+V++qS8fS2cIl =Hh7E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
I'm reading about domain directive in worker properties. I can setup different workers to be in the same domain (p.e. a machine) and have domain affinity. Do you have some idea how it really works? Thanks On Tue, Nov 23, 2010 at 9:01 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/23/2010 10:27 AM, André Warnier wrote: With the configuration below and your explanations, I suppose that there is some kind of load-balancing going on between the two machines. What is used at the front-end to load-balance ? An idea (for the moment vague) would be to use some intelligent front-end, which would decide (maybe as Mark wrote, in function of the client IP address) to start chanelling one client to either machine 1 or machine 2 - and within it to Tomcat A,B,C or D - , set a cookie, and use this cookie later to keep sending the same client to the same back-end machine. Kind of a session on top of a session.. I believe there was a presentation at ApacheCon where someone presented something like this. I didn't attend, but I heard that a relatively simply use of httpd's mod_headers was used to essentially synthesize sticky sessions. The same technique could be applied to do a sort of server stickiness: 1. Check the request for a SERVER_AFFINITY cookie 2. If none exists, choose a server however you like and set SERVER_AFFINITY=A/B or D/C 3. Given a server affinity, send the request to a specific back-end server. Note that #3 can be achieved by simply choosing an AJP worker that is not a load-balancer. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzsK6kACgkQ9CaO5/Lv0PCZWACgwBnHTtm61U3tRM1QXP1w+Tdp EOQAn0YPzA8SVbO589e+V++qS8fS2cIl =Hh7E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
And regarding your question; ~Why can you not run all apps within one single JVM/Tomcat ? Because we have a lot of web applications and we are using 32-bit JVM. Thanks a lot On Tue, Nov 23, 2010 at 10:59 PM, Andrew Hole andremailingl...@gmail.comwrote: I'm reading about domain directive in worker properties. I can setup different workers to be in the same domain (p.e. a machine) and have domain affinity. Do you have some idea how it really works? Thanks On Tue, Nov 23, 2010 at 9:01 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/23/2010 10:27 AM, André Warnier wrote: With the configuration below and your explanations, I suppose that there is some kind of load-balancing going on between the two machines. What is used at the front-end to load-balance ? An idea (for the moment vague) would be to use some intelligent front-end, which would decide (maybe as Mark wrote, in function of the client IP address) to start chanelling one client to either machine 1 or machine 2 - and within it to Tomcat A,B,C or D - , set a cookie, and use this cookie later to keep sending the same client to the same back-end machine. Kind of a session on top of a session.. I believe there was a presentation at ApacheCon where someone presented something like this. I didn't attend, but I heard that a relatively simply use of httpd's mod_headers was used to essentially synthesize sticky sessions. The same technique could be applied to do a sort of server stickiness: 1. Check the request for a SERVER_AFFINITY cookie 2. If none exists, choose a server however you like and set SERVER_AFFINITY=A/B or D/C 3. Given a server affinity, send the request to a specific back-end server. Note that #3 can be achieved by simply choosing an AJP worker that is not a load-balancer. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzsK6kACgkQ9CaO5/Lv0PCZWACgwBnHTtm61U3tRM1QXP1w+Tdp EOQAn0YPzA8SVbO589e+V++qS8fS2cIl =Hh7E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
Andrew Hole wrote: I'm reading about domain directive in worker properties. I can setup different workers to be in the same domain (p.e. a machine) and have domain affinity. Do you have some idea how it really works? No, but it kind of sounds like what you want to achieve, doesn't it ? You could try it, and see how it goes. It sounds like you would need to add one directive to each worker, like worker.tomcatA.domain=machine1 worker.tomcatB.domain=machine1 worker.tomcatC.domain=machine2 worker.tomcatD.domain=machine2 and it would then balance between machine1 and machine2, instead of between the workers themselves. But it also sounds like tomcatA and tomcatB would have to be configured as a cluster, and have some provision to share and replicate sessions between them. That may be more work than you're aiming for. (I'm not sure, just guessing). So you do have an Apache in front with mod_jk then ? Does this Apache do anything else than load-balancing the back-end Tomcats ? And about your JVM's being 32-bit : any reason why that has to remain so ? Are the machines themselves only 32-bit physically ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
On Tue, Nov 23, 2010 at 10:01 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 11/23/2010 10:27 AM, André Warnier wrote:
With the configuration below and your explanations, I suppose that there
is some kind of load-balancing going on between the two machines.
What is used at the front-end to load-balance ?
An idea (for the moment vague) would be to use some intelligent
front-end, which would decide (maybe as Mark wrote, in function of the
client IP address) to start chanelling one client to either machine 1 or
machine 2 - and within it to Tomcat A,B,C or D - , set a cookie, and use
this cookie later to keep sending the same client to the same back-end
machine.
Kind of a session on top of a session..
I believe there was a presentation at ApacheCon where someone presented
something like this. I didn't attend, but I heard that a relatively
simply use of httpd's mod_headers was used to essentially synthesize
sticky sessions.
The same technique could be applied to do a sort of server stickiness:
1. Check the request for a SERVER_AFFINITY cookie
2. If none exists, choose a server however you like and set
SERVER_AFFINITY=A/B or D/C
3. Given a server affinity, send the request to a specific back-end
server.
Note that #3 can be achieved by simply choosing an AJP worker that is
not a load-balancer.
I guess you mean that:
Header add Set-Cookie ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/
env=BALANCER_ROUTE_CHANGED
Proxy balancer://mycluster
BalancerMember http://192.168.1.50:80 route=1
BalancerMember http://192.168.1.51:80 route=2
ProxySet stickysession=ROUTEID
/Proxy
ProxyPass /test balancer://mycluster
From http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html.
Thats working quite good even for not Apache backends like IIS. (To make
basic client affinity possible)
Maybe this could be used to stick the whole Client to one backend by the
first request?
If there is an entry context to set this cookie, it should be possible to
stick the client to the backend for the following contexts - maybe.
Mario
--
http://www.n0r1sk.com
RE: Server affinity instead of session affinity
From: Andrew Hole [mailto:andremailingl...@gmail.com] Subject: Server affinity instead of session affinity The goal is to send all requests (within a session) from a client browser to the same machine. Is it possible to perform it using jvmRoute? Can't you just set the jvmRoute value for each Tomcat on the same box to the same value? That would presume you're doing something to share sessions across all of the Tomcats running on one box. - Chuck P.S. Don't cross-post. THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
Andrew Hole wrote: Hi guys! There is any available configuration to define server affinity instead of session affinity? Our architecture setup is based on multiple JVMs (tomcat) instances in each server (machine). The goal is to send all requests (within a session) from a client browser to the same machine. Is it possible to perform it using jvmRoute? I am not sure I understand the question correctly, but if I do, that's what it does, no ? Does sending to the same Tomcat not imply sending to the same machine ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
No... Session affinity (jvmRoute in JSESSION ID) implies sending to the same tomcat instance (same JVM), not for the same machine. Some idea? On Mon, Nov 22, 2010 at 9:10 PM, André Warnier a...@ice-sa.com wrote: Andrew Hole wrote: Hi guys! There is any available configuration to define server affinity instead of session affinity? Our architecture setup is based on multiple JVMs (tomcat) instances in each server (machine). The goal is to send all requests (within a session) from a client browser to the same machine. Is it possible to perform it using jvmRoute? I am not sure I understand the question correctly, but if I do, that's what it does, no ? Does sending to the same Tomcat not imply sending to the same machine ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
Andrew Hole wrote: No... Session affinity (jvmRoute in JSESSION ID) implies sending to the same tomcat instance (same JVM), not for the same machine. I guess that I still don't get it. The same Tomcat instance /is/, per definition, on the same machine. Or do you want to send the request to a /different/ Tomcat instance, but only one which is on the same machine ? And if yes, why would you want to do that ? In other words, why would you /not/ want to send the request to the same Tomcat on the same machine ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
An example: Machine 1: Tomcat A Tomcat B On Mon, Nov 22, 2010 at 11:05 PM, André Warnier a...@ice-sa.com wrote: Andrew Hole wrote: No... Session affinity (jvmRoute in JSESSION ID) implies sending to the same tomcat instance (same JVM), not for the same machine. I guess that I still don't get it. The same Tomcat instance /is/, per definition, on the same machine. Or do you want to send the request to a /different/ Tomcat instance, but only one which is on the same machine ? And if yes, why would you want to do that ? In other words, why would you /not/ want to send the request to the same Tomcat on the same machine ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
Sorry for the inconvenience. I sent the email with wrong content. An example: Machine 1: Tomcat A App1 App2 Tomcat B App3 App4 Machine 2: Tomcat C App1 App2 Tomcat D App3 App4 Using session affinity, if I make a request to App1 and the Tomcat A in Machine 1 is selected. All the sequent requests will be redirected (within the same session) to the same Tomcat (tomcat A). However, if i make a request to App3, Tomcat B (machine 1) or Tomcat D (machine 2) could be selected. What I really want is that the request to App3 could be done to Tomcat B in machine 1 (the request was done using the same browser client). Thanks On Mon, Nov 22, 2010 at 11:23 PM, Andrew Hole andremailingl...@gmail.comwrote: An example: Machine 1: Tomcat A Tomcat B On Mon, Nov 22, 2010 at 11:05 PM, André Warnier a...@ice-sa.com wrote: Andrew Hole wrote: No... Session affinity (jvmRoute in JSESSION ID) implies sending to the same tomcat instance (same JVM), not for the same machine. I guess that I still don't get it. The same Tomcat instance /is/, per definition, on the same machine. Or do you want to send the request to a /different/ Tomcat instance, but only one which is on the same machine ? And if yes, why would you want to do that ? In other words, why would you /not/ want to send the request to the same Tomcat on the same machine ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
Andrew Hole wrote: Sorry for the inconvenience. I sent the email with wrong content. An example: Machine 1: Tomcat A App1 App2 Tomcat B App3 App4 Machine 2: Tomcat C App1 App2 Tomcat D App3 App4 Using session affinity, if I make a request to App1 and the Tomcat A in Machine 1 is selected. All the sequent requests will be redirected (within the same session) to the same Tomcat (tomcat A). However, if i make a request to App3, Tomcat B (machine 1) or Tomcat D (machine 2) could be selected. What I really want is that the request to App3 could be done to Tomcat B in machine 1 (the request was done using the same browser client). Ok, now I get it. My next question is : why ? Why is it important that, having started on Tomcat A with App1, the same client would get App3 on Tomcat B, rather than on Tomcat D ? What do Tomcat A and Tomcat B have in common, that Tomcat C and D don't ? And vice-versa. And , should your scheme still work if in the future, Tomcat A and Tomcat B were split onto two separate machines ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Server affinity instead of session affinity
There is a middleware-to-middleware connection between Tomcat A and Tomcat B using RMI (point-to-point protocol) and Tomcat A has in-memory data useful to App3. The same aproach in the second server: applications in tomcat d have RMI communication to tomcat c. thanks On Mon, Nov 22, 2010 at 11:58 PM, André Warnier a...@ice-sa.com wrote: Andrew Hole wrote: Sorry for the inconvenience. I sent the email with wrong content. An example: Machine 1: Tomcat A App1 App2 Tomcat B App3 App4 Machine 2: Tomcat C App1 App2 Tomcat D App3 App4 Using session affinity, if I make a request to App1 and the Tomcat A in Machine 1 is selected. All the sequent requests will be redirected (within the same session) to the same Tomcat (tomcat A). However, if i make a request to App3, Tomcat B (machine 1) or Tomcat D (machine 2) could be selected. What I really want is that the request to App3 could be done to Tomcat B in machine 1 (the request was done using the same browser client). Ok, now I get it. My next question is : why ? Why is it important that, having started on Tomcat A with App1, the same client would get App3 on Tomcat B, rather than on Tomcat D ? What do Tomcat A and Tomcat B have in common, that Tomcat C and D don't ? And vice-versa. And , should your scheme still work if in the future, Tomcat A and Tomcat B were split onto two separate machines ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
