Skip to main content
Solved

MCSS storage estimation

Hi everyone.

how do you estimate MCSS storage requirements? MCSS (cool) would be our customers’ cloud secondary copy in their existing Commvault environment. So there are values available like local block size (128KB), deduplication factor, baseline size and such for estimation  We’re seeing around 1.2 to 1.3 x in MCSS demand compared to local disk with customers who set it up recently. As MCSS secondary copies “must have a minimum retention of 30 days", reducing retention (which oftentimes is the customer’s choice for solving storage issues) is apparently not an option here.

While of course we cannot provide a 100% estimation, we intend to not be too much off.

Thanks.

 

 

11 replies

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Great question @Ingo Maus !  Can you clarify a bit on the 1.2 to 1.3 ratio?  Are you saying you had the EXACT same retention, block size, content, etc. on a local disk based copy vs on Metallic Cloud Storage Solution (MCSS)?

Before we look into the MCSS settings, I want to be sure we are comparing apples to apples.  Often, the actual answer is something within the data (clients have grown, more clients added, etc.

https://www.linkedin.com/in/michael-struening
I
Rank
Badge +5

Hi Mike. No, not the same. First and foremost we use 512KB block size as recommended here: https://documentation.commvault.com/11.24/expert/12411_deduplication_building_block_guide.html

However, local retention is 4 weeks (weekly full), while MCSS copy is only 7 days. Still we already see the 1.3 ratio.

In the actual case, local copy: Data size on disk: 5,6 TB, baseline size: 6,5TB, App Size 8,9 TB. MCSS was estimated with 7 TB. Acutal usage is around 7,4 TB.

 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Thanks for the details!  I talked to some of the Associate Managers in support that handle MCSS and they mentioned that the number of factors are so numerous, they’d suggest opening up a support case (and sharing the number with me).

Here’s a list of factors they mentioned could be at play:

that could be quite a few things: Expected behavior due to being a secondary copy, not using space optimized aux copy option, volume updates not updating properly, volume updates not turned on (costs money for cloud), multi partitioned ddb may have been offline and rebaselined

short retention, aux copy multi streaming, compression/dedup order for a secondary copy versus primary copy, optimized aux copy option not turned on to help mitigate some of these things

That’s a BIG list and would take us a long time to check over a forum thread.

Let me know the case number so I can track it accordingly.

https://www.linkedin.com/in/michael-struening
I
Rank
Badge +5

Hello Mike,

thanks for your effort here. However, we decided a support ticket is not the right approach. I would hope that Commvault can provide / put together some form of best practice guide for scenarios as common as using MCSS Cold with DASH for long term retention / tape replacement / DR backup. Considering MCSS is a service provided by Commvault and not Microsoft, after all, these things (mentioned by your support managers) could then be addressed up-front in order to set it up most efficient.

 

 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

I totally understand (and agree!); my initialconcern was that something was simply not working right (based on the extra usage ratio).

Let me reach out to some developers and product managers and see what we can provide for you.

https://www.linkedin.com/in/michael-struening
Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

@Ingo Maus , I had a few chats with some of our internal folks, and we want to be sure you are using this option:

https://documentation.commvault.com/commvault/v11/article?p=93579.htm

If not, please enable this feature.  It randomizes the stream content to ensure a higher probability of deduplicating.

What happens otherwise is that concurrent streams can’t deduplicate against each other and you’ll have a bloated baseline. It’s not an issue with MCSS, but the deduplication of the Aux Copy.

This will randomize the streams going forward reducing the likelihood of the same data running in parallel.

Eventually, as jobs age off, the ratio will balance out as the ‘extras’ age off.

Now if you are already using this feature, it was suggested to open a case as this is not expected behavior (MCSS or not).

https://www.linkedin.com/in/michael-struening
Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Hi @Ingo Maus !  following up to see if you were able to confirm if you were using that option or not.

Thanks!

https://www.linkedin.com/in/michael-struening
Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

@Ingo Maus , I got some information from our internal folks that I want to share (comments are compiled from different people).  Please let me know if you need further information:

The BET calc on MCSS is a straight BET (regular on disk) x  15% head room for object storage x 12 % additional headroom for 128K dedupe size – this comes to somewhere around 28% additional headroom from the regular BET calc for disk.

  • With Cloud storage – the nature of blob as small container storing up to 64 unique dedupe blocks – will increase consumption as the blobs can only be deleted after all 64 segments in the content have expired.  That results in a longer delay in when the data recycles in the store.   Fundamentally, we recommend planning on 20-30% additional capacity on cloud data stores in your BET projection as to what you were witnessing on the same copies on disk libraries.
    • MCSS as a subscription storage service provides a metered quantity for use across the cell, if you consume the capacity at 100% then new copy jobs will be put into a pending state until you delete/recycle the space for reuse or you buy additional capacity on the license.   This means users should also plan in some additional buffer, growth space into the plan to ensure they don’t hit a stoppage in operations.  It is also key to monitor the usage – hint .. use the Trending Chart for Cloud Storage on the Command Center reports and use the alert reminders as you hit the critical consumption levels

Take a look and let me know if you have any questions as I did my best to compile it into a clear format.

https://www.linkedin.com/in/michael-struening
I
Rank
Badge +5

Mike. I still owe you a reply. Thanks again for going at lenghts here.

As a matter of fact I missed your most recent reply completely, which is helpful as it gives us actual numbers to work with. Would be great to see that 20-30% add cap recommendation in the documentation.

To follow up on your post before that - the setting “Space optimized Auxiliary Copy” is active. We have not, however, gone into more detail here with that CommCell.

The initial question is asnwered in details now, but you mention MCSS consumption above 100% results in copies being put in pending. We haven’t run into that situation, yet. However, we discussed this in great detail with your licensing team, since we got many questions from our customers..

What we understood from a call with Mansa Nischith was that MCSS storage behaves like on-prem disk - a grace period will start from 100% to 110%. Mansa being with the Metallic team, I’m not sure, that only applies to MCSS booked within Metallic BaaS.

 

 

 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Happy to help!

Library type shouldn’t matter.  The grace period for licensing is handled at the CS level, not the library level.

Let me know if that wraps everything up for you!

https://www.linkedin.com/in/michael-struening
I
Rank
Badge +5

Happy to help!

Library type shouldn’t matter.  The grace period for licensing is handled at the CS level, not the library level.

Let me know if that wraps everything up for you!

Yes, thanks again.

Reply


Terms & ConditionsCookie settings