MSA 2060 Replication - Storage Implications

[Raffael]

Hello there,

I'm struggling to fully understand the storage implications of replications between two MSA 2060 and hope someone can shed some light into it or give me a link to some helpful ressources on the topic.

For the primary system I have a MSA 2060 with 12x 1.8TB Disks in a MSA-DP+ RAID resulting in a Pool of a Total size of 14.3TB. As soon as I configure a replication, the maximum size I can expand a volume in this Pool to gets limited to 5.6TB. As far as I understand, if overcommit is disabled (which is the case), the Replication (or the snapshot needed for the replication) should "reserve" storage equal to the volumes size - so I would expect to get limited to half of the available space, so around 7.1TB, not 5.6?

Furthermore the implication of the Queue Policy for a replication is a bit unclear to me. If I try to set the queue policy to "queue latest" I receive the message "The requested size for a new volume exceeds the remaining physical space left in the pool" quite fast, even with smaller volumes. How much storage "waste" has to be calculated here for which policy?

Thanks for your help guys!

Some screenshots for further explanation:

Expanding without any replication in place - as expected: https://ibb.co/1KmrXQ7

Expanding with replication in place: https://ibb.co/Fm1CVX9

[sbhat09]

Hello @Raffael,

If you configure the replication, your destination (or secondary) MSA system should have sufficient usable space to copy as much data the replicating volumes will copy. If you configure replication between System A (primary) and system B (secondary), and total physical space used by the replicating volumes in 50TiB, your system B must have more than 50TiB free usable space for the copies of replicating volumes.

Except this, I don't find any other implications. You may find the below document link useful:  

https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00105664en_us 

Regards,
Srinivas Bhat

If you feel this was helpful please click the KUDOS! thumb below!
Note: All of my comments are my own and are not any official representation of HPE.

[Raffael]

Hi Srinivas

The secondary system has about 34TB of Storage Capacity, so I ruled that out as a source of the problem.

[Raffael]

Some screenshots for further explanation:

Expanding without any replication in place - as expected: https://ibb.co/1KmrXQ7

Expanding with replication in place: https://ibb.co/Fm1CVX9

[rakesh_93]

Hi Raffael,

The replication process uses two internal snapshots when the queue policy is set to 'Discard' and three when set to 'Queue latest'.
In this case, the volume size is 4.3TB. Since the overcommit is disabled, the two internal snapshots reserve roughly 8.6TB. 

#show snapshot-space --> This would list the space used by snapshots( including internal snaps )

Regards,
Rakesh S

[Raffael]

Hello @rakesh_93 

Thanks for that reply! 

Unfortunately I don't see any internal snapshots / space usage on the CLI?

# show snapshots volume xxx_vol01
Pool Name Creation Date/Time Status Status-Reason Parent Volume Base Vol Snaps TreeSnaps Snap-Pool Snap Data Unique Data Shared Data Retention Priority
-------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Success: Command completed successfully. (2021-09-29 14:10:49)
#
#
#
#
# show snapshot-space
Snapshot Space
--------------
Pool: A
Limit (%Pool): 10%
Limit Size: 1435.3GB
Allocated (%Pool): 0.0%
Allocated (%Snapshot Space): 0.0%
Allocated Size: 25.1MB
Low Threshold (%Snapshot Space): 75%
Middle Threshold (%Snapshot Space): 90%
High Threshold (%Snapshot Space): 99%
Limit Policy: Notify Only

Success: Command completed successfully. (2021-09-29 14:10:52)
#
#