Thursday, 21 May 2009
Dynamic hot add features for VM's - Friend or Foe?
With the latest feature sets on offer within vSphere focusing on enabling IT departments to perform dynamic on the fly change to Virtual machine resource, this post is provides a simplified view point on the likely impact and required changes to existing processes in departments today, commentary is also provided on what issues may arise within current change processes and what effect this has on typical financial authorisation processes internally. The main question of the post is;
"How will Hot Add features fit into current IT environments and processes?"
The general consensus and observation across various virtualisation experts on the newly introduced sets of feature is that some view the feature as a god send to operations, some as a mechanism to reduce numbers of people involved in the process to actually implement change outside of conventional outage periods and some at the opposite end see it as potentially even technically being detrimental to performance when hot add occurs, the later certainly stands quite true, when adding more CPU's this increases issues with large amounts of %RDY time if you have a workload or OS which isn't capable of dealing with multi threaded activity.
For operational change management teams I predict we will most certainly see the feature requiring careful planning and adoption control when being introduced into departments that currently already have business processes in place for planned maintenance, and lastly most organizations that also have approval processes for gaining cost approval on components associated with Infrastructure services and upgrades will need to change and control dynamic growth.
The crux is that something that anything current IT departments are looking to buy into that has a charge associated with it is almost certainly going to need a sustainable business case as to why you should purchase it. Any organisation is in the current economic climate most certainly experiencing large amounts of kickback for any future potential investment above and beyond the norm, it maybe a Small business that has been told you need to use VMware server for free rather than buying ESX or a medium business being forced to only use ESXi rather than full blown and get on with managing your hosts on a singular basis all the way through to large corporate enterprises that are being forced to reduce spend on Vmware features such as the topic of this post Hot Add.
It is definitely a dead cert that Hot Add resource will save time and money in the small and medium sized operational environments, it avoids spending money planning out of hours coverage as changes if approved are technical possible during the day, the size of the business and maturity level of Infrastructure usually means that the department has to be quite reactive when it comes to reported issues with performance. This flexibility may not be the case in larger enterprises, most larger organisations have a defined business process implemented that has a change control process enforced to ensure that large outages across the Infrastructure landscape are mitigated and also ensure that any proposed changes are regressable within decent time frames if or when that change goes wrong. Change and approval processes are also in place within organizations for things such as service improvement plans, a technical design authority within a company will approve a larger upgrade such as increase of RAM to a host or multiple CPU upgrades due to the overall effect on the larger picture i.e. your Virtualisation farm and general Infrastructure.
"How will Hot Add features fit into current IT environments and processes?"
The general consensus and observation across various virtualisation experts on the newly introduced sets of feature is that some view the feature as a god send to operations, some as a mechanism to reduce numbers of people involved in the process to actually implement change outside of conventional outage periods and some at the opposite end see it as potentially even technically being detrimental to performance when hot add occurs, the later certainly stands quite true, when adding more CPU's this increases issues with large amounts of %RDY time if you have a workload or OS which isn't capable of dealing with multi threaded activity.
For operational change management teams I predict we will most certainly see the feature requiring careful planning and adoption control when being introduced into departments that currently already have business processes in place for planned maintenance, and lastly most organizations that also have approval processes for gaining cost approval on components associated with Infrastructure services and upgrades will need to change and control dynamic growth.
The crux is that something that anything current IT departments are looking to buy into that has a charge associated with it is almost certainly going to need a sustainable business case as to why you should purchase it. Any organisation is in the current economic climate most certainly experiencing large amounts of kickback for any future potential investment above and beyond the norm, it maybe a Small business that has been told you need to use VMware server for free rather than buying ESX or a medium business being forced to only use ESXi rather than full blown and get on with managing your hosts on a singular basis all the way through to large corporate enterprises that are being forced to reduce spend on Vmware features such as the topic of this post Hot Add.
It is definitely a dead cert that Hot Add resource will save time and money in the small and medium sized operational environments, it avoids spending money planning out of hours coverage as changes if approved are technical possible during the day, the size of the business and maturity level of Infrastructure usually means that the department has to be quite reactive when it comes to reported issues with performance. This flexibility may not be the case in larger enterprises, most larger organisations have a defined business process implemented that has a change control process enforced to ensure that large outages across the Infrastructure landscape are mitigated and also ensure that any proposed changes are regressable within decent time frames if or when that change goes wrong. Change and approval processes are also in place within organizations for things such as service improvement plans, a technical design authority within a company will approve a larger upgrade such as increase of RAM to a host or multiple CPU upgrades due to the overall effect on the larger picture i.e. your Virtualisation farm and general Infrastructure.
Vmotion remember that?
In comparison when you look at how a technology such as Vmotion works today, this has certainly made organisational process required to plan for maintenance and upgrade tasks to physical hosts a hell of a lot faster and hot add is no doubt going to be very similar, the premise being that you are enabling IT Operations in large amounts of organisations the opportunity to be able to mitigate and perform maintenance tasks that they would not usually perform on VM's unless pre agreed outages are approved by CAB that allows them to shutdown the VM and add resource. As with most things however their are some possible barriers which may not mean hot add is a possibility, the risk and caveat associated that I can see causing stumbling blocks in organisations are as follows;
Hot Removal
I've investigated the support of hot removal and it doesn't exist as a supported function in Windows versions (only hot add/replace), vSphere may support hot removal at Virtual Hardware level but the important factor is at the operating system layer the OS doesn’t, this may shoot you in the foot when quoting that hot add/remove can be performed at any point in time without disruption, remember CAB's like a regression path (lack of this is quite a good excuse most times for them to defer a change) say you experience more problem than before and can't remove a CPU or RAM unless you turn the service off and you are walking a dodgy tightrope. Also reducing CPU's from VM's is NOT a cleancut 1-2 process, it needs HAL changes. (which I believe on Windows 2003 is not supported in full)
Cost approval and control
RAM and CPU is not free, yes we all know that virtualising workloads provides additional HW resource to use the underutilized hardware resources more efficiently, but each Megabyte of RAM in your hosts still costs money, this starts by you needing to ensure that lower level Virtual admins do not have access to add RAM at the click of a button the minute that a support call gets raised from someone experiencing poor application performance. This is where implementing a full vCenter delegation model is very important.
Within organisations that are currently recharging per VM and recharging back on the actual VM size this is quite important as there is scope to use more underlying resource for the same money if a corner is cut, increase the amount of RAM/CPU constantly and this cost model goes out the window and so do your bottom line figures.
The alternative model of using a Chargeback model for VM’s certainly works more in tandem with hot add, a billing mechanism ensures that if a business unit or a developer requests more RAM it will end up on a PO for approval. If using also VMware FT, this volume of RAM increase needs to double! (FT dosnt support more than one vCPU). For Chargeback enablement in your organization look out for vCenter Chargeback which provides this functionality within the vCenter console http://www.vmware.com/products/vcenter-chargeback/
Summary
Ultimately to avoid any possible issues and arguments in CAB, the key is to ensure you rightsize your Virtual Machines and match the workload correctly in the first place. Hot Add of resource for OS’s supported running in VM’s really is a great thing, it is enabling x86 Workloads to act almost non stop mainframe style which means you have very little experienced downtime for apps and services, this is exactly what you get when you use Mainframe systems and the associated benefits of non stop. This strategy of dynamic growth enables VMware to acheive the goal of turning x86 into the new mainframe, this will undoubtedly play even a small role in adding huge amount of functionality improvements and value add within your organization so make sure you embrace it but make sure it dosnt get out of control.
Summary
Ultimately to avoid any possible issues and arguments in CAB, the key is to ensure you rightsize your Virtual Machines and match the workload correctly in the first place. Hot Add of resource for OS’s supported running in VM’s really is a great thing, it is enabling x86 Workloads to act almost non stop mainframe style which means you have very little experienced downtime for apps and services, this is exactly what you get when you use Mainframe systems and the associated benefits of non stop. This strategy of dynamic growth enables VMware to acheive the goal of turning x86 into the new mainframe, this will undoubtedly play even a small role in adding huge amount of functionality improvements and value add within your organization so make sure you embrace it but make sure it dosnt get out of control.
Subscribe to Posts [Atom]
Post a Comment