Ask the Expert: VNX / MCx - Best Practice - Configuration

Thank you, Mark.

This discussion is now open for questions. I sincerely apologize for the delay in opening it and accept full responsibility for that.

We really look forward to your questions to Mark on this topic for the configuration and deployment of VNXx / MCx.

Best regards,

Mark

Mark,

my question is not about best practices per say but more about why with the introduciton of MCx and all the horse power that is now avaiablel to Block OE, layer application limits are still an after thought. If we look at consistency group limitations for SnapView, MirrorView ..it seems like they have not changed since CX4 days.  For example max of 32 LUNs for one consistency group is a joke these days, i have Oracle DBs with hunders of LUNs that i need to provide consistent fracture functionality.

Dynamox,

I can only agree with you regarding the LUN count limits regarding the Consistency groups with the new architecture of the MCX boxes.  I do see that the larger boxes support up to 64 LUNs in each Consistency group today while the limits still remain at 32 for the smaller configurations.  I have attached the Asynchronous Release notes and the Configuration Limits that you spoke of appears to be on Page 4.

I have seen large databases managed with expanding Metaluns in order to take advantage of the added performance capabilities of more disk which also allows for using fewer LUNs and being able to stay within the limits of the Consistency groups.

I know that these new arrays are much more powerful than past configurations and use the processors and memory much more efficiently.  I can only speculate that these limits will be raised this next year but I would also caution that the new limits will also be on the conservative side.  We are creating Data and managing much larger Databases at a very rapid rate and the cost of storage is continuing to decline.  It appears that we are continuing to develop new tools each day for the management of Big Data.

Please let me know your thoughts and thank you for your comments.

Mark Cox

Mark,

We left traditional Flare LUNs and MetaLUNs in the past so we can take advantage of thin provisioning, dedupe, FAST VP ..etc. For heavy OLTP workloads it does not make sense to go to few larger LUNs, you will start having queuing issues. I just wanted to provide some feedback because while we heard so many great things about MCx, layered apps are not where they should be for todays requirements (let alone what your competition does in mid-tier space).

what has not improved in my experience is fault isolation. Every now and then i keep getting bug checks that panic the entire SP. I would hope that in year 2014 we would fail a component and not cause the entire operating system on the SP to crash. And this goes back a long way when i started working with FC4700, I/O module = panic, memory module going bad = panic. When a DA board goes bad on my VMAX, we don't have the entire engine going offline.

I liked Clariions, i like VNX but it seems like it's moving at a snail pace compared to other platforms (even with EMC) in terms of innovation.

dynamo.

I do agree as I said before with the number of LUNs in a Consistency group,32 and 64, being a limiting factor.  Under the premise of using Thin LUNs and the Pool concept so that we can use the FAST VP functions and make use of the SSD components we can have LUNs as large as 256TB in the Pool, however we do encounter LUN size restrictions with some Operating Systems.  It seems that the 2 TB per LUN limit has plagued the Open Systems environment in the past.  In most cases I believe that we have been able to create or design the database around the restrictions that have been imposed.

I do work for EMC and I have worked with this product for a long time so I may come across a being partial to it.  I am really impressed with the Capabilities and the improvements with this newest MCx code that really does improve the balance on the cores of the multicore processors and makes much better use of memory which in turn improves the performance all the way around.

I have attached the Virtual Provisioning Release notes that outline some of the capabilities that are available with Storage Pools and Thin LUNs.

Again,

Thank you very much for your comments.

Mark Cox

I'm inclined to agree with Dynamox's points and add to them, but I don't want to derail the discussion too much with gripes and suggestions. Maybe there could be another thread where we could 'let it all out' ? Constructively, of course

On topic, what are the current config guidelines around deduplication and MCx ?... I have my finger on the trigger, but read too many stories/warning of things going South after activating it. I can't afford to be a guinea pig on Production workloads.

The last uptime bulletin suggested numerous enhancements/fixes were on the way in 5.33.5.000.074, and I see some reports still of degraded performance and issues. 079 was made available around 1 week ago, but it would be nice to know where it's at ?  Are we just seeing the edge cases and it's generally ok and field ready ?

Brett,

I do not have a response that will satisfy the disappointment with the reliability of the recent Block codes that were released for the VNX Gen II product.  However, in regards to this we have recently released the Block code Release 33 Patch .079

to address many of the issues with the previous codes.

In regards to your concerns with the deduplication of the Block side of the array I have attached the Release notes for Patch .079 and the White Paper from October 2014 on Deduplication in the VNX II.  It appears that many of the problems with deduplication were addressed in Patch .038 and additional issues addressed in Patch .051.  As for addressing your Production environment and the impact that is encountered with the conversion I will recommend that you continue to wait until the Q1 Release of the Block code.

I will reference Article 188409 on the EMC Support site for known issues with deduplication in the VNX Gen II product.

Please see attached and I really hope that this is of assistance.

Thank you for the response Mark, I'll take your advice and re-assess in Q1.