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@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|