You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Sean Alderman <sa...@udayton.edu> on 2013/04/02 17:02:23 UTC
[users@httpd] mod proxy balancer problem/question...
Greetings,
I am running httpd 2.2.23.0-64 with mod_proxy to load balance Tomcat
6.0.36.B containers. I have encountered a somewhat strange situation, and
I was wondering if anyone could comment and or propose an alternative.
I have a case where my tomcat containers have multiple webservice
applications deployed. Most of the deployments are stateless, but a few of
them require session stickiness at the proxy layer. I am looking for ways
to better distribute the workload of the stateless webservice calls, with
the hope of not having to create a new tomcat container separate stateful
and stateless sessions. The following configuration was tested, but had
unexpected results...
<Proxy balancer://webservices-sticky>
BalancerMember
ajp://tccontainer2.test.udayton.edu:12002route=webservices2-sticky
BalancerMember
ajp://tccontainer1.test.udayton.edu:12002route=webservices1-sticky
status=+H
ProxySet lbmethod=byrequests
ProxySet stickysession=JSESSIONID
</Proxy>
<Proxy balancer://webservices>
BalancerMember ajp://tccontainer1.test.udayton.edu:12002 loadfactor=1
route=webservices1
BalancerMember ajp://tccontainer2.test.udayton.edu:12002 loadfactor=2
route=webservices2
ProxySet lbmethod=byrequests
</Proxy>
What I find is that balancer://webservices never sends any requests to
ajp://tccontainer1.test.udayton.edu:12002. It would appear that the
status=+H applies to the BalancerMember object instead of
balancer://webservices-sticky. When I remove the status=+H, it would
appear that balancer://webservices load balances properly, but the
consequence is the possibility of new stateful calls being routed to
tccontainer1.
Is this behaviour expected? Due to the long term nature of these sessions,
I was hoping to avoid making both servers hold sessions and use the
loadfactor to route a larger proportion of stateless calls to the server
not service the stateful sessions. Is there a means to accomplish the end
goal with out creating additional tomcat containers?
Thank you in advance for your time and consideration.
Sean Alderman
Senior Engineer
University of Dayton, UDit Systems Integration
Re: [users@httpd] mod proxy balancer problem/question...
Posted by Sean Alderman <sa...@udayton.edu>.
I have proven, through my own experimentation, that removing the status=+H
from the stateful balancer's member allow normal load balancing for the
stateless proxy balancer. Leaving the status=+H in the stateful balancer's
config causes ALL requests in the stateless balancer to route to
tccontainer1. Reversing the balance member order under this scenario
provides consistent behaviour, e.g. ALL requests goto tccontainer1, even
though it's the 2nd balance member. This implies to me that setting
status=+H in the sticky balancer applies also to the stateless balancer,
because tccontainer2 never receives any requests while the status=+H
resides in the config. If taken out of the config, the stateless balancer
evenly routes requests to both tccontainer1 and 2.
The behaviour is odd and unexpected, but consistent.
FWIW, I used Apache Bench for the experimentation from multiple clients on
the stateless side of things. Unfortunately, due to the complexity of the
stateful sessions I don't have a means to perform a test using apache
bench, I can only do a manual test through an upstream application.
Thanks for your thoughts, your attention to my question is much
appreciated! :)
On Tue, Apr 2, 2013 at 4:40 PM, Igor Cicimov <ic...@gmail.com> wrote:
>
> On 03/04/2013 7:28 AM, "Sean Alderman" <sa...@udayton.edu> wrote:
> >
> > Perhaps I've not explained correctly, I apologize. The concept I was
> going for was to have two independent balancers that point to the same
> tomcat instances.
> >
> > In the webservices virtual host I would have a configuration like so:
> >
> > ProxyPass /service-sticky/
> balancer://webservices-sticky/service-sticky/
> > ProxyPassReverse /service-sticky/
> balancer://webservice-sticky/service-sticky/
> >
> > ProxyPass /service-stateless/ balancer://webservices/service-stateless/
> > ProxyPassReverse /service-stateless/
> balancer://webservices/service-stateless/
> >
> > In my config, both of the quoted Proxy balancer directives exist and are
> referenced by a virtual host for different endpoints. I absolutely
> understand what the status=+H does, and I was hoping to use it to confine
> all requests to services requiring stateful sessions to the tomcat instance
> on tccontainer2 unless it is offline.
> >
> > What I was trying to explain is that it would appear (by using mod
> status to inspect requests sent to each balance member) that applying
> status=+H to the balance member of one Proxy balancer, makes it apply to
> both, since the address:port of the balance members are identical between
> the two balancers. I did not expect this behaviour and was looking for
> advice to accomplish the goal of load balancing the stateless requests
> across both containers and confining the stateful requests to one in a
> highly available way.
> >
> > Does that make more sense?
> >
> Not really, the proxy's have no dependencies of each other. Change the
> load factor in the second one from 1 to 2, thats the only reason i can
> think of that one not being used. Or try different lbmethod.
>
> >
> > On Tue, Apr 2, 2013 at 4:06 PM, Igor Cicimov <ic...@gmail.com> wrote:
> >>
> >>
> >> On 03/04/2013 2:02 AM, "Sean Alderman" <sa...@udayton.edu> wrote:
> >> >
> >> > Greetings,
> >> > I am running httpd 2.2.23.0-64 with mod_proxy to load balance
> Tomcat 6.0.36.B containers. I have encountered a somewhat strange
> situation, and I was wondering if anyone could comment and or propose an
> alternative.
> >> >
> >> > I have a case where my tomcat containers have multiple webservice
> applications deployed. Most of the deployments are stateless, but a few of
> them require session stickiness at the proxy layer. I am looking for ways
> to better distribute the workload of the stateless webservice calls, with
> the hope of not having to create a new tomcat container separate stateful
> and stateless sessions. The following configuration was tested, but had
> unexpected results...
> >> >
> >> > <Proxy balancer://webservices-sticky>
> >> > BalancerMember ajp://tccontainer2.test.udayton.edu:12002route=webservices2-sticky
> >> > BalancerMember ajp://tccontainer1.test.udayton.edu:12002route=webservices1-sticky status=+H
> >> > ProxySet lbmethod=byrequests
> >> > ProxySet stickysession=JSESSIONID
> >> > </Proxy>
> >> >
> >> > <Proxy balancer://webservices>
> >> > BalancerMember ajp://tccontainer1.test.udayton.edu:12002loadfactor=1 route=webservices1
> >> > BalancerMember ajp://tccontainer2.test.udayton.edu:12002loadfactor=2 route=webservices2
> >> > ProxySet lbmethod=byrequests
> >> > </Proxy>
> >> >
> >> > What I find is that balancer://webservices never sends any requests
> to ajp://tccontainer1.test.udayton.edu:12002.
> >>
> >> Thats because it never gets used, the requests are always being served
> by the first proxy. Why do you have 2 of them?
> >>
> >> It would appear that the status=+H applies to the BalancerMember
> object instead of balancer://webservices-sticky.
> >>
> >> Correct, it means that that balancer member is hot standby as explained
> in the documentation.
> >
> >
>
Re: [users@httpd] mod proxy balancer problem/question...
Posted by Igor Cicimov <ic...@gmail.com>.
On 03/04/2013 7:28 AM, "Sean Alderman" <sa...@udayton.edu> wrote:
>
> Perhaps I've not explained correctly, I apologize. The concept I was
going for was to have two independent balancers that point to the same
tomcat instances.
>
> In the webservices virtual host I would have a configuration like so:
>
> ProxyPass /service-sticky/ balancer://webservices-sticky/service-sticky/
> ProxyPassReverse /service-sticky/
balancer://webservice-sticky/service-sticky/
>
> ProxyPass /service-stateless/ balancer://webservices/service-stateless/
> ProxyPassReverse /service-stateless/
balancer://webservices/service-stateless/
>
> In my config, both of the quoted Proxy balancer directives exist and are
referenced by a virtual host for different endpoints. I absolutely
understand what the status=+H does, and I was hoping to use it to confine
all requests to services requiring stateful sessions to the tomcat instance
on tccontainer2 unless it is offline.
>
> What I was trying to explain is that it would appear (by using mod status
to inspect requests sent to each balance member) that applying status=+H to
the balance member of one Proxy balancer, makes it apply to both, since the
address:port of the balance members are identical between the two
balancers. I did not expect this behaviour and was looking for advice to
accomplish the goal of load balancing the stateless requests across both
containers and confining the stateful requests to one in a highly available
way.
>
> Does that make more sense?
>
Not really, the proxy's have no dependencies of each other. Change the load
factor in the second one from 1 to 2, thats the only reason i can think of
that one not being used. Or try different lbmethod.
>
> On Tue, Apr 2, 2013 at 4:06 PM, Igor Cicimov <ic...@gmail.com> wrote:
>>
>>
>> On 03/04/2013 2:02 AM, "Sean Alderman" <sa...@udayton.edu> wrote:
>> >
>> > Greetings,
>> > I am running httpd 2.2.23.0-64 with mod_proxy to load balance Tomcat
6.0.36.B containers. I have encountered a somewhat strange situation, and
I was wondering if anyone could comment and or propose an alternative.
>> >
>> > I have a case where my tomcat containers have multiple webservice
applications deployed. Most of the deployments are stateless, but a few of
them require session stickiness at the proxy layer. I am looking for ways
to better distribute the workload of the stateless webservice calls, with
the hope of not having to create a new tomcat container separate stateful
and stateless sessions. The following configuration was tested, but had
unexpected results...
>> >
>> > <Proxy balancer://webservices-sticky>
>> > BalancerMember ajp://tccontainer2.test.udayton.edu:12002route=webservices2-sticky
>> > BalancerMember ajp://tccontainer1.test.udayton.edu:12002route=webservices1-sticky status=+H
>> > ProxySet lbmethod=byrequests
>> > ProxySet stickysession=JSESSIONID
>> > </Proxy>
>> >
>> > <Proxy balancer://webservices>
>> > BalancerMember ajp://tccontainer1.test.udayton.edu:12002loadfactor=1 route=webservices1
>> > BalancerMember ajp://tccontainer2.test.udayton.edu:12002loadfactor=2 route=webservices2
>> > ProxySet lbmethod=byrequests
>> > </Proxy>
>> >
>> > What I find is that balancer://webservices never sends any requests to
ajp://tccontainer1.test.udayton.edu:12002.
>>
>> Thats because it never gets used, the requests are always being served
by the first proxy. Why do you have 2 of them?
>>
>> It would appear that the status=+H applies to the BalancerMember object
instead of balancer://webservices-sticky.
>>
>> Correct, it means that that balancer member is hot standby as explained
in the documentation.
>
>
Re: [users@httpd] mod proxy balancer problem/question...
Posted by Sean Alderman <sa...@udayton.edu>.
Perhaps I've not explained correctly, I apologize. The concept I was going
for was to have two independent balancers that point to the same tomcat
instances.
In the webservices virtual host I would have a configuration like so:
ProxyPass /service-sticky/ balancer://webservices-sticky/service-sticky/
ProxyPassReverse /service-sticky/
balancer://webservice-sticky/service-sticky/
ProxyPass /service-stateless/ balancer://webservices/service-stateless/
ProxyPassReverse /service-stateless/
balancer://webservices/service-stateless/
In my config, both of the quoted Proxy balancer directives exist and are
referenced by a virtual host for different endpoints. I absolutely
understand what the status=+H does, and I was hoping to use it to confine
all requests to services requiring stateful sessions to the tomcat instance
on tccontainer2 unless it is offline.
What I was trying to explain is that it would appear (by using mod status
to inspect requests sent to each balance member) that applying status=+H to
the balance member of one Proxy balancer, makes it apply to both, since the
address:port of the balance members are identical between the two
balancers. I did not expect this behaviour and was looking for advice to
accomplish the goal of load balancing the stateless requests across both
containers and confining the stateful requests to one in a highly available
way.
Does that make more sense?
On Tue, Apr 2, 2013 at 4:06 PM, Igor Cicimov <ic...@gmail.com> wrote:
>
> On 03/04/2013 2:02 AM, "Sean Alderman" <sa...@udayton.edu> wrote:
> >
> > Greetings,
> > I am running httpd 2.2.23.0-64 with mod_proxy to load balance Tomcat
> 6.0.36.B containers. I have encountered a somewhat strange situation, and
> I was wondering if anyone could comment and or propose an alternative.
> >
> > I have a case where my tomcat containers have multiple webservice
> applications deployed. Most of the deployments are stateless, but a few of
> them require session stickiness at the proxy layer. I am looking for ways
> to better distribute the workload of the stateless webservice calls, with
> the hope of not having to create a new tomcat container separate stateful
> and stateless sessions. The following configuration was tested, but had
> unexpected results...
> >
> > <Proxy balancer://webservices-sticky>
> > BalancerMember ajp://tccontainer2.test.udayton.edu:12002route=webservices2-sticky
> > BalancerMember ajp://tccontainer1.test.udayton.edu:12002route=webservices1-sticky status=+H
> > ProxySet lbmethod=byrequests
> > ProxySet stickysession=JSESSIONID
> > </Proxy>
> >
> > <Proxy balancer://webservices>
> > BalancerMember ajp://tccontainer1.test.udayton.edu:12002loadfactor=1 route=webservices1
> > BalancerMember ajp://tccontainer2.test.udayton.edu:12002loadfactor=2 route=webservices2
> > ProxySet lbmethod=byrequests
> > </Proxy>
> >
> > What I find is that balancer://webservices never sends any requests to
> ajp://tccontainer1.test.udayton.edu:12002.
>
> Thats because it never gets used, the requests are always being served by
> the first proxy. Why do you have 2 of them?
>
> It would appear that the status=+H applies to the BalancerMember object
> instead of balancer://webservices-sticky.
>
> Correct, it means that that balancer member is hot standby as explained in
> the documentation.
>
>
Re: [users@httpd] mod proxy balancer problem/question...
Posted by Igor Cicimov <ic...@gmail.com>.
On 03/04/2013 2:02 AM, "Sean Alderman" <sa...@udayton.edu> wrote:
>
> Greetings,
> I am running httpd 2.2.23.0-64 with mod_proxy to load balance Tomcat
6.0.36.B containers. I have encountered a somewhat strange situation, and
I was wondering if anyone could comment and or propose an alternative.
>
> I have a case where my tomcat containers have multiple webservice
applications deployed. Most of the deployments are stateless, but a few of
them require session stickiness at the proxy layer. I am looking for ways
to better distribute the workload of the stateless webservice calls, with
the hope of not having to create a new tomcat container separate stateful
and stateless sessions. The following configuration was tested, but had
unexpected results...
>
> <Proxy balancer://webservices-sticky>
> BalancerMember ajp://tccontainer2.test.udayton.edu:12002route=webservices2-sticky
> BalancerMember ajp://tccontainer1.test.udayton.edu:12002route=webservices1-sticky status=+H
> ProxySet lbmethod=byrequests
> ProxySet stickysession=JSESSIONID
> </Proxy>
>
> <Proxy balancer://webservices>
> BalancerMember ajp://tccontainer1.test.udayton.edu:12002 loadfactor=1
route=webservices1
> BalancerMember ajp://tccontainer2.test.udayton.edu:12002 loadfactor=2
route=webservices2
> ProxySet lbmethod=byrequests
> </Proxy>
>
> What I find is that balancer://webservices never sends any requests to
ajp://tccontainer1.test.udayton.edu:12002.
Thats because it never gets used, the requests are always being served by
the first proxy. Why do you have 2 of them?
It would appear that the status=+H applies to the BalancerMember object
instead of balancer://webservices-sticky.
Correct, it means that that balancer member is hot standby as explained in
the documentation.