« Helping To Avoid A Really Bad Day | Main | The Kids Are Growing Up »

May 03, 2010



Great write up on VPLEX. It looks really really interesting!! From a hardware-agnostic storage point of view what sort of feature overlap would you see between this and maybe a CX or DMX solution? Does VPLEX require the underlying storage systems to replicate or snapshot or does it handle all that itself? What about thin-provisioning, can it do that natively or does it utilize the underlying storage array’s feature?


David A. Chapa

Lots of information to digest...let the feast begin.



To give you a quick answer to your question..

The intent of VPlex is to do what traditional storage virtualization platforms from other vendors don't, which is to allow you to leverage the technologies inherent in your existing storage platforms - Symmetrix SRDF/Timefinder or Clariion SnapView/MirrorView, for example. Since Vplex is array aware and preserves the array's cache functionality, while enhancing performance with it's own cache, you can still use those tools. That is something you can't do with SVC and USP-V, with those products you are forced to move all of the intelligence into the virtualization layer which may not work for all of your applications. This is a differentiator for VPlex, not to mention VPlex Metro federation which is entirely unique.


Ahhh so this is like a RAMSAN. Cache on the front end, and then let the storage controllers do the rest. I get it.

Chuck Hollis

Storagetexan -- nope, not really.

-- Chuck


Hi, many times by EMC I've been told that one shouldn't use virtualization from IBM or HDS as they sit on the front of the storage, with their own cache, and they damage the performance. How is this different from those performance-wise?

Remember, on argument was that cache-in-front destroys the nice caching algorithms used by symmetrix.

Chuck Hollis

Hi Soikki -- good question.

One of the things we've attempted to do with VPLEX is to leverage and exploit array capabilities, and not replace them. Many of these early attempts had an implied model of "dumb storage, smart appliance" where we worked towards a "smart storage, smart appliance" model.

The "smart" thing that VPLEX does is pooling and caching at a distance, which I believe is an incremental capability to what arrays do, and don't attempt to replace what an array does today.

So, you won't find things like thin provisioning, FAST, dedupe, snaps, etc. in the VPLEX product -- arrays do that. Similarly, you won't find storage federation (at a distance, presumably heterogenous) in an array product.

Good question, though ...

-- Chuck

James Hindman

Hey there old boy,
Can I put this in front of an IBM XiV storage array and net all the benefits of VPlex?

Chuck Hollis

Don't know if XIV has been qualified yet, but -- technically -- yes. Why you'd want to do that isn't clear to me, though ...

-- Chuck


The question about performance impact is still open, it would be very nice to get some clarification. Thanks... :)

Chuck Hollis


There's no way to answer that in a general sense, and incredibly dependent on your I/O profile. Offering up a standard answer is a bad practice in general.

For example, a local read cache hit would probably be a "win" performance-wise. A remote cache hit might be a win, or not, depending on the distance and associated latency.

How many cacheable read hits will you get? We'd have to look at your app mix.

As I understand it, writes are passed through, and thus would be highly dependent on the underlying array's capabilities, which might be an EMC, or not, as the case may be.

You're right, anything in the data path adds a very small bit of turn-around time to I/Os passing through (vs. cached). I don't know what the exact number is, but -- given that we use the same hardware design in the VMAX, I'm not too concerned about turnaround time for I/Os that flow through the VPLEX.

I don't know if you saw Brian Gallagher's keynote, but one of the many important points he made was the incredible amount of testing we do on our products using both live workloads and replayed traces from our customers' environments.

So, if this is really interesting to you, let me know, and I can have someone more knowledgeable than I contact you.

-- Chuck


How can VPLEX be leveraged for services such as VMotion when it is difficult or not possible to stretch the VLAN 100km to geo distances?

Chuck Hollis

Hi DMyers

The version shipping today has a 100km limit, as you point out. We were also very clear that -- before too long -- the same capabilities would be offered at unlimited asynchronous distances.

The technology already does that, we just have a lot of validation work to do before unleashing this on our customers.

We also said that, after that, we'd be offering N-way clustering at a distance as well.

So, if you've got a short term need to go longer than 100km, we'd probably go with a traditional replicate-and-failover approach (using SRM perhaps).

Architecturally, there's a strong point of view that this model will quickly be supplanted by a geocaching approach as found in VPLEX.

If you're really interested, contact one of the EMC tech specialists, and they'll take you through the timelines and relative pros and cons of each approach.

-- Chuck

Christian Guérin

Hi Chuck,
I was in EMC World last week with some customers. One of them is interesting in the V-Plex scalability. In fact, most of presentations shows stretch luns between 2 V-Plex Clusters but what about the scalability of one V-Plex cluster ? I know that it starts with 1 engine to a 4 engines maximum, and after ? are we able to connect 2 V-Plex cluster together on a same DataCenter ? (is it what we call a "local federation" ?)
Tks for your answer and see you in France in June.

Chuck Hollis

Hi Christian

You'd be better off going to PowerLink and getting the real documentation, but -- from memory -- I think the answer is 4 engines in a cluster, and then federate locally to 2, which is (I guess) a grand total of 8 with this release.

But I am outside my depth here -- go get the docs, or, if you can't get them, I'll post a link here.

-- Chuck

Adrian F.

Chuck... So, what you are saying is that after 2 failed attempts to provide this level of virtualization via Invista, this one is definitely going to work? (right from scratch from what was originally Yotta-Yotta)

Chuck Hollis

Hi Adrian F

If you're going to show up with an unreasonably snarky comment like that, please do us all the favor of identifying yourself and your affiliations.

Although Invista wasn't a roaring success, it wasn't a failure either. It did what we wanted it to do. The use cases for VPLEX are very different as well, if you look carefully and resist the temptation to simply throw mud.

Perhaps the biggest problem was that we bet on an intelligent switch design vs. commodity hardware, in essence putting us on the wrong side of the technology curve.

Going forward, we're not gong to make that mistake again.

-- Chuck

Alvin Cly

Hi there :0)

When replicating between sites you mentioned it was asynchronously being replicated or it may have been from someone from the postings above. Anyhow, what happens when the link between sites are down for more than 4 hours? Obviously the changes are still at the primary site - what happens to that data? Common knowledge is that the host will slow down on what is write pending to array cache, array cache will fill up and then what? What about my change data that needs to be replicated?

Chuck Hollis

Hi Alvin

Sorry for the delay. I thought I knew the answer, but I wanted to check to make sure. This response comes from Barry Burke (aka The Storage Anarchist):

Today’s product (VPLEX Metro) provides synchronous replication only…so if the link fails, the default failure mode is identical to what most active/passive synchronous replication configurations support: one side (usually “the primary” site) continues to accept writes while the other stops all I/O.

The site that stays active will keep track of what changes, and when the link comes back, it will re-synchronize these to the remote site. The other site can be manually re-enabled to continue I/O, such as for a DR scenario when the primary site is no longer in operation.

In the future, when asynchronous support is delivered (VPLEX Geo), the actual changes will be managed in a manner similar to Symmetrix SRDF “delta set” change logs.

Like SRDF, these will be able to be buffered to (local) disk if the change sets outgrow memory. The operational models for failures will include configurable responses that mimic that of more traditional Async replication products, as well as several new models specific to the active/active Access Anywhere paradigm that VPLEX Geo will enable.

We’ll discuss these more when VPLEX Geo is announced next year.


Hope that helps ...

-- Chuck

The comments to this entry are closed.

Chuck Hollis

  • Chuck Hollis
    SVP, Oracle Converged Infrastructure Systems

    Chuck now works for Oracle, and is now deeply embroiled in IT infrastructure.

    Previously, he was with VMware for 2 years, and EMC for 18 years before that, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Vero Beach, FL with his wife and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not ever buy him a drink when there is a piano nearby.

    Note: these are my personal views, and aren't reviewed or approved by my employer.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!