This article can also be found in the Premium Editorial Download "Storage magazine: Storage salary survey: Are you being paid enough?."
Download it now to read this article plus other related content.
|Managing storage in SANs|
|There's lots of talk about increasing storage utilization, but so far|
| not many companies are doing a stellar job. The reason? Much of the focus on storage area networks (SANs) today revolves around the network management of SANs: LUN masking, zoning and volume discovery. Performing these tasks can take hours--if not days--to get everything right. Toss in a growing environment with different OS, clustered servers, interconnected switches and varying storage array vendors, and the possible networking permutations become quite complex. As a result, only lip service is paid to increasing storage utilization rates.
Some current solutions such as EMC Control Center, CreekPath Systems CreekPath Suite and Veritas SANPoint Control claim to manage storage, but in reality, they manage and mask the existing networking complexity instead of improving storage utilization rates. That's not to minimize what these tools do. They provide valuable SAN infrastructure networking services such as visualization, performance management, device management and some limited storage management capabilities. But they don't create a central, homogenous pool of storage.
This may almost sound like blasphemy because using these tools in conjunction with SAN-attached storage arrays gives the illusion of a central pool of storage. Yet today's SAN implementations only break the physical relationship between the server and the storage array by placing a Fibre Channel (FC) switch between them; they do not break the more important logical relationship.
Fabric-based storage virtualization addresses the shortcoming that exists not in these tools, but in the current SAN design. Virtualization breaks the physical and logical associations between the server and the storage. By breaking this relationship in the network, it in essence creates what is known in the mainframe environment as a volume table of contents (VTOC).
The VTOC serves three important functions: It allows storage to be discovered and cataloged. It can discover this storage with minimal zoning or LUN masking changes and without the requirement for every vendor's APIs or the latest, greatest SNIA standard because all storage is mapped to and owned by the VTOC. Finally, it provides a central management interface from which storage may be provisioned to servers.
While the value of a fabric-based VTOC may be debated in small SANs where there's only one storage array or a small number of servers, the problems it solves and the value it offers to enterprises is indisputable. By solving the current networking problems, the VTOC not only creates a pool of storage from which all OS can obtain storage, but lays the foundation for concepts such as information life cycle management (ILM) to finally take hold and succeed in large open-systems storage environments.
A growing number of storage providers are jumping on the intelligent fabric bandwagon. Just to name a few: Brocade Communications Systems Inc., for example, has placed routing and QoS functions in its switch's OS; DataCore Software Corp., Ft. Lauderdale, FL, and FalconStor Software Inc., Melville, NY, forcefully argue that volume management best belongs in the network.
While placing functions such as routing, QoS, volume management and security into the fabric solves some current problems, they also introduce new ones. Current storage networking issues such as latency, complexity and management won't magically disappear with a more intelligent fabric, but will simply reappear in different forms.
There's little debate that the ability to manage storage in the fabric is generating increased interest. Volume management appears both as a feature integrated into the switch, as well as on a separate appliance. For file level network-attached storage (NAS) environments, this function most often appears as a separate appliance such as Hitachi Data Systems/Network Appliance's NAS Enterprise Gateway that handles file-level traffic for file sharing between different OS. In block-level storage area network (SAN) environments, this utility appears as an appliance--such as DataCore's SANsymphony product--and as an optional component in Brocade, Cisco Systems Inc. or McData Corp. fabrics.
Much of the impetus behind moving the volume management into the fabric in both SAN and NAS environments comes from the complexity in managing storage at either the host or storage array level. While this is less of an issue in environments with only a limited number of hosts (20 or fewer) or storage arrays (two or fewer), in shops with a large number of storage arrays (five or more), the complexity and difficulty of managing storage in this environment grows almost exponentially, not linearly. (See "Managing storage in SANs," on this page.)
Fabric-based volume management simplifies the picture. No longer does a storage administrator have to allocate a portion of the storage on each storage array to individual servers and leave the unallocated storage in unreportable storage pools. Instead, the storage admin maps all of the storage in each array to the fabric-based storage controller which can detect, manage and report on all of the free and allocated storage under its control.
The storage controller now serves as a volume manager that creates volumes of different sizes on any storage array it controls and then present them as LUNs to any server zoned to see it. It can enable advanced storage management features such as moving data between storage arrays from different vendors, create point-in-time snapshots of data and present a report of the enterprise storage within a single management console. It also lays the foundation for a true open-systems information life cycle management (ILM) solution. It does this by creating a common layer that any open-systems platform can communicate with to automatically move data onto different types of storage devices, be they disk or tape.
Of course, a single storage management tool also brings vendor lock-in to a specific network-based virtualization or volume management solution. While the American National Standards Institute (ANSI) formed a committee in June 2003 to propose a fabric application interface standard (FAIS) to minimize or eliminate vendor lock-in, the time frame before it is approved, and then gains user acceptance, is still years away.
Mike Witkowski, CTO of Maxxan Systems Inc., San Jose, CA, says that users have been reluctant to adopt virtualization for fear of being locked into a specific vendor's solution. Each vendor's virtualization product performs snapshot and mirroring tasks differently, and of course, the devil is in the details.
Yet it's for exactly these reasons that Tom Clark, Nishan Systems (now McData) director of technical marketing, says a standard for virtualization may not take hold. As certain functions move higher up the food chain, the less standardization applies, especially at the application level. He says that companies backing up with Veritas NetBackup don't expect to be able to recover data with Legato Networker or vice versa. He thinks that this same concept may carry over into the volume management space as well because each vendor's virtualization implementation will be proprietary for the simple reason that volume management standards will be difficult to define and enforce.
Users looking to implement network storage smarts right now should see if they can accomplish the same tasks on their existing storage arrays. Most midrange and modular storage arrays all ship with a fair amount of storage intelligence and functionality in them. However, for environments looking to consolidate their disparate storage devices into one ubiquitous storage pool, appliances from DataCore, FalconStor, Fujitsu Softek and IBM--along with storage switches from Brocade and Candera--are nearer than people think to creating these central managed storage pools.
The intelligent switch
Companies such as Brocade, Cisco and McData offer switches that include routing and QoS as part of their switch's native OS that help organizations manage the data flow through their Fibre Channel (FC) network. For instance, Brocade's latest version of its OS offers the ability to trunk up to four of its 2Gb ports and present them as one logical 8Gb path between two of their switches. Directors and switches from McData can also accomplish trunking in a similar fashion assuming they use version 5.0 or later of McData's microcode.
For the switch's OS to treat separate physical paths as one logical path is important for two reasons: First, it reduces the number of inter-switch links (ISLs) required to link core and edge switches. Switches that use trunking can use up to four ports to get an effective throughput of up to 8Gb. Switches that lack the trunking function will require more dedicated ports between the switches to distribute the traffic between the switches.
Second, trunking captures meaningful performance statistics. For instance, each time servers log off and back on to a storage network that uses ISLs, but lacks trunking, they are assigned a different ISL to send their network traffic. This round-robin method of assigning data traffic between switches makes historical performance statistics questionable, and could create a situation in which one ISL handles traffic from multiple servers while another link handles little or no traffic at all. The only way for the SAN administrator to fix this is to force all of the servers on the storage network to log off and back onto the SAN. While this would force a redistribution of the data traffic across the ISLs, it could also negatively affect the servers using the network, possibly resulting in failed paths or outages.
This was first published in December 2003