tdev meta members for large luns

Question

All,

I have been reviewing many of the size recommendations for tdev meta members. Recently I recieved an analysis and briefing from and EMC Engineer that suggested that we use meta member sizes that are multiples of 4 and 8. He suggested meta members be 4, 8, 16 or 32 because of the physical architecture of the VMAX. This made sense because of 8 engines, 4 processors per director, 8 processors per engine, 4 or 12 backend directors per engine depending on the engine and daisy chaining of cabinets. This was to even out the workload across the backend more evenly. In the reading I have done so far Quincy56 and others are stating that the power of 2 or multiples of 4 or 8 do not apply with virtual provisioning. So just to be clear, the current VMAX design and backend architecture has nothing to do with tdev performance or number of meta members? Even though the architecture is all based on even numbers and multiples of 4 meta devices can be 4, 5, 6, 7, 10, 11, 13, 15, 19, members and it doesn't matter except for the meta count against the FA processor?

Thanks for your input.

M_Salem · Accepted Answer

You are most welcome jmudad206. Appreciate if you can mark any of the answers as "Answered" if you really feel your question is answered

This will help our community moderators a lot.

Hope it helps

Mohammed Salem @yankoora

Quincy561 · Answer

With thick volumes, powers of 2 match up nicely on the backend disks since all DMX/VMAX directors are in multiples of 2 directors and 8 CPUs.

With thin (VP) LUNs, there is no connection with the FE LUN to the backend layout. The layout on the backend is the same regardless of the meta count.

So as long as you have enough members to meet your performance and size requirements, you can use any member count you please.

M_Salem · Answer

We generally tend to like powers of 2 but this does not apply to VP for the reason Quincy56 mentioned.

The recommended configuration is to use up to 16 members meta which should be fine with most of the Apps. We may recommend to go beyond this if there is FA CPU queuing issue and in such situations, you will need higher number of metas.

High FA CPU queuing may occur in VMware and MS SQL environments due to large metavolumes seen in these environments.

Mohammed Salem

jmudad206 · Answer

Thank you gentleman for your replys. I am really surprised that the number of meta members doesn't matter but I do like the thought of keeping things on even numbers as opposed to being whatever fits. I get the fact that greater than 16 meta members the performance curve startes to plateau and that volume management on the host is better than volume mamangement on the Symmetrix.

Thanks for providing this information. This was a hot topic after it was recommended by an EMC resource that we use multiples of 4 or 8 for our meta volumes which for some luns sould drive our lun count to FA port count very high very quickly and we have already maxed out an FA one time but that was caused by a migration of older smaller metas that were not resized and drove our meta count thru the roof.

Thank you agian.

Bob

VMAX

tdev meta members for large luns

Was this post helpful?