BlogIT » Virtualisation Tips II: Service Management
Virtualisation Tips II: Service Management
At the introduction of virtualisation in any organisation its impact on service management is often overlooked. Virtualisation is implemented as just another technology. To gain maximum profit from virtualisation changes in the way services are managed are needed. Something, that became clear already in "Virtualisation Tips I". Changes in processes and procedures might even be necessary to remain legally compliant. If cost is the main driver behind virtualisation, the systems management approach is absolutely critical. Not only in processes and procedures, but also in tooling.
Tip II.1: Review the service chain
Hosting is a component in the service chain. If virtualisation encompasses on OS platform and one set of service levels, it is best to leave it that way. However, when several different sets of service levels and multiple OS are involved, not to mention the virtual teams from "Virtualisation Tips I" is is probably best to split this component from the service chain in 2, hosting and virtual hosting.
This helps in a couple of ways:
- It gives mote insight into operational cost and comparison before and after are more clear;
- Clearer picture on how the final service levels are composed;
- Helps in separating the virtual from the physical, the physical part might even be outsourced.
Tip II.2: See virtual and physical as separate
The virtual and physical worlds are interconnected. Full separation is not possible. However, by keeping them separated as much as possible, flexibility increases. If the virtual infrastructure is not dependent on the physical infrastructure at all, than all virtual infrastructures layouts are possible. The complete infrastructure could be remodeled at the push of a button. This might be a good feature at the introduction of a radically new application, company reorganization or a change in business model. It reduces the financial risk in any IT project involved.
If physical and virtual are separated, it also creates more degrees of freedom in outsourcing deals. One might decide to keep management of the virtual infrastructure and outsource the physical (cloud computing by Amazon/Yahoo/Google/etc. provides a lot of bang for the buck), involve two outsourcings partners, or keep even rent out the surplus physical infrastructure to another company.
Tip II.3: Licenses!
Many license models use a per CPU model. But how does that compare to virtual CPUs? Licenses could be bould to a hardware serial number, but those are configurable for virtual machines; thus allowing a second, unpaid, deployment of the same application, without an alarm bell going off. Does the vendor even support deployment of its application on a virtual platform?
The biggest risk here is the deployment of licenses not paid for, in the form of new virtual machines or by adding resources to existing virtual machines. When this happens and more important, if it is discovered, it could result in damages from fines and corporate image.
On the other side, some vendors, you can gain an extra cost advantage. Take RedHat's support contracts for instance. If you deploy Linux on VMware, you pay VMware license and support contract and one support contract for each Linux deployment. If you host Linux on Linux (both RedHat's of course), you only have to pay for one support contract. This could lead to a cost advantage of several thousands of euros per machine per year.
Tip II.4: CMDB
The key to keep II.3 is the Configuration Management Database (CMDB). This database should be adapted to virtualisation. A properly configured database will keep track on which system is running where with which service levels and contracts. The CMDB will report will report any problems with regard to licensing/contracts upon entering or changing information.
Another advantage becomes clear when disaster recovery is needed. If a system breaks, where should be virtual systems be reallocated to? It doesn't do to reallocate a virtual system to a physical system with incompatible service levels. A close relation should exists between disaster recovery tools/procedures and the CMDB
Tip II.5: Tooling is essential, not the Hypervisor
Systems/Service management should be leading when choosing a virtualisation product. True, one Hypervisor gives better performance than the other, but the bult of the cost for any service is not hardware, but rather the management of that hardware. Windows oriented management departments tend to be more comfortable with VMware or XenSources own Xen distribution and Linux/Unix oriented departments like Xen (any) or even things like AIX partitions more. This has a huge influence on the learning curve of the department and the actual functionality they can realize with the product chosen.
An important part of this is the provisioning of new virtual machines. Provisioning of new virtual machines within an hour should be possible. If this was already the case for physical machines, the same tooling could no doubt do the same for virtual ones. If not, new tooling should be introduced (the simplest approach is template based a.k.a. creating one machine and copy it around).
