« Stretched vSphere Clusters? DR with SRM? Why not BOTH? | Main | Isilon X400 and Mavericks »

May 21, 2012

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e552e53bd28833016305b23f15970d

Listed below are links to weblogs that reference VNX Inyo is going to blow some minds….:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

  • BlogWithIntegrity.com

Disclaimer

  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC. This is my blog, it is not an EMC blog.

Enter your email address:

Delivered by FeedBurner