MSA Virtual Pool Expansion

[Andy Haigh]

Hi,

We have a couple of MSA's 2040 and 2052 in which we have configured Virtual Pools with a few disk groups in each.

We have put in some extra disk and just wanted to confirm that all we have to do is add a new disk group to the pool, same disk sizes and same raid and qty.

We will be adding a disk group to each pool, each pool on each MSA is a mirror of each other.

The MSA will then automatically move the data and balance everything across the current and new disk group.

Thanks

Andy

[Andy Haigh]

So we have gone ahead and added the disk groups to the MSA's

Getting very different behaviour across the MSA's

The MSA 2040 has added the disk group to each pool and the rebalance has completed on both pools.

The disk group was added to the MSA 2052 on Pool A first and it's now been 24 hours and it has only done about 350GB of redistribution across a 7.2 TB disk group. The MSA 2052 now has in each Pool:

5 x RAID 5 disk groups each made up of  5 x 1.8 TB drives.

1 x NRAID 797.1GB

Is this normal for the MSA 2052?

At this rate it will take days to complete the rebalance.

One thing we noticed was the 5 x 1.8TB drives used to create the disk groups is .5 GB less in size. 7191.5GB compared to 7192.0GB odd!

Andy

[ArunKKR]

Hi,  Disk group data rebalancing is a slow back end process and would take time to get completed. While creating disk group some space would  be reserved for parity and metadata needed for internal management of data structures.

[Andy Haigh]

Hi ArunKKR,

That's fine but the MSA 2040 completed the rebalancing with a few hours and yet the MSA 2052 has taken 7 days and has completed one disk pool and about 70% through the second disk pool.

In regards to the disk group sizing the disk groups are made up of the same size disks 1.8 TB and yet the latest disk group created is 0.5 GB smaller, does anyone know why?

[ArunKKR]

Hi,

MSA controller firmware determines how fast the data levelling happens across disk groups.
There is no option to speed up the data levelling process across disk groups.
The firmware algorithm differs in each generation of MSA even though most of the basic concepts remain the same.

I tried to create multiple disk groups in one of the MSA G5 series.
However, I was unable to replicate the space difference issue mentioned.
Please check the hard drive size being reported in SMU and confirm whether all the drives are of the same capacity.
The only possible reason that I could think of is slightly lower than advertised capacity of one of the hard drives.

[JonPaul]

@Andy Haigh 
The rebalancing process changes with firmware updates.  The latest rebalance process uses the tiering engine to move data pages.  This works via moving up to 20 pages every 5 sec.... do the calculations and it works out to at best around 1TB per day can be moved.  I'm not sure what process the MSA 2040 used with the firmware you have but it was likely more aggressive. The reason for the slow movement is to limit the disruption to the host I/O flow.  You can actually improve the time by continuing I/O flow while the rebalance is in process as the system will rebalance the new/overwritten data as well as the background data.  Is it possible that the MSA 2040 has less data capacity and less used than the MSA 2050?
There are more details around MSA virtual storage in the MSA Gen5 Virtual Storage Technical Guide:  https://www.hpe.com/psnow/doc/a00087404enw
As for why the new disk-group is smaller I'm not sure.  It could be that the firmware changed between when the others were created and this new one and the metadata overhead increased. It could be that one of the drives is slightly smaller in that disk-group. If you set the CLI to output all the details (CLI>  set cli-parameters api) and show the disk groups (CLI> show disk-groups dgA04) and compare the min-drive-size that may shed some light on the sizes of the drives  You can also see the create-date but unless you know when/if you changed firmware would not help with the metadata question.
CLI> set cli-parameters console    gets you back to human readable
You can also increase the cli output precision to dig down into the drive sizes.  CLI>  set cli-parameters precision 8
My leaning would be toward a RAID set metadata change which is using ~100MB more per drive resulting in the overall drop of 0.5GB