| OPENBENCH LABS SCENARIO |
Under examination
Linux SAN performance and functionality
What we tested
Linux SAN performance and functionality
SGI Total Performance 9100 RAID Array
www.sgi.com
Texas Memory Systems RAM-SAN
www.texmemsys.com
How we tested
(2) Dell PowerEdge 2400 Servers
www.dell.com
Winchester Systems FlashDisk RAID Controller
www.winsys.com
Red Hat Linux v7.0
www.redhat.com
OpenBench Labs OBLload v1.0 benchmark
OpenBench Labs OBLdisk v1.0 benchmark
Key findings
- Red Hat 7.0 performance in the SAN was at a par with Windows 2000 Server with one exception-I/O loading.
- SAN software for Linux is quite limited and often limited to version 6.2 of Red Hat.
|
"You've got to send the cable back." That caveat eloquently sums up OpenBench Labs' first foray into the world of Storage Area Networks (SANs). When we set out to build a Linux SAN we had no appreciation for the Through The Looking Glass world we were about to enter. After all, SANs have been the coming IT panacea for nearly five years and the first major revision of the Fibre Channel hardware-from 100 MB/sec to 200 MB/sec-is about to be unleashed on the market.
What's more, Linux has been a standout no-show when it comes to SANs. From the beginning, it was Sun Solaris über alles. Nonetheless, Windows NT has made dramatic inroads over the last 18 months and now battles Solaris for the honor of being the first OS SAN software is written for. Now that Linux has become the fastest-growing OS, OpenBench Labs set out to prove that a Linux SAN was in fact feasible.
As our first criteria, we wanted to start building the OpenBench Labs SAN on a distribution of Linux that was 2.4-ready. With the new kernel set to dramatically improve a number of key characteristics of Linux for use in the data center, we wanted to be able to move to the new kernel as quickly as possible. What we discovered was a modicum of drivers and software available for Red Hat 7.0 and a disturbingly greater amount of software still only in beta that worked exclusively with Red Hat 6.2. For example, QLogic has drivers that support its QLA2200 HBAs on both Red Hat distributions, but the application to enable automatic failover for systems with two HBAs is only in beta for the 6.2 version of Red Hat.
After much internal debate, we decided to move ahead in this first phase of our project with all Linux systems running version 7.0 of Red Hat. In addition, we had intended to introduce a Windows 2000 Server into our SAN later in the project; however, we found it was essential for the configuration of one of our storage arrays right from the start.
For many people, Fibre Channel is synonymous with fiber optics, but it ain't necessarily so. While fiber-optic cables with SC connectors are the de facto standard, twin-ax copper with HSSDC and DB9 connectors are also quite common. So how does Fibre Channel deal with this dichotomy? With Gigabit Interface Connectors (GBICs) that were once called Gigabit Link Modules, naturally. While many devices-such as a Sony GY 8240FC tape drive that we tested-come with a standard SC connection, Fibre Channel switches and many HBAs come with a slot that requires a module that provides either a copper or fiber optic interface. So in addition to the pricey cables, you'll need to factor in several hundred more dollars to put GBICs on one or both ends of these cables. For OpenBench Labs, the only bad thing about setting up our SAN was the tedium of the nasty connectors.
In our tests, we used 64-bit QLogic QLA2200 PCI HBAs and SANbox-8 switches, which support Class 2 and Class 3 connectionless services with a maximum frame size of 2,148 bytes. Any or all of the eight ports may be fabric ports, which connect to Fibre Channel public devices and device loops; segmented loop ports (SL_Ports), which divide a Fibre Channel private loop into multiple segments; translated loop ports (TL_Ports), which connect a private loop and devices "off-loop"; and trunk ports (T_Ports), which allow the interconnection of multiple chassis to form larger fabrics.
As is the custom with all such devices, the QLogic SANbox switch has a Web-based GUI-dubbed SANsurfer-for administration. The GUI is quite intuitive; however, we found performance with versions of Netscape prior to 6.0 quite sluggish. Using a classic drill-down paradigm, the SAN administrator can view dynamic performance statistics for each online port. Performance data include frames-in (green), frames-out (blue), dropped frames (yellow), and errors (red). In addition, the administrator can also view name-server data for each device connected to the selected chassis, the type of GBIC installed in each port, as well as the view address, WWN, FC-4 Type, and status of each loop device connected to any port on the selected chassis.
The most archetypal device we placed on our SAN was a RAID storage array from SGI. This SGI Total Performance (TP) 9100 array was configured with 12 Seagate 10,000-rpm Cheetah drives on two internal FC-AL loops, a Mylex DACFFX internal RAID controller with dual i960 microprocessors, and 128 MB of cache. The SGI RAID array is configured with DB9 connectors for twin-ax copper Fibre Channel cables. On plugging the array into the SAN, both servers running Red Hat 7.0 recognized and were able to utilize the two logical drives that the array was presenting to the SAN.
The only problem was that there was no way to administer the array. The only way to configure the array is with Mylex's Global Array Manager and the client side of GAM runs only on Windows systems.
This is a GAM server for Red Hat 6.2, but it still requires a networked Windows PC to run the client GUI. We therefore found it necessary to add a Windows 2000 Server into the SAN. Along with providing a means to configure the TP 9100, this would allow us to compare Fibre Channel performance between Linux and Windows 2000.
Our main desire to configure the TP 9100 was to insure that the SGI array was also configured as RAID 0+1 with two logical drives in the same manner as our FlashDisk from Winchester Systems. For sites that don't need a full-blown SAN, the FlashDisk provides a powerful Power PC-driven RAID device that can be ported to multiple SCSI HBAs with no special SCSI cabling. In fact, the configuration capabilities between the two arrays are really quite minimal.
In our configuration, performance differences between the SCSI-based and Fibre Channel-based arrays under Red Hat 7.0 were also quite minimal.
It was only with Windows 2000 and I/O loading that performance dramatically differed. Because of its asynchronous I/O model, Windows 2000 Server was able to drive I/O rates on the order of 4,500 I/Os per second on the FlashDisk and 7,500 I/Os per second on the TP 9100. Both arrays topped out at 1,500 I/Os per second on Red Hat. Nonetheless, for most enterprise applications, including transactional databases, I/O rates above 1,000
are quite exotic.
More applicable to the real world is the need for high-speed data caches and streaming Web multimedia. In regard to this problem, OpenBench Labs tested a Texas Memory Systems RAM-SAN multiported solid-state disk. Memory capacity for RAM-SAN configurations varies from 4 to 64 GB in 4-GB increments. The unit that we tested had 16 GB that we configured as two 8-GB drives on separate Fibre Channel ports. The device has four parallel-memory buses available, which can each have their own Fibre Channel connection.
With our 100-MB per second SAN, streaming throughput measured on both Red Hat 7.0 and Windows 2000 Server were virtually identical. Interestingly for both systems, writes were significantly faster than reads at 90 to 93 MB per second. Reads were a more sedate 66 to 68 MB per second. Once again, the conventional wisdom of Linux performance in a SAN vis-à-vis Windows 2000 was shown not to be exactly correct.
In coming issues, we'll be testing more high-end storage devices, both in Gigabit Fibre Channel and Ethernet configurations. The long-promised upcoming convergence of SANs and NAS will play a significant role in Open over the coming months. Next month we'll be evaluating Sun's T3 Fibre Channel storage array as well as several Fibre Channel tape drives.
|
