The Cult of Gary

It’s been a while since I’ve assessed new load balancers. At my previous gig, we had used LVS successfully for 5 years. It worked great, but was a bit of a configuration nightmare. I think I went through 2 or 3 different frameworks to handle configuration and backend server monitoring.

I’ve just reached the load balancing part of my current project. LVS is a no go for EC2, since you need to be in the kernel and it depends on various natting and forwarding tricks to make it work. So I started my research and looked at a few different options.

I’m currently focusing on Nginx (pronounced Engine X). It’s a light weight web server that has some load balancing functionality built in. I haven’t had it in production, of course, but I really like the features and performance so far.

It handles spoon feeding slow clients. Nginx is a proxying load balancer. It buffers the transfer to the requester, which means the heavy weight apache processes can move on to the next request while nginx sends the data at the clients pace. This is something that LVS can’t do, since it’s a layer 4 app.

Since it’s proxying, nginx can manage backend servers going down. If nginx can’t talk to one backend server, it will move on to the next one. That’s neat, but it also means I don’t need to run another app to pull dead servers out of the load balancing pool.

Having the wrong IP in the logs is the only thing that sucks. The way around this is to use the X-Forwarded-For headers and tweaking your apps to read this instead of REMOTE_ADDR. And of course, if you care about the original X-Forwarded-For header (ie, AOL’s proxy), then you’ll need to mod the nginx config to pass this in a different header.