Unabashed Virtual Server Lovefest
I really, really like Virtual Server 2005 R2. It has made a noticeable difference in the overall capability and disaster-preparedness of our shop, and it moves me toward that happy place where infrastructure doesn’t matter.
We’ve created five images to run specific servers for narrowly defined tasks such as: internal applications the development team uses, CC.NET builds, a customer beta installation of our application suite, system integration jobs we maintain, and debugging deployments of web services that we reference from our presentation layer apps, etc.
The backup story is simple; each image defines a backup “point” that the main server harvests and pushes to a storage location on our network then it’s archived and processes with other backup artifacts. For lazy backup we can just copy the image (though this isn’t the most efficient). I have been considering a hybrid model whereby we capture the whole server image periodically in addition to backing up the content — database, code, app config — which we already do. Because we have such small, narrowly defined servers some of the images really don’t have content that changes very often, so an image backup would make sense; they’re just there to run the application for various audiences or have minimal configuration information (ccnet.config).
I won’t lie: it takes a bit of hardware to run this kind of setup… you need some of the heavier metal, for sure. We’re running on a Dell PowerEdge w/ 8G of memory, 2 Dual Core XEON, loaded redundancies, NBD support, etc. It wasn’t crazy-expensive but it wasn’t cheap either. You could probably do fine with one of the many clone-type AMD boxes and a DIY mentality to IT support or an internal IT support capability that’s ready and willing. So you need one box with a bunch of memory and probably a hot-spare or, at very least, a machine that could run your critical images in the event of a device failure.
What’s cool is that it gives us the flexibility to quickly add a new server. We could, say, prototype a very targeted demo installation for a client/prospect in a minimum amount of time. Creating a baseline image for pilot projects, proofs-of-concept, and pre-sales is one of the big use cases we envision. We can research and experiment with various beta products that we don’t necessarily have the extra machines for. Another awesome thing would be to use FinalBuilder (which we use to make build and deployment scripts) to start/stop/resent/control images on the fly. A road we’ll go down to test our installation process and to run functional / regression test suites inside ephemeral Vista/XP baseline images.
All sorts of options…
Sure you could do it on one or a few servers, but I’ll guarantee they develop hairball problems that will ultimately take you away from more abstract and valuable pursuits. Sure you could buy a separate server or scrounge old workstations for more purposeful servers, but isn’t it just easier to maintain one machine with a hot-spare?
DotNetKicks.com wrote:
Virtual Server in the Development Shop…
You’ve been kicked (a good thing) - Trackback from DotNetKicks.com…
Posted on 11-Jan-07 at 9:50 am | Permalink
GC wrote:
I have a question about Virtual Server 2005. Does it see your 2 dual-core Xeons as 2 processors or four? Can you allocate 1/2 of your total CPU time to a virtual machine, or just 1/4?
Posted on 28-Mar-07 at 8:40 pm | Permalink
Dave wrote:
I’m not an expert on the product, but Virtual Server itself knows the difference between a physical and logical (core) processors. You can see this on the “Physical Computer Properties” screen.
You can configure each instance to use up to (a max) of 100% of one physical CPU. There is no processor affinity. That is, VS will pool across all processors as it sees fit. This makes a lot of sense as there’s no guarantees about what else is running on the host computer.
It’d be nice to have a “Virtual Windows Server” SKU that’s sole purpose in life was being a Host OS.
Posted on 29-Mar-07 at 8:32 am | Permalink