Enforcing Virtualization SLAs: What to Expect

Enforcing Virtualization SLAs: What to Expect
By William Van Winkle December 20, 2011 12:04 PM
Table Of Contents
  • 1. Minimizing Down Time
1. Minimizing Down Time

Uninterrupted service and minimum-to-zero down times are two related, critical goals in virtualization services. Key to the commitment and success of these goals are properly-crafted Service Level Agreements (SLAs).

SLAs establish measures of reliability as well as reference points for objectively evaluating service effectiveness and resolving potential conflicts should they arise. They establish criteria for uptime, availability, and performance, and they can include specific requirements for installation lead times, technology, billing disputes, account management, or all of the above. Newer agreements have even parsed individual, performance-based contracts for factors such as throughput time and mean time response.

“Virtualization has fundamentally changed the typical IT SLA,” says Rick Vanover, product strategy specialist for Veeam Software and 2011 VMware vExpert. “The area where we see the most impact is business continuity and data protection. Too many times, writing a one-size-fits-all SLA is short of the real capabilities of the IT infrastructure or missing out on what’s really important: our mission critical applications. Today, however, we can craft SLAs to protect at virtually any level.”

The ability to enforce these SLAs later can have a lot to do with the clarity of the language upon which they are first built. Much of what the agreements detail establishes responsibilities for both parties. In addition to outlining important service and management elements, SLAs help establish guidelines during the initial steps of development. Testing these SLAs against flaws helps insure a more precise document, as well as a set of criteria both parties must live up to.

The key component addressed by SLAs is service availability—or perhaps more aptly unavailability, as this relates to maintenance issues; planned, unplanned  and emergencies. Customer responsibilities meant to protect the vendor are also included and itemized, from specific duties in performing system administration to agreeing to use only licensed software on a virtual server. The vendor will also likely mandate network bandwidth parameters meant to discourage excessive bandwidth usage.

Security can be something of a shared responsibility, with hosts pledging to maintain the physical security of servers and report virtual intrusion detection. Meanwhile, the customer might be required to manage firewalls and apply security patches. Security requires attention to a different set of details that might have an adverse effect on a wider base of clients, including a provider’s right to remove your servers if a security compromise is affecting other customers.

SLAs for technical and customer support are also critical, defining everything from acceptable response times to which parts of the service have access to 24x7 support and which can only be responded to during business hours. Also important are clearly defined plans for disaster recovery, service costs, and dispute resolution should anything go awry.

The latter can prove to be a major resource when it comes to resolving issues with vendors which have fallen short of their commitments. How will each issue be addressed and escalated within the company if necessary? What will be the specific penalty cost for each failure to meet agreement, and how will this amount be remunerated? In short, what happens on the day that your “100% Uptime Guarantee” reveals itself to be 99.9% correct?

William Van Winkle has been a full-time tech writer and author since 1998. He specializes in a wide range of coverage areas, including unified communications, virtualization, , storage solutions and more. William lives in Hillsboro, Oregon with his wife and 2.4 kids, and—when not scrambling to meet article deadlines—he enjoys reading, travel, and writing fiction.

(Shutterstock cover image credit: SLA)

Take your big ideas off the back burner with Converged Infrastructure

Comment on this article
Comments