Physical & Virtual Proxy on same subnet problem

[lars@norstat.no]

I have a physical machine that is my main Veeam server where the console runs, this machine also have direct FC SAN access to both source and target SAN's.

Then i have 4 virtual Veeam Proxy's that i will use to get more CPU power to load balance my replication jobs ...

The problem is that when set to automatic so that each job will choose an available server each time a job runs the physical server collects data via Direct SAN and then transfers the data to one of the proxy's to be written as hot add mode instead of just writing the data itself.

How can i fix this so that when the physical machine does a job it writes the data itself with NBD. And when one of the Proxy's does a job it collects itself with hotadd and writes itself with hotadd ?

Both physical and virtual machines are on the same subnet and in the same room

[Gostev]

Don't use automatic selection, and force the job to use the specific target proxy (your physical proxy)?

[foggy]

Lars, if Automatic proxy selection is used, Veeam B&R selects the most efficient proxy automatically. Hotadd is more preferable transport method to write data than NBD, so the proxy capable of hotadd is selected, if available. You can, however, explicitly specify the pair of proxies for the particular job in its settings, as Anton suggested.

[lars@norstat.no]

This is not a good choice. There is a lot more job setting specific proxy's on each job when i have to set up about 90 different replication jobs. If i do it that way i also have to know which of the jobs are going to run at the same time so that all proxy servers are used efficiently, this is unknowable with 90 continuous replication jobs.

Hotadd is the not the most efficient way to write data if all jobs have to go through the same physical server first.

P.s i will off course add ALOT more proxys to handle the load before i go to 90 jobs, the 4 i have now is to test the concept only.

P.s.s There is also a lot of servers and replication jobs i know, but there is not much changed data each time. The only important thing is that they are replicated as often as possible ....

[Gostev]

You can select more than one backup proxy in each job (all your future physical backup proxies), and the job will load-balance between them.

However, if you have to keep the data within the specific proxy, then you have to select that specific proxy. But, even in this case, you don't have to plan around concurrency per proxy, as Veeam will automatically maintain the desired job concurrency on each proxy for you (other jobs set to use the same proxy will be waiting for an available slot).

I will keep in mind your request though (to have "same as source proxy" option for the target proxy) for the future releases, and we will add this capability if there is sufficient amount of requests. Don't know if this will be a common request though, since most replications are done over LAN or WAN.

[lars@norstat.no]

Ok, yes i know i would be able to choose all my virtual proxy's and then all jobs would use those. There are several problems with that solution:

Every time i got a new virtual proxy i would go into each job and add those, that is to much for 90 replication jobs. This is in part because the GUI for Veeam is extremely slow opening a job and letting you change things, but also because i can't choose to change one parameter for all jobs at the same time.

Second, with this approach i would only be able to use either physical servers or virtual and not both ... Let's say you have 5 physical machines and 5 virtual and you would like to use CPU resources on both ... You would not be able to do that because this approach limits the automatic feature.

Although a little bit off topic ... If there was an option to set up ONE big job with all 90 machines (which it is) AND be able to run several replications inside that job at the same time (which there is not) then the task of changing parameters in that one job would not be much of a job ..... Although i would see how difficult it would be to run the same job at several different machines at the same time ...

[Gostev]

Actually, you can easily upgrade 90 jobs at once with a PowerShell script. Also, version 6.1 is actually much faster opening a job anyway. But I see your point.

[lars@norstat.no]

Ahh, ok i will look into Powershell possibilities and do another round on how i can set this up. Thnx for now ...