VSAN data path query

[pkelly_sts]

I'm embarking on my first VSAN (VxRail) 4-node deployment whereas previously I've worked on FC SAN based VMFS storage so am trying to understand the differences from a backup architecture.

Previously I'd deploy a physical server with a decent amount of cores (24 I think last time)/memory/JBOD disks, give it read-only access to the VMFS LUNs over FC. This would hold the repository server, proxy, tape server & WAN-X roles, & configure the repositories with a concurrency of around 12 each (from memory).

I'd then add a single Veeam Proxy VM on each host with 6 cores, on the basis that it's running mostly at night so little resource contention, and these would be direct-attach capable, but the backfill backups they performed would always be sent to the repository server over the LAN - I configured a dedicated portgroup/pNICs for this network.

Switching to VSAN (all-flash) I'm guessing a physical repository server won't/can't have direct-attach access any more so there's less justification for configuring it as a proxy any more but rather the proxy load now shifts more to the proxy VMs, which would then also send their backups to the repository server over ethernet again (albeit 10G now rather than 1G previously).

So, it seem to me the proxy VMs would want to be beefier this time around as they'll now be doing the grunt of the work rather than the backfill, or am I missing anything significant?

[Egor Yakovlev]

Greetings Paul!

You are totally right, since main idea of vSAN is to get away from managing underlying storage devices, Veeam will utilize so called Virtual Appliance(or sometimes Hot-Add) transport mode. That mode requires a Proxy role on a VM within vSAN cluster(note that Proxy VM disks shall be sitting on a vSAN alongside protected VMs). Ideally, you want to have a Proxy Server per ESXi node within a cluster and make sure to configure DRS affinity\anti-affinity rules, so that Proxy VMs will not stack up on certain host within a cluster.

When backup starts, Veeam will check which ESXi node local storage has most of data blocks belonging to protected VM, and will pick a proxy on that ESXi host to process it - that will reduce networking load between hosts in a vSAN cluster during the backup.

In terms of Proxy resources, its a question of load and it depends on many factors - amount of jobs you run in parallel, amount of VMs within a job, amount of disks per VM so on. Feel free to read up on Best Practices for Proxy sizing here.

/Cheers!