Veeam B&R Architecture for 2 Peer Sites

[randy]

We are evaluating Veeam B&R and after a lot research and planning, I think we have our plan put together to take into account both our sites, vCenter and Veeam B&R availability itself.

I hope some of you folks with more knowledge and experience have time to take a look at the plan and point out mistakes or ways we could do it better. Validation (or not) is much appreciated!

We have 2 sites: Gamma and Alpha. Neither is a true primary or DR site. Both are really DR sites for the other. Each site has one ESXi host. 1 vCenter server at site Alpha. Site-Alpha is larger site and closer to Primary.

Idea is to have 2 VEEAM servers – one at each site. We’ll install Veeam B&R on both but we won’t set up VEEAM-Gamma. It will just sit there with an essentially empty DB and no Backup Infrastructure. VEAM-Gamma will however be a backup proxy, repository and WAN accelerator for VEEAM-Alpha.

VEEAM-Alpha will backup configuration to its repository at VEEAM-Gamma. VEEAM-Alpha will also replicate vCenter to ESXi-Gamma via its proxy on VEEAM-Gamma.

If we lose site Gamma, all we have to do is fail over / instant recover the VMs replicated/backed up from site Alpha.

If we lose site Alpha, it’s a little more involved but reasonably quick:
1. Bring up vCenter Replica on Gamma manually
QUESTION: Does Re-IP happen at time of replication or at time of fail over?

2. Edit etc\hosts file of VEEAM-Gamma to point to new IP address of vCenter

Then on Gamma B&R:

3. Add repository already physically on VEEAM-Gamma but logically owned by B&R-Alpha

4. Restore the Alpha B&R Configuration in that repository
Enter passwords
QUESTION: do I need to do any re-scans?

5. Disable backup, backup copy and replication jobs that can’t happen until Alpha back up

6. Gamma B&R: recover VMs
We will have a virtual network on our virtual router at Gamma that looks like the Alpha network. We’ll just put recovered Alpha VMs on that network

We are good to go?
Thanks for any and all help.

[foggy]

Hello, Randy. Generally, your plan looks good to me. A couple of answers/considerations below.

1. Bring up vCenter Replica on Gamma manually
QUESTION: Does Re-IP happen at time of replication or at time of fail over?

Re-IP occurs during failover, so you would need to take care of this manually.

3. Add repository already physically on VEEAM-Gamma but logically owned by B&R-Alpha
4. Restore the Alpha B&R Configuration in that repository
Enter passwords
QUESTION: do I need to do any re-scans?

As far as I remember, rescan is performed automatically right after Veeam B&R configuration is restored. So everything you would need to do here is just import the backed up configuration (repository will be added during configuration import) and wait until rescan is completed.

[veremin]

As to RE-IP issue, you can replicate VB&R server in order to have a cold console in the second site (Gamma). Should need be, you can power it up, and execute failover/failback procedure for vCenter machine. During this operation vCenter can be RE-IPed.

Otherwise, restore configuration first prior to doing anything, and then follow the same steps, performing failover operation automatically via Gamma backup console.

Thanks.

[foggy]

Another approach is to make Gamma Veeam B&R instance responsible for replication of VMs from the Alpha site. A bit more management, however easier failover in case of DR.

[randy]

Thank you foggy,

As to RE-IP issue, you can replicate VB&R server in order to have a cold console in the second site (Gamma). Should need be, you can power it up, and execute failover/failback procedure for vCenter machine. During this operation vCenter can be RE-IPed.

That would be nice but how can VB&R bring up vCenter VM if vCenter isn't up in the first place? We're assuming we lost the Alpha site without warning (i.e. unplanned outage). And we would need to manually re-IP VB&R anyway, right? So even if it were possible it would seem like "6 of one vs half a dozen"?

[randy]

Another approach is to make Gamma Veeam B&R instance responsible for replication of VMs from the Alpha site. A bit more management, however easier failover in case of DR.

Hmm, I'd dismissed that but now you are causing me to re-think. So to enlarge up on that. How about 2 "peer" VB&R servers. Each with repositories local and on their VB&R peer at the other site. They would share the proxy and WAN accelerator on each peer. Each VB&R would manage the backup&copy or replication of VMs at the other site. Each peer in effect "pulling" remote VMs to it's local site.

This includes vCenter. That eliminates the need to restore configuration, re-scan or anything else. Either site goes down and VB&R is already up and ready to re-cover VMs.

One minor wrinkle. If the site to go down is Alpha, Gamma VB&R can't do anything until vCenter comes back up. Options:

Manual
1. bring up vCenter replica manually
2. Manually re-ip vCenter
3. update Gamma VB&R etc/hosts file to vCenter's new IP
4. recover VMs

Automatic
1. Configure Gamma VB&R replication job to assign vCenter replica directly to the Gamma ESXi host instead of through vCenter
2. update Gamma VB&R etc/hosts file to vCenter's new IP
3. When Alpha goes down, failover vCenter with Re-IP
4. recover VMs

Hah! Either way I should put a job in vCenter that updates it's record Gamma VB&R's etc/host file whenever it comes up. In the automatic scenario it reduces it to just failing over vCenter. How clean is that? Or just break down and implement a DNS server on the management network with dynamic DNS but I don't want more components.

What do you think?

[randy]

As to RE-IP issue, you can replicate VB&R server in order to have a cold console in the second site (Gamma). Should need be, you can power it up, and execute failover/failback procedure for vCenter machine. During this operation vCenter can be RE-IPed.

Otherwise, restore configuration first prior to doing anything, and then follow the same steps, performing failover operation automatically via Gamma backup console.

But again, am I missing something or how can you perform a failover in VB&R if it can't communicate with vCenter which would be the case at that point in time. And you'd have to manually re-IP the VB&R replica too.

[veremin]

But again, am I missing something or how can you perform a failover in VB&R if it can't communicate with vCenter which would be the case at that point in time.

I'm wondering how Replication jobs are setup. Via standalone hosts or via vCenter? In the former case, you can manually power up backup server and let it perform failover/failback activity for other servers in automatic fashion. Thanks.

[randy]

Been planning to go through vCenter because of Veeam recommendation. I don't care about vMotion because we don't use it now or foreseeable future. Veeam says that you can get a errors when bypassing vCenter...

[foggy]

1. Configure Gamma VB&R replication job to assign vCenter replica directly to the Gamma ESXi host instead of through vCenter

That is what Vladimir actually meant, having vCenter added via standalone hosts, you have the ability to automatically failover and re-IP it via Veeam B&R UI.

[randy]

That is what Vladimir actually meant, having vCenter added via standalone hosts, you have the ability to automatically failover and re-IP it via Veeam B&R UI.

OK, thanks very much to both of you!

So, to finish up for now, if you don't need vMotion what is the risk/downside of connecting vCenter directly to hosts controlled by vCenter? When would VB&R operations throw an error as described in Veeam Documentation? Or is that outdated?

[Vitaliy S.]

I do not expect you to see any errors when using direct host connection, both methods should work fine. Here is the existing topic on all the pros and cons of using each connection method > vcenter vs standalone hosts

[randy]

OK, great. I think we've got a great setup planned and this forum really improved it. Thanks!

[randy]

Quick question re: the other VB&R server I need to set up at this point. It is already a proxy/repository/wan accelerator for my first VB&R server and therefore has those components already installed. Can I simply install VB&R on it? Will the presences of the aforementioned components cause a problem?

[veremin]

Not likely, as you're going to install console of the same version. Thanks.

[foggy]

Keep in mind though that the number of concurrent tasks assigned to each Veeam B&R's components (proxy and repository) is counted within the corresponding instance. E.g. Gamma Veeam B&R will not know about Alpha proxy installed on the same computer.

[mfc]

Is it actually possible to have two B&R servers that are "aware" of each other, and able to act as proxies for each other? I plan on re-architecting when v8 releases and I'm considering the following:

-B&R server A in Primary Site handling local backup jobs
-B&R server B in DR site handling replication jobs
The Whiteboard Friday guys recommended this for two reasons:
1. B&R server is primary site will allow backup jobs to continue running in the event of WAN outage
2. B&R server in DR site will allow easier failover/re-IP since you have a running B&R server rather than just a proxy

I like the benefits this would bring, but I really want to use the "Replication WAN Acceleration" and "Replicate from Backup" features in v8. The only way I see this being possible is if one B&R server can act as a proxy for another B&R server.

Additional info:
Each B&R server will be physical box using "Direct SAN Access" method and will have local SSD storage dedicated to WAN accel. cache.

[foggy]

Both instances indeed are able to act as proxies for each other. What I was trying to say is that you should keep the load aspect in mind - both Veeam B&R instances will assign tasks to the same servers but the maximum number of concurrently running tasks will be counted within each of them (one instance will not count tasks assigned by another instance to the same proxy server), so unless you specifically control it, you might get double load on proxy servers.

[mfc]

Both instances indeed are able to act as proxies for each other. What I was trying to say is that you should keep the load aspect in mind - both of them will assign tasks to the same servers but the maximum number of concurrently running tasks will be counted within each of them (one instance will not count tasks assigned by another instance to the same server), so unless you specifically control it, you might get double load on proxy/repository servers.

Ok I got you. They can proxy for each other, but are unaware of running tasks from each other. So if you're going this route you really need to micro-manage your "Maximum Concurrent Tasks" settings and/or job schedules to avoid overloading a proxy or repository.

Thanks for the clarification. Can't wait for the v8 release!!!

[foggy]

Ok I got you. They can proxy for each other, but are unaware of running tasks from each other. So if you're going this route you really need to micro-manage your "Maximum Concurrent Tasks" settings and/or job schedules to avoid overloading a proxy or repository.

Exactly.