|
However, if a server supports VMware and multiple Windows partitions, it might make sense to deploy an HBA with four FC ports and have a port reserved for each Windows instance. It's generally recommended to deploy one high-performance application on a VMware server along with several lower performance applications; this way, the four-port card can be configured to give a lower performing application its own port with minimal or no impact to the higher performing application sharing the HBA.
The number of HBAs and where they're placed in the server can also affect performance. When using more than one HBA in a server, the HBAs must share the Peripheral Component Interconnect (PCI) bus and its allotted throughput.
"Sometimes the bus becomes a bottleneck," says Mike Smith, Emulex's executive vice president of worldwide marketing, limiting the HBA port's ability to transfer data between the host and storage. If multiple PCI devices share the same Peripheral Component Interconnect Extended (PCI-X) bus, the clock speed of each slot may be reduced, affecting the throughput capabilities of a particular slot. The telltale signs are a general slowdown in server applications and longer transaction latencies.
The use of path failover and load-balancing software should enhance server performance and availability. Software such as EMC's PowerPath and Symantec Corp.'s Dynamic Multipathing (DMP) identifies available HBA ports and then spreads I/O across the ports to increase the traffic flow between the server and the storage array. This software also helps to increase the server's availability. If an HBA fails, or one of the paths associated with it through the SAN becomes unavailable, the software labels the failed HBA as unavailable and reroutes traffic to other HBAs under its management. The main shortcoming of these products is that they generally work with only a limited number of storage arrays or require other foundational products, such as Symantec's Volume Manager.
You should also verify that the latest firmware and appropriate drivers are loaded on the HBAs before they're put into service. This ensures that the latest HBA-tuning features are installed and that the HBA is compatible with the various devices in the SAN environment. Most operating systems like AIX, Sun Solaris and Windows include HBA drivers that automatically detect and configure HBAs. But these drivers don't include optimized settings that some HBA vendors offer for certain vendor's storage arrays; they also don't alter the HBA's internal settings for performance-intensive applications.
Modern HBAs are automatically configured based on the number of target logical unit numbers (LUNs) they detect. For instance, the queue-depth setting--the number of pending I/Os an HBA can hold while waiting for responses from the target LUNs--is managed dynamically by the HBA's firmware. Initially set at 32, the queue-depth setting is adjusted as users add or remove LUNs.
But for high-performance environments, users need to configure the HBA's I/O coalescing setting. HBA vendors find that with most HBAs deployed in low-performance environments, this option is turned off even though each I/O generates a server CPU interrupt. Turning it on allows the HBA to pool I/O requests and bundle them. Once the bundle or buffer is full, only one server CPU interrupt will be generated for each bundle when it's sent, rather than producing one CPU interrupt for each I/O.
|
