MSA 2060 Remote Snap Space Requirements

[JustinGawn]

Hello,

I am attempting to understand the space requirements of snapshot replication between two MSA 2060 arrays.

I have read the MSA Remote Snap Software white paper, however this version is in reference to the previous MSA 2050 generation. Within the white paper it talks of two different methods of replication; linear and virtual. I can't find any refernce online to these differing methods for MSA 2060 - is it the case that snapshot replications for MSA 2060 are all virtual?

Assume the following example:

• Two MSA 2060 arrays, they are identical each with a single volume, pool, and disk group.
• The pool is 100TB, the volume is allocated 90TB, and 90TB has been written to the volume.
• Overcommit is left enabled.
• The primary MSA takes a local snapshot every day, and retains the last 14 snapshots. There is 0.5TB of data change (not growth) per day.
• The snapshots are to be replicated to the secondary MSA.

I understand that on the primary MSA, the volume will consume 90TB, and the local snapshots an additional 7TB (14 x 0.5TB). The amount of space allocated to snapshots is by default 10% of the pool size (so 10TB).

My question are:

For the initial replication, is it correct that no additional data is written.

For the each of the 14 retained and replicated snapshots there are three internal snapshots (current, previous, and queued). Is it the case that each of the 14 snapshots requires 3 separate internal snapshots (for a total of 14 local plus 42 internal snapshots) to be retained, or are these chained so that only the latest snapshot requires 3 internal snapshots?

Thank you

[ArunKKR · Accepted solution]

Hi,
MSA 2060 uses virtual replication.
Only replication uses 3 internal snapshots.
14 snapshots of 90TB volume would be quite huge.
My suggestion would be to limit the retention count.

Lets consider we have a Pool Size of 10TB
- And we have three volumes in the Pool 
--- Vol_1 = 1TB
--- Vol_2 = 2TB
--- Vol_3 = 3TB
- Based on the default "Snap Pool Limit" of 15%, the Snap Pool Limit for this Pool would be 1.5TB
And theoretically, when we initiate a Snapshot Task for any Volume, the FW would require the necessary Metadata Space.
It would not utilize actual Pool Space, but would need the necessary metadata table for the snapshot.
- Thus, if a snapshot is created for Vol_1 it needs 1TB equivalent of Metadata
- Thus, if a snapshot is created for Vol_2 it needs 2TB equivalent of Metadata
- Thus, if a snapshot is created for Vol_3 it needs 3TB equivalent of Metadata

For Example, If we have a 10TB Base Volume with 15 associated Snapshots, it uses a total of "10*(1+15)=160TB" Metadata.

The Pool has 1PB metadata limit.

With 14 snapshots and 3 internal replication snapshots you will easily breach this limit.

In general free space in Pool equivalent to volume size + 2 data changes is recommended in virtual replication with over commit enabled.
You will need to constantly monitor the Pool free space and ensure that it does not reach the high threshold.

[JustinGawn]

Thank you for that response. Is this also the case with overcommit enabled?

E.g. assume 90TB volume with daily snaphots retained for 14 days. If there is just 0.5TB of change per day, with overcommit would the required capacity for local snapshots not be 90+(0.5*14)?

[ArunKKR]

Hi, Yes. The metadata calculation that I have shared is same with over commit enabled.

[JSH-MSA]

Hi,

The MSA 1050/2050/2052 and MSA 1060/2060/2062 generations both use virtual storage only, not linear.

I'm not sure what additional data you might be referring to, but for the initial replication, is it correct that no additional data is written to the primary volume, but note that the entire volume is replicated to the secondary array. 

The internal snapshots are for the replication set, not for a volume or snapshot. They are used to determine the difference between the current volume and the last time it was replicated. So you'll only have 3 (max) internal replication snapshots. You can see them using the CLI command "show snapshots type replication". 

Regards,
John

[ArunKKR]

Hi Justin,

Do you have any further queries for us?

[JustinGawn]

@ArunKKR  @JSH-MSA Thank you both. I understand that with overcommit enabled, daily local volume snapshots will each be only as large as the daily change, and replication of a volume will consume three snapshots with their size also being driven by the amount of changed data.

Regarding the metadata, am I correct in saying that the total number of all snapshots (user and internal) must not exceed 1PB divided by the total provisioned size of those snapshots? E.g.

1PB max / 100TB volume = maximum of 10 snapshots (7 user + 3 replication)?

So in effect there are two limits to be aware of:

1. Pool consumption which (with overcommit enabled) is based on consumed snapshot sized relative to the pool size
2. Metadata consumption which (even with overcommit enabled) is based on provisioned snapshot size relative to 1PB

Thanks,
Justin

[ArunKKR]

Hi Justin,

Yes. You are correct.

From MSA best practices guide:

Overcommit allows snapshots to consume a minimal amount of allocated capacity within the pool. When overcommit is disabled, snapshots consume available space equal to the size of the original volume. In most circumstances, disabling overcommit has an undesired impact on the available capacity of a pool and should be left enabled.