VMAX - striped meta performance of TDEV

As long as 8 Symmetrix volumes are active, it doesn't matter if they are host striped or meta striped.  I prefer host striping for many reasons, but may introduce more complexity at the host level.

First of all following EMC Best Practices your meta must be power of 2.

I mean in a meta device the hypers must be 2, 4, 8, 16, 32.

Following the best practices an 8-way-meta is the best configuration for best performance but it depends again.

This is another discusion and long story.

A meta device must have two levels of stripe.

So, the first step is when you create the hyper and the second step is how you are going to create a meta?

Through the host using the Volume Manager or through our Storage.

For the Redo Logs it is wised to do a host striped meta and for the Data files striped meta via the Storage.

I will find the document and i will send it to you.

Powers of 2 are important for thick devices, not thin devices. 

The power of 2 rule was important so that the volumes the meta spanned on the backend fit nicely.  There is no need for such a concern with VP.   Each volume added to a VP meta will add some performance to and from cache, up to a point where there is diminishing return.  16 members is about the point where adding more won't provide much, if any, benefit.

I still like even numbers of members, but with VP, it really doesn't matter.  The backend layout will be the same.

Good morning Quincy,

let me disagree with you. Even the Thin device is a cache device it is important to follow the powers of 2.

Or else we would create a single hyper and that's all.

Agreed for VP and for backend layout, but a customer faced a performance issue with some Thin devices which were one hyper.

Migrated them to an 8-way-meta or 16-way-meta device and the performance issue disappeared and no changes done on the VP or on the host.

As you mentioned the VP is responsible and takeover to add to a thin device extra performance because a thin device by it' own it is a little bit slower.

Just saying a 9 or 17 way meta would have had the same performance impact.

OK, understood. But doesn't the addition of each member of a stiped meta, each with their own device WP limit, increase the performance on writes for those workloads that are write heavy?

Just to keep things honest here, the performance difference has nothing to do with cache allocation.  There is no read cache allocated per device, one device can use all available cache for reads.  For writes, there is only a device WP limit, which shouldn't come into play in most cases.

Then putting write performance aside, how would you describe the mechanism that explains why a thin stiped meta performs better then a single thin device given all other factors are identical?

Zikas wrote: Good morning Quincy, let me disagree with you. Even the Thin device is a cache device it is important to follow the powers of 2. Or else we would create a single hyper and that's all.

Why? That is not an accurate statement. You saw a performance improvement becuase you went from a single TDEV to a thin striped meta. A thin striped meta will perform better than a single thin device becuase each member is allocated slots from cache and can be used for IO. So you are increasing the cache footprint and ability to process IO concurrently.

This will occur with a 5 way meta, 8 way meta, or 11 way meta. The powers of 2 rule was for standard thick layouts not VP.

Yes, each logical device can have 5% of all writable cache.

However that really won't change the maximum write performance.

Say a host can write at 1000 IOs/sec, and the backend can only destage at 100 IOs/sec.  If I have one device, I can write at 1000 IOs/sec for a breif time, then I will be stuck at 100 IOs/sec.  If I add more devices, the time I can write at 1000 IOs/sec will be increased, but if the host keeps writing at that rate, we will still hit the 100 IOs/sec limit, just a little later.

Having more than one device on the FA active increases the concurrency at the FA CPU level.  For example while we are doing a data transfer for one device, we can start an IO for another device.

Thanks. Very succinct.

Quincy and AranH, if i understood correct if we have one hyper and a meta device, let's say two-way-meta, the WP limit is not the same. The 2-way-meta WP limit is two times the WP limit of the one hyper.

If yes, i believe that this has an affect to the device performance.

Of course it has to do also with many things in order to reach the WP limit and then to slow down pretty much the device performance.

In any case, i will find the Best Practice of EMC that says that it is more or less recommended to use the powers of 2 for the Thin Device also.

Even for a big device, it is recommended to create the device as 32-way-meta and not as 33.

I will find it and i will send it both.

I am not fight both of you, i am delighted with our conversation, but i have been criticized many times by my local office that i am NOT following/using the rule of powers of 2 to the customers that use VMAX and VP.