Continuing on from my previous post on virtualisation, there is another relatively easy, but very effective way of using virtual machines in your organisation. But first, let me ask you a question.
How often have you made a change in your IT environment that either hasn’t been tested properly, or has not gone smoothly despite extensive testing?
I’m sure, like me, you have encountered more that one situation that fits those criteria. After all, IT is a hugely complex subject and you can’t predict everything, right ? Well, actually, I think it is possible, and indeed is becoming easier thanks to virtualisation technology. First of all, though, lets take a slightly closer look at the issue.
The goal of effective testing is, very obviously, to make sure that any changes to your live environment are subjected to sufficient tests before implementation to ensure that, when implemented, the predicted behaviour is actually achieved. Simple, eh? Well actually, it isn’t. There are a number of issues that form a barrier to effective testing. For a start, your test and live environments will always be different. How different will depend on how much investment you make in your test environment, but at the very least there will be data differences.
Now lets consider one of the characteristics of virtual machines, namely the isolation of the operating system from the underlying hardware. 
So instead of needing drivers for a particular make and model of CD-ROM drive, for example, each virtual machine on a physical server will use a standard virtual drive regardless of the physical drive. The story is the same for all the virtual components – CPU, memory, network card, hard drive, etc.
So now, instead of having to ensure there are no hardware differences between your live and test environment, you can go ahead and use pretty much any hardware you like, as long as it can cope with running a single virtual machine.
The other relevant feature of virtualisation technology is the ability to take a snapshot of the virtual machine at any point in time. (Note: this is a feature of VMWare software, and of many other virtualisation solutions. If your software won’t do this then you should probably change it.) So essentially you are taking a complete copy of your live server to do with what you will.
So effective testing is now a much simpler matter. Instead of having to maintain a test environment that stays completely aligned with you live environment, all you have to do now is take a snapshot of the live environment, make the chnages and carry out your testing. If the testing is successful, then you can go ahead and change your live environment with a high degree of confidence that the update will not fail. Indeed, if the live environment has not changed while testing is carried out, then you have the option of replacing the current live virual machine with the updated snapshot.
Don’t forget though, backups are your friend!
April 29, 2007 at 5:17 am
Can I use this for a complete backup strategy?
I work in an environment where our domain controller, SQL Server, and several key applications and services are all running on a single server.
Can I take a snapshot of the server and use that snapshot on a different PC with different hardware incase the motherboard or some other key component gets fried? Does VMware allow different drivers and such?
Ideally, if the main server went down I could simply switch over to this virtual setup and continue as normal with no delay. Right now my strategy would be to repair the part, reinstall the OS, and restore my backups; a process which could take hours at the least.
April 29, 2007 at 7:37 pm
Heath,
A complete backup strategy in itself, I’d have to say “no”. However, it could be a core part of a backup strategy.
Sounds to me like you have a very small number of servers in your organisation (please correct me if I’m wrong). In my experience a lot of smaller companies put their IT eggs in one basket a lot of the time, simply because that it the low cost solution to their needs. The resources to run a number of servers simply aren’t there, and that’s the point at which virtualisation can make a lot of sense.
However, your situation (I presume) is that you have a single server that the whole business runs on, and it anything happens to it the business is down for a few hours whilst the server is repaired or a new one put in place. Will virtualisation work to reduce the turn-around time ? Yes, with one big and pretty obvious proviso. You need to ensure that everything you are currently running on a physical server will work and work effectively in a virtual environment (and there is a suggestion that SQL Server performance will suffer). If that doesn’t pass muster then you are probably better off looking at a different solution.
But lets assume that all your services (domain controller, SQL server, etc) run in a virtual server. So what should your strategy be ? Virtualisation works most effectively in a small/medium business if you can separate the services out as much as possible. Why re-create your current ‘eggs in one basket’ scenario in a virtual environment if you can avoid it ? So if the budget allows for multiple licences of your OS of choice, and for you to chuck some more memory in your existing server, then think about having a virtual domain controller, a virtual SQL server and so on. If nothing else, it makes it easier to move a particular service to it’s own dedicated hardware in future.
Once you have separated the servers out you can then think about snapshots. Something like a domain controller is not going to need snapshotting at the same intervals as SQL server, as the frequency of changes and the effort needed to update from the last backup are much less. So whilst you may want to create a snapshot of your SQL server once a day, you might be happy to snapshot your domain controller once a week.
Unfortunately, the free VMWare Server product has limited automation out of the box. However it is possible to script many functions….this should be a good starting point: http://download3.vmware.com/vmworld/2006/dvt4696.pdf
Getting to the nub of your query (sorry it took so long), restoring the snapshot to another physical server should not cause any problems….as long as the VMWare Server (or your virtualisation software of choice) is up and running then you should be able to move virtual servers around at will. The essence of vistualisation software is that it doesn’t matter what hardware, drivers, etc it is interfacing with, the virtual environment contains a standard set of drivers for network, optical drives, etc.
This is also another reason for separating out the servers, should you have the budget to purchase extra hardware in the future you can move some of the virtual server to the new kit, but leave others running on the old kit.
Hope this has been of use and answered your query? Before you rush headlong into the brave new world of virtualisation, though, I would seriously recommend that you get very familiar with the technology and concepts, and that you set yourself up a small test environment (a standard PC should suffice) where you can try out everything you intend to do. I’m teaching your Grandma to suck eggs, I know, but I’d rather say it than not, just in case
May 2, 2007 at 3:58 am
Thanks
I’m setting up a test environment to virtualize my domain controller and print services. If things go well I’m going to try a virtual applications server as well I think; All of which will be run on two machines with SQL replication.
A few questions though. Is it feasible to virtualize a Terminal Server? When, if at all, will I begin seeing performance degredation ( 10, 20, 50 users)? I had to run a chkdsk on it in the middle of the day once and a lot of users were unable to connect for an hour. I’d imagine this might be handy for that as well.
Best regards,
Heath
May 2, 2007 at 11:01 pm
Heath,
No problem
Re. Terminal Server…have a look at Q15 here http://www.vmware.com/products/server/faqs.html which states that it is a supported application, so you should have no significant problems.
I can’t answer the question about performance degradation as it depends on many factors, including the spec of the physical server, the speed of the network, the number of virtual servers on the physical server, etc. Bear in mind that VMWare Server (i.e. the free product) needs a host OS (if you know Linux then that’s probably your best bet) which can require maintenance in it’s own right. If the host OS is Windows then, of course, plan for reboots at least once a month when patches are released.
Let me know how your testing goes….either on here or in your own blog. It would be goo to know a little more info about your proposed setup too.
Good luck,
Colman