The Reliability Sweet Spot for Low-Traffic Applications 0

During development, Rails deployment is simple—at least, once you have the development or staging server and your Capistrano scripts all configured. I have been using a single RailsMachine VPS served as the production server for two apps and the staging server for two others.

Before taking the medical site live, I wanted to have a more robust infrastructure in place, including separate staging and production servers. Even though the traffic level for this site will be very low by consumer site standards, it needs to have high uptime.

High Availability, High Complexity

Ideally, I’d have it running on a fully redundant cluster, with multiple front-end web and application servers and a clustered database server. This is a big investment, however, and is hard to justify for a small user base. The entry level for this kind of solution seems to be something like two “slices” from EngineYard, for about $600 a month (and really you need to add another $300/month so you have a slice for staging).

I considered implementing dual VPS servers, with DRBD and Heartbeat (two open-source high-availability software packages for Linux), so there would always be a hot backup ready in case the main server had a problem. At our current small scale, however, I concluded that this added too much complexity and not enough benefit.

The Simple Path to Increased Reliability

Instead, I’m taking a path recommended by Bradley Taylor at RailsMachine:

  • Put each major application on its own VPS, so it isn’t affected by side effects from other applications.
  • Use automated monitoring so I’ll know if memory usage starts creeping up, or a process dies, and can take immediate (and generally automated) action.

The “Resource Pool” Pricing Model

RailsMachine’s unusual pricing model is a good fit for this multiple-VPS approach. You pay for the resource pool you need: RAM, disk space, and bandwidth. The entry level is 256M RAM, 10G disk, and 100 GBytes/month, for $75/month. You can step up to 1G RAM and 25G disk for $200/month total; for another $50/month, you can have 2G RAM. (The RAM seems expensive, relative to RAM chip prices, because it is really being used as the proxy for the fraction of the machine you’re getting.)

You can then spread that resource pool among multiple servers for a small increase in cost. For another $10/month, you can spread your resource pool across two or three servers. If you get a bigger pool, you can spread it across up to 5 servers for $25/month extra or 10 servers for $50/month extra. So you could have 10 separate virtual servers, each with enough resources to run an app with a handful of mongrels, for around $350/month total.

Three Servers and Counting

We’re now running on three VPS servers at RailsMachine: one for staging (with multiple applications), one for our medical practice application, and another for this blog and some other small applications. The virtual servers are on different physical machines, so there’s some redundancy. I can, if necessary, press the staging server into duty as an emergency replacement for the production server.

So far, it seems like a good arrangement. Have you tried anything similar? Or something superior? I’ll be following this piece with a series of “lessons learned”. If you have some to share as well, please add a comment.

Comment



If you're reading this message, your browser is not interpreting the CSS file properly, and your comment may not be posted.