Building Storage Shouldn’t Be Trick or Treat
Storage purchasing with an eye toward promised "treats" may ignore the "tricks" that follow.
With Halloween having become a high holiday for many, and revenues from sales of decorations, candy, and costumes rivaling those of Christmas festivities, the similarities between trick-or-treating and storage purchasing are too compelling to ignore.
Many times storage purchasing is made with an eye toward the promised "treats" that a new array or fabric will deliver, while ignoring the "tricks" that vendors sometimes play when marketing their wares.
Begin with capacity, the number-one driver of storage acquisitions. Disk drive manufacturers will say that capacity improvement is the only factor that can be counted on to drive unit sales. It's not that speed is unimportant, but capacity improvement has a much stronger connection with actual purchasing than any other attribute of disk products. In fact, the pressure is constantly on disk engineers to reduce the number and complexity of other drive components, such as read/write heads, in order to pump out more high-capacity units at a lower price.
The array makers have also become wise to this rule of thumb. Many are now offering ranks of high-capacity drives, usually Serial ATA drives with Perpendicular Magnetic Recording technology that increases drive capacity into the terabyte range, to serve as a second tier of storage inside the array. They can, therefore, brag about how much data you can store on their box, even if you never will grow the chassis to its maximum number of spindles in real life—at least not if you are looking for any sort of real performance.
Both EMC and Hitachi Data Systems are claiming petabyte capacities for their high-end products. However, theoretical attachment limits aside, the performance of a DMX from EMC is significantly hobbled if you deploy higher-capacity/slower-performing drives to achieve the theoretical capacity touted by the vendor. One IT integrator wrote to me recently that he would never deploy a box with more than a third of the vendor's advertised capacity maximum because of the performance hit he's seen.
Another tricky dimension of this high-capacity "treat" is the assertion by array makers, such as Network Appliance and EMC (among others), that re-driving arrays with higher-capacity drives will enable you to increase capacity while keeping carbon footprint requirements (aka electrical power demands) the same.
The treat is "greener" IT operations, but the trick is rarely discussed. Because SATA drives have a higher failure rate than SAS, FC, or parallel SCSI drives (as documented by Carnegie Mellon University and Google researchers), RAID is a must-have. However, RAID 5, the preferred RAID scheme used since the 1980s, becomes painfully slow when the drives in the RAID set are of large capacity. What that means is that re-driving arrays may be a code phrase for replacing gear altogether to obtain a RAID 6 or RAID n controller that handles redundancy and striping differently.
Performance and Footprints
Higher capacity drives also do not change the inherent capacity limitations imposed by other aspects of array architecture. For example, Network Appliance, with its release of its NAS operating system ONTAP 7 a short while ago, upped the maximum capacity of its high-end filer to 16TB (it was previously 10TB). Re-driving arrays with higher-capacity drives doesn't change this limit, which is seen by some as an Achilles Heel of the product. In fact, larger drives will simply top out the file space limit more quickly.
Here's a bit of dialog, recounted to me recently by an operative of a storage-engineering company dealing with a customer who had been advised by Network Appliance to upgrade his older NetApp 980 filers to newer NetApp 3040 arrays. The customer seems to have fallen prey to a storage vendor's equivalent of the traditional trick-or-treat pitch.
Customer: "I'm following Network Appliance's advice and getting rid of my 980's and replacing them with 3040's."
Engineer: "Why would you want to do that?"
Customer: "Network Appliance told me that the change will give me more performance with a smaller footprint."
Customer: "Smaller box, more capacity with 700 GB SATA drives, less power demand."
Engineer: "With 700 GB drives, you will be running Network Appliance's double-parity RAID (RAID DP). You need to in order to get any sort of rebuild performance from your RAID set when drives die, and SATA drives fail more frequently than other types of drives."
Engineer: "So, let's assume that you abide by NetApp's 16 TB limit per RAID Group. You are going to sacrifice two drives for RAID DP and another drive as a spare: that's three drives or (2.1 TB of capacity from your 16TB limit). You will also sacrifice 40 percent of the remaining capacity of the 13 drives that are left, so you now have only 6 TB usable per filer."
Engineer: "So, your footprint won't be smaller, you will just need to deploy more 3040s to get to the same capacity you currently have with your older 980s."
Customer: "But they said the new boxes would be faster."
Engineer: "Want the truth? The 980 has more RAM, more cache, and more non volatile RAM than the 3040. The 3040 has 4GB of RAM, 512KB of cache, and 512KB of NVRAM, but the 980 has 8GB of RAM, 512KB of L2 cache, 2MB of L3 cache, and the same amount of NVRAM."
Customer: "I think they said the processor was much faster."
Engineer: "Nope. The 980 uses two Intel 2.8GHz P4 Xeon Gallatin processors; the 3040 has two AMD 2.4GHz Opterons. Truth be told, there hasn't been a speed gain in processors for over two years. The Wall Street Journal just ran an article on that very subject."
Customer: "So, I am not getting a smaller footprint or better performance?"
Engineer: "Not that I can see."
As suggested by this exchange, vendor claims may not line up with actual product capabilities. My advice in this post-scare season: X-ray your vendor's treats before you consume them. There is no telling what tricks might be lurking inside even the most appetizing deal.
Your feedback is welcome. email@example.com.