The UC Santa Cruz http://emergency.ucsc.edu web site is used as a primary information source for near real time information in the case of a campus or regional incident.
The emergency site is based on the Drupal platform and runs under Aegir on an Ubuntu operating system. The hardware running the site is nearly five years old. It has several other Drupal sites running on the same hardware. We manage this server using a combination of shell and Webmin.
The site is configured with a few modules to handle specific functions. An example of this is the use of the FeedAPI module to pull in the Public Information Office emergency RSS feed. In the case of a local incident, the Fire Department staff can update the site and in turn, create additional RSS feeds that can be subscribed back to other web locations. Most of the content on the site is fairly static.
We want to move this site to an off-campus location so that in the event of a network or power outage, the site would remain available to the world. Our basic use case is how to do we provide information to the world in an incident? For our planning purposes, we should think about our experiences in the Loma Prieta earthquake of 1989, or more recently our ATT outage that took out communications to our entire region. We could anticipate a slashdot like effect and should be looking at how to optimize our performance and scale to meet demand.
We've explored the idea of siting this at the UC San Diego data center, but have been slow to get the necessary infrastructure installed. We've begun looking at vendor provided alternatives and associated trade-offs.
There are several approaches we can take. I had seen a recent presentation by Josh Koenig at a Drupal meetup on the Pantheon Mercury efforts and his general experience in the cloud. That got me thinking about what type and level of hosting service we need to be looking for and the associated costs. Basically, our options break down into:
- Dedicated server - We would own the hardware and software and have complete control (and responsibility). The server would be collocated at a vendor facility.
- Managed server - A vendor would manage the operating system and applications installed. We would provide the data and configuration information.
- Shared web server - We would share the resources allocated to a particular server. Many web sites running on a shared infrastructure. We would be abstracted from the system administration and tuning options.
- Virtual private server - In a VPS, you are buying a virtualized server that acts as a dedicated server. You are sharing resources, but running your own copy of an operating system.
- How big do we need to plan for?
- What metrics drive that equation?
- How do we backup?
- How do we handle workflow (dev->prod)?
- How charges for bandwidth or disk utilization differ between vendors.
Vendors in this Space
We need to do some more investigating of the packages offered by a variety of vendors. Here's a few that we'll be looking at in our next phase of work:
- Pantheon Mercury
I'm curious about how Mercury could work for us. We're used to managing the Ubuntu and the packaged Drupal would be a fairly easy and incremental set of work to manage over time. I'm not sure we'd need a lot of technical support, but then again, we might be willing to pay for it for this type of critical service.
If you've got thoughts or comments, leave them here for me to follow up on.
Update - 03082010
This article is pretty interesting background, http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.html.
Update - 092111
We're working with CENIC and Amazon on some special UC reserved instance deals. We've been able to cost out some simple small and large reserved instances into less than $1k/year. If we go this route, I'd be turning off 2 7 year old servers that are not very energy efficient. We'll need to do the calculation on energy efficiency to see what that metric would save in this type of arrangement.