This post is more than 5 years old
211 Posts
0
5755
In TDEV Meta expansion, stripped is no better than Cancatenated?
I know there are quite a few discussions here about this topic, however, by reading those messages, I still could not get this question straight in my mind. I just wanted to make it clear in my own thoughts if you don't mind
1. Is this true that in VMAX TDEV meta expansion, stripped is no better than Cancat. and then not recommended, since blocks are already striped across thin pool?
2. In some discussion, Somebody said that the difference exists in Cache operation. Since the cache is very fast to both situation, then my question is how much different would that make between stripped and cantcat.?
3. With Enginuity 5876, what is the method to expand stripped TDEV meta device?
Thank you for your advice in advance!
seancummins
226 Posts
1
February 28th, 2014 04:00
Every device, including meta members, has one queue per front-end slice. Only one IO in a queue can be serviced at a time. By using meta devices and mapping to multiple FAs (aka front-end slices), you provide more queues to host-facing LUNs. Using concat metas will tend to concentrate IO on a small number of the available queues, because the active LBA regions at any particular time will not be evenly distributed across all devices. By using striped metas, IO will tend to be more evenly distributed among queues... The net result is that a particular LUN will be able to do more concurrent/simultaneous IOs when it has more queues (via metas), and when IOs are evenly distributed among queues (via front-end striping).
This becomes more important when you're dealing with highly multithreaded workloads, which is very common now... Especially when you have hypervisors running multiple VMs or vmdks on a single LUN.
Zhang_Jiawen
1.2K Posts
1
February 27th, 2014 05:00
Concatenated meta devices have two important operational advantages over striped metas: Concatenated metadevices can be expanded without destroying existing data by adding meta members to an existing metadevice. Non-metadevices can be converted to concatenated metadevices without destroying existing data.
If performance is more important than ease of expansion, you should use stripe.
If expansion is more important than performance, you should use concatenated.
You could see more details from this thread: https://community.emc.com/message/648463#648463
emcmagic
211 Posts
0
February 28th, 2014 03:00
If data will be all stripped across thin pool in either Cancat. or Stripped situation, then why stripped performance will be better?
What are steps to expan stripped luns?
emcmagic
211 Posts
0
March 1st, 2014 12:00
This is the best answer I can find with regards this question. Thanks!
Can anybody please show me steps to expand stripped luns in vmax thin provisioning?
cincystorage
467 Posts
1
March 2nd, 2014 11:00
Its pretty easy, but a lot of steps.. I'd suggest going here Meta Expansion in Symmetrix VMAX(VMAX 10k, VMAX/VMAX 20k and VMAX 40k) and reading about it. It's detailed very well.
I don't find much of a performance difference between striped and concatenated meta devices..
Quincy561
1.3K Posts
1
March 2nd, 2014 12:00
You won't find much performance difference between striped and concat unless you need more performance than the concat can provide. If you volumes are doing on average just a few hundred of IOPs or 10s of MBs/sec then you might not notice. If you need thousands of IOPs and 100s of MBs/sec, you probably need striped someplace, metas or host.
emcmagic
211 Posts
0
March 2nd, 2014 13:00
Thank you all!
My questions get addressed. I learned from Sean on what caused stripped TDEV better than concat, from Quincy56 on the different on how much different is. It is really not too much, if the required IOPS is not so high.
cincystorage
467 Posts
0
March 2nd, 2014 17:00
Interesting enough, but do we have a formula for max iops for a concatenated meta?
cincystorage
467 Posts
0
March 3rd, 2014 06:00
That 5% is each TDEV tho, isnt it? Not the entire device. So your 8-way meta can consume 40% of writeable cache.. If a DBA were to kick off a db export writing to that lun, and it takes up its 40%... At the same DBA does the same thing on a second host.. it it takes it's 40%... And if FAST had pushed all the target LUNs extents to a sata pool (since it hadn't been used in weeks).... and it can't write the data from cache to the sata drives quick enough....
Not that this has happened to me or anything...
Quincy561
1.3K Posts
0
March 3rd, 2014 06:00
You shouldn't worry about that in a VP system. One device can use 5% of writable cache, so only 20 devices can bring a system to max WP limits. BTW, the VMAX is the only storage array I know of that limits how much writable cache a single device can use.
cincystorage
467 Posts
0
March 3rd, 2014 06:00
The problem i'd be worried about us hitting WP limit if you have to many of these large stripped meta devices... All the sudden a server or two fires up a massive write operation... can't destage the data quick enough... not fun.. not fun at all..
Quincy561
1.3K Posts
0
March 3rd, 2014 06:00
Actually there is. Take the response time of a single IO and do the inverse. That will give you the maximum IO rate for a single LUN on a single FA. However IOs do not arrive on a regular frequency, they tend to arrive in bursts.
Just make a 8 way striped meta if you know you have LUNs with large performance requirements. Maybe 16 or 32 members in extreme cases, where you don't need to worry about LUN counts on a FA.
Also the performance will scale nearly linearly as you add FAs to a given volume, so more FAs can work as well instead of adding members.
cincystorage
467 Posts
0
March 3rd, 2014 07:00
I think we're going down the route of concanated meta devices for this.. Quick testing suggests the performance difference in my vp environment is not much... I'm not a fan of DCP for these once a quater/year work loads...
Quincy561
1.3K Posts
0
March 3rd, 2014 07:00
Yes, this is true. However usually a VMAX has many thousands of devices active at the same time.
I think a better approach to a rouge hose would be host IO limits than trying to rely on the number of meta members to control WP counts. DCP could be another approach, which can limit cache for a set of devices.
Saurabh_Chaudha
3 Posts
0
November 27th, 2014 06:00
I have one query on this post.
If we are creating Striped Meta for TDEV and since the TDEV are bounded to a Thin Pool ( in which the data is already striped over data devs). So are we are not doing double striping of data, is it recommended?