https://slotsdad.com/ - casino online slots

Tears of Storage

by Administrator on February 20, 2010

NetApp’s Georgens said aloud the other day that automated tiering of storage is not the hot button that everyone is making it out to be.  As reported by Tech Target,

Georgens maintains automated tiering is definitely overrated, although it’s being hailed as another “must-have” offering within a year or so due to the rise of Flash solid state drives (SSDs) in enterprise storage. NetApp’s smaller competitor Compellent has been trumpeting its Data Progression software while EMC is pushing its burgeoning Fully Automated Storage Tiering (FAST) technology. Georgens downplayed tiering when asked about FAST. He also downplayed FAST.

Apparently, this quote raised the hackles of companies offering automated tiering. Compellent sent out the following message to editors, including mine at ESJ.com.

Compellent Technology today issued a statement on recent remarks NetApp CEO Tom Georgens made that the “concept of tiering [storage] is dying.”

Bruce Kornfeld, vice president of marketing, Compellent, said:
 
The only thing that’s dying in storage is static data and the belief that the same old storage systems are intelligent enough to sort and store increasing amounts of data in a budget-constrained world. Any vendor who believes that automated data movement is not the future of storage either misunderstands where the industry is headed, or simply can’t offer this feature in their portfolio. For some vendors, automated tiered storage is hard to deliver but most acknowledge that it is becoming a core requirement – just look at EMC’s recent intentions with FAST. The fact is, if data isn’t being actively used or accessed by applications, why would anyone keep it on expensive storage if they don’t have to? 

Compellent’s Fluid Data storage enables automated tiering at a granular level between any drive technology, speed and even RAID level. Shifting data between SSD, FC, SATA, and SAS works quietly and unobtrusively in the background. Businesses want a “set it and forget it approach” and that’s why automated tiering has proven popular – because it saves customers a lot on disk drives, space and power costs. The fact that most large, legacy storage vendors are now introducing their own solutions only validate that customers are asking for automated tiered storage. Automatic tiering is one party no storage vendor can afford to miss.

Looks like another little war is shaping up over the worthwhileness of on-array tiering.

I asked around, and one guy whose opinion I respect and whose firm builds high available storage infrastructure for Global 2000 firms, chimed in:

I find the discussion amusing. First of all why would any consumer  want to pay premium prices to support archive, secondary or tertiary storage? Does warehouse space cost as much as prime office space? Of course not, hence rational consumers should value their types of storage differently. Automated Data Movement might be a cool set of buzz words, but I am pretty certain that the majority of our customers do not have the concept on their top 5 issues to deal with in 2010. Just because something is a feature set that the major OEM’s are incorporating in their proprietary firmware does not mean that most customers will use it. For example, how many folks that you know  have a clue of how to use all the features in Microsoft Office’s biggest applications? Similarly, few customers use all the features that the OEM’s include in their packages.
 
As companies are forced to find efficiencies and cost savings within their storage architectures there will be a trend toward commoditization in hardware and software. As automated open source tools for Hierarchical Storage Management become mainstream, there may be an adoption of these tools. Just because something is in vogue by the early adopters of a market niche does not mean that it will be embraced by the broader market for the long term.
 
There may be a profitable niche for the technology, but vast market acceptance for any product or service  is serendipity.

I couldn’t have said it better.

I would add that, IMHO, functions like automated tiering are best performed off of the array controller, if at all.  I think that HSM as presently conceived is a blunt instrument for data management.  I think that Novell’s latest File Management Suite is worth a close look by anyone who is really interested in doing intelligent tiering.  Dave Condrey et al are doing some remarkable things to improve the positioning of data based on a variety of business and capacity variables.  A webcast covering the latest version is here.

I like some of the savvy things that Novell is saying and doing of late.  I have been holding on to this snippet from a ZDNet Asia publication I was reading in flight during my recent travels (WiFi on Delta is great!).  Quoting Novell’s CTO for Clouds,

Not all servers can, or should, be virtualised, according to Novell cloud-computing chief technology officer, Moiz Kohari. He urges cloud service providers to focus on making their heterogenous setups work as one.

In an interview with ZDNet UK’s sister site, ZDNet Asia, Kohari said virtualisation has yet to overcome I/O (input/output) latency issues at the hypervisor level, as compared to provisioned servers. As a result, virtualisation is not the best choice in cases where service providers and businesses need to ensure as little latency as possible — for example, in a stock exchange environment, he explained.

And with adoption hovering at 20 percent, according to Gartner, though some put it at a lower five percent, server virtualisation deployment remains a far cry from the mainstream adoption that vendors had expected would happen today.

Somebody is doing their homework.

{ 3 comments… read them below or add one }

johndias February 20, 2010 at 12:17 pm

(disclosure – I work for Compellent as a pre-sales Storage Architect)

With respect to your trusted advisor I would disagree with the parallel between automated functionality within block storage devices and features in MS Office. The entire point of automated tiered storage is to allow the user the advantage (i.e. $$$ saved and efficiencies gained) of data lifecycle management without the complexity of implementing and managing the infrastructure to deliver this service.

Implemented properly, as Compellent has done, automated tiering should provide lower capex and opex without adding a whisper of complexity.

Not sure why tiering in the array is anathema, Jon but I can tell you this – it’s a heck of a lot easier to manage data tiering on an array than within multiple file systems and data stores. And that’s coming from someone whose opinion I trust and who ran enterprise storage operations for 10 years (me!) 🙂

Administrator February 20, 2010 at 5:08 pm

Received via email:

“I would add that, IMHO, functions like automated tiering are best performed off of the array controller, if at all. “

Spot on, Jon. The hype surrounding “automated” (it’s really neither automated nor dynamic, if you peek under the hood) storage tiering is ridiculous. What it really is – a scheme to sell more drives, not less and a scheme to insure more tier 1 drives are sold. The consumer ends up spending more for the same storage requirements!

Administrator February 20, 2010 at 5:39 pm

Hi John,

My intent wasn’t to diss Compellent, but to examine a larger issue. If you are a small IT shop with server admins doing storage admin work and one array — say, Compellent’s — I guess you could legitimately claim that doing tiering on one array automatically could save some time and effort. This is especially true if you are only interested in moving bits around without reference to their actual content or value to the organization.

As someone who managed 16 data centers for several years, I have to disagree that on-array tiering is a good idea for a large enterprise. Here’s why (and you can feel free to disagree with me):

1. On-array tiering places your archival data on the same rig as your production data. As I see it, you are paying an inflated price for disk to support the archival data, which probably belongs on tape rather than disk, with inflated Tier 2 disk price being a reflection of licensing costs for the tiering firmware.

2. Tiering is not just about capacity allocation efficiency, but also about utilization efficiency. Allocation efficiency favors placing less frequently accessed data (usually data that has gone to sleep completely!) somewhere other than your 15K spinning rust (FC or SAS disk) that tends to have lower capacity and higher price. SATA has greater capacity, but less performance — so some data that is only occasionally accessed should reside on SATA. For the most part, sleeping data of archival quality should go to tape or even optical. That said, I am ultimately concerned more about utilitization efficiency than allocation efficiency. Utilization efficiency considers the value of the data to the organization and requirements imposed on it from business considerations such as regulatory retention requirements and criticality. A simplistic watermark-based shuffle of data from T1 to T2 (tier 1 is X percent full, so migrate older files to tier 2) is bullshit, whether you perform this function automatically or manually. So is the migration of data based on date last accessed or date last modified metadata stamps. These methods ignore data value and business context in favor of simple capacity management. The real value of tiering is assigning data the service it needs — the right storage resources and protections — based on the data requirements.

3. Assuming that automatic tiering can be done in a granular manner that considers data value and business context, I would contend that it should be delivered as a service that can be used across all infrastructure, not as a function dedicated to a proprietary array and embedded on its controller. The array controller is already bloated. The software breaks more often than the hardware. This is partly a reflection of the testing matrix required to vet array controllers with a lot of embedded “value-add” functionality. Testing is too complex, according even to engineers who work for brand name array makers. I like all of this array controller enhancement foo to be done in an independent software-based abstraction layer, not on the array hardware. Watch Ziya Aral’s video a couple of posts back. He makes the case well. The things best done on the array controller are things related to the operation of the disk itself, such as RAID or RAGS, drive remediation, and configuration/setup. Everything else, from automated tiering, de-dupe, thin provisioning, etc., should be done as a software service that is extensible to all disk subsystems. Otherwise, we end up with a bunch of proprietary stovepipes that usually can’t be managed in common.

I respect your years of experience. My experience leads me to a different view.

Previous post:

Next post: