Need advice/direction on a new setup

[lrod78]

Hey folks, needed some advice on a new Veeam B&R 9 setup. I've been doing a lot of researching, but I feel like I still need some help/advice with what I have to work with.

Current Setup:
I have 2 VMWare clusters, located at two different locations on our campus that are fiber attached to their own IBM XIV SAN storage. Unfortunately, I don't have any physical servers or won't be able to get any other storage besides this. Both clusters and san are connected to each other via Fiber as well. One cluster is our primary cluster with about 60VMs. The other cluster we use as a secondary cluster that runs secondary VM's(10 VM's atm).

What I'm thinking for a setup is this:
Pri Cluster
-B&R Server
-Proxy 1
-B&R SQL-
Repo Server

Sec Cluster
-Proxy 2

For the Repo Server:
Disk 1 - OS/Installed apps drive
Disk 2 - RDM(Physical) from XIV 1
Disk 3 - RDM(Physical) from XIV 2

I know this isn't recommended, but I don't have any other storage to use atm and I figured with using 1 disk at one location, 1 disk at the other location, I can have the primary storage copied to the 2nd disk, which puts it at a second location, plus I have tape. That would cover the 3-2-1 rule right? 3 copies, 2 locations, 1 offsite. It should all be going through the Fiber network, rather then the Ethernet network, so speed shouldn't be an issue either.

Given what I have available, that should work right? The only thing I'm unsure of is, which is the best way to copy the to the second the XIV, via B&R copy function or use the XIV to replicate over.

If anyone has any ideas or advice, I would really appreciate it.

One additional question, the repo storage, should that be it's own server or should I connect the storage directly to the B&R Proxies?

Thanks in advance.

[DaveWatkins]

If I understand you right, what I would do is this. Have a Proxy in each cluster, have a Repo in each cluster using local storage and replicate your B&R server and SQL server using B&R. Backup VM's in cluster 1 to the Repo hosted on Cluster 2 and vice versa.

From there I'd put it all to tape. I'm not sure I'd worry about backup copy jobs in your case, if you have decent network speed between clusters I'd just push to tape directly from the repo servers.

One thing I'm not sure I follow is you say "fibre network" and "Ethernet Network" like they are different things. A fibre network typically uses ethernet packets so I'm now wondering if your FC SAN's are directly connected with fibre. Also the other question is what speed is the ethernet link between the clusters?

[PTide]

Hi,

Just to make sure we are on the same page:

Both clusters and san are connected to each other via Fiber as well.

Do you have pure FC or FCoE? What are your Ethernet connections, if any? Please describe your infrastructure interconnections.

I can have the primary storage copied to the 2nd disk, which puts it at a second location, plus I have tape. That would cover the 3-2-1 rule right? 3 copies, 2 locations, 1 offsite.

Right, that covers the 3-2-1 rule.

It should all be going through the Fiber network, rather then the Ethernet network, so speed shouldn't be an issue either.<...>One additional question, the repo storage, should that be it's own server or should I connect the storage directly to the B&R Proxies?

You can place proxy and repo on the same machine thus you'll not have to deal with networking between them.

The only thing I'm unsure of is, which is the best way to copy the to the second the XIV, via B&R copy function or use the XIV to replicate over.

I think that Backup Copy Job is more preferrable - it provides flexible management tools + it can perform health checks so in case your source backup has been corrupted it won't go to the secondary location (as it would happen in case you had native inter-SAN replication).

Thank you.

[lrod78]

One thing I'm not sure I follow is you say "fibre network" and "Ethernet Network" like they are different things. A fibre network typically uses ethernet packets so I'm now wondering if your FC SAN's are directly connected with fibre. Also the other question is what speed is the ethernet link between the clusters?

Do you have pure FC or FCoE? What are your Ethernet connections, if any? Please describe your infrastructure interconnections.

Pure FC. For the storage connection the clusters and XIV san are connected to brocade fiber switches.

[VM Cluster 1]-----[Brocade]------------[Brocade]-----[VM Cluster 2]
[ XIV 1]-----------------|(ignorethisjustspace)|-------------------[XIV 2]

The VM Clusters have 10Gbe NICs for connection to the network.

Right, that covers the 3-2-1 rule.

Ok thanks.

You can place proxy and repo on the same machine thus you'll not have to deal with networking between them.

Ok great, was wondering if I could do that, but wasn't exactly sure.

I think that Backup Copy Job is more preferrable - it provides flexible management tools + it can perform health checks so in case your source backup has been corrupted it won't go to the secondary location (as it would happen in case you had native inter-SAN replication)

That's exactly the thing I was worried about, was the replication of bad data with going the inter-SAN route.

[PTide]

May I also ask you why do you want to place B&R SQL on a separate VM?

Thanks.

[lrod78]

May I also ask you why do you want to place B&R SQL on a separate VM?

Thanks.

To be honest, not 100% sure why. Off the top of my head I think it was because I believe we're going to hit the 100+VM count soon and in reading the documentation, the deployment scenario that seemed to fit was the advanced deployment scenario. I guess I got it stuck in my head that meant a separate SQL server since it also meant breaking out the other components. Is there any info on at what point it's recommended that SQL be run on it's own server as to not bog down the B&R server?

[PTide]

Is there any info on at what point it's recommended that SQL be run on it's own server as to not bog down the B&R server?

It's more a matter of resources availability and taste (OS licenses, spare hosts, management habits etc.). You can create one powerful VM and place both SQL and VBR servers on it, just make sure that your VM meets system requirements. Also it will be worth disabling default proxy (VBR), should you choose to place SQL on the same VM with VBR.

Thank you.

[lrod78]

It's more a matter of resources availability and taste (OS licenses, spare hosts, management habits etc.). You can create one powerful VM and place both SQL and VBR servers on it, just make sure that your VM meets system requirements. Also it will be worth disabling default proxy (VBR), should you choose to place SQL on the same VM with VBR.

Thank you.

I will go that route then. As far as the dedicated mount server and interaction proxy, is it a good idea to a specific server for each component?


And once again, thank you very much for your help, I really appreciate it.

[skrause]

To be honest, not 100% sure why. Off the top of my head I think it was because I believe we're going to hit the 100+VM count soon and in reading the documentation, the deployment scenario that seemed to fit was the advanced deployment scenario. I guess I got it stuck in my head that meant a separate SQL server since it also meant breaking out the other components. Is there any info on at what point it's recommended that SQL be run on it's own server as to not bog down the B&R server?

Even using SQL express, we have experienced almost no issues running backups on 150 VMs in 4 different datacenters (jobs running from the same B&R management server). If we start to run into performance problems we will probably just upgrade SQL to standard. The VM running Veeam has 4CPU and 16GB of RAM and has no issues. We do run hot-add proxies and our repository servers separate from our console server.

Honestly, from a "ease of use" as well as performance standpoint, for an infrastructure your size the SQL express database should be fine and even if you are going to go with a full version of SQL, running it on the same machine will be easier to manage.

And as for the location of the B&R server: If you are doing replication, you will want the server running the replication jobs to be in the target location so you can use failover plans without having to first restore the B&R server.