Oh. One more issue I forgot to include. Since the 4 backend servers are "guard"ed to not accept more than MAXCONN connections each, I have to handle the situation where all the servers are full. In this case, I just want to return a quick "all servers busy page". To make this happen, the frontend load balancers will only load balance the first 3 backends. Each backend HAProxy will "first" balance to the localhost server with overflow going to the next backend server. For the 4th backend, HAProxy will return an "all servers busy" status code if unable to serve the request by its localhost server and the frontend NGINX will return the appropriate "servers busy page".
In this setup, I get an early warning that I might need to add more backend servers if the 4th server ever starts serving requests. I can also set MAXCONN for this 4th server to a smaller value and use the 4th server to run other tasks. Also, adding a new server to the backend is simple. Add the new server as the first and reload NGINX load balancers to start balancing to the new server. Same for removing a server due to reduced demand. Always remove from the front. Kevin On Jan 4, 2013, at 9:05 AM, KT Walrus <[email protected]> wrote: > I've had a change in thinking. > > I've decided to not use HAProxy on the frontend load balancers and will go > with NGINX for SSL and simple ip_hash load balancing to the 4 backend servers. > > I've also decided to handle sessionDB selection totally in PHP using a cookie > and to always use the localhost sessionDB with possible copy of session > record from the EC2 active backups of the sessionDBs (if sessionDB is > different). > > I will use HAProxy to "guard" each backend server from going over MAXCONN > connections, running on the backend server. These HAProxy's will use "first" > load balancing to prefer the localhost server over the others. Also, HAProxy > will proxy for the sessionDBs (not load balancing) so that it can use the > active backend sessionDBs in preference to the EC2 active backups. > > This means the HAProxy in each backend will be responsible for letting the > frontend NGINX know to mark the backend as down if any part of the backend > stack fails (nginx, php, local mainDB, or local sessionDB). Of course, NGINX > will also mark the backend down if HAProxy simply doesn't respond at all. > > Any further comments on this? If not, thank you for those that responded > previously to help me get to this point in planning out my system > architecture. The key for me in using HAProxy is the "first" load balancing > algorithm. I haven't read about anyone else using "first" in this manner > (the documentation seems to indicate this is just for elastic cloud operation > to minimize cloud instances). > > Kevin > > On Jan 3, 2013, at 3:55 PM, Kevin Heatwole <[email protected]> wrote: > >> I intend to have a two tiered LB architecture: frontend LBs and "guard" >> backend LBs. >> >> The "guard" backend LBs serve to guarantee that the backend server never has >> more than MAXCONN concurrent requests. Excess request are forwarded to some >> other backend using "first" load balancing. >> >> Since I now plan to use "cookie persistence" in the frontend LBs, I'm >> wondering if I can use the same cookie in the backend "guard" LBs to change >> the cookie to the new backend if the request is forwarded? >> >> That is, should all LBs, whether frontend or guard use the same cookie and >> the same pool of backends (only the "guard" backends would proxy to >> nginx/varnish while the "frontends" would proxy to the "guard" HAProxys)? >> >> Now that I can handle backend server changes occasionally, I want the change >> to stick for all subsequent requests by the user. Even if the server change >> was made by a second level guard HAProxy... >> >> >> >
