Understanding Proxy Selection

[ccitrano]

Hello,

I've got an environment that has 3 Local Proxy Servers installed. 2 of the servers are just Proxy and the third is a Proxy and the main Veeam Server.

I have two Veeam Backup Repositories located on a SAN. Server1 and Server2 are connected to one each by iSCSI. Server3 does not have a Veeam Backup Repository directly attached to it. All of the Proxies are configured identical with regard to Transport mode, etc. My jobs are all configured with Automatic Proxy Selection.

Can someone comment on my observations and questions:
1. It seems that Server3 gets selected most frequently as the Proxy. I find that a bit odd since the Repository is only reachable via Network. I thought that Server1 and Server2 would be selected first since they have the Repository setup as a local disk. Is there a way to prioritize the proxy selection if all things are equal with regards to load?

2. I thought within a single job that multiple proxies could be utitilized. If I have a job with 50 servers to backup, wouldn't it make sense that all available proxies would be used to increase throughput? Or does the dedup'ing inside of a job require that all VM's within a job pass through the same proxy?

3. How does a proxy communicate to a Repository if the repository is not directly attached to the proxy. Does it use SMB? Or is it some Veeam Process talking to another Veeam Process on the Repository host?

I'm fairly new to Veeam and am trying to optimize the design of my local environment. I need to incorporate Replication next but want to make sure that my on premise setup is functioning smoothly and as intended.

Thanks.
Chuck.

[cag]

I have other odd selections with autoproxy setting. ( The logic is very stupid )

In my situation I have a local proxy/server with a DR Proxy on a slow WAN Link. First job that starts the selection uses local proxy for both the source and target, 2nd job kicks off and selects the DR Proxy for both source and target. Of course this selection is stupid because the WAN link will force the job to take 10x longer than running using 2 jobs on the local proxy. I have force each job to use the local proxy and replication job use the local proxy for source and DR proxy for target.

Since the autoproxy logic doesn't use actual perforamce tests to determine what will work best I have made the decisions.

Bad autoproxy logic.

[dellock6]

One trick to "disable" the Veeam Backup Server acting as a proxy could be to set a specific transport mode like san mode, without any failover to network. In this way the proxy cannot be able to do that job and another one will be choosen.
Maybe another way could be to set manual selection on connected datastores, and than do not pick any datastore. Never tried this one.

Luca.

[foggy]

Chuck, answers below.

1. Proxy selection mechanism has nothing to do with backup repository location. What is really important is proxy's ability to retrieve data from source host using this or that transport mode. You can read about this in detail in the sticky FAQ topic.
2. Within a single job multiple proxies can be used to process different VMs. But all VMs in a job are processed sequentially.
3. If you are talking about Windows or Linux server acting as a repository, then Veeam agent is started on the repository host and data is transferred between agents on proxy and repository. If CIFS share is used as repository, then the agent is started on the proxy itself (or on a target-side proxying server, in case of offsite backup) and writes to the SMB share directly.

[ccitrano]

Foggy,

Thanks for the information. I think I understand the architecture, I'm just trying to tune things to get the most efficient throughput. In my world, all Proxies are configured for HotAdd mode with Network failover. There really is no preference on which one get's selected from a Proxy perspective. I'm just trying to get as many job streams running concurrently as possible. With that said, if everything from a Veeam perspective is quiet and all proxies are idle, I would like the proxies that have Repositories directly connected via iSCSI to be assigned first. It just eliminates any traffic on the data side of my network. I'm not sure if I'm over analyzing things, but a simple proxy preference ranking could help tune things more efficiently when you have more than 1 proxy that supports a given mode.

thanks again.
Chuck.

[foggy]

I understand your point. Thank you for the feedback.

[tqmbill]

foggy,
Is this description still accurate for v9.5? This post is almost 7 years old.

[foggy]

Hi Bill, what description are you asking about? My points regarding proxy selection above are still true except the fact that due to parallel processing functionality that has been introduced later VMs are now processed in parallel. So I suggest you asking some particular questions or describe concerns you have so that we could answer/advise based on the particular case.

[tqmbill]

I'm sorry, foggy... i guess that was pretty vague. Ccitrano had said, "a simple proxy preference ranking could help tune things more efficiently when you have more than 1 proxy that supports a given mode," and you said you understood his point. I guess i was asking whether such a thing had ever been implemented in the intervening years.

I was drawn to this thread because I have 2 virtual and 2 physical proxies, and I'd like to reduce the load on one of the VMs, as it seems to be selected most often. So a way to rank it lower as a preference would have been a possible solution.

[foggy]

Got it. No, there's no ability to set the priorities for the proxy servers, but why can't you just lower the max number of concurrent tasks that can be assigned to that particular proxy?

[f1ref0xy]

dear foggy,

I've found this thread because I got a similar question about proxy automatic detection:

I've deployed serveral proxies in the same network range (Subnet)
My esx cluster is streched on 2 Sides.
one repository on each side.

Backup Jobs are setup like
"siteA -> VMs to repository on side A"
"siteB -> VMs to repsoitroy on side B"


on Backup-Time, if i've selected "automatic detection" it can happen, that proxy from side A (who got ressources free) is used to process a Job on Repository Side B.
so my backup traffic (hotadd) will go over our connection between the 2 sites -> slow.

My workaround:
I've edited all Backup Jobs und selected "manual proxy selection" - so I'm only using proxies on the same "site" - and its working.

my question:
there is also the option to set at repository level "proxy affinity"
if I select "only the follwing backup proxies can access this repository" I should have the same "workaround" like selection proxys manually by job?

[foggy]

Yes, proxy affinity should help in this case.