Start a Conversation

Unsolved

This post is more than 5 years old

C

862

October 30th, 2017 16:00

Avamar "failover and failback" in a bi-directional replication environment

Trying to figure out if there is any feasible way to "failover and failback" clients in an Avamar bi-directional replication environment.

(in this particular case, both environments have Avamar integrated with Data Domain, but effectively the failover is at the Avamar level)

Clients at site A are activated to Avamar A; clients at site B are activated to Avamar B.

Avamar A replicates to REPLICATE on Avamar B; Avamar B replicates to REPLICATE on Avamar A.


Scenario - each Avamar needs to be able to be the backup target for clients at both sites should the other Avamar not be available.

Since clients cannot activate to the REPLICATE domain, my thought is that each Avamar will need a "failover domain" set up on it that reflects the same domain structure that its partner Avamar has for what are typically its "local" clients. So the overall domain structure of Avamar A will need to be recreated in an easily manageable location on Avamar B, and vice versa. As well, each Avamar will also need the "failover objects" necessary to perform backups on the clients in the "failover domain" (datasets, schedules, retention and groups). Having this in place will allow the same backups to run on the "alternate" Avamar as were running on the "primary" Avamar before the failover.

Up to this point, there's a lot of stuff to do, but it's not too difficult (IMHO), since a lot of it is just recreating what already exists on the other Avamar. The fun part is what needs to happen for things to work when failover actually occurs - activating the clients to the alternate Avamar.

This is the part I am trying to figure out - is there any "efficient" way to activate clients to the alternate Avamar without doing it from the clients themselves?

I have done some testing with Client Manager and it doesn't seem to like "moving" clients to a target where they already exist (which they would if one had previously failed over, then failed back, and then later had to fail over again). If absolutely necessary, I guess there is the option of "retiring in bulk" when the clients in the failover domain are failed back to their original Avamar, but it would be so much easier if clients could just be "reactivated" between Avamar systems from the Avamar systems themselves.

I have also tried to deactivate and reactivate clients between Avamar servers but typically I run into a situation where the client "doesn't want to play" with the alternate Avamar because it has a different IP/hostname, or doesn't want to "reactivate" with its original Avamar because it's already activated. I believe these issues could possibly be addressed by restarting the Avamar agent on the client, but if that has to be done for hundreds of clients, it's not really that much more efficient than just reactivating from the clients themselves, which is what I am trying to avoid.

So, is there a feasible way for Avamar clients at site A to be activated to the Avamar at site B, and then later reactivated to the Avamar at site A, without having to do so from the clients themselves? Or are we (and customers) still stuck with client based reactivation and/or agent restarts?

(FWIW - I worked with Enterprise Hybrid Cloud a bit a while back, and it seemed like there was a lot of "normal" Avamar stuff that had become automated in that environment in terms of keeping the configuration "in sync" in case failover was needed; certainly that overall environment is better suited to consolidation and automation relative to the virtual and cloud aspects, but a lot of things looked like they were just "typical" Avamar functions that were "platform generic" and had been automated somehow - not sure if any of that could be used here)

(also FWIW - I understand that this kind of "failover/failback" will result in a "mix" of backups for each set of clients in terms of some residing in the REPLICATE domain and others residing elsewhere; at this point, I am more concerned with the failover and failback aspect - the clients have to be able to back up before anyone worries about where to look when restoring)

All comments/feedback appreciated - thanks.

No Responses!
No Events found!

Top