Breaking down what's in your cloud SLA
A comprehensive collection of articles, videos and more, hand-picked by our editors
Typically, service-level descriptions are used to codify expectations with respect to storage efficiency. It's...
as if vendors are seeking to apply the old Supreme Court definition of pornographic materials -- "I know it when I see it" -- to storage efficiency.
Of course, service-level agreements (SLAs) are legal fictions created in contracts that, from a consumer's perspective, set goals or minimum requirements for the delivery of services by a contracted vendor. Ideally, these statements are intended to reassure consumers that vendors understand their needs and possess the capabilities to do an effective job of delivering the required services. However, the specification of service levels is sometimes intended to provide the basis for exiting the arrangement. Some outsourcing vendors complain that a storage SLA does little more than sow the seeds of contract failure by establishing impossible service delivery expectations (and inflexible methods for remediating missed goals). What those SLAs wind up guaranteeing is the dissolution of the agreement on the first occasion of a missed service level.
Regardless of the intent, a storage SLA may be established between a company and a third-party vendor -- such as a cloud or outsourcing service provider -- or it may be established between the firm and its internal IT department. A storage SLA can be a mixture of measured outcomes and general targets. For example, a service-level statement may refer to the total amount of data to be stored on a Tier-1 disk each day -- a measurable thing. Or it may state requirements in more general terms. For example, a requirement may specify that high-availability architecture will be provided to prevent the failure of any single storage array or RAID set from resulting in downtime or data loss.
Typically, storage service levels will cover at least six distinct areas:
1. Capacity: A storage SLA will generally specify how much storage should be available to the company and its users and applications at any given time. For example, storage capacity will be maintained equal to current capacity requirements plus "x" percentage of anticipated or forecasted data growth for the next "x" months. If thin provisioning technology is used, the forecasting algorithms used in calculating capacity reserves may be specified to provide both for forecast-able storage demand and non-forecast-able "margin call" events. The objective is to ensure applications don't run out of room for storing their data.
2. Performance: Storage performance requirements may be specified in terms of IOPS or bytes per minute, or using metrics dictated by the application using the gear, such as the number of transactions stored per hour in an accounting system. Good service-level standards for performance are based on accurate measurements of application workload output, separating from consideration non-storage-related performance inhibitors such as interconnect issues, protocol issues or application software problems, as well as the performance of storage gear itself.
3. Allocation efficiency: Storage needs to be allocated to workloads efficiently, with provisioning of resources and services occurring within a specified period of time. To accommodate this service level, IT needs to streamline the processes for sharing storage resources with the applications or end users. This is one definition of agility in IT operations.
4. Utilization efficiency: This level is often overlooked, but it's critical to running an efficient storage operation. Utilization efficiency is a measure of how effectively data is assigned to infrastructure components based on the value of the data, frequency of access, and the cost and capabilities of the storage itself. In a tiered storage environment, this is an assessment of the methodology or algorithms used by the hierarchical storage management software, which moves data from expensive, high-performance tiers to less expensive, high-capacity tiers as the data ages and reference frequency declines.
5. Availability: This area specifies the total number of units of downtime permitted within a measured timeframe. This is where you will likely read a discussion couched in the number of 9s of downtime that will be tolerated. The greater the number of nines in the fraction, the lower the amount of downtime expected (99.999, or five 9s of availability, represents less downtime than 99.99, or four 9s). Storage that's expected to support always-on application workloads will likely be configured into active-active clusters to provide zero downtime.
6. Protection: Various data protection service levels, often aligned with the requirements of data itself based on business criticality and regulatory requirements, may also be established in the SLA. Typically, these levels will include synchronous replication for full and uninterrupted access to data provided by two or more storage components: asynchronous replication for continuous access to most data in the event of an interruption, and tape backup for access to most data within a specified timeframe following an interruption. Additional service levels may specify strategies for continuous data protection with guaranteed recovery points or a specified maximum number of transactions that could be lost in the event of an interruption.
The value of a storage SLA depends on your point of view. Placed in a positive context, SLAs clearly articulate the expectations of the consumer and specify obligations for the vendor so work, time and resources can be properly priced and fairly compensated. When the SLA is between internal company groups, the contract may have less to do with cost management than with incentives or bonuses for meeting or exceeding targets.
However, SLAs also have a punitive function. They sometimes do more to frame the conditions for contract termination than to incentivize contract participants to work together to surmount difficulties when they arise. When setting and reviewing your SLAs, ask yourself whether the contract is designed to help two partners succeed, or to allow one to opt out when needs aren't met. In its best form, an SLA does the former.