Storage Area Networks: Dissecting a Management Framework - dummies

Storage Area Networks: Dissecting a Management Framework

A storage area network (SAN) management framework consists of various pieces of software that run on a server in your data center. In the most simple definition, its job is to discover, report on, and control all the components that make up your SAN.

Of the many different packages that do SAN management (and more are being developed every day), some are better than others. Some that let you view the status of (but not modify) the storage arrays themselves are very weak at handling the rest of the SAN, such as the hubs and switches. Some are great at controlling the hardware but skimp on visualizing the status of the components or the level of detail contained in reports. If you’re lucky, you may actually be able to see how much of your Fibre Channel bandwidth is being used by the traffic going between hosts and storage arrays. Most give you a way to be alerted to critical events on the SAN by paging you, sending an e-mail, or actually calling your home phone and, using a voice synthesizer, telling you what the event was. Pretty cool stuff; but creepy to your grandmother if she happens to answer the phone. One more thing a SAN management package can do is perform an action based on an event, such as running a script that allocates more fibre links to a disk if the utilization goes above 90 percent on the current links. The possibilities are endless, and all depends on how you need the SAN to be automated.

Using a common language to intercommunicate

Most frameworks consist of some type of database in which all the information about your SAN is stored. Having a single repository for collecting, monitoring, and controlling your SAN is vital to seamless management. These dedicated repositories make keeping track of what makes up your SAN really simple. Also, a central repository gives other vendors a chance to integrate their particular expert niche of SAN management into the framework, resulting in true best-of-breed solutions. A good SAN management framework isn’t necessarily a one-vendor solution. In fact, the more, the merrier. As long as vendors coordinate their efforts by being the best at what they do and then using a common language to monitor and control components, a seamless cross-vendor SAN can be managed quite easily.

Getting long-time enemies to speak to each other

If you’re wondering how to foster world peace — or at least how to get vendor X’s software to talk to vendor Y’s switch — the answer is easier than you think. You create a common language (call it Z) and teach it to both vendors’ hardware and software. Now, because they speak the same language, they can communicate and be managed by the same framework software.

The Storage Network Industry Association (SNIA) standards group is tasked with promoting efficient, interoperable, and robust solutions in emerging SAN technologies. Several of the big storage companies are members of SNIA, giving it a lot of clout. SNIA is pushing the Storage Management Initiative (SMI) code-named Bluefin, which is designed to bring to market a storage management platform (or platforms, take your pick) that can powerfully yet efficiently manage heterogeneous storage platforms simultaneously.

At the core of Bluefin is a common interface that all storage vendors — array, HBA, or switch vendors — will use to manage their products. This common interface doesn’t stop with SAN components. There are initiatives under way to expand this standard way of intercommunicating to other types of components, such as server hardware, operating systems, and networking devices, so that frameworks specializing in each class of component can intercommunicate and share information. This way, all management can be rolled up into one “global” framework that you can view and use to control any piece of hardware that you decide to use in your computing infrastructure.

To accomplish all this, the computer industry created a few more abbreviations for you:

  • CIM: The Common Information Model (CIM) is another way of saying, “We all agree to call a thing with four legs that you sit on a ‘chair.’ Anyone who sits on your dog will not be allowed to participate in the SAN.” You get the idea. It’s a way of setting the ground rules of a language: Point to an object, call it a “chair,” and then everyone else in the group understands that if they want to talk about that object, they better call it a chair, or nobody will understand them.
  • SOAP: SOAP isn’t for washing your hands. The Standard Object Access Protocol is an established set of rules for communicating back and forth between different entities. If CIM covers the language to speak, SOAP covers how to put together sentences using the language.
  • WBEM: Web Based Enterprise Management (WBEM, pronounced webem) is a language that uses Internet browser-based technology to communicate with and control SAN components. And all it takes to run a WBEM application is any old Web browser. CIM/WBEM management tools will all be little Web applications that you point your browser to, and it builds the user interface on your screen using Web languages such as Java, HyperText Markup Language (HTML), or eXtensible Markup Language (XML).

Figure 1 shows a block diagram of how these components sandwich together to make everything translate efficiently.

Figure 1: Web-based management framework.

The really cool thing about using a Web-based management framework is that you can get to it through any Web browser so that you don’t have to install an elaborate console to manage your infrastructure. In addition to that, because it is Web based, there really isn’t a single entity that you need to funnel all the information to. The framework will know whether you should be getting information from a central server for something like alerts, or whether you need to communicate (via the same Web interface) directly to the Web address of a storage array to carve up some volumes. It will handle the redirection of your commands for you instead of making you launch five separate consoles to look at your five different storage platforms. You view changes via the Web page depending on the task being performed, all handled dynamically by the little, embedded Web server application on each SAN component. When a new feature is added to a SAN component, or a new component is added to the SAN, the Web apps communicate to each other and figure out how to play together.