| Q1. |
What's new with HP's latest Emulex-based Mezzanine cards? |
| A1. |
These cards are based on Emulex's sixth generation Fibre Channel controller chip, "Thor". Thor is a highly integrated dual-channel PCI-X 133 to Fibre Channel controller capable of delivering 70,000 I/Os per second (IOPS) per channel. |
|
| Q2. |
How do these new FC Mezzanine cards stack up against the competition? |
| A2. |
The Emulex Emulex-based Mezzanine cards features not found in competitive models, include firmware-upgradeable architecture, hardware-independent drivers that are compatible across the product line, large on-board data buffers and context caches, and extended reconfigurability options - including firmware upgrades - without rebooting the host server. These features improve performance in complex SANs, protect the value of the HBA assets, and directly lower the Total Cost of Ownership (TCO). |
|
| Q3. |
What operating systems are supported with Emulex-based Mezzanine cards? |
| A3. |
These mezzanine cards ship with standard Emulex Windows and Linux drivers. Driver support for Windows include Windows NT, Windows 2000, and Windows 2003. Driver support for Linux include RedHat Kernel versions 2.4, and 2.6, and Suse. Emulex drivers are shipped with the latest Linux CDs. |
|
| Q4. |
I've read that Emulex drivers are hardware-independent and compatible across the product line. What does that mean? |
| A4. |
Emulex drivers can be used across the product line, including previous generation HBAs. Some competitors make this claim as well but close examination of the driver bundles provided will reveal different components within the driver name wrapper. In the case of Emulex drivers the identical driver (also referred to as the driver binary form) is what is run across the HBA product portfolio. New drivers are binary compatible with older hardware allowing new features to be added to an existing infrastructure. Perhaps the major impact this has is in the area of SAN management. With this feature an administrator can manage a SAN that incorporates old and new generations of Emulex HBAs while maintaining only one driver version across the entire SAN, removing the risk of outage due to an inadvertent mismatch between drivers and HBAs. |
|
| Q5. |
How did Emulex make their products driver-compatible? |
| A5. |
Early on, Emulex recognized the benefits of flexibility and stability that result from a common, consistent architecture. Emulex established a standard interface between the host-based software components of its Fibre Channel architecture, and the hardware and firmware elements resident in its controller chip-based hardware solutions. Emulex designed a firmware-to-driver interface called the Service Level Interface (SLI) for their very first generation HBA technology over six years ago. Firmware releases for each of the following generations of HBAs have all adhered to this SLI. Similarly, future drivers will also follow the SLI, making them compatible with the older versions of the product. For more detailed information on Emulex's SLI, please see the white paper entitled "Emulex SLI Architecture Simplifies Storage Management".
|
|
| Q6. |
I have a small company with only four servers that use direct attached storage (DAS). Can I still benefit from installing a SAN? |
| A6. |
Yes! A SAN allows better utilization of existing storage resources, and simplifies the addition of new devices in a computing environment. With a SAN, multiple servers can share a pool of storage and back-up devices such as tape drives. This provides both flexibility and simplified management of storage resources. The implementation of a SAN over DAS can translate into lower total cost and greater protection of data. |
|
| Q7. |
Can I run my tape drives off the same HBA as my storage array without destroying my performance? |
| A7. |
Yes, Emulex HBA technology has an architecture that can maintain a high level of performance even with mixed workloads such as tape backup and data base transaction processing. Unlike competitive HBAs, Emulex HBAs multiplex the frames of I/Os (Tape and Disk) rather than the whole I/O sequence. This means that a frame of a disk I/O does not have to wait for a large tape I/O data block to complete before being serviced. Other HBAs have to stall the small block data transaction until the tape sequence completes, drastically degrading I/O performance.
|
Printable version
