The recent announcement of the VMAX 10K brought up an interesting discussion for us storage folks: what -- exactly -- might "enterprise storage" be?
I find that the definitions offered by the industry analysts are incomplete and unsatisfying at best.
And there's certainly strong motivation for any storage vendor to slap an "enterprise" label on their product in an effort to attract more potential customers.
My credentials to offer an informed perspective are substantial, but not impeccable. I've been in the storage business now for almost twenty years. I meet over a hundred customers and partners every year, and I've been doing that for many years. My biases are to be expected: I've been at EMC now for 18 years, and have worked closely with the Symmetrix and VMAX product lines for virtually all of that time.
Like another infamous quote, I know an enterprise storage requirement when I see it.
While one might be tempted to dismiss electricity itself as a commodity, there are those consuming power who have particularly demanding needs: serious juice, absolutely dependable, handle unpredictable spikes in demand and so on.
Certainly, the power plant that delivers those services isn't a commodity :)
With that useful-but-imperfect analogy in mind, let's take a tour of what I think defines enterprise storage.
The Customer Is Different
When you meet an authentic enterprise storage customer (or someone who is in the process of becoming one), they tend to have a mature perspective on IT in general, and storage specifically. They've moved beyond buying storage tactically and on an ad-hoc basis, and are thinking of it as a pooled set of capabilities to be invested in centrally, and shared widely.
They know what they want, and why they want it. And, when you ask, there's plenty of painful lessons as to how that perspective evolved :)
At the core of their thinking is storage support for a handful of mission-critical, bet-the-business applications. If any one of them has a bad day -- for any reason -- it's not that IT team has a bad day, the company has a bad day. As in someone might get a call from the CEO.
At the same time, they're thinking about efficiency and broader requirements as well. Back to our analogy: as long as you've invested in a world-class power plant, why not plug more stuff in? The marginal cost to supply a decent storage service level to an incremental user or application is often far less than building something separate.
These same customers aren't shy about committing to a specific technology and vendor. They understand it can be a long relationship, and not just a point-in-time transaction. And they tend to look much farther than just speeds and feeds, or price per pound.
Scale Is Thought Of Differently
While there are plenty of modest-sized enterprise array customers out there (e.g. 1PB or less), some of these environments can get very large indeed.
For example, the largest VMAX 40K can reach 4PB of usable capacity, and we've got many, many customers with multiple VMAXs. It's not unusual to be routinely discussing environments with tens of thousands of volumes, thousands of I/O ports, tens of thousands of physical and virutal machines, etc.
Just as electrical power plants can get really, really big -- the same is true for enterprise storage environments. At scale that large, the discussions certainly are quite different. But it's important to note, not all enterprise storage environments are necessarily huge -- there's currently plenty of action in the entry-level market.
Performance Is Thought Of Differently
Imagine an enterprise-class storage workload: IOPS, bandwidth, read/write ratios, data skew, etc. Any one of these is rarely steady state in its performance requirements, and can often change in hard-to-predict ways (e.g. doing a database restore). When considering enterprise storage, you value the ability to handle the unexpected.
Now, take multiples of those same workloads, and put them on the same enterprise storage array. Their I/O profiles might be randomized -- or more likely painfully correlated -- like at the end of a quarter.
Back to our power plant analogy, a heat wave tends to put unusual demand on the grid.
If there happens to be more demand than supply, you'd like to have tools at hand to manage the situation: degrading gracefully if possible, quickly adding more resources, or prioritizing performance consumption as needed.
If you're a long-time reader, you'll remember that I've ranted at the poor state of affairs when it comes to industry benchmarks, and storage performance testing in general. Simulating this kind of real-world aggregate performance demand takes substantial effort, and isn't as easy as firing up a handful of servers with canned scripts.
And for the IT organizations in this category, this stuff matters. Really matters.
The architectural responses you'll typically find in enterprise storage arrays is a reflection of these demands:
- a minimum of two intelligent controllers, with a requirement to grow to far more as requirements expand
- extensive use of DRAM nonvolatile (write) storage caching within the array, in addition to flash
- closely-coupled, low-latency scale-out architectures for linear scaling and load balancing
- very mature intelligent algorithms to balance requirements against resources
- substantial amounts of compute power
- good visibility and controls in the hands of administrators
Array Availability Is Thought Of Differently
Sure, everyone cares about data availability, but the enterprise storage crowd takes it to an entirely different level. At the enterprise array level, just talking about things like RAID levels and no-single-point-of-failure is far too simplistic.
For example, advanced enterprise storage array design routinely assumes that there might be multiple concurrent failures within an array.
Data integrity is checked and re-checked for every logical operation. The health of the array is proactively monitored, and if things are trending in the wrong direction, an critical alert is raised (usually directly back to the vendor) before there's a user-level issue of any sort.
An enormous amount of attention is given to exactly what happens when power isn't available, or -- more likely -- a sequence of short power failures before a very long one :) That thinking extends to expediting storage service availability as quickly as possible when power is eventually restored.
Of course, everything has to be designed to be non-disruptive: hardware reconfigurations, logical reconfigurations, software updates -- no exclusions. You can't be shutting down the power plant just because there's a new code version.
So many availability scenarios can impact performance (failed drives, controllers, paths, etc.) so there's inevitably clear thinking about application performance impact if one or more components fail for any reason.
Having sat through so many of these technical presentations, I often use the term "redundant redundancy" to describe the architectural thinking.
Every scenario has been thought through, and the product people can take through plans A, B, C etc. for just about any scenario you'd care to envision.
The architectural choices reflect the thinking of the enterprise storage customer:
- strong preference for a minimum of four controllers, to support N+X failover scenarios (although some people get started with two)
- predictive diagnostics continually running, with an expedited vendor support capability if a threshold is breached
- non-disruptive everything: hardware, software, configs, etc.
- redundant error-checking wherever you look
- incredibly thorough qualification, code testing and progressive introduction of new capabilities
- performance considerations when multiple components fail
EMC note: we use the notion of DU/DL (data unavailable or data lost for any reason whatsoever) to measure storage array availability. It's far more reflective of customer requirements than the more familiar MTBF (mean time between failure). I have been told that the ESD team (includes the VMAX folk) have DU/DL fleet stats as a part of their compensation program -- which means that should one of our customers have a painful day, the entire product group will also have a painful day.
Now that's what I call alignment of incentives:)
Array Manageability Is Thought Of Differently
Just like running a power plant, running an enterprise storage array means you're delivering critical storage services people count on. You've got to be able to provision new customers quickly and efficiently, monitor service level delivery, and get to root cause immediately if there's a problem of some sort. And, of course, you need all sorts of detailed reporting against the shared asset -- utilization, performance, availability, chargeback, etc.
Like power plants, enterprise storage assets must have an exceptionally long useful life -- longer than the norm in the rest of the industry.
That means being able to mix-and-match old and new hardware as much as possible, continually adding new functionality for older technology, and providing incredibly long support periods after the product is no longer being sold. Given the rapid pace of the industry, recent examples include things like adding newer flash drives to an all-disk array, or adding FCoE to a box originally configured for FC.
You want your power plant to be able to leverage all the new tech for as long as possible.
Business Continuity Is Thought Of Differently
All that valuable information, all those important applications -- is it any surprise that enterprise storage is where most of the great business continuity technology comes from?
The key supporting technologies of local and remote replication are advanced to a very high state in any enterprise storage array environment -- not only in performance and scale, but robustness, efficiency and application integration.
Newer technologies that support advanced active-active topologies (e.g. EMC's VPLEX) are also very much in demand by this crowd.
Not only is the best technology in play, you'll also find the very best processes and methodologies for configuration, testing, automation and management of business continuity scenarios. In many of these environments, "good enough" isn't -- it's got to be the best available.
There are other important aspects I could dive into: security and auditability, configuration management, customer services, etc. -- but I think the above is enough to give you a flavor.
The Customer View -- Again
Give me five minutes with an IT group, and I can tell whether they're an enterprise storage customer or not. Give me ten minutes, and I can tell if they're in the process of becoming one -- simply because their needs have evolved.
The storage marketplace is a large and diverse beast. There appears to be an infinite variety of segments and subsegments, with new ones being created all the time. Vendors who are adept at targeting the interesting portions will have a strategic advantage over the one-size-fits-all crowd.
But one thing that really hasn't changed much over the last twenty years are the needs of enteprise storage customers. The product answers keep getting better, of course -- that never changes. For those who loudly proclaim "enterprise storage is dead", well -- I'd encourage them to get out more often.
If anything, the opposite appears to be true. The reason is simple: as enterprise information grows -- in both volume, velocity and importance -- we're seeing more customers with enterprise-class storage requirements than ever before.
How do you think about enterprise storage -- especially if you're a user of enterprise-class storage array products along the lines as I've described?
Agree? Disagree? Have a different perspective?
I'd love to hear from you in the comments section ...