Wan Accelerator Questions

[salyerma]

Just a couple of quick questions over Wan Acceleration.

A) If a person has a dedicated 100mb connection, does Wan Acceleration make sense?
B) I know that "virtual" wan accelerators are supported, but everything I read said dedicated SSD's. Does virtual wan accelerators make sense as well?

I have a dedicated 100mb connection but I am not seeing a speed increase testing a couple of virtual wan accelerators. In fact, it seems to slow down. I can do some tweaking, but is it worth the effort.

Thanks

[foggy]

Hi Mark, starting v10, Veeam B&R can operate in different modes based on the available bandwidth. In your testing, have you tried High bandwidth mode?

[salyerma]

You know, I have and it is not doing much better, but I have never seen that document before. I have done a ton of google searching for best practices and have not seen that one. I will go over it with a fine tooth comb and see if I am missing anything. Thanks.

[foggy]

Looking at the most typical bottleneck for your WAN accelerated jobs should help to find the parts of the processing chain that should be optimized first.

[salyerma]

So the jobs show Source WAN, but only 1%. But I am getting very slow replications. So next I have a different question.

We are setup like this:

Site A: Main VEEAM Server with SAS for local backups.
Site B: Secondary HP Store Once.

We are trying to Backup Copy the local backups on the main Veeam server stored on the SAS drives to Site B.

If I do WAN accelerators it goes like this Main Server --> Site A WAN --> 100mb --> Site B WAN --> Site B Gateway --> Store Once.

Would that not be less efficient due to the fact that it has to copy everything across the wan without getting the benefit of Data Deduplication of the StoreOnce's. Watching the job log, it seems to be copying most everything. Would I be better off doing direct so that data dedup comes into play?

[foggy]

So the jobs show Source WAN, but only 1%. But I am getting very slow replications.

Is it with Low or High bandwidth mode (note that to use the High bandwidth mode, you must configure it on both source and target)? High bandwidth mode puts more load on the source WAN.

Would I be better off doing direct so that data dedup comes into play?

Data is deduped while being written to the storage. If you want to use source-side StoreOnce dedupliction with the gateway located on source, then WAN acceleration is not an option.

In case of a slow connection between the gateway and the storage you could also use the corresponding repository setting for data compression over this link.

[salyerma]

Thanks for the response. So as I understand it, if data is deduped when written to storage, then in the case of a dedupe appliance, the entire backup will be sent from Source Wan Accel, to Destination WAN Accel with dedupe happening at the destination. So in the case of a dedupe appliance at the destination, you really want to use direct instead of wan acceleration so that dedupe happens between the source Site and destination Site.

That's not to say that WAN Accelerators dont do some dedupe, but the *entire* backup gets presented to the Dedupe appliance from the destination Accelerator so that it can store it correct?

Oh, and I am using high bandwidth and inline deduplication was already selected.

[foggy]

It is not the entire backup as you're sending just the changes anyway.

[salyerma]

<It is not the entire backup as you're sending just the changes anyway.>

Right, but there is no dedupe between wan accelerators, just between the destination accelerator and the storeonce. I have a lot of daily changes that need to get replicated, but I am struggling getting them replicated. Once Catalyst replication of backup copy jobs is supported, I will go that route, but I am trying to find the best option to get the best performance.

If I do wan accelerators, then I loose the performance of using catalyst copy which takes more data off the network. With WAN acclerators, the major dedupe happens after the transfer across the WAN. That is what I am trying to confirm or get advice from people who have this setup and found the best way to do it.

[salyerma]

So I found a *new* document by HP that showed setup examples using Veeam 10 and a storeonce. Basically it stated that if you had a remote Storeonce the preference in order:

Veeam Catalyst Copy Job (waiting on support for Backup Copy Jobs)
Veeam direct to Storage (using catalyst)
Veeam Wan Acclerator
Veeam direct (no catalyst)

What I learned is, when you setup the remote Storeonce as a storage repository in Veeam do *not* select auto for the gateway, make sure you select a gateway *at the source* so that Catalyst is used across the WAN. I had picked a gateway at the destination site, so Catalyst was not used. In effect, I was using the bottom option on that list.

I fixed my settings to match what HP had, and I have finished in 4 hours what had been running since Saturday.

Things seem to be better for me. Now when I can upgrade to get Backup Copy Jobs supported in a Catalyst Copy Job, I will be flying.

Thanks!

[foggy]

Catalyst Copy is indeed the preferred approach as it sends only the blocks that don't exist on the target array and avoids additional hops that involve Veeam data movers, sending the data directly between the Catalyst Stores. Support for backup copy jobs as a source in Catalyst Copy jobs is coming in v11.

[JannieH]

Might not be your issue, but for whoever else reads this thread: Something that caught me the first time I used WAN accelerator is that I underestimated the amount of disk space at the *source* side required for digests.

The thing that threw me was that Veeam B&R (at least in 9.5) seems to fail "safely" when there is insufficient disk space for digests - if it runs out of space it throws away older digests and recalculates digests for the server being replicated. This can take *forever*, and results in a lot of "dead" time during replication, as WAN accelerator causes VMs in a replication job to be processed serially.

So if your replication is slow and you're *always* seeing "calculating digests" in the status for every single replication job, it probably means you've run out of space on the disk that holds the digests.

Also make sure you always replicate the same set of VMs over the same *source* WAN accelerator, to ensure that you don't have the same digests being calculated by different WAN accelerators, which would be a waste of time.

For reference: https://helpcenter.veeam.com/docs/backu ... ml?ver=100
* For low-bandwidth mode, digest size is 2% of the total provisioned size of all VMs being replicated by that WAN accelerator.
* For high-bandwidth mode, digest size is 1% of the total provisioned size of all VMs being replicated by that WAN accelerator.

(PS: SSD is only recommended for the *target* WAN accelerator, for storage of the Global Cache. Global cache is not used in high bandwidth mode. Also, the amount of SSD recommended seems to be ~100GB, and any reasonably performant disk should do: "It depends", but if you put it on a handful of SATA disks with no r/w cache you will probably not have a good experience.)

[mrholm]

Hi
Just want to comment on the setup with having the Gateway at source and the StoreOnce at target and do a Catalyst Copy using Veeam. We had this setup initially but changed to use WAN and setting a local Gateway at target close to the SToreOnce. This du eto the fact that when cretaing the GFS point sit took forever for the Gateway at source to read data from the StoreOnce at target.
This is true fr Data Domain as well. Setting it up with WAN accelerator between the sites and add the SToreOnce Gateway locaaly on same site as the StoreOnce might take longer for the single copy jobs but it will speed up the GFS creation.

//Mats

[foggy]

Hi Mats, what was your setup in this case, seems you had both Catalyst Copy jobs and regular backup copy jobs to the same device (as you mention GFS, which is not available in Catalyst Copy jobs)?

[mrholm]

We did not have any Catalys Copy we used only Backup Copy from Veeam, sorry for my mis-writing

[foggy]

Ok, got it. In this case though gateway located on source shouldn't read the entire backup data from the target as data processing during GFS is just a metadata update operation performed right on the storage (virtual synthetics).