VNX Inyo is going to blow some minds….

VNX had an incredible 2011, and 2012 is looking as bullish!

So – what’s new?

In Rich Napolitano’s keynote – the standout to me is the preview of the upcoming (2H’12) VNX software upgrade – codenamed “Inyo” (because code names are cool).   This has 6 big features that will help our customers get more out of their existing infrastructure:

1. 50%+ higher core efficiency.
2. Mixed FAST VP pools
3. FAST VP pool automatic rebalancing
4. All-new snapshot behavior
5. Appsync
6. Storage Analytics package

Read on past the break for detail and some additional color.

1) More efficient storage pools – with larger RAID groups, with the same protection and rebuild characteristics.  

EMC tends (not always, but tends) to be relatively conservative around the IO stack.   It’s one of those things you can only take deadly seriously – as a “bad storage day” is really, really bad.   The VNX engineering teams looked at the stats across all our customers – and also at the increasing CPU horsepower in the Storage Processors in the VNX, and realized we needed to open up some additional RAID options.   This means that between faster rebuild times, relative lower parity penalties with CPU horsepower, hot-sparing and more – they all that translates into larger RAID groups being possible within storage pools.   The parity configurations that are added are 8+1 for RAID 5 (used with 10K/15K SAS or SSDs) and 14+2 for RAID 6 (target is NL SAS).   While I expect that it will take time for the customers to really adopt the 8+1 RAID 5 config – I expect the 14+2 RAID 6 for NL SAS to become the defacto model rapidly.    These net out to a 50%+ efficiency improvement, and when you consider we fared well against other when it came to efficiency before this – it’s upside :-)

2) Mixed RAID types in a storage pool!

This is, IMO, the #1 feature request from current customers: “can I mix different RAID types in a storage pool”.   Before the answer was “no”.   Customers are digging the new “create a pool and just go” provisioning model – but today, when you create it, the RAID type of the underlying disks in the pool are the same – and that’s not as efficient as it could be…   With Inyo, you can have differing RAID types in a pool – meaning you can have large RAID 6 for Nearline (NL) SAS, RAID 5 for 10/15K SAS, and RAID 10 or RAID 5 for SSDs – simple and efficient.

3) VNX FAST VP Pool rebalancing!

This next one is probably the #2 request from customers :-)   Customers would configure their pools, love it, and then want to grow the pool (most commonly in either the IOps vector by adding SSDs, or in the capacity vector by adding NL SAS), they would expect (naturally) that the pool would rebalance.  Until Inyo, it doesn’t.  The good news is that Inyo has a fundamental update to the the “virtualization/indirection” (think of this as the block mapping layer) code layer in VNX-OE that makes FAST VP work better overall, including rebalancing pools.   BTW – this continued investment in this pooling/abstraction layer will continue to pay dividends, making the system perform better, and also be able to continue to add additional features.

4) Brand new VNX Snapshots!

This is a ground-up re-write of snapshot behavior in VNX.   Like the FAST VP pool rebalancing – this is dependent on the pooling/abstraction/virtualization layer of the VNX-OE code, and has nothing in common with SnapView.   It uses a pure pointer-based “reallocate on write” model rather than the Copy-on-Write model of SnapView.  No Reserve LUN Pool.   No Snapshot sessions.   Auto-deletion policy.   Simple.  

This has a dramatic increase in the scale (both per device and per array) and function (nested snaps).   One thing that is cool is that you can create a clone of prod into another storage pool, and then take snaps off that clone to isolate the snaps from prod if you want.    Also cool – all the goodness that people expect with respect to consistency groups has been maintained.   There’s still a lot of work to validate the performance envelopes (I’m particularly curious about the snapshot delete behavior – that’s always the bugaboo with these pool/pointer based models), but expect more right around the corner.

Personal Sidebar: It’s interesting to see how both VNX and VMAX are keeping the things they did well (SnapView Clones worked well, ditto with TF/Clones), but are re-architecting their snapshot models as the core architectures move to pool/virtualized based models.   Everyone now uses this redirection mechanisms in their core architectures – IMO we should have been using this snapshot approach sooner.   The startup I came from into EMC was using a virtualized pool model with Reallocate on Write snaps – back in 2001.  While I’m a huge fan of EMC – sometimes it takes us time to realize errors in our ways, and when you are big with loads of customers – change can be harder than when you are small.  That said - when it happens, we do realize it, and work to fix.  I wish we had done it earlier, but I’m glad to see we’re doing it.  

5) AppSync!

Replication Manager is the EMC tool that integrates applications and storage replication.  It’s one tool, and one that covers a ton of use cases, applications, and recovery/replication technologies.   But… It could be simpler.   AppSync is designed to (like ProSphere is doing for Control Center) start with simpler use cases, be re-architected for simplicity and scale, and then over time, cover the set of use cases that Replication Manager covers today. 

From a simplicity standpoint, AppSync is much simpler than Replication Manager.  It integrates with the Unisphere UI, so can be “part of the array”.   It also has application modules (people want to drive protection from the application context) – so for example, there will be a vCenter plugin (the next major version of VSI), an addition to the EMC System Integrator (ESI) for AppSync.

Beyond that – we got feedback that agentless is preferable, but where a host agent is required (VSS operations, log handling during restore), we needed to think about the maintainability – in other words, push install/update need to be part of the thinking.

Out of the gate, AppSync will support Exchange and SQL Server use cases – and then expand to cover Sharepoint and then others (like Oracle/SAP).

…  While the above are all big news – I think this one might turn out to be the biggest:

6) EMC and VMware collaborate on the VNX Storage Analytics pack – which is based on a custom vCenter Operations and VNX Connector integration.

I’ll put it this way: EMC has worked with VMware and we will be providing a version of vCenter Operations targeted (and priced) to be included with almost every array.  

This is a customized version of vCenter Ops designed to be included with the array, and used by both the VMware administrator and the Storage Administrator.   It includes the EMC VNX connector which does more than just pass data – it helps correlate core issues (performance, availability – anything that could affect health) from the VM to the array innards.

It will be very easy for customers when they see just how cool vCenter Operations is to look to see how they could provide the same intelligence to other parts of their infrastructure and check out the full vCenter Operations Enterprise.

I would be remiss if I didn’t point out the pioneering efforts of a couple vSpecialists (Clint Kitson, Matt Cowger – feel proud!) who invested a lot of personal effort into initial prototype vCenter Operations connector development (at VMworld 2011) and are plugged in to the engineering teams as it has been productized.    It’s no coincidence they were up with Rich during his keynote doing the demo :-)

Once again – I’m so proud to see folks on the team innovating, and then working hand in hand with their engineering brothers/sisters to turn an idea into a product!

Cool stuff coming from EMC in VNX-land…   Customers – what do you think?

Comments

[paul]

Any chance the VNX snapshot allocate on write technology will be available for Celerra software updates?

[INDStorage]

Chad,

I will give you credit for the last bullet (6). That looks impressive and is inline with my expectations for what I now expect out of EMC-VMware integration. Kudos on that.

While everything above that is good to see, and some of it looks cool, the VNX updates are long overdue......and technically still not here yet.

[bob]

Will appsynch require rdm luns, a big drawback why we could not use replication manager.

Using vmfs luns would be quite useful.

Also do you need vcenter ops for the Storage Analytics as a component ? or can it be stood up alone.

[Petar Smilajkov - Peconi]

I second Paul - we need some of these features on Celerra - are we going to get it? Say auto-rebalancing of pools, etc. It was promised!

[CSC_China]

Those are great news!!! Hopefully, we have most of features with non-disruptive migrations from the old ones.

Hello Chad, I'm wonderring if there is any news or rumar about VNX FAST VP Private LUN.

Since the granulary is 1G for allocating space. I think if the VNX FAST VP Private LUN size reduce to 1GB, it helps about FAST VP pool automatic rebalancing. Because VNX OE can simply use "LUN Migration" to migration some PP LUNs of a VP LUN to the other PP LUNs - it's a FAST VP auto-rebalancing.

And most important it helps resolving the VP LUN trespassing issue, because VNX OE can just simply trespass all the PP LUNs of a VP LUN to the other SP. The trespassing of a VP LUN is really a big concern of mine, and it's really costly for migrating VP LUN to the other SP with "LUN migration".

[Mike Sheehy]

Much improved and needed features. Can't wait to get my hands on Inyo and the Analytics vCOPS.

[Just a guy]

I was wondering, doesn't the New snapshot method require a new SRA to be written for SRM on top VNX?

[Squillmo]

This all sounds like a step in the right direction... I heard that block based replication for Celerra might also be included... (would allow use of consistency groups and replication over fibre etc.) Anyone know anything about that?

[50mu]

Cool post Chad!

[Anonymous Coward]

I completely agree with your personal sidebar post. To be honest coming from a vendor where reallocate-on-write type model to a COW model - I found it quite aggravating. I'm very much so looking forward to this!

[rd]

Will any of this get into VNXe?

[Jona Blocker]

Replication Manager does not work with INYO code FYI

[Hampus]

Guys, have you any input regarding performance impact when using VNX snapshots and other possible limitations with the product? We've been testing it and found some issues with performance impact and slow snapshot delete process causing the MAX snap per LUN (256) to kick-in. We are an old netapp shop which has switched over to VNX and when someone says "we can do 256 snapshots per lun" we tend to trust that.. There are no available information about performance impact or limits within snapshot frequency so we are somewhat disappointed with our findings.

I have read and appriciated several of your blog posts and wonder if you guys could test this product in depth and post your performance findings and other feedback on your blog? Since there is no real good documentation or guidelines regarding vnx snapshot I think it would be helpful for many of us.
Thanks and regards!

[Ron]

Chad, so what is up with OE32 stability? We have had our VNX for almost a year waiting to go from 31 to 32. I'm told by EMC that we shouldn't unless it is an emergent need. We should wait for the next code release which is months away. Anything you can share on what the problems are?

Thanks
Ron

[Chad Sakac]

@Paul - The new block allocation model will, over time, apply to the NAS model on the VNX family over time. Stay tuned for timing, and on what platforms.

@INDStorage - thank you for the feedback, I'm pumped about vCOPS integration. I also feel that while the VNX updates are great, they aren't enough :-) I expect more (from everyone and everything we at EMC do :-) Stay tuned, more goodness coming soon :-)

@Bob - RM and Appsync don't explicitly need RDMs. You can use VMFS with both (and NFS with RM now, Appsync too in it's next release). The KEY is that if you want app-integrated replicas on VMFS - you need to have only a single VM in that datastore (because otherwise snap and restore will affect others). That's not true on NFS (where we can snapshot at the VM level). Expect this to change in future vSphere releases that supports vVols.

@Petar - I hear you. Expect future VNX releases to couple the filesystem much more closely with this new block abstraction model.

@CSC_China - thank you for being a customer and partner! Expect big changes in FAST VP granularity. I can't be specific right now, but stay tuned! Also expect more of an "active active" behavior in future VNX releases.

@Mike - thanks for your feedback, I'm glad you dig it!

@Just a guy - the existing MV and RP SRAs continue to work, so you're good to go!

@Squillmo - thanks for the feedback. You can actually use RP or MV for filesystem replication, but FOR NOW, it isn't at the filesystem layer - it's the whole frame. Working on it! Today, Replicator is the way to go.

@50mu - THANKS!

@Anonymous Coward - I'm glad, thanks for the feedback!

@rd - Will it get into VNXe, YES. The model of how these are engineered, VNX is the vehicle for new features, VNXe is the vehicle for "fully integrated" code stacks. Expect these to merge over time.

@Jona - RM update 5.4.4 is expected (I believe) to support the new snaps.

@Hampus - I'm sorry that your experience has been less than perfect. I have heard and experienced otherwise, but the customer is always right! Would love to hear more, and help. Drop me an email (first dot last @ emc dot com) ideally (but not required) with an SR.

@Ron - VNX OE 32 is now on platforms shipped from the factory, so I'm suspecting there might be some misinformation. Can you drop me an email (first dot last @ emc dot com), I'll chase it to the ground.

[Ben Conrad]

Chad, you said: "I’m particularly curious about the snapshot delete behavior – that’s always the bugaboo with these pool/pointer based models"

I've got an SR open (59247626) where I've documented that removing a single VNX snap (leaving 6 more snaps on the LUN) takes the storage processor from 10% to 50% CPU and sends the disks in the Performance Tier from about 7 IOPS to 130 IOPS for approximately 70 minutes.

I was planning on implementing VNX snapshots of VMFS volumes (via AppSync) on a system wide basis but with this performance problem that wont' be possible. Have you been made aware of any performance issues regarding removing VNX snaps? I know of one support article that says don't delete the last snap but we're not doing that.

Ben