Lots to talk about as a follow-on from today's discussion around virtual storage, global federation and the underlying distributed cache coherence technology that makes all this wonderful juju possible.
Most of the focus was on the specific capabilities around global storage federation, and the underlying distributed cache coherence technology that makes all of this useful and interesting.
After participating in Pat's event today, some useful questions and comments came up. I thought it'd be interesting to share the thoughts.General Reactions
The room was predictably divided between "NFW" skepticism and "OMG" enthusiasm.
I fully understand the skepticism; I too was very skeptical when I first started learning about this effort some time ago. However, that may quickly give way to "OMG" enthusiasm, as it has with many of us and the customers and partners we've shared this with.
But now I'm convinced that it's going to be useful enough for enough use cases that -- yep -- this sort of global federation of storage is going to be part of the landscape going forward.
How Do You Solve The Multi-Writer Problem?
Actually, that's handled elsewhere in the stack. Applications (databases, filesystem, clusters, etc.) have had to deal with locking issues for decades. We use existing mechanisms, and don't introduce new ones.
What we do accomplish is two things (1) making existing locking mechanisms work well over geographically dispersed storage, and (2) better information logistics behind the locking -- in having information located (real image, copy or cache) in a policy-optimized manner.
Put differently, there should be no need to change existing applications to take advantage of this newer environment. That being said, there's a *ton* of qualification and characterization work that we'll have to get done. Fortunately, we've done it before for other similar technologies, e.g. SRDF etc.
How Do You Know What Data To Cache Remotely?
We've got decades of experience around local storage caching algorithms in our array products. Indeed, the Symmetrix was the first "large cache" storage array in the industry. As a result, we know what workloads work well with cache, and which ones don't. I consider this "storage caching IP" one of EMC's crown jewels.
We also know how longline storage networks behave in the real world, thanks to plenty of experience with SRDF and related technologies at both moderate and global distances.
We've used both technologies against some of the most demanding enterprise workloads on the planet -- a segment where EMC earned its initial success.
Put these three knowledge bases together, and we believe we've got a unique leg up on a successful solution.
Is This Vision, Or Is This Product?
We wouldn't be sharing a vision without real products coming to back them up. As Pat mentioned, this stuff is in use today in real-world customer environments, and they're pretty excited about it.
Then again, seeing is believing. As an example, I didn't believe that Vmotion could do what it said it could do until I saw it with my own eyes. And I'm probably not alone in this regard.
Is This Yotta Yotta's Product?
No, not really. We did get a nice piece of cool IP from them around distributed cache coherence algorithms as a starting point, but you'd be incorrect in thinking this is the same technology that they were selling a while back.
What Are Your Competitors Doing?
We're not aware of any similar efforts from any competitors -- large or small -- on this specific technology. Now, if it's successful, that won't last forever, but none of us have heard of anything remotely similar.
Where Will You See Initial Adoption?
Anyone who owns more than one data center seems to be intently interested -- simply because it can move them to a pooling model vs. a hardwired role model. Service providers see this as an enabler of a new class of IT services targeted at the enterprise.
How Will This Be Coordinated / Orchestrated / Managed ?
That's a good question, since we don't want to introduce Yet Another Thing To Manage. So the proposed technology can be managed in three ways, depending on customer choice -- as an extension of the storage environment (think ControlCenter), as an extension of the VMware environment (think vCenter plug-ins), or as an enterprise orchestrated service (think Ionix).
Going a bit farther, there's a lot of work going on in capturing "policy hints" from applications -- whether isolated or in groups. To the extent an application can tell us "these are transaction logs" (as an example), we have that much more information to exploit.
How Does This Fit In With Cisco?
Like all useful technologies, it's best when it can be used in a vendor-agnostic way -- storage, network, application, hypervisor, etc. That being said, there are a *ton* of optimizations and integration that the network could provide with this use case. And that's a great oppotunity to work with Cisco, VMware and others in this regard.
Will This Be Part Of The vBlock?
I think that it's safe to say that eventually the answer has to be "yes". I mean, the idea of multiple vBlocks acting as a tightly federated cluster over short and long distances -- well, that's going to be just too darn cool to pass up.
Is This Just For Big IT?
No, not really. The technology scales down to a very reasonable price point. I think we all have different opinions, but the idea of a smaller IT shop (a) being able to pool in their data center, (b) support remote operations, and (c) being able to federate with compatible service providers -- well, that works for me.
What About Security?
Sure, security is an important discussion -- not only with traditional IT approaches, but especially as we think about newer IT-as-a-service models. This particular technology discussion is rather independent -- it's about moving block abstractions around -- and, of course, they have to be secured, audited, compliant, etc.
I think that first they'll have to understand what we're doing, and second start hearing more questions from their customers. I'm sure we'll have some healthy FUD-slinging from the usual suspects -- all part of the fun.
Some storage vendors may choose to invest in this technologies, others will choose to pass. Too soon to tell how this will play out.
This Sort Of Sounds Like Atmos StorageYou're right -- it does. Atmos storage was our first serious foray into federated storage models.
However, Atmos has a very specific use case tied to object-oriented storage models. This technology, on the other hand, is targeted at more widely usable block models.
How Will You Deliver It?
The answer is -- it's software, so it can potentially delivered in a variety of ways. Pat was pretty clear that the logical starting point was an appliance that works with what people have today -- which makes sense, if you think about it. But there's no real reason why we couldn't easily make this a feature of the array, or even a completely abstracted virtual machine.
Don't You Need Cooperation Up And Down The Stack?
Not exactly -- we're presenting a block abstraction that works pretty much like every other block abstraction.
Put simply, it looks like any old disk or LUN or whatever. Because the abstraction is so low-level, there's no mandate for cooperation or integration with the rest of the stack.
That being said, yes, there's plenty of opportunity for stack cooperation and integration going forward.
Does This Only Work With VMware?
VMware is an excellent example of a great use case, but not the only one. Again, since we're presenting a low-level block abstraction, anything that knows how to read and write data to a block device (or a file system that uses a block device) is a candidate.
When Will We See Shipping Products?
Stay tuned, please ...
Comments