Fibre Channel SANs: Changing The Rules For NT.

Every programmer makes assumptions. The assumptions that OS programmers make tend to pervade the software that is built upon the OS. To create hardware with features that exceed those assumptions, the rules must be changed via software (e.g., drivers). Eventually, the OS catches up, but, in the meantime, the software emulation can provide the advanced features needed by today's applications.

Such is the case with SCSI over Fibre Channel. SCSI is both a bus specification and a protocol. SCSI over Fibre Channel uses the protocol, but the assumptions based on the bus specification are no longer valid. While Windows NT 4.0 allows for 32 SCSI targets per bus and Windows 2000 expands this to 128, neither is large enough to accommodate Fibre Channel environments, so a single Fibre Channel bus is mapped to look like multiple SCSI buses. Similarly, a single target is mapped with a large number of LUNs to look like multiple targets with an acceptable number of LUNs each. As you can imagine, this presents some difficulties for the OS.

Windows NT assumes that once it has found a target and scanned the target for LUNs, the OS knows which LUNs are there, If the target is a RAID device with configurable LUNs, the OS might not be able to see the newly configured LUNs.

A SCSI bus is not normally reconfigured for new devices with power on and the operating system running. A Fibre Channel bus, however, is configured this way, which can cause new loop IDs to be assigned to the targets. The OS doesn't expect the SCSI target ID to change on a system, so via software we have to make sure that the OS sees the same target ID, even if the loop ID changes. The retry logic for the software driver also has to take into account that the device may appear to be temporarily offline while the bus is broken and try to shield the OS and file system from this condition.

These features have been around since the first Fibre Channel arbitrated loop, but today's Storage Area Network (SAN) configurations are even more challenging. Now, the OS must deal with multiple hosts that have multiple paths to shared devices. The Unix operating systems have been keeping up with these changes and support dual-ported devices, mount controls, etc. NT, however, is based on the model that there is a local SCSI bus with devices on it and the OS should mount any devices it finds.

Take QLogic's failover between multiple adapters, for instance. NT doesn't recognize the concept of dual-ported devices and can interpret the same device as drive F: on one adapter and drive M: on another. This would, of course, be bad news for the file system, so the software driver takes over and must fool the OS into thinking there is only one device. The failover between ports and the load balancing between adapters must be completely hidden from the OS.

When the Fibre Channel fabric is introduced, it's possible to have more devices than the operating system can support, so an effective Fibre Channel driver has a method of determining which devices should be presented to the OS. Remember that NT will attempt to mount every device it finds. The dual-port issue comes up again because there could be any number of host adapters connected to the same fabric. The driver must be able to protect against the OS seeing multiple instances of all the devices.

An additional challenge is sharing devices between multiple hosts. If the hosts are all servers in one cluster, then the cluster can arbitrate access to the devices. It is just as likely that the hosts are all independent servers trying to share a large RAID device. To prevent multiple hosts from mounting and writing on the same volumes, a solid driver will have a form of access control created beyond the default NT operation. This can be target-level and LUN-level access control in the driver or some form of volume management software that is added.

System administrators want the ability to dynamically migrate a volume (target or LUN) from one host to another. This implies some operating system facility to flush and dismount the volume (or volumes if there are multiple partitions) on one host, and mount the volume on the other host. The right software driver can offer utilities to support the dismount.

System administrators are demanding the features that Fibre Channel SANs offer: reliability through dual-porting and failover; accessibility through volume control and dynamic volume migration; scalability through hot adding of devices and hosts; and performance through load balancing and fabric path selection. The way to get these advanced features today is through additional software utilities, like QLogic Management Suite, designed to maximize device availability, reliability, and performance. While the issue of backward compatibility versus new functionality will continue to exist in NT environments, the rules may be bent to meet the growing needs of SANs and the system administrators who manage them.

Wade R. Wooldridge is the principal software engineer at QLogic Corporation (Costa Mesa, CA).