|
The explosion in the computer market for physically thin (2U and even 1U form factors) single-purpose servers is raising the profile of RAID storage. More frequently than not, racks of servers are now dedicated to very explicit tasks; these tasks are often as explicit as providing a Web cache and nothing else. With the typical thin server having no more than two usable PCI expansion slots, one of which is typically earmarked for network redundancy, it's imperative to maximize channel connectivity in any storage controller.
To this end, a number of companies have carved out a distinct niche in the storage market with RAID controllers sporting i960, and now StrongARM, chips. Originally, these high-powered controllers closely targeted the Windows NT arena and concentrated on providing a big performance boost via data caching. While intimately tied to all of the major Linux distributions, the ICP Vortex RAID controller family also strongly targets Windows NT/2000 systems. As a result, it's easy to look at this controller in the Windows context and miss some significant value propositions in the Linux space.
The ICP GDT7663RN, which was tested by OpenBench Labs, is made in Germany by ICP vortex Computersysteme and is powered by a 100-MHz i960 processor. A proprietary real-time multitasking operating system is embedded into the controller. What immediately distinguishes the controller for today's dense storage-connectivity needs are six Ultra160 SCSI channels; with each channel able to connect to 15 devices, support for 90 drives is connected to this one controller. Assuming that popular 18-GB drives are used, a site could easily hang 1.5 TB of storage off this device. What's more, two of the channels also have 68-pin UHD connectors for external storage connections.
The i960 runs the top-level functionality of the controller, which includes an intelligent cache algorithm with adaptive delayed write- and read-ahead functions. An LSI Symbios SCSI processor handles the actual SCSI bus communications, including double-edge clocking, cyclic redundancy check, and domain validation for Ultra160 SCSI functionality. In terms of raw, seething SCSI performance, however, the ICP RAID controller is a bit disappointing. In a Windows NT environment, this could be seriously problematic, but in a world of pugnacious penguins, it turns out to be no problem whatsoever.
We conducted all of our tests with Red Hat Linux 7.0, which is based on the 2.2.16 kernel. It speaks well that both Red Hat 7.0 and SuSe 7.0 are packaged with the latest driver software for ICP controllers. For maximum performance, we teamed the ICP RAID controller with four Seagate Cheetah X15 drives, which have a capacity of 18.4 GB and spin at 15,000 rpm. To house the drives, we used an Enlight EN-8720 hot-swappable drive module, which provides for placing five 1-inch drives in the space of three 5.25-inch half-height bays.
Since the ICP controller architecture is Ultra160 SCSI-based, it is naturally designed for optimal use in a 64-bit PCI environment. Nonetheless, like other 64-bit PCI host bus adapters, the ICP RAID controller is backwards-compatible with a 32-bit PCI slot. In fact, a quick calculation for today's 32-bit PCI buses clocked at 33 MHz yields a maximum throughput of only 132 MB/sec.
For a transaction-processing environment where most I/O is 8 KB in size, even running a spectacularly heavy load of 2,000 I/Os per second consumes less than 15% of the available bandwidth. As a result, we expected to see no difference in transaction-processing performance when we used the ICP controller in a Dell PowerEdge 2400 server with its 64-bit PCI slot from when we used this controller in a Siliconrax 2U Rax2100 Web Server. Everything went according to Hoyle. Transaction throughput was indistinguishable between the systems. Only when we ran our streaming-throughput performance benchmark did we see a difference, with peak sustainable throughput dropping from about 140 MB/sec on the PowerEdge server to 80 MB/sec on the Rax2100.
In terms of performance, the singular most enticing feature on the ICP RAID controller is the standard PC100 DIMM slot for the cache. Standard PC100 DIMMs-with or without ECC and having capacities ranging from a required minimum of 16 MB up to 128 MB-can be used for the cache. Naturally, we first went looking for a spare 128-MB DIMM to get maximum performance. We soon realized that this was a distinct mistake and reversed ourselves 180°.
Why did we go looking for the smallest DIMM we could find to put in the controller's cache? The answer to that question lies in the aggressive nature of the Linux file cache. When we began testing on the Siliconrax Rax2100 server, we had a 512 MB of RAM. Even under quiet conditions, Linux immediately assigned 305 MB of that memory to the file cache. So it should come as little surprise that when we examined the hit rate for our 128-MB cache on the controller, we were seeing a whopping hit rate of less than 1%.
At this juncture, we reduced the memory configuration in the Rax2100 from 512 MB to 128 MB and still found no significant improvement in the cache-hit rate. As a result, we reduced the onboard cache to 64 MB simply to better reflect typical user configurations. To get a better characterization of the controller's raw performance, we left the RAM configuration of our Rax2100 server at 128 MB. On the other hand, improving overall system I/O performance under Linux means putting more RAM in the system and not in the controller cache. In our tests, upgrading system memory from 128 MB to 512 MB quite literally quadrupled the I/O load-processing profile of the system as peak processing went from 400 to 1,600 I/Os per second. In a more typical load range, effective system throughput was tripled rather than quadrupled.
In terms of the absolute number of I/Os per second that we could process, our high-powered hardware RAID controller significantly lagged behind the QLogic QLA12160 Ultra160 SCSI controller that we tested in Open's September 2000 issue ("Database Dervish," p. 15) in terms of throughput on each of its SCSI buses. Through a queue depth of about 20 I/O daemons, our hardware RAID and software RAID systems provided similar profiles in delivering about 500 I/O requests per second on a RAID 5 array.
The two parted company at this point with the software RAID subsystem delivering a significantly higher level of performance headroom. This result was counterintuitive, to say the least. Examining the hit rates on the ICP controller revealed the nasty secret that on Linux, the RAM cache rules. What's more, this exercise revealed the extensive overhead that RAID processing places on the operating system. Fulfilling the I/O requests of from 50 to 75 I/O daemons consumed 18% of the CPU cycles of our Rax2100 server, which was powered by twin 800-MHz Pentium III CPUs. So while the CPU-lite benchmark program was able to satisfy close to 200 I/O daemons and keep the average response time below 100 ms, CPU cycles were entirely exhausted as the overhead went up exponentially.
In contrast, the Rax2100 was blithely unaware o f all of the work being done to provide high availability. With a hardware RAID subsystem, overhead processing is the same as if all of the requests were being directed to a very large disk. This is the big payoff!
The value proposition for a hardware RAID controller on Linux is its ability to abstract out all of the RAID configuration overhead from the operating system. The secret sauce for the ICP RAID controller is the ICP console program, which is the interface to that real-time OS running on the onboard i960 CPU. From a console terminal, running ICPCON provides the exact same interface and functionality that is available from the BIOS at boot time, plus it also provides for remote monitoring and diagnosis during operation.
Moreover, this interface abstracts out all of the RAID configuration logic more completely than any comparable interface that we've tested. In fact, at first glance, it appeared that we were opening a peanut with a sledgehammer. Only after seriously thinking about all possible configuration issues did we begin to understand the power of this configuration tool.
The four levels of abstraction that ICPCON provides can be quite mind-boggling. These levels start at the physical drive, move to logical drives, then to arrays, and then move up to host drives that are presented to the OS. Each of these levels has its own menu of functions in ICPCON. As a result, the total functionality IPCON offers is quite formidable.
Like most good RAID controllers, the ICP RAID controller supports RAID levels 0 (data striping), 1 (disk mirroring), 4 (disk striping with a parity drive), 5 (disk striping with striped parity), and 10 (disk striping and mirroring). In addition, there are the requisite RAID high-availability functions of hot-plug and hot-fix for either manual or automatic exchange of a failed disk while the system is still in operation. Checks of the parity information of RAID4 and RAID5 arrays can also be performed.
More importantly, the capacity of existing disk arrays can be expanded as a direct result of these four levels of abstraction, which make disk arrays completely independent of the computer's operating system. Migration is also possible between the RAID levels with all data remaining redundant during either capacity expansion or RAID-level migration.
In short, the ICP RAID controller nicely complements one of the biggest weaknesses of Linux vis-à-vis the Windows NT/2000 operating system: I/O configuration. Compared to Linux, control over the configuration of directly-attached storage resources is quite a trivial task for the Windows systems administrator. On Linux, administration overhead goes through the roof, which keeps many IT executives tossing and turning at night, worried about total-cost-of-ownership nightmare scenarios. For RAID storage, the ICP RAID controller levels the administration playing field.
OPENBENCH LABS SCENARIO
UNDER EXAMINATION
RAID5 hardware performance
WHAT WE TESTED:
ICP GDT7663RN, 6-channel Ultra160 SCSI disk array controller
www.icp-vortex.com
HOW WE TESTED:
Siliconrax-Sliger Rax2100 Web server running Red Hat Linux v7.0
www.siliconrax-sliger.com
(4) Seagate Cheetah X15 drives
www.seagate.com
Enlight EN-8720 hot-swappable drive module
www.enlight.com
OpenBench Labs lload v1.0 benchmark
KEY FINDINGS
· Hardware-based RAID dramatically reduces system overhead incurred when processing RAID5 parity bits in a high-transaction environment.
· The ICP configuration module, ICPCON, completely abstracts out the physical configuration of RAID arrays from the Linux operating system via four levels of abstraction.
· Full control over hot-swap and hot-fix functions via ICPCON extends to the expansion and migration of RAID arrays.
· Lackluster pure Ultra160 SCSI performance is readily mitigated by the addition of memory to the system and not the controller cache.
|
