Ask the Expert: EMC Symmetrix VMAX - Latest Advancements

This is weird. I can see the live feed, but I don't see my question appearing.

I missed the first 20 minutes, so almost all of it and I just wanted to know in a nutshell what the enhancements were.

Hi,

We will forward the details of your question to performance engineering and get back to you with a reponse.

Regards,

Paul

For those who missed it, here's the video on demand replay of the presentation. 

Your browser must have Flash installed to view the video

Video Link : 4702

Currently, we support 2.5" drives in 3.5" carriers on the VMAX 20K.  We are evaluating future support of 2.5" drives in 2.5" carriers on VMAX 20K.

I posted my question during the webcast and never saw it or any comment it show up for after over an hour of waiting, so I'll try it again here.

We’ve got a VMAX-1 with Enginuity code 5876 – the equivalent of a VMAX 20K (?) – with vSphere 5.0 on HP ProLiant BL465c G7 blades with 8Gb Emulex HBAs, and BL460c Gen8 blades with QLogic 8Gb HBAs, going to Brocade directors.  Any idea why we cannot drive any more than 13,000 IOPS (100% sequential read) on a RAID5 or RAID6 TDEV striped META with NMP RR (IOPS=1, 2 paths)?  That's a far cry from 1 million IOPS, let alone "over 2 million IOPS on one storage system using VMware vSphere 5.0."

This discussion is now open for questions to our experts. We look forward to an interactive and informative discussion.

Best,

Stephanie

2.5” drives supported in VMAX 20K ? Can i mix 2.5 and 3.5 in the same array ? Any other best practices around these drives.

Thanks

DDMIjadams

The IOPs you can get from a single engine will depend on the workload.  The maximum IOP rate is with 100% small block reads from cache.  Also to get the maximum IOPs or throughput from any VMAX, you will need to use many devices, not just one volume, or even one meta.

You can see the white paper showing 1 Million VMware IOPS using vsphere 5.0 with VMAX 20K http://www.vmware.com/files/pdf/1M-iops-perf-vsphere5.pdf. 

And a Virtual Geek blog on it here.

The paper shows a VMAX 20K with 8 engines was used, along with a lot of drives, front end FC ports, and meta LUNs.

Regarding FAST VP on 5876 code, can you please explain the difference with respect to how FAST VP handles binding of TDEVS that move between FVP tiers? I know 5876 handles this differently (more efficiently?) from 5875 code. More specificallly, how will this ultimately affect thin pool capacity/usage reporting?

Hi All,

we've created a mirror thread 【英语专家问答同步直播】EMC Symmetrix VMAX - 最新竞争优势 in Chinese Support Forum for broadcast the this event to Chinese audience.

I will forward the question from Chinese audience and translate to English and look forward expert's greate answers.

First Chinese questions from  lei liu:

Does new model VMAX support disk pool as default instead of using disk group?

Fenglin,

Hi--we would like to respond to your inquiry, but we wanted to be sure we clearly understood the context of your question.  Could you please clarify reference to "support of disk pool as a default", as contrasted to your reference of diks groups?  We weren't 100% clear on what you were asking here, and we want to be sure in order to give you an accurate response.  Any additional data you can supply, including where you saw other references to support of disk pool as default as opposed to diks group would be most helpful.

Best Regards,

Paul

Dancheng,

Thanks for replying.

I have read the documentation and am confused by this change in the binding of FVP-associated tdevs. What is the advantage or improvement in the way 5876 handles this versus the way 5875 handled new writes from the originally bound pool, typically FC thin pool?

I am not looking for documented explanation, but maybe a real-world example would help me to understand better? I am failing to see the benefit here. Is there one?

Are you talking about the 5876 change "VP allocation by policy”?

VP allocation by FAST Policy

The VP allocation by FAST policy feature allows new allocations to come from any of the thin pools included in the FAST VP policy to which the thin device is associated. (Allocations are not limited to just the bound pool.) Traditionally, new extent allocations generated by writes to a thin device come from the thin pool to which the device is bound.

There are no significant changes, as a result of this feature, in the reporting of capacity usage. More details about this feature can be found in the "FAST VP for EMC® Symmetrix® VMAX® Theory and Best Practices for Planning and Performance Technical Notes" on Powerlink. If you don't have access, please contact your EMC account team.

Best regards,

Dancheng