Ease of administration.
To a sys admin, those 3 words mean a lot. To a decision maker like a CIO or a CFO (often one and the same) they mean nothing.
It’s rare enough that I find myself working with physical boxes these days. Most everyone is looking for a virtualised service which is cool with me. Over the last 2 weeks I’ve been doing some physical server builds with Windows Server 2008 R2. I know the techniques for a automated installation. I just haven’t had time to deploy them for the few builds I needed to do. Things like Offline Servicing for VM’s and MDT/WDS (upgrade) are in my plans but things had to be prioritised. I’ve just kicked off a reboot of a blade server. By the time that’s finished it’s POST I’ll have made and half drunk a cup of coffee. After working with VM’s almost exclusively for the last 18 months, working with a physical box seems slow. These are fine machines but the setup time required seems slow. Those reboots take forever! VM reboots: well there’s no POST and they reboot extremely quickly.
Let’s compare the process of deploying a VM and a physical box
Deploy a VM
- Deploy a VM.
- Log in and tweak.
- Handover the VM.
Notes on this:
- The free Offline Servicing Tool can allow you to deploy VM’s that already have all the security updates.
- This process can be done by a delegate “end user” using the VMM self servicing web interface.
- The process was probably just an hour or two from end to end.
Deploy a Physical Server
- Create a purchase request for a new server.
- Wait 1-7 days for a PO number.
- Order the server.
- Wait for up to 7 days for the server to be delivered.
- Rack, power and network the server.
- We’ll assume you have all your ducks in a row here: Use MDT 2010 or ConfigMgr to deploy an operating system.
- The OS installs and the task sequence deploys updates (reboots), then applications (reboots), then more updates (reboots) and then makes tweaks (more updates and a reboot).
- You have over the server.
Notes on this:
- Most people don’t automate a server build. Manual installs typically take 1 to 1.5 days.
- There will probably be up to 1 day of a delay for networking.
- The “end user” can’t do self service and must wait for IT, often getting frustrated.
- The entire process will probably take 10.5 to 16.5 days.
Total Hardware Breakdown
Let’s assume the VM scenario used a cluster. If the hardware failure crashed the host then the VM stops running. The cluster moves the VM resource to another host (VMM will choose the most suitable one) and the VM starts up again. Every VM on the cluster has hardware fault tolerance. If the hardware failure was non-critical then you can use Live Migration to move all the VM’s to another host (VMM 2008 R2 maintenance mode) and then power down the host to work on it. There’s no manual intervention at all in keeping things running.
What if you used standalone (un-clustered) hosts. As long as you have an identical server chassis available you can swap the disks and network cables to get back up and running in a matter of minutes.
Unbelievably worst case scenario with un-clustered hosts: you can take the data disks and slap them into another machine and do some manual work to get running again. As long as the processor is from the same manufacturer you’re good to go in a few hours.
If a physical box dies then you can do something similar to that. However, physical boxes tend to vary quite a lot. A farm of virtualisation hosts don’t usually vary too much at all. If a DL380 dies then you can expect to put the disks into a DL160 and have a good result. It might work.
Most companies don’t purchase the “within 4 hours” response contracts. And even if they do, some manufacturers will do their very best to avoid sending anyone out by asking for one diagnostic test after another and endless collections of logs. It could be 1 to 3 days (and some angry phone calls) before an engineer comes out to fix the server. In that time the hosted application has been offline, negatively affecting the business and potentially your customers. If only a physical server was a portable container like a VM – see boot from VHD.
Summary
You’ve heard all those sales lines on virtualisation: carbon footprint, reduced rack space, lower power bills, etc. Now you can see how easier administration can make your life easier but positively impact the business.
My experience has been that when you translate techie-speak into Euros, Dollars, Pounds, Rubles, Yen or Yuan then that get’s the budget owners attention. The CFO will sit up and listen and probably decide in your favour. And if you can explain how these technologies will have real positive impacts on the business then the other decision makers will also have your attention.