I'd like your thoughts on the below server and B&R config.
The production environment is a 2-node system running vSphere Essentials Plus as a 2-node cluster. The shared storage is a 10G iSCSI SAN running StarWind "VSAN for VMware", using pure SSD storage. The vsphere cluster nodes connect to the iSCSI SAN via 10G NICs.
The backup appliance is a third machine running ESXi and running a single Veeam VM. It also has 10G NICs, oodles or RAM and CPU. It stores daytime backups to local HDD storage and ships off nightly retention backups to separate iSCSI storage and also to CloudConnect.
Ideally I would use direct SAN transport to pull backup data from the SAN to the backup appliance. Unfortunately I cannot do that in this case because the SAN software allows iSCSI connections from vmware only, and not from a Windows B&R proxy. So my next preference is to use a hot-add proxy.
Using the hot-add proxy I can pull backup data from the SAN at up to 800MBytes/sec. The SAN seems capable of dishing up data at this speed without impacting the actual SAN latency significantly. However a problem is that if the hot-add proxy is running on one of the vSphere cluster hosts it pulls all that data through the iSCSI NICs and initiator on that host, and the production VMs on that host suffer a nasty performance hit (the VMs running on the other host do see a latency increase but it's not enough to start users complaining).
So, my thinking is to use a hot-add proxy on the Veeam backup appliance. This gives me a data path similar to what I'd have if I was using SAN access mode, that is the data flows from the SAN straight to the backup appliance. The only issue I see with this is that it's not sufficient for the backup appliance to have an iSCSI connection to the SAN. It also needs to be a part of the vSphere cluster. vSphere essentials allows up to three clustered hosts so it's not a problem right now to add the backup appliance to the cluster, although if the site later needs a third compute node I'd have a problem.
I'd appreciate any and all thoughts

Thanks,
Steve