The SAN Management Dilemma

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Since the advent of SANs, customers have complained that storage area networks are difficult to manage. Along with interoperability issues, the lack of comprehensive and robust SAN management has inhibited the widespread adoption of SANs by the IT market. And although progress has been made on the interoperability front, SAN management itself seems to be stuck under constant construction. The Storage Management Initiative (SMI) of the Storage Networking Industry Association (SNIA) is the first industry-sponsored, multi-vendor effort to create a solid foundation for storage management across multiple transports and applications.

Leveraging the Common Information Model (CIM) framework, SMI will enable both hardware and software vendors to engineer SAN management solutions to a common standard, thus providing greater interoperability and simplifying the customer’s management tasks. SMI, however, is not a panacea for all ills associated with implementing and supporting SANs. The problem with SAN management is not so much that it has yet to be mastered, but rather that the scope of SANs is too broad and complex to be contained within a single management framework.

Combining storage and networking into a SAN creates new capabilities that are far more diverse than the sum of its parts. Traditional network management, for example, focuses on data transport between source and destination. Address assignment, device configuration, bandwidth allocation, routing protocols, traffic monitoring, and historical reporting for capacity planning may be incorporated into a network management application to ensure proper data transport through a network infrastructure. Conventional storage management may center on allocation of storage resources via LUN assignment, RAID levels, storage utilization, and backup scheduling.

Page 2: The Added Complexity of SAN Management

The Added Complexity of SAN Management

Placing storage onto a network integrates all these management requirements and also introduces new features that result from the synthesis of storage and networking. Device discovery, zoning, LUN mapping, alternate pathing and failover, centralized backup, third-party copy, HBA and fabric management, and virtualization of storage assets within SANs impose new management tasks that are non-existent in direct-attached storage solutions. While these SAN-specific capabilities give customers a powerful toolset for managing storage data, they also inject added complexity into storage administration.

SAN management is predicated on a myriad of functions that must necessarily interact if the SAN is to perform its mission. Each device must be configured to its specific requirements. HBA vendors, switch vendors, storage array vendors, and tape vendors each provide their own device managers that must be invoked at least once for initial configuration. LUNs must be created, ports enabled, and parameters set. Once each component is operational, relationships between them must be defined.

HBAs must be assigned to specific storage LUNs, switch ports or attached devices must be zoned, and interswitch links for failover or load balancing must be defined. High availability solutions require additional management to ensure that redundant links are operational, clustering software is properly configured, or disk-to-disk data replication requirements are properly met. For redundancy purposes, management, snapshots, backup scheduling, and hierarchical disk-to-disk-to-tape utilities each require additional manual configuration and monitoring. Auxiliary functions such as bill-back for storage utilization, security policies, and capacity planning may also be implemented.

On top of all these strata, storage virtualization must hide the underlying complexity of the SAN and its management, although in today’s products the manual overhead of virtualization setup is even more labor-intensive than non-virtualized storage administration.For the past few years, management vendors have been struggling to integrate these diverse functions into a single platform, but with only partial success.

Page 3: No ‘Single Pane of Glass’ Solution in Sight

No ‘Single Pane of Glass’ Solution in Sight

The current effort by the storage industry to define a common standard for SAN management will facilitate creation of interoperable management frameworks, but it will not instantly deliver the “single pane of glass” management application that masters all aspects of SAN management. Customers will still have to operate multiple instances of SAN management, each focusing on specific functions. Backup, for example, is today commonly executed via standalone applications that do not integrate directly into SAN transport management frameworks. Multiple applications means multiple administrators, multiple management workstations, separate training and expertise, separate acquisition and support costs, and often separate management access methods to configure and monitor the SAN. Common management standards alone will not eliminate this requirement, but they are an evolutionary step towards SAN management integration.

In addition, streamlining SAN management is desirable from the standpoint of minimizing the impact of management on the SAN infrastructure itself. In a complex SAN, for example, the storage disk arrays, tape subsystems, SAN switches, and host bus adapters may be polled by multiple management applications simultaneously, as each attempts to solicit only those bits of information required for narrowly defined management tasks. This imposes considerable overhead on both the end devices and the storage network.

This situation is not helped by the fact that individual vendors, in their haste to add value to their product offerings, are extending the reach of their own management applications outside the boundaries of what is required for the immediate configuration and monitoring of their equipment. A SAN switch vendor, for example, may provide utilities for switch configuration, but also include a tool that draws a complete map of the SAN and its attached devices. Likewise, a storage array vendor may provide useful utilities for management of RAID and LUNs, but also lay claim to other aspects of SAN management as well.

This duplicates the work of other management applications and often results in excessive polling of storage resources without providing significant customer benefit. Although massive amounts of raw management data points may be retrieved, there is no correlation of this data into a comprehensive view of the SAN and its diverse functions. For the customer, maintaining five or six management applications to oversee a single SAN is an exasperating experience.

Page 4: Resolution via Integration into Operating Systems?

Resolution via Integration into Operating Systems?

The resolution of this anarchic state of affairs is not likely to be in the form of a gentlemen’s agreement among the storage vendors and management application providers to divide up areas of SAN administration. Since SAN management has significant value to customers, every vendor instinctively competes for this business. Vendors who began their lives producing value-added hardware in the form of sophisticated storage arrays are now marketing SAN management software applications that monitor and manage other vendors’ SAN products. Software, after all, commands much higher margins than hardware and offers sustained profitability even as the underlying SAN hardware components are driven toward commoditization. Common management standards will actually increase competition in this space, since standardization allows vendors to focus on value-added functionality and greater market differentiation instead of the mechanics of granular device administration.

It is more likely that the goal of a comprehensive SAN management solution will come not from traditional SAN vendors alone, but from the operating systems and applications that originally fostered the development of SANs. Microsoft, for example, is introducing APIs into Windows Server 2003 that will, under the auspices of the operating system itself, facilitate alternate pathing for failover, snapshots for backup, and storage virtualization for pooling, as well as iSCSI and iSNS device discovery in IP SAN environments.

If previously standalone SAN management applications are absorbed by the operating system, competing vendors may suffer, but customers will ultimately benefit from reduced costs and consolidated presentation. Although this is the sort of phenomenon that generates antitrust initiatives, the adaptive radiation of solutions within the SAN management market is undergoing a natural selection process that favors both centralization of functions and convenience in implementation. By analogy, no one gives much thought to printer sharing and management these days, since those functions are now seamlessly integrated into the operating system that bridges infrastructure to applications.

Conclusion

The inherent complexity of SANs is demanding more intelligence from the management frameworks to streamline or automate processes that currently require manual intervention. Although it is unlikely that SANs will become self-configuring and self-administrating, the integration of SAN-aware functionality into the operating system and reduction of duplication between vendor-specific utilities will make it easier for customers to deploy and support productive SAN environments without the background noise of today’s SAN management dilemma.

Tom Clark

Director of Technical Marketing, Nishan Systems

Author: Designing Storage Area Networks Second Edition (2003) (available at Amazon.com), IP SANs (2002) (also available at Amazon.com).

»

See All Articles by Columnist Tom Clark