httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <DRugg...@primary.net>
Subject Re: [users@httpd] Struggling with Reverse Proxy Configuration for Server with multiple subdomains
Date Fri, 15 Mar 2013 19:21:20 GMT
On 3/15/2013 10:38 AM, Ryan Merrell wrote:
> 1. I found that once server 1 came back online, it started receiving
> all the requests again. Is there a way to keep that server in an error
> state until I'm ready to have it start serving again? Is this what the
> "retry" value is for? Do I just have to set it to a really high
> number?

I would suggest enabling the balancer manager and then taking the server
that you plan to do maintenance on out out of service. Consider it
"administratively down" until you say otherwise in the balancer manager
(a quick howto is in that presentation and the docs). Note that if you
are on 2.2 and you restart the reverse proxy at this time, the first
server will be put back into service. If you are on 2.4, there is shared
memory persistence as of 2.4.4 that will preserve these balancer manager
changes.

> 2. I also found that once a failover occurs, users are logged out
> because their session doesn't exist on the hot spare. Sessions are
> handled by a cookie with PHPSESSID. I saw that there is a
> "stickysession" option. Will this allow the session to be maintained
> across the two servers? If not, is there a way to do this? (Forgive my
> ignorance on this part, but I'm just a systems guy and
> cookies/sessions is a little beyond my knowledge area).
Not exactly. The sticky cookie to httpd is a cookie that tells it where
to send the request. If you haven't configured a sticky cookie in httpd,
I encourage you to do so (there is a "universal sticky cookie" example
in that presentation. You won't see much of a benefit until you add a
second, live server. The sticky cookie tells httpd which backend served
this users last request.

The reason the user has to log back in is because the session is not on
the second server. To get the session to fail over (prevent
reuathentication/etc) you have to have some sort of session replication
where session state is shared by the two backends. There are a few ways
to do this in PHP. A quick search on the 'tubes for "PHP session
replication" should get you started on the right path.


> 3. To make sure I'm understanding the BalancerMember config
> correctly... "route=1" means to always use this member first, right?
> And "redirect=2" means that if that member is unavailable, to always
> use the member with route=2? And status=+H means to keep this member
> inactive until all other members are in an error state, correct?

Think of the route parameter as an identifier. That identifier comes
into play with the sticky cookie. When a user presents a cookie (let's
say "Sticky=myApp.1") it is parsed to figure out where to send them. In
the example quoted, it means the user would go to the server named "1"
as the route. You are correct otherwise on your statements. If you would
like to have a few servers in grouping "A" and a few other servers in
grouping "B" but only use group B if all the members of A aren't
available, that would be a use case for the lbset parameter.

> 4. Now that I have it working with the above configuration, and
> considering I'm a mod_proxy newbie, are there any other settings I
> should be aware of? Any advice or suggestions you have?

Depending on the settings on your backend, you may want to play with the
min and max parameters for the BalancerMember. A persistent ready to use
connection (so long as the backend keeps it open and firewalls don't
drop it) is going to be a bit faster. If you want persistent connections
and have a firewall between the front and back, the keepalive parameter
will probably be helpful. Otherwise, the sky is the limit. You have app
traffic running through the Swiss Army Knife of the Internet - you can
do almost anything you'd like as it crosses the proxy. There are a few
examples in that presentation of some of the scenarios and use cases
that might be interesting. Deflate would be a good start - it's always
nice to save bandwidth.

--
Daniel Ruggeri


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message