Solved

Tweak FS performance of File server via Command Center


Userlevel 7
Badge +19

We're running FR30.43 and a customer asked us if there are ways to improve backup/recovery performance of a Windows File Server cluster based on Windows Storage Spaces Direct. Our customers manage everything via Command Center and have to access to the CommCell console. From the CommCell console there are/were several ways that allowed you to improve backup/restore performance:

  • Enable the option "Allow multiple data readers within a drive or mount point"
  • Increase data readers
  • Spread contents over multiple subclients

Besides the last one mentioned the other two mentioned cannot be set/tweaked when you use protection plans. So, my questions is what is the default behaviour when using plans and what options can you implement that improve backup/recovery performance for large file servers. 

icon

Best answer by SparshGupta 9 May 2023, 05:16

View original

10 replies

Userlevel 4
Badge +10

Hi @Onno van den Berg 


Please find details below -

 


 

From the CommCell console there are/were several ways that allowed you to improve backup/restore performance:

  • Enable the option "Allow multiple data readers within a drive or mount point"

    @SparshGupta  - This is always enabled by default for Win / Unix FS for achieving optimum performance. Is it not the case with clusters?
     
  • Increase data readers

    @SparshGupta - Support is coming out in SP32 to modify data readers setting at Server Plan level (All subclients mapped to plan will be impacted) using RestAPI. Changing it from UX won’t be supported still.

    To change the property at individual subclient level, you would still have to rely on Java GUI.

 



Thanks,
Sparsh

Userlevel 7
Badge +19

@SparshGupta thanks for the update! Updating it on an individual subclient is not possible as the properties are locked within the CommCell console by the subclient policy that is related to the server plan! 

I honestly do not understand why this is not improved so it is disaggregated from the server plan and moved to something like a generic policy. Most of the times you only want to change this on specific systems and this approach means you have to create a separate server plan and change the amount of readers via the API. In that respect you could even consider adding the option in the UI anyhow which improves user experience. 

Userlevel 4
Badge +10

Hi @Onno van den Berg 

 

From SP32 onwards, we are moving away from subclient policies (FOR SERVER PLANS ONLY).

 

Which means, once the customer commservers are upgraded to SP32, if the exisitng server plans is qualified based on some criteria, we will remove the subclient policies mapped to it and things will be manageable at individual subclient level easily. All the properties set at current subclient policy will be preserved for all subclients.From customer perspective, there would be no change in end user experience. Everything will continue to work as same.

 

For new server plans, no more subclient policies will be created. Instead of creating explicit subclient policies, we will inject few properties in DB directly and convert it to “content policy” (internal term used within commvault).

 

This will DECOUPLE the dependency completely and each and every property could then be managed at individual subclient level, which will simply things.

 

But, at the same time, we are not porting all GUI options to Command Center. For instance, number of data readers. It needed, it would need to be managed via API or manually via Java GUI.

 

Also, please note that this is not a hard restriction. If there’s a CCR in future, development team can surely re-evaluate. Command Center always go with smart defaults, which 90% of the customers are already using today.

 


 

  • Let’s say, today you have a server plan.
     
  • This in turn has 3 corresponding subclient policies (Windows / Linux / MAC)
     
  • Let’s assume, some custom settings are set at subclient policy level.
     
  • There are 10 subclients mapped to the subclient policy.
     
  • To change any property, today you have to go to subclient policy and change it, but this will impact all 10 subclients.
     
  • After CS is upgraded to SP32, subclient policies will be removed silently if the server plan qualifies for conversion.
     
  • The custom properties which were already set, will be preserved and nothing will be changed from end user perspective.
     
  • Now, for existing subclient mapped to the server plan, if any property needs to be modified, it can be done so at individual subclient level.
     
  • For new server plans created from SP32 onwards, subclient policies will not even be created. We will inject those properties into the database directly, and things will again be manageable at individual subclient level.

 




DISCLAIMER - SP32 is not released yet for customers, and if any last minute hiccups are noticed, we might push this forward to future releases.


 

Thanks,

Sparsh

 

Userlevel 7
Badge +19

@SparshGupta Finally and I hope we'll see more of these changes coming, but do hope this is something that has been build from scratch instead of an enhancement that builds upon existing functionality like the current plan implementation. 

I do hope all server plans are migrated by Commvault very soon after FR32! Please make sure changes are carried forward, so you will not have to drag legacy with you as this is impacting stability and user experience. 

Userlevel 3
Badge +10

Hi @Onno van den Berg 

 

From SP32 onwards, we are moving away from subclient policies (FOR SERVER PLANS ONLY).

 

Which means, once the customer commservers are upgraded to SP32, if the exisitng server plans is qualified based on some criteria, we will remove the subclient policies mapped to it and things will be manageable at individual subclient level easily. All the properties set at current subclient policy will be preserved for all subclients.From customer perspective, there would be no change in end user experience. Everything will continue to work as same.

 

For new server plans, no more subclient policies will be created. Instead of creating explicit subclient policies, we will inject few properties in DB directly and convert it to “content policy” (internal term used within commvault).

 

This will DECOUPLE the dependency completely and each and every property could then be managed at individual subclient level, which will simply things.

 

But, at the same time, we are not porting all GUI options to Command Center. For instance, number of data readers. It needed, it would need to be managed via API or manually via Java GUI.

 

Also, please note that this is not a hard restriction. If there’s a CCR in future, development team can surely re-evaluate. Command Center always go with smart defaults, which 90% of the customers are already using today.

 

 

  • Let’s say, today you have a server plan.
     
  • This in turn has 3 corresponding subclient policies (Windows / Linux / MAC)
     
  • Let’s assume, some custom settings are set at subclient policy level.
     
  • There are 10 subclients mapped to the subclient policy.
     
  • To change any property, today you have to go to subclient policy and change it, but this will impact all 10 subclients.
     
  • After CS is upgraded to SP32, subclient policies will be removed silently if the server plan qualifies for conversion.
     
  • The custom properties which were already set, will be preserved and nothing will be changed from end user perspective.
     
  • Now, for existing subclient mapped to the server plan, if any property needs to be modified, it can be done so at individual subclient level.
     
  • For new server plans created from SP32 onwards, subclient policies will not even be created. We will inject those properties into the database directly, and things will again be manageable at individual subclient level.

 



DISCLAIMER - SP32 is not released yet for customers, and if any last minute hiccups are noticed, we might push this forward to future releases.


 

Thanks,

Sparsh

 

This seems like a sharp shift away from the way things were previously done.

Does this mean that in the future all subclient content will have to be managed individually?

Userlevel 4
Badge +10

@chrisknows - No

 

Okay, so in SP30, when you create a server plan and go to plan details page, you would see a tile called "backup content". When that toggle is enabled, it allows you to set backup content at plan level. But, this in turn creates multiple subclient policies in Java gui, and all the subclients mapped to the plan will fetch the properties from the subclient policies.

 

From SP32, when you create a server plan and go to plan details page, you would still see a tile called "backup content". When that toggle is enabled, it allows you to set backup content at plan level.

 

BUT now, when backup content is set at plan level, we will not create subclient policies, rather insert a DB query at server plan properties level. All the subclients which will be mapped to this plan will still continue to inherit the content set at plan level by default, which can be overridden as needed. You won't have to set content for each subclient manually.

 

Now, the greatest advantage this would offer in huge performance improvement specially on Metallic. Previously, api calls from subclient policy level were quite expensive, which will not be the case anymore. Secondly, the subclient properties will not be tied to subclient policy anymore, which means if the customer wants to modify any property for just one subclient, he can do so without the need of creating a new server plan.

 

As I mentioned earlier, from an end user perspective, there would be absolutely no change in user experience.

 

Userlevel 4
Badge +10

Also, to add, in case your question was specific to editing plan content later, once the content is updated at server plan level, we will immediately update the db entry, and it will straightaway be reflected across all subclients which are inheriting content from this server plan. So, you don't have to manage anything individually.

 

Please let me know if you have any further queries.

Userlevel 2
Badge +10

@chrisknows - No

 

Okay, so in SP30, when you create a server plan and go to plan details page, you would see a tile called "backup content". When that toggle is enabled, it allows you to set backup content at plan level. But, this in turn creates multiple subclient policies in Java gui, and all the subclients mapped to the plan will fetch the properties from the subclient policies.

 

From SP32, when you create a server plan and go to plan details page, you would still see a tile called "backup content". When that toggle is enabled, it allows you to set backup content at plan level.

 

BUT now, when backup content is set at plan level, we will not create subclient policies, rather insert a DB query at server plan properties level. All the subclients which will be mapped to this plan will still continue to inherit the content set at plan level by default, which can be overridden as needed. You won't have to set content for each subclient manually.

 

Now, the greatest advantage this would offer in huge performance improvement specially on Metallic. Previously, api calls from subclient policy level were quite expensive, which will not be the case anymore. Secondly, the subclient properties will not be tied to subclient policy anymore, which means if the customer wants to modify any property for just one subclient, he can do so without the need of creating a new server plan.

 

As I mentioned earlier, from an end user perspective, there would be absolutely no change in user experience.

 

Understood. 

Thanks.

Userlevel 7
Badge +19

@SparshGupta Again thanks for the detailed insights in what is coming in the FR32 release which will add some level of tweaking that can be done on servers plan to optimize backup/recovery performance for specific use-cases. are there any other ways and or enhancement coming which help in this matter? 

Userlevel 4
Badge +10

Hi @Onno van den Berg 


Number of data readers was one very specific property related to performance && tweaking of properties at indiviual subclient level without the need to create a new server plan; we first hand noticed the benefits these 2 use-cases would provide for all customers, hence this was prioritized.

 

Other plan related enhancements specific to File Servers might come into future packs, however since there are no fixed timelines, I will not be able to provide further insights into it. But, please do take a look into the newsletter once SP32 is released, which might include enhancements for other agents, even I might not be aware of.
 

Thanks,

Sparsh

Reply