What we (currently) use virtualization for

November 4, 2010

I've pulled this out of Random's comment on yesterday's entry:

[...] but I stop short of doing everything on virtual machines, which I think you do more of.

Although I may have accidentally left people with a different impression, right now we're actually not using virtualization for very much. We have one virtualization host machine, and on it we currently run only three virtual machines: two Windows images and a small Linux machine that forwards some low-priority email.

The Windows machines are Terminal Services servers; they exist because we have a departmental mandate to provide general access to Windows and the Office suite, so that (for example) non-Windows people have some way of reading Powerpoint presentations. Virtualizing our Windows servers has huge management advantages, especially that we will never have to worry about hardware upgrades (including via hardware failure). We also get some ability to reliably roll the state of the system back if something goes catastrophically wrong, which is reassuring.

(We have two Windows machines because we need to provide access to both Office 2003 and Office 2007.)

The small Linux machine is virtualized because we couldn't be bothered to find and deploy some physical hardware for it (not 'wasting' hardware on such a small machine was less of a consideration than you might think).

I would kind of like to use virtualization for more than just this, but in our environment it's hard to find small unimportant services to virtualize. Our machines tend to be either big, important, or both. Big matters because virtualization, especially cheap virtualization, currently costs you performance and capability. Importance matters because when a service is important, you wind up wanting fault isolation for it, fault isolation that our virtualization environment does not give us.

(Thus, for example, we run two local caching DNS servers for our local users, each on dedicated hardware, despite modern DNS servers not exactly requiring big machines.)


Comments on this page:

From 129.102.5.10 at 2010-11-04 06:44:21:

As far as I can tell, the environment I work in is quite similar in size to yours. We only run a few Xen VMs but we have lots of containers (currently linux-vserver, considering switching to lxc when we find it mature enough).

We have lots of small web sites (for teams, projects, conferences, intranet apps...) and it has proved easier to manage each one in its own container rather than as Apache vhosts on the same server. Mostly, we can tweak the configuration of one server with confidence we won't end up impacting anything else.

We also use containers for almost everything else except big, high-performance servers (a couple of high-traffic web sites) and file servers (because of limitations in linux-vserver, which can't run kernel-mode NFS server). To date we have not had any real problems with this. It just required some tuning, for instance ensuring puppet runs don't start at the same time on all containers.

It has downsides though; we still have a few RHL 7.x-based containers with PHP3 apps that we can't easily upgrade. This is not really related to virtualization, but we don't have to upgrade OSes as old hardware dies anymore. I'm still not sure of the solution to this problem: virtualization allows us to run more services, but I'm not sure we have the manpower to maintain them in the long term.

Written on 04 November 2010.
« One reason that I call us a midsized environment
GNU sort and -k: a gotcha »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Nov 4 00:12:11 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.