SAN Control: Using SRM to Plan for a SAN

Today's SANs can be built with low-cost, interconnect methods making them ideally suited for open systems, such as Windows NT and UNIX. Fortunately, an emerging set of tools provides the glue that lets you manage SANs on your own terms.

• 08/01/2000

Today’s SANs can be built with low-cost, interconnect methods, such as Fibre Channel and/or common SCSI protocols. At the same time, these interconnect methods make SANs ideally suited for open systems, such as Windows NT and UNIX. Fortunately, an emerging set of storage management tools provides the glue that allows you to plan for a SAN and to manage it on your own terms.

A SAN functions as a separate, high-speed network, similar to a LAN. Think of it as a LAN for storage only. The SAN establishes a direct connection between storage resources, such as large RAID systems or robotic tape libraries, and servers or workstations. It acts as an extended storage bus and uses the same networking elements as a LAN. These routers, hubs, switches and gateways help to achieve two things:

• -To eliminate the distance limitations of traditional bus interfaces like IDE or SCSI

• -To enable storage resources to be reached from a single server, and to be shared among multiple servers. (This arrangement does not affect the primary LAN’s performance.)

The advantages of centralized storage via a SAN versus disparate servers with attached storage on a LAN include: Greater application availability, better applicable performance and practical data movement.

Because a SAN is its own network, it can be accessed through alternate data paths, such as clustering or a wide area network. You can design a SAN’s topology to eliminate single points of failure.

The server’s CPU speed and activity, and bus overhead usually limit the performance of storage attached directly to a server on a LAN. Being independent of a server with storage, a SAN never becomes affected by a host. And like conventional subnets, a SAN can add bandwidth without placing more overhead on the primary LAN. Thus, a SAN allows you to come up with affordable disaster protection configurations, such as remote clustering, mirroring and vaulting. Since it consolidates storage, a SAN becomes more scalable, reliable and flexible. Also, servicing a SAN becomes easier than storage attached to disparate servers on a LAN.

On the one hand, SAN technology offers advantages over storage attached to servers on a LAN. On the other hand, virtually all of today’s storage connects to a server via a bus, usually though SCSI or IDE. Surveys done by Strategic Research, an industry consulting firm specializing in storage, show that a bus attaches 98 percent of all storage.

SANs also add complexity and cost to your enterprise network. They raise questions about how the SAN will work with an existing LAN and/or WAN. You need to answer these questions before going ahead with a SAN.

What storage should you put on a SAN? While it would be nice to put all storage on one, most SANs are carried out as SCSI upgrades. These SANs take advantage of the greater bandwidth – usually 100 Mbps. Some SANs benefit from the connectivity and distance advantages of Fibre Channel.

As you begin to experiment with SAN pilots, you must first decide the following: What data and applications warrant the added cost and complexity of a SAN? What storage should remain on less costly servers with RAID storage or JBOD (just a bunch of disks) storage?

Industry analysts, such as David Hill of the Aberdeen Group and Michael Peterson of Strategic Research, target storage-intensive and mission-critical applications as the most obvious SAN candidates. Peterson says, "Applications, such as e-mail and enterprise resource planning, can benefit most from a SAN. It will give these applications advantages in performance, availability and data protection."

To configure a SAN, you must decide how best to partition (which parts of the disk will be assigned to what applications) the storage array used by the SAN. The needs of your end users should drive how you partition the SAN. Look at past and current storage consumption and usage patterns. Next, ask yourself the following questions:

• Which servers and workstations will have access to which partitions?

• What kinds of user activity can be expected?

• How much capacity should each partition have?

• Which partitions should be shared by more than one server for failover?

• What is the ratio of application files to data files?

Over the years, you probably have racked up a lot of time, energy and money managing storage attached to disparate servers. SAN topologies initially can mean a number of management challenges. However, you can eliminate some of the headaches you had with storage attached to servers on LANs.

You might want to consider some storage resource management (SRM) tools to help you manage the SAN. SRM is an emerging class of storage management tools. It describes the detailed monitoring, alerting, reporting and trending of storage resources. These resources could include RAID, disks, partitions, file systems and files. SRM is to these logical and physical storage resources, as network management is to routers, hubs and packets.

SRM automated tools can deliver information (usually via a Web interface) to help you determine the ongoing health and availability of the SAN. Features to look for in SRM tools include the following:

• Automated polling intervals

• Partition space thresholds

• Asset and configuration management

• Alarm/alert generation

• User consumption monitoring

• Backup sizing and planning

• Load monitoring and leveling

• Performance metering and management

Network management frameworks, such as HP OpenView, do provide some disparate SRM features, such as user consumption monitoring. SRM tools, however, provide you with a full network view of storage resources. Likewise, SRM vendors are making their products accessible through a variety of network management frameworks.

Some SRM vendors and their products include: HighGround’s Storage Resource Manager, Veritas’ Storage Manager, Astrum Software’s StorCast, and Sterling Software’s SAMs:Vantage.

Products from these SRM vendors will automatically scan everything from disks to share points, and make this data available as realtime alerts, dynamic reports and historical trends. You can use these reports and trends to classify and to measure your current storage as a SAN candidate. You can go one step further and use SRM information to the SAN once it is put into use.

Deciding what storage to move to a SAN and what storage to leave on servers with attached storage resources involves classifying all of your network storage. Without automated SRM tools, you can find this to be a daunting task. Just locating the largest multiple files and database applications among thousands of disparate documents can consume a lot of your time. Don’t forget the amount of network time swallowed by this task. With the increased use of operating systems, such as Windows NT and Novell, you have more disparate servers filled with gigabytes, if not terabytes, of storage, making the problem more difficult.

Some SRM tools provide the file size information needed for comparing and contrasting your current server storage, and locating servers with many large files. You may even want to drill down and to get the details on every one of the files. This information will help determine whether this storage could benefit from migration to a SAN.

SRM tools with filtering capabilities help you to audit network storage for SAN planning and SAN migration. For example, setting pre-defined filters or user-defined filters can yield a report with the largest files for an entire NT-based network, or for specific disk partitions or servers. By using more filters, you can then locate files by type. You can even use the filters to get reports by file size, file creation and file modification.

How do you partition disk space on a SAN so it can be connected to and accessed by various servers and workstations? You need to understand storage use patterns and user behaviors, and partition, directory and file statistics. SRM can provide the historical trends of end user space consumption and file access, modification, creation and size statistics. With this information, you can partition disk space for best results.

Entire network consumption rates and historical trends filtered by end users can help you to determine peak access time, and identify high-demand users. Likewise, SAN partition capacity requirements can be easily determined by looking at reports for the amount of directory space. Again, filtering by file size can aid in the analysis of the ratio of application files to data files for SAN and RAID tuning.

For ongoing SAN management, use SRM tools to poll and to monitor logical and physical storage resources. SRM tools that support SNMP traps ensure that SAN alerts get issued through network management frameworks, such as CA-Unicenter, HP OpenView and Tivoli TME. Discovering SAN assets, such as Fibre Channel disks, can help you define alerts and thresholds for file server partitions.

SRM reports for backup sizing, as well as historical trends, can help you gauge the SAN’s performance and ensure its availability.

Finally, as SANs grow in popularity, many network and storage vendors are scrambling to participate in this technology. The Storage Network Industry Association (SNIA), a trade organization, has brought SAN hardware and software vendors together to ensure that their products work with each other’s.