Handling Frequent Failover between hosts

[Rumple]

In our field offices we have 2 local servers with no shared storage. We have Backup jobs and a replication job occurring against the VM that's the "passive" VM.
The challenge is, when we failover to the passive node (for instance to patch the primary), I need to go reconfigure all the jobs again to start now replicating the other way after failover)

Is there a better way to manage this. I was thinking creating 4 jobs...when host1 is active, and when host 2 is active and just enabling and disabling the jobs depending on which is active, but not sure if thats going to make a mess of the backups. Storage wise I'm not really concerned, more, is the replication jobs going to screw things up.

[foggy]

Hi Mark, could you please elaborate on active/passive nodes and what node you're actually backing up/replicating? Generally, you're totally fine with several jobs backing up/replicating the required VMs based on the failover status. Backups will be stored in separate repositories/folders and replication jobs will create the corresponding replicas on different hosts with different names so you wouldn't mess anything up. I'm only a bit concerned with how are you performing a failover.

[Rumple]

Sorry, I didn't get the notification on this.
The situation is we have is this:
Host 1 running "live" VM (VM1)
Host 2 has a replica of live VM (VM1_Replica)

We have 2 jobs...
Replicate VM1 to VM1_Replica every 15 minutes
Backup of VM_Replica every hour and Copy job offsite

Currently, if I want to patch Host 1 we do a permanent failover so now the "Live" vm is VM1_Replica
Because I cannot lose any data, I now have to change both my replica and backup Jobs. I can't remember if I can just remove VM1_Replica and ADD VM1 to the jobs so that the "Passive" VM is getting backed up or if I need to recreate the jobs.
I think I can remove replica and add non replica named VM, but then I get warnings that a VM was removed from the Job

Trying to come up with a more seamless way to do this, but I can't think there is one currently.

[ronnmartin61]

Unless I'm missing something a more seamless way would be to simply run failover but NOT make it permanent. When your Host 1 maintenance is completed initiating a failback we will run a "reverse replication" to synchronize VM1_replica changes back to VM1 on Host1.

[Rumple]

I've honestly never done a failover and failback..I honestly always thought it would just drop the changes by reverting the snapshot...Infact it never occurred to me to even try...seriously...if its that stupid I am going to kick my own ass....

[ronnmartin61]

I think you'll be pleased with the results

[Rumple]

I've been testing and reading and I was using undo failover in my previous testing, without actually paying attention to the menu and realized there is failback to production as the option which will basically replication backwards, however the challenge is that its going to introduce another problem is that the digest calculation that's happening is going to cause an outage when no one is expecting it (even me) since we can't predict when that's going to finish.
Normally with these VM's we have a vendor plan the outage with the Field Office, we do the failover (which takes 5 minutes), the vendor ensures things are working (its a critical SCADA system) and then at some point (week or 2 later if needed), the same thing happens in reverse.
Using my older copy of a system, Phase 1 (failover) worked as expected, however, the failback is basically at a point of, I've started failover, sometime in the next X hours its going to complete failback...then I will vendor to check it...of course vendor will already know because the Field staff are going to start screaming most likely because system went down. On this particular VM..its 700GB..its been 35 minutes@19% calculating digests....so I "Guess" somewhere in the next 2.5 hours it should go down and up?

Shared storage...can be a wonderful thing when you have the option...lol

[ronnmartin61]

We are planning some new capabilities in the upcoming v11 VBR release to make failback more predictable via scheduling and such. It won't make the failback faster necessarily but allow you a bit more control.