STRATEGIC STORAGE    
 

OpenBench Labs tests a Titan of high availability.

    
  by  Jack Fegreus      
     
  As companies like Sonera Entrum and Tommy Hilfiger move Linux into a mainstream and even mission-critical IT processing roles, no CIO can afford to dismiss this operating system as a toy for geeks or simply a cheap way to host a web site. As Linux or any OS moves into the limelight of support for critical IT functions, the issue that naturally takes center stage is high availability. And when that happens, the threshold for what constitutes an acceptable subsystem becomes much more stringent.

Whether we are simply talking about best practices in device redundancy or have escalated the construct of high availability all the way up to HA-clusters, one of the critical components is always a high-availability storage system. These systems customarily include a RAID controller, one or more disk enclosures, disk drives, rack-mount or desk-side cabinetry, and now frequently a uninterruptible power supply or at least provision for one. Among those integrated components, foremost in importance is indisputably the RAID controller, which dictates overall functionality and plays no small role in system performance.

  
       
 
OPENBENCH LABS SCENARIO
UNDER EXAMINATION
Dual-port external RAID

WHAT WE TESTED
CMD Titan CRD-7040 RAID controller
Vision Storage Management Utility
 http://www.cmd.com

HOW WE TESTED
HP Netserver LP 1000r with 512MB RAM
Dell PowerEdge 2400 Server with 512MB RAM
http://www.hp.com
(2) QLogic QLA12160 SCSI HBA
http://www.qlogic.com
SuSE Linux 7.3
Windows 2000 Server
 http://www.suse.com
Cremax ICY Dock MB018 http://www.cremax.com (4) Seagate Cheetah Ultra160 SCSI Drives http://www.seagate.com
OBLdisk
OBLload

KEY FINDINGS
 Sequential data throughput on the DuraStor 6200RS consistent with PCI-based RAID controllers.
 Best overall performance measured with ReiserFS and JFS file systems.
 Transaction processing benchmarks using OBLload benchmark demonstrated significantly lower results when compared to the performance of a similar configuration using an HP NetRAID-2M controller.

 

Because of the importance of the RAID controller’s role, OpenBench Labs departed from our routine practice of testing only end-user products and took on the task of playing a storage systems integrator. The product in question is the Titan 7040 RAID controller from CMD Storage Systems.

 CMD has long been noted for excellent dual-porting support of shared SCSI devices in HA-clusters. Recently, the company was acquired by Silicon Image Inc. Now a new Java-based Silicon Image Vision Storage Management Utility (Vision SMU) has been released for all members of the Titan controller series—both SCSI and Fibre Channel—that dramatically enhances the configuration flexibility of the controller on Linux, HP-UX, Solaris and Windows.

Sadly, what immediately sets apart Vision SMU is the fact that it does what a Java application is supposed to do: run on any system that supports a Java Runtime Environment (JRE). After testing countless direct-attached, NAS-attached, and even SAN-attached high-end storage systems that work with Linux, but must be configured on Windows, it’s surprisingly just how refreshing it is simply to have a choice. Vision SMU communicates with each Titan via an RS-232 port or an Ethernet port, which makes each controller manageable from any point on the network without restrictions.

 From a pure hardware architecture viewpoint, the Titan 7040 stands out through the integration of best-of-breed components. All of the critical components are naturally hot-swappable. The taskmaster for each internal controller—the Titan 7040 can have two internal controllers—is an SA-110 StrongARM RISC CPU clocked at 233 MHz. Each controller can be configured with up to 1GB of cache (512MB when mirrored) using two industry-standard 168-pin, unbuffered PC100 ECC SDRAM DIMMs. With two internal controllers, the Titan 7040 provides transparent fail-over and fail-back of its controllers for any host.

  
     
 

Whether configured with one or two controllers, each Titan 7040 has two distinctly configurable host bus interfaces with in and out ports. These Ultra2 SCSI Low Voltage Differential (LVD) ports can be configured to support everything from a single computer with a single SCSI HBA to dual computers each having dual redundant SCSI HBAs. In turn, there are two Ultra160 SCSI LVD ports, which support two independent disk buses.

That gives each Titan 7040 a potential pool of 28 Ultra160 SCSI drives from which to create RAID sets. These sets can be configured as simple single drives (JBODs), striped volumes (RAID 0), mirrored volumes (RAID 1), striped and mirrored volumes (RAID 0+1), and parity volumes (RAID 3/5). In addition, the disk bus ports support Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.), which reports on mechanical or electronic degradation of components in order to predict and warn about possible future failures.

 When the underlying multi-channel architecture of the Titan series controllers is combined with the Vision SMU configuration software, the result is an extraordinarily flexible subsystem for any IT configuration. To test the possibilities, we configured an I/O subsystem using a Cremax ICY Dock, which provides for 4 1-inch hot-swappable drives with 80-pin SCA connectors in a form factor that occupies 3 standard 5.25-inch drive bays. We used this dock to support 4 Seagate Ultra160 disk drives. For cache, we configured each controller with 192MB.

The initial configuration of a RAID set with Vision SMU is little different from the steps required by numerous other subsystems. In our case, we configured our 4 Seagate Ultra160 drives as a RAID 5 stripe set (RAID Set 0) and made the owner controller A. Then we proceeded to set up a working dual-port configuration with a Dell PowerEdge Server running Windows 2000 and an HP Netserver running SuSE Linux 7.3. What's more, we were able to virtualize the storage so that it was impossible for an administrator of one system to corrupt one of the volumes being used by the other system.

  
       
 

The real differences in the Titan first emerged when we began to logically partition the drive. The first example is the option to create a private partition on the RAID set to store the contents of the write-back cache in case of an unexpected shutdown.

What really makes all the difference in the world, however, is the extent to which an administrator can configure the partitions that will appear as logical disks at the hosts. Because of the multi-channel architecture of the Titan controller, each partition can be individually assigned to an individual host connection channel, both of the host connection channels, or none of the channels.

 
For our test, we mapped the first 4 of RAID Set 0's 12 partitions to our Linux server and the next 4 to the Windows 2000 server. Mouse over the Vision System Management Utility to view the Windows Administration tool which shows access to only the last 4 partitions.
 
     
 

In our configuration, we wanted to allow a Windows and a Linux server to share the same storage resources, which is an exceedingly tricky exercise given the penchant of Windows for gobbling up every LUN in sight and writing a disk signature on the master block. With the Titan controller, the solution to this problem is nothing short of trivial. We simply connected the SCSI HBA in our Windows 2000 Server to the first host SCSI port on the Titan, which is mysteriously dubbed Channel 2. There are no channels 0 or 1. In turn, we connected the HP Netserver running SuSE 7.3 to the second host SCSI port, dubbed Channel 3. With that done, we then could assign any partition to either channel using the Vision SMU GUI.

  
           
 

The result: Our Linux server saw four logical drives that we formatted as Ext2, Ext3, JFS, and Reiser, while our Windows 2000 system saw four different logical drives, which it formatted as NTFS. The only thing left to do was test the performance of the CMD Titan vis à vis the Adaptec DuraStor that OpenBench Labs recently tested.

The results were a curious mix of the highly predictable and the curiously inscrutable. The performance differences between the  journaled file systems followed the same patterns, with JFS and Reiser having the same edge using the CMD Titan that they sported in the Adaptec DuraStor tests.

 
 
         
 

Since we had increased the controller cache size by 50% and given all of the internal optimizations within the Linux kernel to leverage every possible advantage from cache, we expected to see a consistent improvement across the board within a given file system. We didn't. 

Within each file system, sequential read performance on the CMD Titan followed the same pattern as it did on the DuraStor. There was, however, one distinct difference: it was lower. Nonetheless, with 16 read threads, in every case we saw the kind of improvement that we would expect with the larger cache.

Even more intriguing was the performance on writes. Once again the relative patterns between the DuraStor and the Titan were the same. And once again the performance on the Titan was considerably slower. In fact the differences were such that we triple-checked our configuration parameters to make sure that we had not somehow negated the write-back configuration of the cache and transformed it into a write-through cache.

Our last test was our OBLload benchmark which stresses the transaction processing capabilities of the I/O subsystem. In this test, everything went as expected. With its larger cache, the Titan controller could fulfill double the number of I/Os per second that we could process with the DuraStor and could respond to twice as many processes before average access time exceeded 100ms.