Everyday Virtualization

Creating a Virtualization Service Catalog

• By Rick Vanover
• 11/01/2010

All too often, organizations function without a Service Level Agreement (SLA) in the face of stringent expectations. Does this sound familiar? The infrastructure administrator should be one step ahead of those expectations with documented materials. One approach for the collection of virtualization technologies is providing a service catalog that documents what is available and at what level. The service catalog should dispel any myths of the private cloud. How many times have we heard something to the effect that simply because a server is a virtual machine (VM), off-site disaster recovery is built-in? The fact is, virtualization technologies are frequently blurred with cloud technologies.

As a style guide, infrastructure administrators can check out the Storage Networking Industry Association (SNIA) Tiered Services and Classification presentation. While written specifically for storage, this can also be a format guide for all key categories of virtualized infrastructures. With this in mind, virtualization service catalogs should include all areas of virtualized infrastructures in a simple menu format. Here are some categories to consider:

Guest operating systems: This feature outlines which guest OSes are offered in virtual environments. This can help users keep up with new releases as well as unsupported offerings such as Windows 2000, which has fallen off of the Microsoft extended support list.

Data protection solutions: If standard backups are available, workload-protection solutions or full site-recovery solutions can include their respective recovery time objectives and recovery point objectives.

Workload provisioning: There's an entire set of challenges around cost allocation and chargebacks, but the fact is that most organizations don't charge back. A virtualization service catalog should document what types of workloads are available free of infrastructure charges. Many organizations have rules such as "500GB or less is free" in regards to enterprise storage. Virtualization revolves around advance capacity in terms of storage, processor and memory, implying there's always headroom. Effective service catalogs should document that headroom for organic server growth. As an alternative, when a request comes in above this amount, there should be a requirement to purchase infrastructure that will satisfy the request.

Performance objectives: There's nothing more frustrating than trying to troubleshoot a symptom such as a vague report indicating a system is slow. It's also a good idea to spell out disk latency for a LUN (or datastore). If infrastructure administrators provide the performance characteristics up front, there are no surprises later. There may be a revelation when it's found that specific applications are consuming more than the established baseline, and at that point the options are either to move them or add additional resources to mitigate the performance increase. Either way, simply having a baseline number for datastore latency ahead of time is a good idea.

Cost model: While most organizations don't have a formal chargeback process, a cost model for unit costs should be defined. Obvious categories include guest OS licenses, agent software costs for in-guest packages and anything else on a per-OS basis.

Access and security models: All VMs are not created equal, nor are they accessed in the same way. Virtualization tools allow advanced role creation and assignment, but can become complicated. The infrastructure should provide a menu of what access is available and how.

The objective of virtualization service catalogs is to provide infrastructure menus to internal customers. This can look a lot like the SNIA resource -- or it can look like a resource within your own organization that delivers a catalog of services. Above all else, you can't satisfy your customers' expectations if you don't know what the current run rate is.