Virtualization
Overview
This document describes the rational, possible design, and possible problems of a move to a virtualized infrastructure.
Progress
Updates on tests and experimental implementations of a virtualized infrastructure at BBOP can be found here: Virtualization_progress
Rational
In addition to the general advantages of virtualization in a computing infrastructure, there are potentially several advantages specific or especially important to the GO.
Consistency of Development Platform
AmiGO is currently developed on This
This would also make the
Redundancy and Recovery
Given that no infrastructure is bullet-proof, the ability to take a running image and move it to a different machine or facility with minimal downtime is a great feature. This is also nice in the sense that
Cloud Computing (buzzword!)
Given a proper choice of platform,
While no concrete plans to use this feature currently exist
GO Software Distribution
Similar to the idea of the experimental GO software ISO images, VM images are potentially a way to distribute GO software .
Also, with it's larger size, it would be possible to make
Speed to Production
A bonus to having this as a software distribution method is that it could be used internally to speed the release cycle of server-based GO software (e.g. AmiGO). A small set of internal changes could change a development image into a production image, which could be immediately deployed. If a new production image was problematic, it could be immediately switched with an older one, causing minimal disruption to users.
Platforms
In addition to the software mentioned below (what we currently believe to be the best solution for what we want), we have tried: Open Nebula, libvirt, XenServer, CentOS, Debian, and openSUSE.
Below is a brief discussion of
Ubuntu/Debian
Currently, the preferred platform for development on AmiGO is Ubuntu 10.04 (two paragraphs of reasons cut out here). In particular, Ubuntu is tightly tied to
In addition to being the
Also Tried
Eucalyptus
This is the
While there are some annoying hooks (i.e. Canonical's paid Landscape service), it seems to be more community driven and open than the Citrix equivalent.
and it seems to pretty well done
Open Nebula
Also Tried
Amazon API
KVM
KVM seems to be better supported by the Linux kernel and is the preferred Anecdotally, it also seems to be the preferred
???
Cons
While the cons list would seems to be fairly minimal with virtualization, there are several points which need to be considered.
Initial infrastructure cost
While most newer machines support virtualization in the hardware (necessary to get to make virtualization worthwhile), it is not worthwhile on older hardware or, given KVM's current connection to x86 architectures, non-x86 systems.
In addition, moving large images around can me a slow and time-consuming process. Either patience or switching to faster networking hardware (where not already in place) would be necessary to get all of the benefits.
Both of these issues are at least partially addressed by the fact that new infrastructure rollout is necessary anyways as machines are replaced in the normal course of things. If a virtualization infrastructure is planned and rolled out over time, additional cost could be minimal.
Increased complexity
Even though virtualization gives better management and resource allocation at a high level, the fact is that there is at least one additional layer between software and hardware, and management and resource allocation at a low level becomes much more complicated, albeit largely hidden from the administrator.
This can make troubleshooting of some kinds of problems more difficult and increases the number of ways that things can go wrong (also connected to para-virtualization versus full-virtualization).
Some of this is inevitable--computing has always gotten more complex over time as higher-level abstractions are created over old ones. The increased flexibility presented by virtualization will hopefully pay for the increased complexity and problems associated with it.
Inexperience
Related to the above, as with any new way of doing things, there is going to be a learning period where the solutions to new problems are slow and non-optimal. Hopefully, by using a well-supported software infrastructure with a large community around it, this will be kept to a minimum.
Monoculture
- Put all your eggs in the one basket and--WATCH THAT BASKET.
- — Pudd'nhead Wilson's Calendar
Currently, AmiGO is developed on one platform, put into production on two others, with software developed for on a fairly wide variety. Just the act of having AmiGO function in all of these different places helps maintain a clean architecture and good coding practices (e.g. bugs that are not apparent on one platform cause crashes on another). To some extent, it becomes tradeoff between robustness and time to develop and get into production. Given resource limitations, favoring the latter is probably the best at this time.
On a more paranoid angle, monoculture also increases the risk of a bug or security hole on one instance being trivially exploitable on all instances. I'm unaware of any specific attack against AmiGO/GO software, (only general attacks again, say, LBL), but the potential is there.