Unsolved
This post is more than 5 years old
12 Posts
0
694
July 15th, 2014 21:00
Load distribution across disks in a pool
Another important question an answer to which I can't find in official EMC materials is how the load is spread across disks in a pool.
Let's suppose we create a pool (single-type disks, no tiering), and the system creates several underlying RAID groups invisible to the storage administrator. Then we start creating new volumes in this pool and writing data to them. The question is, how chunks of data are distributed across the disks in the pool?
I can see different ways to implement this technology:
- Option 1: all chunks of data are distributed evenly across ALL the disks in ALL the RAID groups in the pool no matter to which volume they actually belong.
- Option 2: all chunks of data are distributed across the disks in a SINGLE RAID group in the pool. Different volumes' data are placed on the same RAID group until is full, then the system moves to the next RAID group.
- Option 3: all chunks of data are distributed across the disks in a SINGLE RAID group in the pool, but different volumes are placed on different RAID groups if possible.
- Option 4: ... ?
Which one is correct?
This is very important because if I create classic RAID groups manually, I can manually distribute the volumes among them to spread the load across different spindles thus balancing the array's general performance. However, I don't understand how I can balance the load across different spindles in a big pool.
lotto741
12 Posts
0
July 15th, 2014 22:00
I've already read the document you've mentioned, but it isn't the kind of answer I'm looking for. Yes, one slice can belong only to one private RAID group, but how are those slices distributed among different RAID groups? All volume slices are on the same RAID group? Or are they distributed/balanced somehow among those groups?
Not quite so. AFAIK, it heavily depends on how much data was already written to this volume. I might be wrong here, but I believe that as a MetaLUN is composed of several usual LUs, all the IOs are going to the first LU in the chain until it's full. Then the IOs are redirected to the next LU, and so on. Unless the MetaLUN is completely filled with data and the data access pattern is completely random, you can't guarantee that all private LUs in the MetaLUN are used for data access. That's why one huge RAID group is always preferred over several small ones in terms of efficiency.
Roger_Wu
6 Operator
•
4K Posts
0
July 15th, 2014 22:00
Actually Pool LUNs are comprised of slices. Slice – A 1 GB unit of capacity (256MB in VNX2), which represents the minimum amount of capacity that can be physically allocated to a pool LUN. One slice could only be on one private RAID group. Refer to https://www.emc.com/collateral/hardware/white-papers/h8222-vnx-virtual-provisioning-wp.pdf
It's quite difficult to make the load spread across all the disks in a pool, for example if it's a 2*(4+1) RAID5 Pool. MetaLUN (with traditional RAID group LUN) still has the best performance.
Roger_Wu
6 Operator
•
4K Posts
0
July 15th, 2014 23:00
My fault. What I mean is, striped metaLUN (rather than concentrated metaLUN) has the best performance...
Anonymous User
375 Posts
0
July 16th, 2014 00:00
"as a MetaLUN is composed of several usual LUs, all the IOs are going to the first LU in the chain until it's full. Then the IOs are redirected to the next LU, and so on. Unless the MetaLUN is completely filled with data and the data access pattern is completely random, you can't guarantee that all private LUs in the MetaLUN are used for data access."
It takes place in Windows FS, that's even in Concatenated Meta-LUN, not in all cases neither in striped Meta-LUNs. That's reason EMC advises to use Concatenated Meta-LUN for Windows Apps, for better performance.
Thanx
Rakesh
lotto741
12 Posts
0
July 16th, 2014 00:00
Yes, that's correct. If, for example, we attach several LUs in different RAID groups to a single host and make a single RAID0 volume of them using the means of the server OS, we'd get the maximum performance possible. However, such volumes are just a pain in the rear, so I hate using this trick. That's why I'm so interested in the pool technology.