Optimal use of multi-NIC repository

[TitaniumCoder477]

This scenario is hypothetical and arguably gross, but I'm laying it out precisely in the hopes that I can better understand how multiple NIC usage can be optimized.

Source hosts:
- Three identical VMware hosts with internal storage (not shared)
- Each host has 4 x 1GbE NICs in a single VMware virtual switch
- Each host has a VM assigned as proxy with recommended resources

Repository:
- Rack mount NAS w/ 4 x 1GbE NICs (NOT bonded, each with own IP on same network, i.e. 192.168.1.132 - 135)
- Four shares: Host1Backups, Host2Backups, Host3Backups, and AllHostsCopy

Backup server and config:
- Physical server w/ 16 cores, 32GB RAM, and 4 x 1GbE NICs (NOT bonded, each with own IP on same network)
- Three proxies, one on each host: Host1Proxy, Host2Proxy, and Host3Proxy
- Four repositories:
> \\192.168.1.132\Host1Backups
> \\192.168.1.133\Host2Backups
> \\192.168.1.134\Host3Backups
> \\192.168.1.135\AllHostsCopy
- Three backup jobs: Host1Backup, Host2Backup, and Host3Backup
- One backup copy job: AllHostsCopy

In my understanding, the gateway server will be the proxy that is assigned to the job since the repository, a NAS, does not support the Data Mover Services.

Given this deployment, will each NIC be used exclusively by the job assigned?

Host1Backup = Host1 w/ Host1Proxy (gateway server) > \\192.168.1.132\Host1Backups
Host2Backup = Host2 w/ Host2Proxy (gateway server) > \\192.168.1.133\Host2Backups
Host3Backup = Host3 w/ Host3Proxy (gateway server) > \\192.168.1.134\Host3Backups

I understand the copy job would be a different story altogether, but I am less interested in that outcome.

My reason for asking is because I have found mixed results with NIC teaming/bonding and wonder if this type of deployment would have better results.

[PTide]

Hi,

In my understanding, the gateway server will be the proxy that is assigned to the job since the repository, a NAS, does not support the Data Mover Services

If you want to make sure that each job uses a particular gateway you need to explicitly set the gateway in the repository settings.

How distant is the NAS from the hosts? Also, do you plan to send backups that will be generated by backup copy job somewhere? Because it does not seem to be practical to keep backup copies on the same device with primary backups.

P.S.

have found mixed results with NIC teaming/bonding

Out of curiosity - would you describe you experience and the setup you are referring to?

Thanks

[TitaniumCoder477]

Thanks for that info about specifying the particular gateway in each repository.

In this scenario, the NAS would be in the same network, likely even the same rack, as the production hosts. It would be primary backup storage only. The backups sent to it would be just the standard Veeam backup jobs, except each of the three backup jobs would be configured to exclusively use the matching proxy and matching repository.

My apoologies about the copy job. I could have left that out, as it doesn't really enter into my reasons for this use case. But yes, if it was included, it would be roping in all three backup jobs and sending the data to some offsite location.

Now to the NIC teaming/bonding... So it's apparently often debated, the usefulness of bonding NICs, and how much this really helps. One would think bonding three or four NICs would translate into a wider pipe, more throughput, etc. but apparently this is not how bonding actually works. Apparently the source and targets, even if both ends have bonding in place, only realize a performance increase when multitasking or sending multiple streams at the same time. So with this in mind, I was wondering if it would make more sense to dedicate a single NIC to each job/proxy/repository. That way each one has a 1GbE pipe. Would this result in better performance than a 3 x 1GbE bonded connection which isn't truly 3GbE but rather 1GbE w/ better handling of multiple streams.

[foggy]

Generally, it should also work the way you want even if everything is set to automatic (i.e. each proxy will serve as a gateway for its respective repository). However, you could use proxy affinity settings to achieve what you're after.