Bladewatch.com

One of my favourite conversations was had yesterday with a colleague. He’s a small consultancy 2/3 guys that go around small businesses and help them out with virtualization. Anyway, they’d turned up at this medium sized business, they had 300 servers they wanted to virtualize using VMware. They knew why they were going to do it but didn’t know how to and were committed to spending money on tools, to getting a guy in that could do everything in about 7 minutes with a vmware cd and couldn’t understand why it service providers were asking them questions.

With this conversation in mind, I thought I’d write my quick guide, (please note it was written on the train to London), so I haven’t covered everything.  Related to this are the articles (one and two) that were written in the past – note the process and operations are just as important if not more so than the technical aspect of server virtualization.

• Identify business/technical drivers – what is it you want to achieve – what platforms/server models/applications do you wish to virtualize – not everything is best suited to virtualization just because you can.
• Perform an inventory of what you have, applications, servers, platforms. With this we can then define applications/servers and platforms in scope. For this we’ll take your Windows.
• Define the in scope parameters – THE RULES OF ENGAGEMENT – Are we doing the virtualization per application, one application end to end, or are we simply using it as a box replacement project, anything older than DL380G3 becomes a virtual machine?
• Perform a per application, per server inventory of the systems in scope, what downstream and upstream feeds do we have to migrate/be aware of if we virtualize the machine, related to this if there is an ip address change is it world ending?
• Using the in scope parameters, establish usage patterns and combine with system requirements
  • Do we want to go for maximum virtualization, virtualize as many small servers to a few larger servers, or are we working on the basis of abstracting applications from the underlying hardware?
  • MANAGE THE SALES PITCH – sort out IT first, make sure we’re all playing nicely, happy with the platforms before we speak to ‘customer’s end users about virtualizing their servers.
• Identify the process bits – who owns what, what are the standards for virtualizing? The rollback?
  • Standards – if a server has a 8GB C drive when we virtualize it, do we increase it to make life easier in future? If it’s Windows NT/2000, do we give the application team a new Windows 2003 virtual machine or is it just virtualize and tidy it later?
  • The rollback, firstly can we rollback operationally, and secondly do we support it so to speak, or do we work with the end users to work through the issue and fix it?
  • What virtual features do we support and how does that work in real life – so I want rollback enabled to make changes and then undo them if I don’t like them, who manages it?  If I want an extra GB of RAM what processes are in place, do they pay more for support?
  • Billing – if we’ve got an existing billing metrics how does this work going forward?
  • Lifecycle – how do we define the lifespan of the hypervisor server?
  • Multiple farms – do we want an ESX farm per business? If so what happens when it’s full? What’s the time to live in deploying a new ESX server, if it’s month can a per business line farm work?
• Define how we begin – do we start on development/staging systems first, or back office IT, what benchmarks for success have been set?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.