Discussions specific to the VMware vSphere hypervisor
Post Reply
GreenEnvy
Influencer
Posts: 21
Liked: 3 times
Joined: Jul 31, 2012 3:45 am
Full Name: Lee
Contact:

Recommended Topology?

Post by GreenEnvy » Oct 17, 2018 11:36 am

We have two sites running vSphere, a few hundred Km apart. Sites have 100Mbps fiber connections going over general internet (VPN'd), so not direct/dedicated lines.
We recently switched from having a vCenter in each site (vsphere essentials plus) to having one vCenter in the 'main' site (vsphere standard) and using ROBO licenses in the 2nd site (about 10 vm's).
We have a Windows VM in each site running Veeam B&R 9.5. Each site has it's own SAN's for storage.

Currently Veeam runs in each site, connected to the vCenter in the main site. Backups are done to a SAN local in each site. Replication jobs are setup in each site in Veeam to replicate to the other site.

Is this the recommended way to do this? Or should all the Veeam jobs be setup in one site, just using the other site as proxy? It's working how we're doing it now, but I want to make sure we're doing this the most efficient way.

Thanks for any input.

Rick.Vanover
Veeam Software
Posts: 601
Liked: 129 times
Joined: Nov 30, 2010 3:19 pm
Full Name: Rick Vanover
Location: Columbus, Ohio USA
Contact:

Re: Recommended Topology?

Post by Rick.Vanover » Oct 17, 2018 12:14 pm

I think what you are describing is a good setup, Lee. One thing that I recommend is that the Replication Metadata repository is kept close to the source data. Meaning, each site has a backup proxy locally and the metadata repository locally (can be on the proxy - it's small) and that there is a proxy in the remote site as well for local manipulation.

So - what you outlined is good, my tuning is to then have the local site have a metadata repository for the job and a proxy - with the target site having a proxy and the Veeam B&R console. And do the reverse for the other site. Note - there is no additional Veeam cost to have an additional B&R console as such.

GreenEnvy
Influencer
Posts: 21
Liked: 3 times
Joined: Jul 31, 2012 3:45 am
Full Name: Lee
Contact:

Re: Recommended Topology?

Post by GreenEnvy » Oct 17, 2018 1:22 pm

Ok Thanks Rick, we do have the metadata stored locally on source site so I think we're good.

Rick.Vanover
Veeam Software
Posts: 601
Liked: 129 times
Joined: Nov 30, 2010 3:19 pm
Full Name: Rick Vanover
Location: Columbus, Ohio USA
Contact:

Re: Recommended Topology?

Post by Rick.Vanover » Oct 17, 2018 1:30 pm

Cheers, Lee - thanks for bouncing ideas off here!

foggy
Veeam Software
Posts: 18366
Liked: 1575 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Recommended Topology?

Post by foggy » Oct 17, 2018 2:57 pm

Just one point that you should keep in mind in case any of the servers are added to both Veeam B&R instances (for ex., single server acting as a source proxy for one instance and as target proxy for another) - Veeam B&R instances are not aware of the tasks assigned by each other, so plan the load accordingly.

bdufour
Expert
Posts: 199
Liked: 29 times
Joined: Nov 01, 2017 8:52 pm
Full Name: blake dufour
Contact:

Re: Recommended Topology?

Post by bdufour » Oct 17, 2018 5:26 pm

one thing ive thought about - which may not be the case, but would seem to be. if you have two veeam instances running different jobs, if you lose one. would you need to spin up another veeam instance to restore the config too? bc it seems if you restore a config to the other instance you would lose the jobs currently running on that instance. bc i dont see a way to preserve existing jobs, if you restore a config - which may not even be possible. if this is the case - it would make more sense, to have an active/passive setup. as in, one veeam instance running all jobs, and another veeam instance (in another DC/location) not running any jobs, but just a hot spare ready to accept a config backup in the event that you lose a DC or the veeam server in the DC.

Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests