Friday, January 30, 2009

Storage - Question of the WEEK

Question of the week:

In the last few months, I’ve been involved with a couple of Proof-of-Concepts. Two of these had the element of doing a bake-off between the competition (one was EMC, the other was NetApp). In both cases, the IBM system was the DS4700. Because both of these competitors have lots of features and impressive marketing, I was expecting a very competitive fight. What I wasn’t expecting, was that in both instances, the customer wanted me to explain exactly why our system, and their applications, ran so much faster than the competitions. In the case of the EMC bakeoff, during degraded mode testing, the application actually failed when the Clariion was put into a degraded mode (when cache was disabled). The only noticeable difference when the same condition was experienced on the DS4700 was a slight increase in host CPU utilization.

With the NetApp bake-off, I’ll just insert a quote from the account team;

The NetApp box is a FAS2050. In the DS4700, the LUN used for testing is striped (RAID5) across 30 physical drives; on the FAS2050, it is distributed across 26 physical drives (RAID5 or RAID6, I’m not sure). The NetApp SE spent two days configuring the 2050 in accordance with NetApp best practices. Our SE set up the DS4700 in 4 hours. The test workload the customer is using is not very big, and consists almost entirely of database reads. The customer reports 40% better performance when the test is run on the DS4700.

Answer of the week:

The quick answer is that the DS4000 line was built for speed. Our engineers maintain that as a top priority in the design process because performance is what provides the customer the best ROI day-in and day-out for the life of the system. This is also why we run SPC-1 benchmarks on every system we make. If you look at www.storageperformance.org, you’ll realize that our competition will only report certain systems, if they report any at all.

One thing that you should keep in mind is that many companies had different groups, with different goals. Typically, the storage group does not put performance at the top of their list, but concentrates on “ease of use”. While our systems are very easy to use, others remove the raid set definition from the required configuration steps as an ease-of-use feature (HP’s EVA, Equallogic, etc). This step may ease the storage administrators’ tasks by one step, but it does not help performance at all, which is why HP hasn’t published SPC-1 benchmarks on the EVA in over 6 years (Equallogic never published them). So, bake-off’s turn out to be a fantastic venue for us to showcase our products. Even storage groups can recognize the value of high performance, but it’s hard to capture that benefit from comparing PowerPoint presentations.

With respect to EMC, there are several factors that come into play. First and foremost is that they generate RAID parity on general purpose processors with their firmware. We have dedicated specialized hardware that offloads the process. The DS4000 has a full switch-based architecture that enables both controllers to have dual paths to each drives. We also have a compact firmware load that is designed around cache management with independent front-end and back-end DMA IO processing. On top of this, we have imbedded various cache optimization techniques like dynamic read-ahead and dynamic write-through. The FLAIR OS running on the EMC systems typically is a memory hog that utilizes a lot of DLL’s to expand their capability. This has some plusses, but the downside is that we usually see a performance difference in the neighborhood of 100 IOPS/drive in comparable configurations (that is huge in case you’re wondering).

With respect to NetApp, the key is that they implement Block-Level IO on top of their WAFL (write anywhere file layout) system. This means that they have a very difficult time with sequential read IOs (nothing is sequential, it’s always random). Since most “real world” applications are 80% read, the apparent write advantage of WAFL when writing data becomes a liability when reading data. To counter this effect, they employ a “reallocation scheme” process that will rearrange data on the drives to be more sequential friendly. Of course, all this effort is quickly negated when the customer starts using the storage system, so it must be run often (using many storage subsystem processing cycles).

So, as the customer base is looking for more efficient storage and more productivity out of their system, don’t be afraid to enter into a bake-off with the DS4000 product line.

Coming from the desk of:

James Latham
DS3000/DS4000 Product Specialist

Storage Solutions Engenio Storage Group

LSI Logic Corporation

jim.latham@lsi.com
www.lsi.com/engenio

No comments: