Testing out Veeam WAN Accelerators for VM Replication jobs, have some questions.

[cerberus]

Running VBR10 in PROD and recently added a trial of Enterprise Plus to play with WAN accelerators. I got everything configured according to best practices and running through the initial seed right now.

Using many to one method, 3 WAN accelerator VMs at source so we can run a few jobs in parallel; the one VM at a time per accelerator limitation would not come close to saturating the pipe.

Rundown of the step:

50 VMs with under 20TB of VM data
VMware 6.7, thin allocated VMDKs
Microsoft heavy shop, Win2016/2019 with SQL and Exchange
Coast-to-Coast 50mbps MPLS (80-100ms latency)

We are doing reverse incremental B2D2T daily backup, enabled with CBT/fast-clone/san mode on SSD ReFS repository; makes for a very fast B2D process and air-gapped tapes always have full backup.

VM Replication jobs configured to pull from backup files instead of production (this is an amazing feature!!), to reduce load on production cluster and avoid long snapshots on VMs during initial seed.

Using the many to one model, 3 accelerators at source and 1 accelerator at destination.

Each source accelerator VM is configured with 2vCPU, 8GB RAM, and 100GB disk (ssd); 20gb cache size
Destination accelerator VM configured with 8vCPU, 64GB RAM, 1TB disk (ssd); 250GB cache size configured (250x3 source accelerators = 750GB total for cache)

Couple of questions...

For the source WAN accelerators, when adding these to Veeam it tries to set 100GB for cache (default). According to best practice the source does not use this cache. In this case, where does the digest overhead go... into the "free space"? Should one then reduce source cache space to zero to allow for more free space to be used for digests?

Are there any reporting other than the job logs to see how effective the WAN accelerators are, or how well sized our global cache and digest space is? Perhaps something in Veeam ONE?

How does one know if replication would benefit from increased disk space at both source and destination accelerators?

Any new features or enhancements in V11 that improve on the VM Replication jobs and/or WAN acceleration process?

What is the technical reason to cap the source WAN accelerator to process VMs one by one, why can't this be a parallel process if B2D is set for per-VM backup files?

[Gostev]

1. Digests are created in the same folder used for cache. The size of the cache you set will have no impact on the source WAN accelerators behavior, so there's not point in adjusting it.
2. When WAN accelerators are used, jobs will provide some additional efficiency information directly in the action log.
3. In general there are very diminishing returns from increasing cache size, so I personally would not go in this direction.
4. Not really. V10 was a big release for WAN accelerators.
5. There's simply no point, you will see that even a single VM easily caps the processing engine, as it is a very math-heavy process. Adding concurrency will only make the overall performance worse, because now multiple such processes will share the already limited CPU L1/L2/L3 caches, leading to reduced overall performance.

[cerberus]

Thanks for the details Gostev.

Some follow up to this, in particular for #1 and #5.

For the source WAN accelerator, if size of cache has no impact then I can essentially set this to zero so that no cache is reserved at source? This won't affect the digest cache as I guess that uses whatever free space is available on the drive that the VeeamWAN folder is on correct?



On the last point, you are talking about the processing engine on the WAN accelerator VMs or the data mover process on the backup server where the repository is? I suspect the former and this is why the many-to-one model exists?

[Gostev]

I don't know how the product will behave if you set it to zero, most likely UI will not allow this, but it should be safe to reduce this value to some small amount.

I'm talking about the Source WAN Accelerator component, this is the one that does the heavy lifting. The target WAN accelerator, as well and all other backup infrastructure components can process multiple tasks concurrently.

[cerberus]

Sounds good, thanks for the info Gostev!