Tiering is Dead, Long Live Tiering

The term Dynamic Tiering has really been abused in the network storage industry lately. Everyone talks about tiering in one form or another. Vendors that do not have currently shipping products talk about futures and those vendors that have shipping products do not actually disclose how their tiering works, which applications benefit, nor by how much.

Unfortunately, one of the giants in the industry has even further muddied the waters. According to a TechTarget article last week regarding NetApp’s earnings call, NetApp’s CEO said that “the whole concept of tiered storage is going to go away.” Presumably, this refers to EMC’s Fast technology, since one industry Goliath always needs to beat up on another Goliath. The unfortunate thing for NetApp, is that on the same call, they completely reversed their position on tiering when they touted the success of their form of tiering, which includes their SSD-based performance accelerator. Tiering is dead, long live tiering!

The simple truth is that no single technology has ever proven to be the panacea of data storage. SATA drives have the lowest cost per bit and are great for archival storage. FC or SAS drives offer a compromise of performance and capacity, excelling at large block accesses like those found in large sequentially read files. Solid State Devices, based on Flash, offer unsurpassed performance for random reads and small block sizes.

More importantly, the differences from one technology to another are measured by orders of magnitude, not by mere percentage improvements. Because of this, a solution that can leverage the strengths of all the technologies is guaranteed to out-perform and cost less than a solution that only uses one or two.

Rather than predicting which storage tiers will win and the capacity of those tiers in a solution, the important information needed to judge a tiering solution is how the tiers are used. Most vendors are completely silent on this. Here are three examples of the more egregious mis-steps in dynamic tiering.

The first mis-step is tiering at too large a level of granularity. Consider a solution that tiers at the volume level. If a few files in a volume become active, the entire volume will need to be promoted to a more expensive tier to get the performance needed for the few files. This results in cost inefficiency as extra data is promoted to the expensive storage and performance inefficiency as the entire volume consumes read/write bandwidth of both tiers that are involved in the promotion of the volume.

The second mis-step is not tiering frequently enough. Several vendors have proposed tiering schedules that are measured in terms of days. This is crazy. Consider the file that I am editing for this blog. I might work on this file for a few days and then rarely, if ever, look at the source file again once the blog is posted. If activity is measure across days, by the time this source file is promoted, it should be archived.

The third mis-step is not using the correct media. Most vendors actually completely avoid this question and require the administrator to set policies. In those instances where the vendor does decide, frequently wrong media is chosen.

An example of this third mis-step is to examine the two stage architecture promoted on NTAP’s earnings call – SSD & SATA. In their architecture the SSD-based performance accelerator is apparently only used for read data. All write data is sent to SATA storage. This is terribly inefficient and is even proven in their SPECsfs®08 posting. To achieve the same performance in a NTAP 3160 with the accelerator module, they required almost twice the number of SATA disks than when they run the same benchmark using FC disks (96 SATA disks versus 56 FC disks). Since the SATA disks have over 3x the capacity of the FC disks, they deployed over 6x as much capacity to store the same amount of data. This over-provisioning is a result of not tiering the media properly and is extremely inefficient in terms of space, power and equipment costs.

What is clear from all of the press on “Dynamic Tiering”, is that the term is both extremely overused and misunderstood. Because of the orders of magnitude differences in storage media costs and performance, data storage solutions can clearly benefit from tiering if executed properly.

Ron Bianchini

Adding SSD Performance to NAS-Based Applications

Today we announced the FXT 2700, which is our first product based on SLC Flash technology. In the time that customers have been evaluating this product, we have talked to many organizations interested in testing the benefits of SSD technology. The good news is that for those looking to experiment with the performance benefits of SSD, the FXT 2700 turns out to be an easy and cost effective way to add SSD performance to any NAS-based application.

Using Avere’s 2-stage implementation, the FXT 2700 can be deployed in any vendor’s environment. Deployment and removal requires no down-time. You are not limited to the offerings of a single vendor. You are not limited to expensive internal hardware adapters, nor are you limited to entire arrays of SSD media that must be allocated to specific volumes.

The FXT 2700 only allocates the portion of the namespace to the SSD media that needs the added performance. The SSD media is shared for the entire namespace. It can be deployed in any environment with an existing NFSv3-based NAS server. And the SSD media can be scaled by clustering FXT 2700s which globally share the media across all nodes and all application workloads.

Avere built the FXT 2700 specifically to support two types of workloads, those with very high performance applications and those applications with high levels of random-access data.

For high performance applications, our typical customer is already running a NAS server, usually with costly Fibre Channel media by necessity. Introducing an FXT 2700 cluster in that environment dramatically reduces the workload on the NAS server. In some of these deployments, short stroking is used to eke out even more performance. By reducing the workload on the NAS server, the requirement for short stroking is eliminated, which effectively frees up previously unusable storage space on already spinning media.

For applications with high levels of random-access data, hard drive based NAS servers can be inefficient. Hard drives are excellent at reading data from their platters once the read head is located at or near the proper track. If the read head is not near the proper track, which is usually the case for random workloads, the head seek time reduces the performance of a hard drive from thousands to hundreds of operations per second. Adding the solid state tier of the FXT 2700 in such systems not only improves application performance, but it also allows the hard drives to be used for bulk updates, which increases their efficiency as well.

Through the FXT 2700 launch and customer evaluations, I continue to be fascinated by the many applications that users have chosen to deploy its SSD technology, even outside of our expected workloads. This breadth of applications and workloads that can be attributed to the FXT 2700’s ease of deployment, made possible by Avere’s vendor neutral 2-stage architecture, and by its cost effectiveness, in that the SSD tier is automatically used only where needed.

Ron Bianchini

Avoiding Long Lines at Christmas (and at Your File Server)

The holidays are upon us and traffic is backing up everywhere. I don’t do much of the Christmas shopping at my house so typically I’m not really impacted. This year is different. The Avere office is near one of the largest malls in Pittsburgh and there are lines everywhere I go. Traffic lights are backed up. The parking lot at my favorite burrito shop is packed. Even the drugstore is full of holiday shoppers.

Waiting sucks.

(Beware of segue.)

And waiting is exactly what you’re doing if you’re using a file server with high latency. Check out Jeff Butler’s blog post on this very point from last week.

Latency can kill your company’s productivity and, more importantly, profitability. Amazon found that every 100ms of latency cost them 1% in sales. Google saw a 20% drop in search usage from 500ms additional latency. TABB Group estimates that if a broker’s electronic trading platform is 5 milliseconds behind the competition, it could lose at least 1% of its flow; that’s $4 million in revenues per millisecond.

In a previous blog post, I explained how Avere is providing a high-performance NFS file server that uses, on average, 5x less disks, power, and space than competitive offerings. Avere demonstrated this using SPECsfs2008 results that can be found on the spec.org site. This time let me use these same results to demonstrate our latency advantage.

Like before, let’s compare all the results that achieved greater than 100,000 ops/sec. (Note: SPECsfs2008 reports latency as ORT, or overall response time, in msec.)

Avere FXT 2500 6 Node Cluster: 131,591 ops/sec, 1.38msec ORT
BlueArc Mercury 100 Cluster: 146,076 ops/sec, 3.34msec ORT
Exanet ExaStore 8 Node Cluster: 119,550 ops/sec, 2.07msec ORT
HP BL860c 4 Node Cluster: 134,689 ops/sec, 2.53msec ORT
Huawei Symantec N8500 Clustered NAS: 176,728 ops/sec, 1.67msec ORT
NetApp FAS6080 FCAL Disks: 120,011 ops/sec, 1.95msec ORT

Avere is the clear winner when it comes to latency (i.e. ORT). The average of all the non-Avere latencies above is 2.31msec. This is 67% higher than Avere’s latency of 1.38msec. This difference can have a huge impact on application performance and the productivity and profitability of your business. For example, this can mean completing a large data processing job in an hour on Avere rather than an hour and forty minutes on average with the other solutions. Add this up across all the people and jobs in your company and this can mean getting your product to market months earlier with Avere.

Don’t wait. Check out the product pages on our website for more information.

Now if we could only get some elves to help with our end-of-year shipments.

SPEC® and the benchmark name SPECsfs®2008® are registered trademarks of the Standard Performance Evaluation Corporation. Competitive benchmark results stated above reflect results published on www.spec.org as of Dec 21, 2009. Above we compare all SPECsfs2008_nfs.v3 results that achieved greater than 100k ops/sec throughput. For the latest SPECsfs2008 benchmark results, visit http://www.spec.org/sfs2008.

Jeff Tabor