Just a few years ago, bandwidth was measured in MB/s. Today the norm is 2GB/s, with higher bandwidths on the way. Another factor is the inherent complexities of storage networks, which occurred when Fibre Channel (FC) SANs arrived. Devices are farther apart and are connected through many ports, making the problems encountered harder to find. As a result, storage analysis tool vendors are scrambling to kick their products up a notch or two.
 |
| ||||||||||||||
Requires Free Membership to View
When you register for SearchStorage.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Our goal is to keep you informed on the hottest topics, the latest news and the biggest challenges you face as a storage professional today.
Rich Castagna, Editorial Director
|
||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
In the storage industry, analysis tools exist for developing and maintaining storage devices and networks. The analyzer plugs into a network and records the traffic. Users can view this traffic - known as a trace - in a decoded, understandable format to monitor and research link activity. Analyzers offer many features for examining traces such as searching, traffic filtering, code violation checking and triggering on a specific activity. They're also slowly emerging as invaluable tools for IT staffers to optimize performance and resolve problems.
With the move to FC and serial communications, analyzers had to become more robust, e.g., the analyzer's onboard high-speed memory, disk capacity, CPU speeds and port counts have increased dramatically. Five years ago, a typical SCSI bus analyzer contained 5MB of memory and a 20MB hard drive. Today, a 2Gb/s FC analyzer can have up to 4GB of memory and a 60GB hard drive. That is an 80-fold increase in memory alone.
One reason analyzers have been forced to bulk up can be explained as a simple equation: Link data volume increases proportionately to bandwidth increases over a given period of time. In other words, increasing link speed means more data passes through the network, so there's more data to store and analyze. Another factor is the growing complexities of storage networks. With bus protocols such as the SCSI architecture, problems were confined to short distances and between few devices, making the traces relatively small, and the issues easier to locate. Now with serial communication network storage protocols such as FC SANs and the future iSCSI SANs, the distances are great and the number of devices enormous. As SANs grow with increasing port counts, link lengths and higher bandwidths, the analyzer will be further challenged.
Trace sizes are exploding
Dramatic increases in bandwidth are contributing to the rising volume of link data. For a 2Gb/s link speed running at peak utilization, there's more than 400MB of data transferred across the port each second. At 10Gb/s link speed, there would be more than 2,000MB (or 2GB) of data transferred across the port each second - a five-fold increase - and would require at least 2GB of memory and disk to store. This is leading to an explosion in trace sizes.
To confront this ongoing concern, some vendors such as Ancot, Menlo Park, CA, have begun offering up to 4GB per port, while others, such as I-Tech in Eden Prairie, MN, offer more than 20GB in a chassis that includes 16 ports. With traces becoming so large, the demand on the analyzer's trace memory is challenging practical limits, and simple everyday operations such as trace file management and post processing are becoming slow and cumbersome. For users, this translates into longer debug cycles and decreased productivity.
To handle large traces, vendors are incorporating a number of techniques. To address the trace memory constraints, all analyzers from the major vendors incorporate the well-known pre-capture filter and triggering hardware features. Pre-capture filter enables users to eliminate specific link data from being stored, which elongates the capture time. For example, eliminating all but the first 16 words of payload can increase the capture by 20 times.
The trick is users need to know what data they're not interested in ahead of time. Triggering enables users to eliminate all incoming data until an event they want occurs on the link, and then capture begins. Both of these features address the issue to a certain extent, but require some knowledge of the events before the capture begins. And, there remain cases where intermittent and unpredictable problems require all link traffic be captured. To address this need, vendors are attempting to design ways to combine memory from several analyzers together into one virtual memory space. For example, if you have four individual analyzers with 1GB of trace memory, together, they would appear as one analyzer with 4GB of memory.
In addition, many vendors are improving their analyzer's searching operations. Some vendors utilize the analyzer's hardware logic to assist searching, resulting in operations taking seconds to complete. However, hardware-assisted search engines only work on traces stored in the trace memory, and are somewhat limited to the range of search criteria supported by the hardware. The limitations arise from the number of hardware levels used in making the comparisons. In sophisticated searches exceeding the hardware capability, the software takes over and validates the search, introducing delays. When hardware-assisted search works, the results are impressive.
This was first published in October 2002