commvault.com commvault.com
Solved

MA Decommission hosting GDSP - Is there a way to migrate but keep the Storage Policies in tact?

  • 4 February 2022
  • 6 replies
  • 141 views
M
Rank
Userlevel 2
Badge +6

Hi Commvault People,

 

I have a tidying up exercise to do, which will ultimately involve this:-

 

1 - Decommission two MA’s currently working as partitioned dedupe  (lets call, them MA3 and MA4)

2 - Migrate workloads to remaining MA’s, also with their own partitioned GDSP configs.

     Lets call them MA1 and MA2.

3 - Noting that Storage Policies on MA1\MA2 versus MA3\MA4 have very different retention.

 

I know that generally speaking, you can easily reassociate to another SP and away you go, but that’s only useful if you have matching retention.

The issue I have is that my MA3 and MA4 Storage Policies (whose ma’s I want to retire) are set to Infinite retention.  The Storage Policies on the remaining ma’s (MA1\MA2 are not).

 

So If I want to migrate the workloads away from MA3 and MA4, is it possible to somehow keep the Storage Policies in tact that were previously associated with MA3 and MA4. I would prefer to keep them in tact to avoid yet more legacy and historical SP’s clogging up the environment. And given that the retention is infinite, they will be around forever.

 

I suppose what I night need to do, is add a second library to the MA3\MA4 GDSP, which is the same library used by MA1\MA2. Therefore when the MA3\MA4 library is decommed the SP will continue to write to MA1\MA2.

 

That raises two questions:-

1 - Is that possible? Can I add a second library to an existing GDSP.

2 - What do I do about DDB migration?

 

Question 2 “What do I do about DDB migration” is also very interesting.

Not being satisfied with wanting my MA3\MA4 Storage Policies to remain in tact, I also don’t want to bring across the MA3\MA4 ddb’s.  And the reason for that, is that the extra workload from the MA3\MA4 jobs can easily be accommodated in the MA1\MA2 DDB’s. 

Similarly, if I bring across the DDB’s from MA3\MA4 it means I need to find volumes to host them, and it will almost certainly have a negative impact on the MA1\MA2 DDB’s and their Q&I times.

 

My closest solution so far is to:-

 

1 - Associate MA3\MA4 clients to the MA1\MA2 Storage Policies.

2 - Create a new Copy on one of the MA1\MA2 Storage Policies and assign infinite retention

3 - Assign MA3\MA4 clients to new SP Copy.

4 - Migrate the DDB’s from MA3\MA4 but only select “change config only”.

 

I think this would take it pretty close, however, there are a couple of things I don’t like:-

 

1 - Once you have a “selective” copy on a Storage Policy, no clients are ever added to any of the copies in future. This is a big gotcha for the unsuspecting and I have been backups without a copy for this reason. It is far more practical to leave Storage Policies which add all clients to a secondary copy automatically.

 

2 - Impact on migrating the GDSP DDB’s from MA3\MA4 but selecting “change config only”.

I know we don’t need the DDB’s for restoration purposes, but is there any downside to this action?

 

Soz for such a big question, but if anyone has had a similar situation or maybe one of the Commvault people could chip in then that we help a lot.

 

Thanks

 

 

 

 

 

 

icon

Best answer by Vaidotas Tamasauskas 7 February 2022, 14:35

View original
If you have a question or comment, please create a topic

6 replies

S
Rank
Userlevel 7
Badge +15

Hi @MountainGoat 

Thanks for the question, that’s quite a bit to take in.

I’ve been having some discussions in support and there’s certainly risks involved with making these changes, so immediately I would like to advise caution.

Give me a little more time and I’ll come back with some more details shortly.

Thanks,

Stuart

Customer Support
M
Rank
Userlevel 2
Badge +6

Thanks Stuart,

 

I suppose my second preference would be to create a new SP (and associate with MA1\MA2 resources).

And if I had to that, I would still be interested in the DDB “ change config only “ so as to avoid having to host the original DDB’s.

 

I would definitely be interested to know your viewpoint on that.

Thanks

 

V
Rank
Badge

Hello @MountainGoat ,

In general we would recommend to deal with our Professional Services to set configuration the best way accordingly to your business need.

There are few questions to clarify to make sure we will go right direction:

  • Is the disk library a local storage on MA03/04, or is this a storage, which could be accessed by MA01/02 after decommissioning the MAS03/04?
  • Are you going to continue running jobs for the clients, which are now associated with MA03/04, or keep only for restore purpose?

Few initial answers:

  1. I assume for the second question above, the answer is yes, as you mentioned moving workloads, but then there is no other chance, as migrating DDBs etc.
  1. Also you would need MAs 01/02 having access to data, written by MAs 03/04.
  2. You would need to migrate index cache to MAs 01/02.
  3. As I understand, your are running primary backups with “Infinite” retention on MA03/04, so you need these clients run to primary copies on MA01/02 (not secondary copies) - I would say you would just need fix data paths under policies pointing to MA01/02 having access to the library, where MA03/04 are writing to.
  4. To consider - MA 01/02 will have load of all four your current MAs.
  5. You can create NEW policies with infinite retention and assign to the global policy with MA01/02 and associate MA03/04 clients to it, but again here a lot different scenarios happens for your current global policy, which need to be properly discussed and reviewed, like additional baseline written to MA01/02 library, also restore questions about old jobs.

To answer the question about migrating DDB with config only to a new empty location - this will make DDB corrupted. So it’s way better to perform DDB move action, where we do all checksum controls ensuring DDB integrity during the migration process.

 

I guess that is it for beginning. I can clarify any further questions coming from it.

 

Thanks,

Vaidotas

 

 

M
Rank
Userlevel 2
Badge +6

@Vaidotas Tamasauskas 

1.    I assume for the second question above, the answer is yes, as you mentioned moving workloads, but then there is no other chance, as migrating DDBs etc.
Sorry - I don't quite follow on this statement can you please clarify.

 

2.     Also you would need MAs 01/02 having access to data, written by MAs 03/04.
Yes - We are familiar with and it is very straight forward.
   
3.     You would need to migrate index cache to MAs 01/02.
OK. This is interesting, but if I create a new SP what purpose will moving the IC perform?
I would expect the new jobs to reference the MA1\MA2 DDB since we will model the new SP from the MA1\MA2 GDSP.
And since a copy of the I\C is written to the media (Cloud Storage accessible by all MA’s) then I would hope we are safe.
(But if copying the i\c is recommended then I will do that, thanks).

 

4.    As I understand, your are running primary backups with “Infinite” retention on MA03/04, so you need these clients run to primary copies on MA01/02 (not secondary copies) - I would say you would just need fix data paths under policies pointing to MA01/02 having access to the library, where MA03/04 are writing to.

Apologies - I should have clarified. Its only the Secondary Copy on Infinite (Cloud). The primary copy is short-term.
And if I go with plan B (new SP’s based on MA1\MA2 GDSP) then I don’t believe  the fixing of data paths will be required.

 

5.    To consider - MA 01/02 will have load of all four your current MAs.
Correct. I have “ran the maths”. We look ok. Although my biggest concern is creating a new DDB for the Infinite-retention copy as over time this will obviously bloat out. However, I have the previous DDB to compare to for size, records and performance.
Also worth noting MA1\MA2 are extra-large specced servers so plenty of beef.


6.    You can create NEW policies with infinite retention and assign to the global policy with MA01/02 and associate MA03/04 clients to it, but again here a lot different scenarios happens for your current global policy, which need to be properly discussed and reviewed, like additional baseline written to MA01/02 library, also restore questions about old jobs.
Yes. So I'm thinking along these lines:-

New SP based on MA1\MA2 GDSP.
I'm not sure how I would calculate new baseline based on previous MA1\MA2 ddb performance with added extra workload.
Is there a way of doing that (please provide url if there is, thanks).
So far, I've really look at MA1\MA2 Q&I's, baseline size, server performance, and MA3\MA4 Q&I's. This is never an exact science, so not that easy.

 

7.    To answer the question about migrating DDB with config only to a new empty location - this will make DDB corrupted. So it’s way better to perform DDB move action, where we do all checksum controls ensuring DDB integrity during the migration process.
OK. I think we need to clarify something here.
For the old MA3\MA4 SP Infinite Copy (which will become legacy\ inactive SP) I don't believe I need to physically migrate the DDB. Is this correct?
And if I don't need to physically migrate, I would prefer to migrate but using the "change config only" option. The reason I would use "change config only,  is that I have read it is better to do that than not bring the DDB over at all. Something to with Commvault wanting to sync the ddb totals in its Commserve DB.

Thanks for the input so far.
Can you please check on my replies and see what you think.

 

 

 

M
Rank
Userlevel 2
Badge +6

*Bump*

 

Anyone from Commvault out there.

 

Thanks

V
Rank
Badge

Hello,

Apologies for late reply, but without seeing whole environment (like having CSDB on test VM staged) is really hard to answer all your questions and I believe even more will appear later. 

There are many points where the things can go wrong and I do strongly suggest to contact your Commvault account manager (sales person) to involve professional services (billable), but to get all configuration right from beginning.

 

Thanks

Terms & ConditionsCookie settings