Why Do You Need To Test Fibre Channel? - Technology Information

Computer Technology Review,  July, 1999  by Greg Beutler

• E-mail
• Print
• Link

Greg Beutler is the product marketing manager for Xyratex International (Irvine, CA).

Fibre Channel has fulfilled many expectations and undoubtedly will continue to do so. This promise has changed the view on storage. It is now being viewed as a different type of resource with more capability than ever. Unfortunately, to get to the Promised Land of SAN, more work needs to be done and system-wide testing issues must be addressed. Manufacturers have begun testing and are continuing to solve these large system issues. Until operating systems, like Windows NT, include commands to mount and unmount disks and have more robust recovery mechanisms, manufacturers and integrators need to address these issues by bolting on their proprietary file system solutions. Integrators are dealing with error recovery issues and protocol compliance as well as migration and integration of legacy SCSI products with Fibre Channel products. End users are testing to enhance their system's performance and ensure that fail-over mechanisms work properly. These types of problems require analysis tools, which capture and disp lay link level events to give insight as to exactly what is happening and why 4 on this gigabit network.

Manufacturer Test Issues

Before any Fibre Channel product is released, the manufacturer has done extensive electrical and physical level testing to redress transmission line effects, and has met jitter budgets.

Integrator Test Issues

Integrators deal with the interplay of the various devices that make up a Fibre Channel installation. They need to test for the robustness and interoperability of vendors' implementations. As Fibre Channel produces new paradigms, error recovery scenarios become more complex, which requires more testing.

While vendors are selling usable Fibre Channel solutions, there are some error recovery scenarios, which need to be tested. Some initiator devices, since they execute commands sequentially, will know which command is supposed to be executed and can start to recover just that command. Disk devices, due to conunand reordering, may be working on several commands at the same time and it would be difficult for the initiator to properly recover all I/Os.

Protocol Compliance Testing

This level of testing ensures that the frames generated and received by the upper level protocol(s) are correct. The specific pieces of equipment are a Test Adapter (a highly controllable host bus adapter) and a Protocol Analyzer (a device that records all events on the monitored connection). Besides performing all legal operations, the Test Adapter can generate illegal codes or sequences, essential for testing the robustness of the device driver implementation.

The workings of an upper level protocol frequently encompass a sequence of frames and more than one process (or even more than one protocol) may be active at once. Given the finite amount of high-speed buffer available for data capture, the Protocol Analyzer may be called on to filter the incoming data to capture only the connection of interest. This is analogous to SCSI filtering on a single ITL (Initiator/Target/LUN) nexus. In this way, one can view sufficient history to understand how a process is proceeding.

Migration And Integration Of Legacy SCSI Products

There is always the need to reuse valuable older model devices into a new system because of investments involved. Luckily, there are Fibre Channel vendors providing 'bridge-type' products that bridge the legacy parallel SCSI products with the 20 Computer Technology Review July 1999 new Fibre Channel devices to provide user-transparency in their operation. As well as the original manufacturers have done their initial testing, there will be the "odd-duck" legacy device that no one even thought still existed, much less was being used. This problem of integrating the old with the new will fall upon the shoulders of the integrator to ensure interoperability.

End User Test Issues

* Performance Testing

Once a system is working correctly, testing objectives shift to optimizing the system's operation. Commonly one would test the link utilization and observe the heaviest "talkers" on the network. In most cases, the Host Adapter and Targets make a separate Test Adapter unnecessary, but the Protocol Analyzer is still essential. It is used to record the sequence of communications and to monitor the utilization of the communications pathway. It is especially useful if the Protocol Analyzer can store an abstract of the traffic to a large disk, thereby preserving hours or days of traffic statistics.

* Fail-over Mechanisms

Many of today's commonly used operating systems only provide about 98% uptime, which translates to 7 days a year of downtime. The need for 24/7 uptime requires fail-over mechanisms, which, if implemented properly, can reduce downtime to less than a few hours a year. An example of a fail-over implementation is a clustered email server. This uses two host computers attached to a common storage device via a hub or switch. This configuration allows both hosts to serve email requests and provides fail-over protection. A signal is passed back and forth periodically between two hosts such as "I'm okay--how are you?" and if the message is not returned in the prescribed time of, say, a second, the fail-over monitor will cause the properly functioning machine to service all of the requests rather than just half the load.