I've turned my hand to a bit of Infrastructure Architecture and lending a hand working out what physical servers would make good candidates for making the transition to virtual.
IBM, HP and DELL, to name afew, all offer services to work out what would make good candidates for you. There is also tools that can also help such as the popular PlateSpin's PowerRecon but to be fair these methods only really give potential technical candidates, that’s half the story! What about the business perspective?
You are also going to want to continually select candidates after big migration project has finished, hopefully this post will give you afew hints in helping write a strategy.
The first task is lay down some simple rules of thumb to communicate to other so you are all on the same 'hymn sheet'.
A Physical Server would be considered for Virtualisation Candidacy if,
1) No specialist hardware – Virtual Machines are designed so that they can run from any physical server in the VMware Farm, placing a physical restriction on a specific server will greatly limit this flexibility, in addition, there is a limitation on the range of devices that VMware supports.
2) No licensing Constraints – Not all software vendors support their software to run under virtualisation, this is now going to need to a question you ask in the initial engagement process because it has the potential to change the implementation cost and size of effort.
3) Platform compatibility – VMware is designed to run on x86/x64 architecture so software design to run under Mac, IBM Z and P Series architecture, for example, will be incompatible, so do your homework.
4) Not already using a different type of virtualisation – i.e. Citrix
5) Isn’t complex – Some servers could form part of a complex system configuration. It would be worth assessing whether to concentrate time and effort vitalising as the best use of resource, or alternatively reducing the priority of these cases so an attempt is made after more servers have been virtualised increasing the experience level and reducing the risk of potential impact on prior virtualisation projects.
6) Not a Database Server - Applications with an Oracle or SQL Server database layer can be segregated and consolidated on Database service infrastructure rather than VMware. Also many vendors do not support production instances of their database products under virtualised environments.
7) Prioritise the order of virtualisation in order of least criticality to the business.
Know Performance Constraints
A system is only as fast as its slowest part so it would be wise to understand the physical constraints of the physical servers that will host VMware and it's virtual servers will reside because the amount of available resource of these physical servers is finite.
The Key Performance Constraints to get to know are,
- LAN - understand the speed of the NIC in the back of the physical servers and the speed of the network and what the job of that network. Also get to know the LAN, what's it peak times? It's configuration? (VLANs? QoS? Spanning Tree?) Also the number of NIC is important as you will need at least 4 for VMware especially if you are running VMotion but that's another topic.
- SAN - Storage Attached Network is common. It is a science to work out and average IOPS because of the different sizes of cache (usually measured in GB) and their successful hit-rate preventing a slow read to disk and also a slow write as many virtual's arrays these today can store data and write it back during idle cycles. Wouldn't it be nice if more developers would make their programs more SAN cache friendly.
- RAM - amount of it and speed.
- Level 2 Cache - The size of '2 cache prevents slower trips off to the RAM
- CPU - speed, number of cores and configuration which has to all be the same accross all your VMware hosts servers if you want VMotion to work.
Typically there is a lot of servers out in the typical data centre and it's not possible to profile them all, it is worth performing a initial round of statistics gathering to workout the easy wins, the ones to ignore or the ones that will need further more detailed testing to determine the best option. The table below is static's that can be gathered from MOM/WMI and PlateSpin PowerRecon that will help you determine technical candidacy.
Number of cores
|% utilisation over test period |
|% utilisation over test period |
Average Disk Throughput
Peak Disk Throughput
|number over test period |
Average Network Throughput
Peak Network Throughput
One of the key measurements of success in business terms is no detection of change to the quality of service they enjoyed with a dedicated server. Key to understanding this is to understand when applications that reside on a server are used the most.
With technologies such as VMotion virtual machines can be moved from one data-centre to another without outage giving business a higher level of availability than they may not have ordinarily enjoyed.
Correlating technical candidacy with business important and SLA will give you the best idea of what will make the ideal candidate as it's worth doing the least resource hunger, least important business applications as priority keeping the risk down. Attempting more critical and important systems is better attempted after getting some experience and working our the gremlins in the physical to virtual processes.
Virtualisation is one of the hot topics and it's high time we all started getting our heads around it as pretty soon most of the systems we use, write and implement will be to a virtual server rather than a physical one.