Discovering new LUNs
The other major issue is the ability to discover new LUNs on the SAN, whether on storage array ports where the HBA already sees LUNs or on different storage array ports on the SAN that will present new LUNs to the server. The degree of difficulty in discovering and configuring LUNs behind these ports will vary widely, depending on both the OS and HBA.
The newer HBA cards' ability to autodiscover LUNs dramatically reduces the time administrators spend managing which LUNs the server has access to. Before this important new feature, some storage administrators chose to set up configuration files to recognize every possible LUN behind every storage array port on the SAN, even if the HBA didn't have access to them. This workaround allowed system administrators to discover new LUNs without server reboots.
Yet using configuration files to recognize LUNs has a big downside. During a reboot, for example, some operating systems will probe each of the LUNs described in its configuration file. This is a problem when a reboot is required and the server does not have access to all of the LUNs in its configuration file (and in large SANs, this number could be significant). In these circumstances, server reboots would take forever while the server timed out on LUNs it didn't have access to. New HBAs from Emulex, JNI and LSI Logic, along with more intelligent server operating systems, eliminate this gotcha.
Consider the QLogic QLA2342 HBA.
For HP-UX and AIX operating systems, as long as they support the vendor's HBA, the autodiscovery of LUNs feature should be available. Each ships with utilities native to its operating systems that allow new LUNs to be discovered without requiring reboots of its respective systems, regardless of the HBA manufacturer.
With these advances in simplifying the maintenance and configuration of HBAs, vendors are now turning their attention to address the next generation of FC HBA challenges. One such feature that's been available but whose future acceptance is still debated is the WWN spoofing functionality. To date, few--if any-- HBA vendors natively ship this feature, even though they have it available in their labs. Atto's Donnelly cites lack of customer demand and that fact that WWN spoofing introduces security risks into the SAN as reasons for not promoting this feature more aggressively.
Yet with the number of servers coming onto the SAN growing consistently, the growth of clustered servers and the desire by some to either simplify LUN security or establish a meaningful corporate HBA naming schema, this feature continues to generate some attention.
Currently, SAN administrators have to reapply the LUN security of the new HBA on every LUN the server sees if the old HBA fails. With the deployment of WWN spoofing, system administrators may now re-assign the old HBA WWN to the new HBA, reducing any risks involved with reapplying LUN security. Atto's Donnelly also sees this feature being used by customers who have clustered server environments. The HBAs of the failover server inherits the HBA WWNs of the server that failed, ensuring that failover server receives access to the data of the server that failed.
However, a more important benefit comes in the potential to come up with a meaningful WWN naming standard for all HBAs similar to what has occurred in the TCP/IP networking space. Right now, each server--regardless of its make, model or underlying operating systems--assumes the WWN that comes with the HBA. With the introduction of WWN spoofing, system administrators may now assign Windows servers one set of WWNs, Sun servers another and Novell servers yet another. This could enable a higher degree of QoS and better recognition of the nature of the FC traffic traversing the SAN.
All HBA vendors will provide this WWN spoofing function to customers who ask. Also, there are some third-party drivers available that replace the HBA's vendor driver with their own driver to deliver this sort of functionality. For instance, the leading storage array and tape drive vendors have driver code they use that replaces the HBA driver software on their respective device arrays that permit WWN spoofing for easier SAN management.
However, use WWN spoofing on servers with extreme caution. If, for example, an HBA on a Windows server is assigned the same WWN as has been assigned to a Unix server, the Windows OS could see the Unix storage on the SAN, which will result in a loss or corruption of the data associated with the Unix server. Worse yet, depending on the management and security tools deployed within the SAN itself, this situation could be difficult to diagnose and could occur again.
Fibre Channel speeds
Another feature that seemingly every SAN environment wants is more speed. The move to 2Gb-compatible HBAs now seems a done deal. Atto reports that more than 80% of its sales now come from 2Gb-compatible cards, while all of the HBAs LSI Logic ships are now 2Gb compatible. Atto's Donnelly says with 1Gb and 2 Gb cards costing the same, there's no longer any compelling reason to buy 1Gb cards.
Yet lurking around the corner are the 4Gb and 10Gb FC standards. Here's where the next generation of HBA speed remains a little murky, though LSI Logic's Charles Kraus sees momentum starting to build for 4Gb. Kraus points to simple economics as the reason 4Gb FC HBAs have a future. The 4Gb HBAs will be backward compatible with 1Gb and 2Gb protocols, and they will autosense the older protocols and cost about the same.
Meanwhile, 10Gb HBAs aren't backward compatible with 1Gb, 2Gb or 4Gb because the optics they use are different, and it will cost about $10,000 per port to deploy.
Yet Kraus says one shouldn't assume 4Gb is a done deal, as the HBA vendors are still waiting for a major switch vendor to join the 4Gb fray. While Kraus notes the industry hasn't made a decision on 4Gb or 10Gb yet, he suspects that 4Gb will appear in the marketplace in about 12 months.
The final feature that's generating attention among the HBA vendors is the CIM standard that was just recently proposed by the SNIA. Atto Technology's Donnelly sees CIM putting all HBA vendors on equal footing in terms of being able to manage HBAs. While he doesn't see this standard as necessarily making HBAs a commodity, it will give SAN administrators the ability to perform 70% or more of the needed management functions on any HBA, regardless of which vendor they are dealing with.
The introduction of CIM support, LUN autodiscovery capabilities, remote management and faster FC speeds will all help to increase the value of the next generation of HBAs. These features will help SAN administrators make their SANs faster, less complex and easier to manage.