The Storage Team Blog about file services and storage features in Windows Server, Windows XP, Windows Vista and Windows 7.
About ten years ago, a group of engineers from different storage companies got together to create a powerful management abstraction that would enable tools for centralized storage environments like storage area networks (SAN) to become less vendor-specific but still allow any vendor to fully surface the capabilities of their storage hardware. One of the original goals was to build a model that relied on industry standards, largely from the DMTF, W3C and IETF. This included using a common model and schema (the Common Information Model or CIM). Unfortunately a model and schema only get you so far; they don’t give you something that can be implemented. You need a transport and a language to encapsulate the model. At the time, the logical choice for encoding the data was XML, specifically CIM-XML (also standardized in the DMTF) and the logical transport was HTTP. Collectively these technologies are known as Web-Based Enterprise Management, or WBEM.
[There are other choices for transport now available, such as WS-Management, a SOAP protocol that is also on the way to becoming an international standard, and the Windows-only WMI COM implementation of WBEM. I’ll speak more about those technologies at a later time, as they are also key to Microsoft’s standards-based management approach.]
The direction had been set in the Storage Network Industry Association, but the work moved into a private consortium known as PDP for reasons that I won’t go into here. A few years later, the group handed the work back to SNIA as a draft called Bluefin, which later became the Storage Management Initiative Specification, or SMI-S 1.0.
So what is SMI-S? Well, it’s basically a cookbook that explains how to use the model elements to do useful work, like discover and provision storage. Actually, it has grown into multiple cookbooks now, divided into topics like Common Profiles, Block, Filesystems, Fabric, etc. The SNIA has active working groups updating the specification every year or two to keep up with the latest technologies. The current (recently) published version is 1.6.0, with some updates expected by the end of the year.
Let’s look at the different components that make up SMI-S:
An SMI-S provider is a software component produced by or for a particular storage product or family of products. It implements an HTTP server, it can parse XML requests, and it knows how to control those specific devices which usually have their own unique management interfaces. The provider can be embedded in the firmware or operating system of the device itself, or it can exist as a standalone application running on a general purpose computer operating system. The latter model is called a “Proxy” provider, and it is the most common way to implement SMI-S providers at this time.
Profiles are a way of describing what components of the schema will be used to describe a particular management domain. For example, there is an Array profile. If a vendor claims support for the Array profile, they also agree to implement the classes defined in that profile, the specific properties and methods of those classes deemed necessary or optional to do useful work, and they also have to implement other related component profiles or subprofiles.
Profiles and subprofiles also tell you what the array can do. If the array can perform snapshotting or cloning of storage volumes, the provider can advertise that capability by claiming support for Replication Services. Application developers then know that they can use the CreateElementReplica method to create a new copy of the storage volume – an incredibly powerful capability used heavily in virtual machine management.
Profiles were created by SNIA and also by the DMTF. In some cases, SNIA specializes the profiles for use with SMI-S.
A class is a set of properties and methods that pertain to a specific object, or to an aspect of an object. Classes typically inherit properties from base or superclasses. An example class is a Disk Drive (in the CIM model, CIM_DiskDrive). Some properties of the disk drive might be what kind of drive it is (SSD, hard disk, etc.), how fast it spins, and what it’s doing right now.
A vendor can introduce new properties and methods by creating their own version of a class, inheriting from the base class and then adding their uniqueness to their derived class. In that way, the model allows extensibility while still preserving the common functionality that any application can use without understanding the specific value-added capabilities of the device it is trying to manage.
Most of the classes used by SMI-S are standardized in the DMTF CIM schema. There are over 1500 classes already defined, and new classes and additions to existing classes can happen frequently as the schema gets updated about three times a year.
The provider creates an instance of a class when it represents the actual objects. In our disk drive example, there will be an instance of the CIM_DiskDrive (or vendor-derived version of that class) for each physical drive in the storage array. An enumeration operation will retrieve all the instances, or a specific instance can be retrieved by itself.
It isn’t really enough to just count up all the objects of a particular class. Objects of one class might be related to another class and this is represented by associations. So a disk drive would be associated directly or indirectly to the object that represents the storage array. That way you can start at the top and find the related objects, or you can go from the bottom up to the top.
Microsoft has become an active participant in the SNIA technical working groups and also in the SMI-Lab plugfests. Over the past few years we have been testing hardware vendors’ providers with our client interfaces, first with System Center Virtual Machine Manager 2012, and later with Windows Server 2012. One goal was to make sure the most important scenarios for these products will work well with our interpretation of the specifications. And another objective was to allow for extensibility so that anything exposed through SMI-S could be leveraged on Windows without having to redo the considerable plumbing for interacting with a remote WBEM client. I’ll present more about this “passthrough” capability in a future blog.
As part of our commitment to management standards, Microsoft developed support for SMI-S and now includes this support with VMM 2012 and Windows Server 2012. Working in conjunction with the new storage management interfaces in Windows Server (see the references below), SMI-S enables command line access and easy scripting of many common storage tasks using Windows PowerShell and can also be used with the newly enhanced File and Storage Services role in Server Manager.
SMI-S support is implemented as an optional feature in Windows Server called Windows Standards-Based Storage Management. Keep in mind that it is designed for consolidated storage environments, and although most providers support simultaneous access from multiple clients, it is a best practice to also centralize the management of those devices. It would be unnecessary (and unwise) for the majority of servers to all be managing the same resources individually.
Because SMI-S is an industry standard built on top of other standards and widely implemented in other environments (such as VMware® and AIX®), vendors no longer need to produce proprietary providers for one particular operating system (or release). They can expose all of their product’s goodies using one provider as extensibility is inherent in the object-based approach of CIM. As client applications learn to take advantage of the advanced features, they can do so without resorting to yet another provider-model. CIM also has a good backward and forward compatibility story.
On Windows Server 2012, once an SMI-S Provider is configured for use with the service, the storage will be manageable using the new Windows Storage Management API, and the Storage module in Powershell.
In the next post, I will explain how to get started using SMI-S with Windows Server 2012. Some assembly is required, but you should be up and running in a few minutes.
To see more about Microsoft’s commitment to standards and storage management, refer to Jeffrey Snover’s blog on this topic.
System Center 2012 Virtual Machine Manager also uses SMI-S providers. See http://technet.microsoft.com/library/gg610600.aspx for more information about storage automation and VMM.
Refer to the following section on technet for more information about the Storage cmdlets http://technet.microsoft.com/en-us/library/hh848705.aspx or the Storage Management team blog for the latest information at http://blogs.msdn.com/san
Learn more about the Storage Management Initiative at http://snia.org/forums/smi.
SMI-S is based on many industry and worldwide (ISO) standards:
CIM, WBEM and WS-Management are the products of the Distributed Management Task Force. For more information, see the DMTF website.
The Service Location Protocol, Version 2 (SLPv2), and Transport Layer Security (TLS, including Secure Sockets Layer or SSL) are protocols from the Internet Engineering Task Force (IETF).
The current specification for Hypertext Transport Protocol (HTTP) is a joint effort by the IETF and the World Wide Web Consortium (W3C).
That's a great documentation. It will clear all IT Experts questions about SMI-S.
Good job Jeff. As an author of SMI-S, I'm glad to see that Microsoft sees value in it.