Testing Replica (B&R 6.0 and later)

[Choodee]

Can someone provide me with a link to a document outlining how to test a failover replica on v6? I knew the procedure on V5 which was cumbersome to say the least but I was able test without messing up the replication job. I noticed that there is now a failover and a failback in the wizard.

Thanks
Sandee

[Gostev]

This is covered in the sticky FAQ topic...

[Choodee]

Q: I want to test replica failover. Can I simply power on any replica restore point with vSphere Client?
A: Yes. Because each restore point is a snapshot, its contents will remain the same (all disk changes from the running VM will go into the new snapshot file the host would automatically create). Replication job also won't brake. Unlike with v5, testing replicas with v6 is really a breeze - thanks to the new way of storing replica restore points.

I did read the Sticky FAQ as well as watched the screencasts. But I'm actually more interested in using the Veeam wizard as opposed to manually powering on the replica through VClient. Namely the 'Failover to Replica' and the 'Failback' options in the Restore wizard.

Thanks
Sandee

[Vitaliy S.]

You can find all details about these wizard in our User Guide (page 192), which is available on the product web page under the Resources tab. Thanks!

[Choodee]

great thank you!

Sandee

[fbroussey]

HI all,

I read the User Guide but I just want a precision on one point: Does tip page 49 says that you can do a failover in order to test the replica even if the original VM is in an operational state ? If yes what about the duplicate IP address and the client vue ?

Thanks for your answer.

[Gostev]

Hi Frederic, just use common sense considerations here. Would you power on a complete copy of the VM on the same network? Probably not. However, if you replica VM is on the different network, or has re-IP rule in place and the actual application will not go crazy because of both VMs operational (such as in case with DC), then you can do this. Thanks!

[fbroussey]

Hi Anton,
Of course the replicas are just in case of a disaster on the first technical room (in our case we use replica on the same site but the replicas are in a technical room at the other side of the building) . In such a case, what is the method to test that the replicas are ok ? Should I disable the job, make a snapshot of the replica, change its vm network (on a vswitch isolated) , and boot it, and then delete the snapshot as it is toldl by veeam for the V5 ?

Thanks for your answer.

[dellock6]

You do not need to stop the job or snapshot the VM. Simply isolate its network from the production network and power it up while the replica job is not running; you can create a isolated vswitch to test. After tests are ok, simply shutdown the replica VM.

[fbroussey]

Hello all,

I have just a question that may be a newbie one but on page 48-49 of the user guide, it seems that you can do a failover to replica even if the Original VM is alive , isn't it.
If yes, what's about duplicate ip, in an ON-SITE Replication , as the last step of the failover to replica is to start the replica VM? ...

Thanks for your answer...

[dellock6]

For onsite you need to fence the network of the replica VM in some way, the easier one is to create a vswitch on VMware that has no uplink connected to it, and power up the VM with a port group connected to it.

[Daveyd]

Here is my scererio:

I would like to perform a test failover of several replica servers to our DR site. I have set up port groups with a separate isolated VLAN on each vswitch in the DR site. I plan to create a job to replicate the VMs and changing their networks to the DR port group and re-IPing each server to match the VLAN id. I am going to log into a client that is on the same VLAN that my replicated VMs just failed over to. However, in order for me to log into the application from the client to the replicated VMs, the appliction needs NTLM authentication. We are not replicating any of our DCs in this test scenerio. I assume allowing the replicated VMs access to Production DCs for client authentication would be a bad thing since the replicas have the same host name and SID. Is that correct?

[Gostev]

Yep, you most definitely should not do that! Having a DC replica in DR site is a must-have for your scenario.

[Daveyd]

Yea, I thought so. Should I replicate a DC that holds a specific FSMO role or should that not matter? Also, in the replication job, I would need to change the IP address to match all the other replicated servers on the DR VLAN, would that srew anything up with authentication in my test scenerio?

[Gostev]

I believe, you will need to replicate at least two DCs (not sure about FSMO roles, believe this does not matter). Otherwise, they will disable NETLOGON service after certain period of time (due to not being able to contact any other replication partners). We handle that in SureBackup jobs by booting DC in the special mode, but you would not be able to do this in your case.

Why do you need to re-IP all servers, if you are bringing them up on the isolated virtual network? Why not just have everything keep its existing IP addresses? Also, if you re-IP, what about DNS records? Do you have existing DNS server in DR site with DNS records pointing to the new IP addresses?

[Daveyd]

The original thought process was to have the replicas on a routable VLAN in DR and have a client access the databases on the replicas in that VLAN to test client functionality. Now seeing how the client/server communication relies on NTLM authentication and having to replicate DC(s), we are thinking to put the replicas on a non routable VLAN or even a port group with no attached physical NICs and having a VM with the client software installed on that same VLAN.

We need to do a complete Test failover every 6 months and are thinking of the easiest way of doing it. We also use SRM, which makes things a little bit easier

[Daveyd]

I have 3 hosts in my Production site and 3 hosts in my DR site. I configured multiple replication jobs to remap to a different port group on the DR site. When I run multiple jobs, it puts the associated VMs into the correct DR port group, however it puts all the replicas onto 1 DR host. Is there a way to prevent that and have the replicas reside on all 3 hosts or do I not have something configured correctly?

[Gostev]

Did you configure the replication job to put all VMs onto the same host?

[Daveyd]

I have 1 replication job per VM that I want to replicate (8 jobs/8 VMs). Each job is pointed to the DR cluster, not an individual host

[Gostev]

Ah, OK. I will need to check with devs how exactly the host is picked if cluster is specified as the target.

[Daveyd]

Ah, OK. I will need to check with devs how exactly the host is picked if cluster is specified as the target.

Any luck?

[Vitaliy S.]

Hi Dave, replication job just picks up the first host which is returned by the vCenter Server query.

[Daveyd]

So it sounds like choosing a cluster as the target in the replication jobs will not accomplish my task on evenly distributing the replicated VMs across each host in the cluster. Of course, when they are powered on, DRS will handle that, but I was hoping not to tell each job where to place the replica, thus choosing the cluster instead of each individual host.

[exmoor]

[merged]

Hi all, we are using Veeam 6.1 and have 2 sites, head office site and a DR site connected by a WiFi link between the 2 buildings.

We are using Veeam 6.1 to backup all our VMware 4.1 Vms to a SAN on site as one job and also replicate our VMs to a SAN at the DR site. We have 3 ESX hosts 2 at the main site conected to the local SAN and one at the DR site connected to its own SAN. We have a dedicated WinSvr 2008 R2 server running Veeam to handle the backup at main site and a VM Svr2008 R2 running veeam and acting as a proxy at the DR site.

I have tried to import the replica VMs to test the DR site but cannot complete the import as Veeam does not seem to want to play. I navigate to the VM folder on the SAN where the VMs are replicated to but the OK button remains greyed out.
What is the best way forward for me to be able to test the replicas and provide a simple solution to test the replicas using Veeam at the DR site and utilising the failover funtionality in Veeam.

Is it to setup a backup job at the DR site and map it to the already available replica VMs? or is there another way to test the replicas at the DR site? We have around 10 vms we will need to run in a DR event

I don't really want to Vsphere to the VMs on the ESX host at the DR site and snapshot the replica VMs before testing as I would like to use Veeam to keep things simple incase it is not me that has to bring the DR site up in a DR event.

Thanks
Allan

[kjc3303]

Hi Alan, my understanding is that the import facility is for importing backup files (vbk's,vrb's,vib's) so will not recognize the VM files created by replicating your production VM files.

Here is a nice article and the discussion comments below are nice for you concerns re simplicity.

http://www.virtualizationteam.com/veeam ... edure.html

I would say that the above solution is far more simpler that setting up another backup job. The latter would add more steps to the testing process as you would have to restore the VM from the backup file first although you could use instant recovery facility, but why bother when you already have a ready to turn on VM at you DR site a further argument is this is a real test aginst the VM\Host\Storage that you would need in a disaster.

Kev

[kjc3303]

You do not need to stop the job or snapshot the VM. Simply isolate its network from the production network and power it up while the replica job is not running; you can create a isolated vswitch to test. After tests are ok, simply shutdown the replica VM.

Looks like the link I posted above is out of date and Veeam is even better than I thought Guess I should read manuals more often!!

[exmoor]

Thanks Kev, I've seen that link before and followed those instruction when we were using Veeam 5. Great for testing but not good for for what I'm trying to achive. If a person can go into veeam already running on the server at the DR site and choose the failover option from a dialog box it simplifies things for us for non ict staff.

Once the backup job is done, its sorted. I am just trying to find out if there is another way.
We may be testing mothly so the chance of forgetting to snapshot could cause the replica backup to fail at next backup. Don't ask me how I know this ;o)

Thanks for the reply though.

Ta
Allan

[kjc3303]

No problem Alan as per Luca's post there is no need to snapshot anymore in version 6, does this not solve you issue?

Edit

Alan are you looking for a sort of sure backup for replicas feature? - This would be a pretty cool - automated scheduled DR testing.

[thavener]

kjc, I was just about to ask if this would be in a future release. Why wouldn't it be? It's already built. I would love this and maybe in Enterprise Manager run some reports on the DR Testing. Sure Backup Replica testing would be very awesome.

[exmoor]

Looking at page 49 of the user Veeam 6.1 manual

Important! If possible, avoid powering on a replica manually as it may disrupt further replication operations or
cause loss of important data. It is strongly recommended to use Veeam Backup & Replication
functionality to perform failover operations.

So this is why I'm trying to do it this way,

The VM replicas are on the DR SAN.

I have already created a job to copy the replicas to a new replica job on the DR installation of Veeam. I think the best way forward is the create the replica job on the DR site install of Veeam, map the vms to the copied replicas and stop the replica job on the main site. See if all is OK and use Veeam failover to test the site. I can do this without having to worry about duplicate IPs as I can just pull the plug on the WiFi link to disconnect from thr main site. I then literally have a replica of my main site at my DR site if the pooh hits the aircon at the main site.

Just a shame I have to copy the data thats already there, unless I'm missing something obvious?

Ta
Allan