Failover Question

[Jonohue]

Hello all,

If I have two different sites (one in one city, one based out of another) and they're both in their own datacenter / host cluster in the same vCenter, and I'm looking to fail over a site completely (Detroit, MI to Flint, MI)...

If I have replicas that are only as far as I know in the Detroit, MI site (not the Flint, MI site) in their replica jobs and all that I plan on failing over to Flint, MI as far as replicas go are in ready status and have at least a couple of restore points...

Assuming both Detroit, MI and Flint, MI sites both have master backup servers (they have VBR 11) and also they both have backup proxies....

*NOTE* Flint, MI site does not have anything "set up" right now within Veeam Backup and Replication console, when you open VBR 11, it literally just shows the console and that's about it, but it does however link to storage repositories and what not as the secondary proxy is being used for attached storage....


Why am I here?

I want to ensure that my thought process here is correct in what I'm looking to do, and the goal that I'm trying to achieve.

Let's say 6 months from now I wish to fail over my Detroit, MI site to my Flint, MI site (~18-20 virtual machines that have replicas both in ready status and good restore points - AGAIN - only stored on the primary and not listed on the secondary VBR server in Flint, MI to my knowledge if this changes anything) if my boss asks, and just be able to say "OK" - then if we wish to move over to Flint, MI for the next 6 months instead of Detroit, MI for PRODUCTION rather than a secondary, BUT ALSO HAVE THE ABILITY TO FAIL BACK TO DETROIT, MI and essentially be able to flip flop back and forth between which site is production and which one isn't....

Is there anything besides the following that I would need to do to perform this process?

From the VBR workflow that I see within the VMWare Documentation, it appears that "Have Dependent VMs?" - Let's assume YES - I create failover plans. We already have a couple created.

Movement of workload to replicas is planned? - Let's say "YES" as of right now in this instance as again, we're looking for the ability to simply switch back and forth and have the ability to run from one or the other for sometimes months at a time, and keep the data after each "flip flop between sites" - the Veeam documentation points to doing a Perform Planned Failover which would then in the workflow move down to Swithc back to original VM? ........ The workflow in this case is where I'm tripped up - since I could be looking at wishing to run production from the Flint, MI site for maybe months at a time before flipping back to the Detroit, MI site, would I want to perform a permanent failover, or do a "fail back" once I'm done 3-6 months later and want to "flip flop" between sites?

Any help in this matter would be appreciated.

Thanks!

Jonohue

[HannesK]

Hello,
yes, one VBR server per site is good to be prepared for unplanned outages to be able to press the "failover now" button.

With a duration of months, I would to for permanent failover. Otherwise you would end up with large snapshots that finally probably just fill up all your datastores. After permanent fail over, you need to set up a new replication job again to the original location.

Just curious: what is the use case of the scenario? sounds like work (network configuration) for little benefit...

Best regards,
Hannes

[Jonohue]

HannesK,

Thank you for the information.
To my understanding, the procedure with our current setup would be a little something like this:

Detroit, MI (Primary site / VBR Server DetroitMaster)
Flint, MI ("DR" site / VBR Server FlintMaster)

Each server has its own proxy as well.

The replica jobs for the virtual machines that we would be "failing over" to the Flint, Michigan site are all on the PRIMARY Detroit, MI VBR server as replication jobs..
There are currently no replica jobs or anything for that matter really listed in the VBR console on FlintMaster.

The Detroit and Flint environments are within the same vCenter, but as far as the VBR current configurations are concerned, literally everything is only in the Detroit, MI server right now, the DetroitMaster server.

With this being said, I would be able to create a failover plan to put the failover in a certain order......
Then I would be able to say "yes, my movement of the workload in this instance / usage case is planned, so let's perform a planned failover"...
Then in the workflow for DR replication, the next point is "Switch back to original VM?" - my understanding is that in this specific usage scenario and set of circumstances, that answer would be "NO" as it could be for 3-6 months at a time, and doing a "PERFORM PERMANENT FAILOVER" would make more sense than doing a failback or something like that where snapshots would be chewing up datastore space, and there could be issues if the snapshots are broken, etc....

So once we do "Perform Permanent failover" from within the VBR console within the DetroitMaster VBR server on the machines that we wish to permanently fail over, the workflow as far as transferring and shifting IO processes to the other site (Flint, MI) has been completed. Is THIS the part of the process that actually takes the replica and then we can choose to target the other site, aka Flint, MI within the same vCenter? I'm hoping that once we say yes to perform permanent failover, it comes up with an option to move this replica VM that is turned into a production VM to the host cluster within the Flint, MI datacenter in our vCenter.

The Detroit, MI and Flint, MI datacenters are all visible to eachother within the same vCenter.

Is that how "Perform Permanent Failover" operation works?

That is the question that I have at this point as well as once that is done and we have production VMs that were once replicas on the Flint, Michigan side (hopefully) - do I need to do anything specifically on the Detroit, MI side?

Is there virtually anything else that needs to be done on the Detroit, MI side after the failover has been performed, and then the Detroit, MI side should be DR?

On the Flint, MI side it should now be production after "perform permanent failover" is performed to my understanding and the VMs should then be located within the vCenter in the Flint datacenter / ESXi hosts rather than being on the Detroit side, correct?

Once the VMs are running as production VMs on the Flint, MI side, I then would need to take the Flint, MI side and create replication jobs that replicate the same virtual machines within the Flint, MI VBR console sort of like we were doing on the Detroit side prior to the failover to ensure that we can actually go back the other way when needed? We would also need to set up manually all of the storage infrastructure, jobs, anything that used to be in the Detroit Veeam Backup & Replication console once Flint, MI is the "production" site right?

The usage case scenario is the following:

We want to be able to when necessary just "flip over" to the DR site and turn that site into production when our boss requests it. We would also just like to ensure that our process is structurally sound and makes sense so if we need to do this for an actual usage case other than "our boss requests it" - we can do so and spend 3-6 months at a time running in Flint, MI as the "primary production" site and then have Detroit running as the "DR" site.

I know it's a lot of work for seemingly little benefit, but I just want to ensure that if for some reason the company wants to go ahead and bounce out of the Detroit, MI location and use Flint, MI as production that we can, and that we can then also go the other way around.

Sorry for the long post, please let me know if this sounds correct or if any adjustments would need to be made.

Thanks again!

Jonohue

[HannesK]

sorry, I got lost in that text... I suggest to test it out with a small VM. It's really easy once you have done it

the user guide also describes it step by step: https://helpcenter.veeam.com/docs/backu ... lback.html

[Jonohue]

Hello,

I do not currently have an environment at my disposal where I can actually run a test of the failover plan to start firing up all the replicas, and then go to the replica tools / replicas menu and do "perform permanent failover".

My idea is that as the VMs / replicas original location / replicated location are all pointing to the vCenter that these locations share, I should be able to do the following:

Run my failover plans that have been created. Each has less than 10 virtual machines. This should to my understanding power on the replica VMs and then they will be powered on in a "failover / failed over" state. The replicas should then show up in the vCenter as well.

The workflow in the Veeam B&R 11 guide shows the "Movement of workload to replicas is planned?" ----> yes -----> Perform planned failover.

This is referring to the failover plans that I'm going to be running that powers on the replicas and puts the VMs listed in a "failover" state, yes?

My second question is once I do a "perform permanent failover" - this will break all replication with the original site, take that powered on virtual machine from my failover plan that I ran previously, and then I'm assuming when I actually can run a "perform permanent failover" VM by VM, it should give me the ability to decide which datacenter / host cluster / set of hosts to put the replica in?

Any input on this would be greatly appreciated as this is the way I understand it.

As long as somewhere in the process it gives me the opportunity to specify which datacenter / datastore / esxi host to move the replica VM to during a permanent failover / any part of the failover process, that would be great.

Thanks!

Jonohue

[HannesK]

Hello,
an empty test VM costs a few MByte in VMware (small Linux maybe a few hundred MB). That should be working for production environments.

the number of VMs in a failover plan is irrelevant. Your understanding about "power on" is described in the user guide and is correct, yes. Replicas are always visible in VCenter.

Failover plans are for emergencies. Planned failover does not involve failover plans. See user guide

These decisions about cluster / datastore etc. are already made. Trying it out or re-reading the user guide should clarify how it works.

The replica stays where it was configured during replica job creation.

Best regards,
Hannes