HBAs and Network Storage Interfaces

While it is true that storing and connecting functions are independent, there obviously has to be some sort of connecting interface that storage data passes through on its way between systems and storage. The connecting interface for SANs is a network adapter. Storage adapters in host systems are usually HBAs. This section discusses the use of HBAs as SCSI initiators, the qualification process for HBAs within the industry, the use of multiple HBAs in systems, and adapters used in devices and subsystems.

NOTE

An interesting marketing problem is brewing with product naming due to the emergence of iSCSI. There are a few approaches to implementing a network adapter for iSCSI, including the ability to use an off-the-shelf network interface card (NIC). In that case, why would you call something that already has a name and a product class (NIC) by another name (HBA)? The answer is that you wouldn't.

But what about a NIC that has been reengineered for the needs of iSCSI SANs? It still functions as a NIC in an IP network, but its primary application is for storage. The terms iSCSI HBA and iSCSI NIC have been used and are likely to last due to their relative simplicity. The acronym SNIC (storage networking interface card) has been suggested. The desire of some vendors to amplify their TCP offload technologies has given rise to other names, such as TOE adapter,NAC (network accelerator card), and TNIC. I'm glad not to be a marketing person this go-round, trying to figure out what to call them, as long as we don't call them TOE snacs.

HBAs as SCSI Initiators

Regardless of the connectivity used, an HBA's primary function is to communicate storage data. It receives requests from system applications, such as file systems and databases, to transfer data to and from storage using READ and WRITE commands. It also performs various management functions for applications using commands such as REPORT LUNS, INQUIRY, REQUEST SENSE, MODE SENSE, and MODE SELECT. HBAs need to be able to handle a large number of commands, operating parameters, and responses used in SCSI implementations.

As mentioned previously, an HBA is much more than a hardware implementation; it is a combination of hardware and device driver software. Using a top-down I/O stack approach, the first interaction an HBA has is between its system device driver and the operating system of the host system. Due to the nature of multitasking operations and SCSI's command/response protocol, the interactions between the operating system and the HBA system driver are interrupt-driven. Whenever there is something to deliver to the host from the HBA, an interrupt is generated and the host system makes the necessary context switches to accommodate it. These exchanges need to be as efficient as possible without errors in order to meet system performance expectations. HBA vendors list the operating systems and versions their products support; it should not be assumed that they will work with versions that are not explicitly named.

The HBA must operate with system hardware, and, therefore, HBAs are designed to work with specific system I/O bus technologies. Over the years, there have been many different system buses, including the S-Bus, Microchannel, Industry-Standard Architecture (ISA)/Extended Industry-Standard Architecture (EISA), and protocol control information (PCI). Today, most systems use the PCI bus. Care should be taken to understand the various PCI technologies in systems to make sure there is not a mismatch.

Besides working with SCSI storage data and the host operating system, HBAs also participate as citizens on the connecting bus or network. This means that network device driver software is also involved. The HBA and network driver put SCSI commands and data into a network PDU (or send them over bus lines in the case of parallel SCSI) and then manage the network transmission to a device or subsystem in the SAN. Conversely, the HBA spontaneously receives transmissions from SAN target ports that it must route correctly to the proper requesting application.

There are, of course, other networking elements to consider with HBAs, including transmission media, signaling, and network protocols. Readers interested in SAN transmissions should look for details in other books and writings on SAN networking technologies, including those covering FC, Ethernet, and TCP/IP.

Qualification of HBAs by System and Subsystem Vendors

Due to the critical nature of their mission, and the fact that the engineering work is difficult, SAN products receive a great deal of testing from vendors selling SAN solutions. In general, the selection of an HBA for a SAN is not really an exercise in open-systems economics. The HBAs people usually buy are the ones that a systems or subsystem vendor has qualified and sells.

NOTE

SAN system and subsystem vendors so far have been able to dictate which HBAs are used by their customers by withholding support for configurations using unqualified HBAs. People tend to look at this situation and wonder why SANs have to have tightly controlled qualification lists when other networks like Ethernet can have widespread interoperability almost immediately after a new technology is introduced.

The situation is not as one-sided as it seems. There are big differences between the nature of the data transmissions in SANs and LANs. Say what you want, LANs are not even close to being as critical a component as SANs are. Things can go haywire with LANS, and it causes pain but usually not the loss of data and employment. Because SANs can be complicated and nobody really wants a million degrees of freedom in something complicated where there is a lot at stake, it is much safer to go with a prescribed solution that is blessed by a SAN vendor.

That said, the situation will likely change over time as SAN standards mature and stabilize. When? Who knows? iSCSI SANs will likely influence attitudes and practices as Ethernet and TCP/IP networks are already universally interoperable.

Multiple SAN, Multiple HBA Configurations

High-availability systems often use multiple HBAs for high availability. The topic of multi-pathing is covered in Chapter 11, "Connection Redundancy in Storage Networks and Dynamic Multipathing." But that doesn't address the situation where more than one HBA is in a system to connect to different storage resources without regard for redundancy. An example of such a configuration includes a separate SAN connection to a backup SAN populated with tape subsystems and devices, as opposed to disk.

In general, there is nothing wrong or dangerous in doing this as long as some common sense is used. Things are simplest if the HBAs are the same product with the same version of driver and firmware code. However, you could be in a situation where you want a system to connect to storage subsystems sold by different vendors, without a single HBA qualified by both subsystem vendors. In this case, you need to proceed with caution in testing the dual-HBA configuration. Check with HBA vendors' technical resources about any known compatibility problems, and test the configuration on a test system before adding a second, different HBA to a production system.

SAN HBAs coexist with parallel SCSI HBAs in many systems. It is common for the boot drive that stores the operating system to be a SCSI disk while the application data is stored in the SAN. As it is with any system, the configuration of the boot drive should be fairly uncomplicated.

Device and Subsystem Network Controllers/Adapters

The product scenario for device and subsystem SAN network controllers is considerably different from HBAs. With HBAs there might be some leeway about the manufacturer or product, but with a subsystem you get the controller that is integrated with the subsystem. Subsystem controllers might have two or three options determined by the number of target ports in a configuration, but the controller is not sold by another vendor.

System HBAs and subsystem controllers appear to do the same things from a network perspective, but from a SCSI perspective they are considerably different. For starters, HBAs implement only SCSI initiator functions, whereas subsystems (and even some devices) implement both initiator and target functions. While the HBA initiator works through details of the operating system kernel, the target works through the details of connecting to multiple logical units and their device servers, task managers, queues, and storage mediaincluding memory cache. More importantly, there are usually several systems working with a single subsystem concurrently in a SAN, while systems are less likely to be communicating with multiple subsystems. The dynamics of the SCSI work are completely different.