Wednesday, 27 May 2009
Siloed DRS Clusters - Would you, do you or will you have to?
Getting push back when wanting to Virtualise applications which are still under licensing policies that go back to the dark ages is definitely a kick in the teeth to anyone waxing lyrical about Virtualisation, also its very hard for someone who believes in the excellent benefits of cutting edge technology such as VMware that an ISV could be so backwards and cruel. The most common barrier with the licensing model you experience is you can't virtualise something due to the fact you have to license all Physical CPUs and sometimes even the Cores on 32 hosts in your DRS Cluster just to run it on a single VM instance, the cost just makes it impractical and I think any VM Lover would see sense (after punching a wall) in this.
One option to get around this is you could Silo DRS Clusters or segregate ESX hosts, This has its plus and minuses, some things I can think of are;
Implementing Silo'd clusters allows you to sensibly afford the licenses to cover for the workloads in a virtual environment that are subject to the ludicrous rules, it allows you to virtualise across say 2-3 Hosts and still reap benefits of dynamic load balancing and high availability with Vmotion but within a smaller cluster.
Indirectly this may also work well for supporting the higher end more expensively licensed database technology (hey i'm generalising here) that are subject to different SLA coverage, you may for example only want to license the underlying hosts for additional technology such as for DR purposes with VMware SRM which is licensed per CPU, you may not necessarily want to license hosts for SRM that have non critical tier 3 VM's running but have coverage for tier 1 apps.
Silo'ing clusters is going to be a pain in the arse for architects and designers to plan the Virtual landscape for large scale environments and also to plan for the DR of this. Technology wise this option limits you to embrace and achieve what VMware is designed to do of sweating your underlying Tin and Infrastructure assets.
Silo'ing doesn't allow you to make use of resource and scale out as much across the hosts in a DRS cluster to facilitate the smaller app workloads and to slot into the gaps that are available when you have larger apps running within a Cluster. On the operational side this creates more day to day management overhead within the virtual environment and management console, it also means you have more things that can go wrong in your environment and more change control considerations going forward.
I'm sure its evident that Siloing clusters is probably more hassle than its worth to acheive virtualising your un-license virtualisation freindly applications, carefull investigation is needed to ensure that the business case stacks up and you will gain benefits cost wise to virtualising your workloads. A saving grace for Virtualisation adopters is that VMware makes this possible, it allows you to design and build your environment in ways to facilitate this.
Another thing to also consider when it comes to licenses is the latest ESX licensing changes with the introduction of dare I say it vSphere Enterprise Plus. ESX Licensing across the complete ESX Landscape may mean we silo ESX versions to economically make use in datacentres of extended features such as Powerpath VE. In other areas of the datacenter this is done at application level with products such as SQL, it is not economical to put a low end 5GB DB on a Enterprise cluster so Standard clusters get built to host workloads that do not require the high end functionality.
All of these pointers and thoughts may well be something that Virtualisation peeps will cringe at the thought of doing, it certainly is not something I like as I like shared clusters and making use of my Infrastructure, but the mindset might have to change and it may have to happen due to there being no option or room for negogiation with ISV's to virtualise such workloads at both the Virtual Host and the Application licensing stack where ISV's wont budge to allow us to virtualise on a per vCPU basis.
Subscribe to Posts [Atom]