Service level agreements and service level objectives are the keys to modern policy-based storage management. Between them, they set the rules for making storage meet the business objectives of the enterprise. SLAs are, in effect, the storage administrator's promise to the rest of the enterprise. They are the standards that the IT department agrees to meet. SLAs should always be defined at a high level and in terms of business objectives rather than technical objectives. Examples include agreements on availability and response time.
SLOs are technical goals that ensure the SLAs will be met. While the SLAs are set in generalities and business goals, SLOs are set as specific technical objectives. To be successful, SLOs must meet several criteria. First and foremost, SLOs must be measurable objectives. Respond rapidly to outages is not good because it is not measurable. Restore access for applications and within 30 minutes of receiving notification of storage outage is measurable.
A good SLO also specifies the metric to be used to measure the objective. For example, an SLO on response time might specify what reports or utilities are to be used to measure response time. SLOs must be actionable. That is, there has to be something the administrator (or the software) can do to correct the situation if the SLOs parameters are not met.
While SLOs are objectives, policies are the steps to be taken to meet those objectives.
Generally a policy can be expressed as a condition, action sequence. In other words, a policy has a triggering condition or conditions that produce an action or actions.
Creekpath Systems subdivides policies into explicit, rule and constraint policies.
Explicit policies set the ground rules for storage. Often they determine the storage architecture, kind of hardware and software that is installed, when additional equipment is brought online and other fundamentals of the storage systems. Explicit policies also define the relationship between the applications and things like classes of service, restore times and backup methods. It is important to rank explicit policies according to their importance. There are likely to be some situations where all the explicit policies cannot be met due to something like equipment failure. In that case administrators need to know which policies are more important so they know which ones to comply with first. For example, in a transaction-processing application, keeping the application running is probably more important than meeting response-time policies.
Rule policies are rules setting parameters for responding to various events within the storage system. For example, requiring that an administrator be notified if a disk in a RAID fails and the array switches to a hot standby disk is a rules policy. In general, rules policies consist of a condition (disk failure) and an action or series of actions (swap in hot standby and notify administrator). Constraint policies set out the limits to action. Often these apply to specific devices, such as storage arrays and switch configurations.
Constraint policies are usually more important for those jobs that are automated. However, some constraint policies represent IT, imposed restraints, not directly related to the limits of the hardware and software. Taken together, SLAs SLOs, and policies determine what the storage operation does. It is important that they be carefully thought out and developed by the appropriate people. SLAs, in particular, require consultation and negotiation with the user communities in order to meet their needs. SNIA has a paper titled Policy-Based Storage Management.
Creekpath has a white paper titled The Need for Policy-Based Management Software in Storage Area Networks at www.creekpath.com. A collection of papers on policy-based management of distributed systems is available at www-dse.doc.ic.ac.uk/events/policy-2001/PositionPapers.pdf. These papers do not deal with storage systems directly, but they provide a broader view of the questions of policy-based management.
Rick Cook has been writing about mass storage since the days when the term meant an 80K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last twenty years he has been a freelance writer specializing in storage and other computer issues.
For more information:
This was first published in December 2002